需求管理是产品经理日常工作中很重要的一环。今天阿G就结合自己的一些工作体会，和大家聊聊这个话题。
我把需求管理拆分成这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. 市场环境/公司战略变更
这种不可抗力的因素，我们产品经理能做的就很少了，只能走一步看一步。
