B端产品思考（二）：需求管理指南

我把需求管理拆分成这6个部分：需求收集、建立需求池、需求分析、需求反馈(需求排期)、需求跟进、需求变更。

需求收集

1. 需求来源

我把B端产品的需求来源，总结成3个维度。

1）内部需求：公司内部的需求

• 业务方/运营/技术等公司同事的业务需求
• 相关系统的配合需求

2）外部需求：公司外部的需求

• 客户调研/竞品分析
• 市场动态

3）自创需求：产品经理自己YY的需求

• 头脑风暴/灵光乍现
• 产品规划

2. 收集手段

工具的话，这里推荐我偶像苏杰老师的需求采集「Z」。

苏杰老师的「Z」模型

虽然这个工具表面看起来比较适合C端产品，但万变不离其宗，其核心思想我们完全可以移植到B端产品上。

具体可以自行搜索，这里就不过多赘述了。

我结合上面需求来源，再讲讲实际工作中每个维度有哪些收集的手段。

1）内部需求：业务反馈、头脑风暴

通常业务方有需求会及时的向你反馈（有时候会多到数不清……下面会讲如何做需求过滤），毕竟业务同学也希望尽量通过系统解决不必要或重复的人工。

2）外部需求：调查问卷、客户访谈、客户反馈

如果你做的B端产品是带有商业化属性，那么很多需求都会来自甲方爸爸。这个时候定期的客户访谈、调查问卷就必不可少了。

当然，作为一名合格的产品经理，不应该整天坐在电脑前等着别人来反馈需求。我们应该更主动、更积极去沟通，去调研，去挖掘需求，这样才能得到更快的成长。

3）自创需求：有些时候我们也会通过：数据分析、经验总结，去自创需求。

建立需求池

收集了很多需求后，就需要建立需求池来管理这些需求。接下来我们就一起重新认识需求池。

1. 工具

一般我们使用Excel、禅道、JIRA等工具来建立需求池。

2. 使用原则

• 宽进严出：收集大量的需求，但要严格的过滤需求
• 定期整理
• 平衡ROI（工作量与效率、资源评估）

3. 包含信息

通常建立需求池时，需要包含以下信息：（*为必填项）

• 需求编号：按团队的习惯，在需求录入时给一个编号
• *提出人：谁提的需求，方便产品经理做需求调研和上线前的验收找到关键人
• 提出时间：需求的提出时间
• 需求名称：根据需求内容取名，方便团队信息传递
• *场景描述：调研并记录需求的真实场景
• *价值点：完成需求可以带来的价值
• 所属模块：根据系统实际模块来划分
• 协作系统：需求需要对接到的系统
• *分类：按照需求内容来划分
  • 新增功能
  • 优化功能
  • 修复BUG
  • 升级体验
  • 其他
• *优先级：根据需求内容和产品规划来划分，P0最高，P3最低
  • P0
  • P1
  • P2
  • P3
• *状态：根据需求进度划分
  • 待调研：未接收或仅接收了需求，还没进行调研
  • 待评审：通过需求调研并产出了原型和PRD，但还没通过需求评审
  • 待开发：通过需求评审，但仍未进入开发阶段
  • 待测试：开发完成，但还没进行SIT
  • 待验收：通过SIT，但还没进行UAT
  • 已上线：通过UAT上线试运行
  • 已拒绝：需求没有真实场景或者无法完成
  • 已暂缓：现阶段需求的优先级低
• 进度：当前需求的进度（延迟时需要在备注填写原因）
  • 正常
  • 延迟
  • 超前
• 上线时间：需求上线的实际时间
• *版本：V大版本号.中版本号.小版本号，例如V1.0.0
  • 大版本号：产品发生了重要变化、例如产品定位/方向调整
  • 中版本号：添加新功能/删除现有功能，或一些比较重大的功能优化
  • 小版本号：较小的功能优化、体验升级，或BUG修复
• 备注：需求额外的补充信息

需求池模板截图

公众号私信发送「需求池」，免费领需求池模板

4. 分类

在大一点的产品团队里面，有时候是多个产品经理负责同一个产品/产品线，这时就要把需求池划分为：个人需求池、团队需求池。

原则上个人需求池是为团队需求池服务的。

需求分析

需求收集完，也建立好需求池，接下来就是重头戏：需求分析。

而需求分析的第一步，就是根据需求内容的必要性、合理性、完整性、可行性去筛选、过滤。

1. 需求过滤

根据工作经验，我总结出3大需要过滤的需求：

1）不用处理的需求：一般这种需求，都有以下3点明显的特征

• 被现实表象欺骗

  

• 已有更好的替代方案或已有类似功能

  实在没有开发资源，且数据量不大的情况下，做报表功能不如产品经理帮业务/客户手动导出Excel表格。

• “我认为”、“我觉得”、“应该是”……张口就来

2）不合理的需求

例如OA流程，某些业务方要求上线自动审批。这个需求咋听好像可以提升业务方的工作效率，其实非常不合理。

自动审批是否意味着这些节点可以不用出现在流程上？如果需要查看流程内容，直接将审批节点换成抄送节点即可。

我们不能被业务/客户带着走，得时刻“提防”着他们，要想清楚需求内容和现实业务指标是否匹配，区分。

想要的 和 需要的

应该做 和 可以做

3）非体现本质的需求

最经典的就是那句“想要更快的一匹马”。

在实际工作中，有很多需求方自以为懂产品、懂研发，就会直接和你说这里要怎么做、应该这样做、做这个功能就行了……

我们绝对不能照着做，只需要用心去倾听需求，然后用自己的专业能力把业务需求转化成产品需求。

一定要学习如何透过现象看本质（听起来挺玄乎的，但真的得这么做），不然你永远都不知道，业务/客户提的需求下面暗藏了什么……

2. 鉴别伪需求

上面讲了这么多种需要过滤的伪需求，那在实际工作中，我们应该如何去鉴别那些没有真实使用场景的伪需求呢？

在这里给大家介绍一个工具：5W1H。

1）WHO：场景中都有哪些角色参与

2）WHEN：在什么时间点发生

3）WHERE：在哪种场景下发生

4）WHY：需求的背景和动机

5）WHAT：需求方表达的需求是什么（他们到底要什么）

总结一句话：谁，在什么时候，什么场景下，为了达到什么目的（获得什么收益），干了什么事情。

3. 需求分类

通过前面两步，我们就可以筛选出合适的需求，那需求分析就算完了吗？

不，还差最后一步：需求分类。

我们可以用「重要紧急四象限」这个工具，结合实际的投入产出比来做分类。

（B端产品不建议使用KANO模型，收效甚微）

1）重要紧急：马上做，例如线上BUG

2）重要不紧急：未来做，制定版本迭代，例如

3）不重要紧急：下次做，

4）不重要不紧急：不做，同时反思一下自己，为什么经过前面两步之后，还有这种需求进入需求池。

需求反馈（需求排期）

接到需求，并且做完需求分析后，我们要尽快告诉提需求者结果，给人留下“件件有着落，事事有回音”的好印象，毕竟产品经理是很需要在团队中构建影响力的。

根据刚才的需求分类，如果是重要紧急的需求，那么就应该将需求分析的结果（最好附上原型）以文档的形式和提需求者确认。

B端产品一般需要和业务/客户确认的内容：

• 需求范围
• 需求的优先级
• 业务流程（每个节点的角色、活动、流转规则、涉及系统、异常情况）
• 需求的解决方案

如果不需要再修改，那么最好以邮件的形式再正式确认一遍，甚至是可以打印出来让对方确认签字，避免日后背锅。

需求跟进

正式确认需求后，我们要做的就是需求跟进，一般分为以下几点：

1. 需求评审

如何做好一场完美的需求评审，其实是一件很有技术的工作。

首先我们写完文档后，不要着急约会议室、约人来做需求评审，那样大概率你会被各种人怼到怀疑人生。

应该先把文档初稿，拿给上级领导看一下，让他帮你做一些修改。

接着约上业务方，过一遍需求方案。

然后约上关键研发人员，对一下里面的需求逻辑。

这样一套组合拳下来，基本会议开始前，需求就已经和大部分关键干系人达成了共识。除了能少挨怼，还能提升会议效率，何乐不为？

2. 需求开发

终于通过需求评审，终于通过立项，你以为熬出头了？

呵呵，开发阶段作为产品经理也是需要时刻关注的。

研发过程中会有很多小细节，在需求评审时大家没发现，所以我们需要时刻准备着为开发同学做需求解释、需求澄清，消除信息不对称。

3. 需求测试/验收/上线

千呼万唤，需求终于做完了，这时我们还需要充当测试同学的小助手，帮他完成测试。

有时还要写用户操作手册，在需求验收阶段培训业务方。

在上线阶段做开发、运维同学的秘书，帮他们检查上线清单是否有某项遗漏。

4. 效果监控

上线之后，我们仍然不能掉以轻心。要通过埋点数据，看用户行为和业务效果是否达到预期，然后做下一轮的迭代计划。

需求变更

到目前为止，一切都很顺利。但是，实际工作中，一定会出现让人闻风丧胆的需求变更。

说实话，不管需求分析阶段做的多严谨，需求文档写得多完美，需求变更通常是逃不掉的。

根据工作情况，我总结了需求变更出现的几点原因：

1. 产品方案有问题

产品经理的锅，别说客户的需求提供不完整，在需求分析阶段没有发现问题就只能让产品背锅。

解决办法：可以尝试使用MECE原则（相互独立，可以穷举），将业务流程每个节点的异常情况都考虑进去。

2. 开发/技术方案有问题

系统的架构不具备低耦合、高可用的特性，在后期维护就比较容易出问题。

解决办法：在系统建设初期就要考虑后期扩展；或者后期维护时，定期抽出一些时间来做重构（内部B端产品更应该如此）。

3. 业务/客户变更

这点真的是避免不了的，不管前期说得多好，想变的时候他们绝不手软。

解决办法：这时候就体现刚才需求确认的重要性了。同时也要提高需求变更的门槛，让爸爸们不敢轻易变更需求。

比如说加钱、项目延期等等，抓住他们现在最关心的痛点去说。

4. 市场环境/公司战略变更

这种不可抗力的因素，我们产品经理能做的就很少了，只能走一步看一步。