编辑导读：需求，是戴在每一个产品经理头上的紧箍咒。产品经理每天要面对大量的需求，建立需求管理机制能够帮助产品经理更好地工作。本文作者对此进行了分析，希望对你有帮助。
产品经理每天都需要面对大量需求，很多朋友会通过“需求池”对零散需求进行统一、高效、有序的管理。但需求池只是需求呈现的载体和工具，并不能包治百病，实际操作中会出现各种意外，比如：
- 无效的需求记录：不是指需求记录的不清晰，而是指明显不符合产品定位、场景不明确的需求未经筛选就被记录。
- 超量的高优先级：需求方都认为自己的需求更重要更紧急。面对多方的各种催促，出现了大量高级别需求，导致等级制度失效。
- 短视的版本规划：将迭代周期内的需求塞满即可。把需求、设计、上线做成了下意识的循环，缺乏产品整体层面的发展规划。
为了避免需求管理的效果打折扣，接下来根据需求的流转，依次讲解需求处理过程的管控要点。
01 需求的有效采集和过滤
需求是产品的源头，产品是需求的解决方案。所以，有效采集需求是需求管理的第一步。虽然每个产品所处的环境存在差异，但是为了不在需求阶段迷失其中，需要从全局角度对需求来源、采集方法、需求筛选（初步）有整体的认知，便于后续对不同需求采取更合适的应对策略。
1. 需求获取渠道
不同产品的适用场景和使用角色都不一样，造成了需求来源较为复杂的现象。可以通过渠道通用属性的方式进行分类。
分类目的在于全面了解产品的相关方，避免遗漏。毕竟不是每个角色都会主动反馈问题和需求，更多情况下需要产品经理主动沟通和挖掘。产品经理不要忘记“沉默的大多数”。
渠道分类的维度也多有不同，本文以内外渠道区分为例：
- 内部同事：组织内任何和产品相关的角色都有提建议的权利。比如：Boss、销售、运营、技术等。
- 外部客户：客户通过对应渠道反馈产品需求或问题。在项目中客户也区分决策人、使用人等多种角色。
- 产品经理：基于对产品、用户、发展战略的观察、分析等行为，进而得出需求。
2. 需求采集方法
需求获取的方法是多样的，有的是产品经理通过设计进行获取，有的是客户主动进行反馈。具体方法如下：
- 产品方获取：由产品方主动获取需求的方式。如：行业研究、调研问卷、实习轮岗、数据分析、现场访谈……（详见：B端需求调研：客户访谈操作详解）
- 客户方反馈：由客户方主动反馈需求或问题的方式。如：客服咨询、用户投诉、意见建议、公开渠道的评价（微博、垂直社交媒体……）
客户主动反馈时，产品经理并不能改变采集方式。针对产品经理主动获取情况下，采集方式应当如何选择？我们知道每种方法各有优劣，要结合实际情况灵活选用。影响选择的关键因素有哪些呢？我认为至少考虑以下3方面：
- 用户是否接受此方式？面向不同角色，或同一角色的不同场合。用户对各方式的接收程度都是不一样的。有时我们希望面谈，但客户总是没时间……
- 资源是否支持此方式？公司的时间、人力等资源都是有限的，产品经理需要在合理资源限度内完成采集。比如实习轮岗，可以较深入的了解现场，但耗时太长，通常采用的比较少。
- 能否达到采集的目的和效果？如果调研后没有达到目标，意味着采集无效以及投入资源的浪费。
3. 需求初步筛选
通过各个渠道获取需求后，就进入的记录阶段。会发现需求总是源源不断的过来，但是产品经理的精力以及公司的资源都是有限的。所以要辨别需求的真伪和潜在价值，把不符合要求的需求剔除，不计入该产品的需求池中，避免后续资源的无效投入。
筛选的过程是“砍需求”的过程，是对需求潜在价值判断的过程。除了要对产品本身有所了解，也需要专业能力的支撑才能更加准确的判断。事实上，从需求收集到研发上线之间会经过多次“砍需求”。
此时作为初步筛选，要求并不严格。只需要做2件事：需求场景还原，需求属性分类。
1）需求场景还原
需求有对应的完整场景是筛选的第一步，如果还原不了场景，则认为需求是假需求。场景还原只需要问几个问题，能回答出来且逻辑自洽即可——谁（角色）在什么情况（背景）下，遇到了什么问题（需求）？当前的处理方法是什么？
场景还原时需要将相关的场景进行穷举，避免因场景遗漏导致后续产品设计时出现漏洞。
需要注意的是，有的需求场景还原完整，但不符合本产品定位，此类需求对本产品无价值，但需求本身没问题。建议记录在另一张需求池表单中，作为外延产品的需求储备。
2）需求属性分类
除了需求基本的信息记录，还要判断需求的类型，为后续的需求评级和需求分析提供支持。比如：核心需求，基础需求，衍生需求，技术需求，运营需求，体验需求……
需求分类同样没有标准答案，存在多种维度的分类方式。重点在于你定义的需求类型，在后续分析中是否存在对应行动策略，如果仅作为需求池的统计查看使用，意义不大。
存在潜在价值的需求将被一一记录在需求池中，等待下一轮的筛选和价值分析，直到被某个版本选中……
02 优先级的制定和维护
初步过滤可以把部分需求排除在外，剩余需求将被纳入到需求池中。至于选择哪些需求进入实现阶段，则根据需求的优先级来排序。每个团队都应该有自己的优先级评估标准——你的优先级评估标准是什么？评估标准又是怎么维护的？
1. 区分需求所属类型
在制定具体的优先级规则之前要先区分需求类别，不同类型的等级制定策略存在差异。可以基于“产品管理权”和“需求确定性”来划分需求类型。
1）基于“产品管理权”划分
在公司内部，一款产品的管理权限通常是由多个角色共同组成。不仅有产品经理，还有运营、上级领导等其他角色也具备管理权。
- 响应性需求：对应角色行使自己对产品的管理权限，产品经理没有拒绝的权利，根据具体要求排期和执行即可。比如运营同事策划了一场活动，需要在产品中实现。此时产品经理没有拒绝的权利，只要建议的权利。
- 自主性需求：当产品经理在处理自己管理模块内的需求时，其他角色也不能拒绝（领导可以拒绝）。其他人同样可以提供建议。并不是要产品经理刚愎自用。
2）基于“需求确定性”划分
针对自主性需求也要区别对待，首先是判断需求实现结果的可控性，面对可控和失控的需求要制定不同的策略来应对。
- 不确定需求：对需求实现的结果预测精准度过低，不具备参考价值。常见于全新业务情况，没有过往数据和历史经验作为参考。面对此类需求通常采取MVP策略。
- 确定性需求：对需求实现的结果预测相对准确的，可以将需求代入制定好的优先级等级，进而找到优先级顺序。（本文针对此类需求的优先级进行讲解）
2. 制定优先级标准
优先级标准是判断各需求实现先后的依据。比如Bug优先还是需求优先，实际上当然不会如此粗犷。可以用常见的重要紧急程度、KANO模型等方法帮助我们建立和细化等级标准。
1）重要程度：以产品目标为中心
假设有2个需求，实现需求A可以带来新用户10000人，实现需求B可以提高活跃用户10000人。可使用的资源有限，只能实现1个需求。你会选择那个需求实现呢？选择依据是什么？
需求重要程度的判断依据是“产品目标”，契合产品目标的需求就是重要的需求，偏离产品目标的，不论能够带来多大的收益，都不能称之为重要。
产品目标是根据公司战略、产品定位、发展规划、领导决策、用户反馈（KANO模型 – 期望型需求）等综合因素制定的。产品目标落实到执行层面，会反应在某项数据指标的变化上。比如：产品/某活动/某功能的拉新；产品/某功能的促活；某环节/某功能模块转化；商业化指标……
需要注意区分用户目标和产品目标。提升效率、降低成本、优化体验等以用户视角提出的诉求都是用户目标。需要把用户目标转化转为为产品目标。比如，在满足了提升效率的用户目标后，会达成产品目标数据指标A的变化。
2）紧急程度：以严重程度为中心
假设产品目标是提升拉新数据，现在有2个需求，需求A可以带来新用户10000人，需求B会带来新用户1000人。可使用的资源有限，只能处理其中1个。你认为那个更紧急呢？
很显然，多个需求都满足产品目标时，效果越好的越优先（紧急）。
假设产品目标是提升拉新数据，现在有1个需求和1个Bug，需求可以带来新用户10000人，Bug会造成流失用户5000人。可使用的资源有限，只能处理其中1个。你认为那个更紧急呢？
处理Bug时不考虑产品目标（重要程度），只考虑紧急程度。把需求和Bug的紧急程度放一起对比，之后再根据各自评估的严重程度来决定先后顺序。通常采用如下的紧急程度标准：
P1：处理需求，获得良好的正面效果
P2：处理Bug ，避免持续的严重损失
P3：处理需求，获得一定的正面效果
P4：处理Bug ，避免持续的轻微损失
3）其他代价：关联指标的变动
经过重要紧急程度的筛选，我们可以得到重要（符合产品目标）的需求和Bug，并根据紧急程度进行排序。实际操作中还需要注意需求实现后的其他代价！
这里的代价不是指实现需求的成本，而是指需求实现后对产品目标之外的其他数据的影响。正面影响也就罢了，需要格外注意负面影响，负面影响会改变需求的价值。
假设产品目标是提升营收，现在需求A是向用户端投放广告，预测能够获得50万营收，但是会造成3万名用户的流失。这时候需求A还是高优先级的需求吗？
3. 需求等级的动态调整
产品目标不是一成不变的，产品目标变更后对应的优先级标准也同步变化。标准变更后，各需求的优先级也要重新评估。
比如：产品目标从原来的提升“活跃”数据，变成了现在的提升“拉新”数据。对需求A的结果预测是能够拉新1000人，促活100人。需求A对拉新显然价值更大。结合产品目标来看，需求A的价值随着产品目标变更而同步变更，从低优先级转变成高优先级。
产品目标的变更有什么规律？变更的影响因素和建立时一样，此时更关注目标变更的触发点。基本分为2种：定期变更、临时变更。
- 定期变更：通常以1个季度为周期，定期检查产品所处环境和发展进度是否符合计划。出现脱节时要及时调整，避免发展偏航。
- 临时变更：通常是因为市场、政策、竞品、产品自身发展突然出现重大变化，所以需要及时关注产品相关的重大事件，便于及时应对。
03 契合优先级的需求序列
当我们获取了有效需求，建立了优先级规则。各个需求具体的优先级顺序如何排列呢？大部分公司都有自己的优先级制度，但是为什么执行总是不如人意？可能是因为执行力松散，也可能是因为对需求价值的判断失误。
一旦实现的需求选择错误，会造成数据结果不能满足产品目标。意味着投入的时间，人力等资源的浪费，也可能导致产品在瞬息万变的市场上失去竞争机会。所以要建立更加细化的规则，进而量化需求的价值。
1. 判断需求属性
对“确定性需求”的优先级排序，首先根据“优先级”的重要程度判断需求属性——即：需求是否符合产品目标。
需求的实现会影响产品的多项数据表现，列出受需求影响程度较高的数据项和产品目标进行匹配。选取匹配程度更高的需求进入当前版本的“待定清单”中。
比如：产品目标是提升拉新数据；需求A有效提升活跃数据，拉新数据影响不大；需求B有效提升拉新数据，活跃数据影响不大。所以会选取和产品目标更匹配的需求B。
通常1个版本中只有1个产品目标，更有利于增强目标的实现效果。如果设立了多个目标，则需要先对各目标本身做优先级排序，并分配对应的权重。估算需求的对各目标的效果后，结合目标权重再重新进行需求排序。
2. 量化需求价值
假设需求A、B、C都进入了本版本的待定清单中，现有的资源有只能够实现2个需求。那么淘汰谁？剩下的谁先谁后？只有对需求价值或Bug的影响进行量化，才能够得出较为客观的结论。换言之对产品所带来的正向数据变化就是需求的价值所在。
需求价值的计算过程中，需要充分考虑关键影响因素。公式表达：需求价值 = 潜在用户数 x 转化率 x 使用频次 x 用户价值 – 关联指标负面影响
1）潜在用户数
- 评估需求会影响的用户类型，再估算对应类型客户的数量。
- 用户类型根据企业内部对客户的分类。比如：普通用户、会员用户、活跃用户。
- 估算对应用户数量时，注意用户的存量数据和增量数据。
2）转化率
- 预估潜在用户使用该需求对应功能的转化率。
- 转化率一般按照活跃度来计算，不同类型用户的活跃度不一样。
3）使用频次
- 估算目标用户一定时间内使用该功能的次数。针对不同类型的需求采用不同的时间长度计算。
- 见效快的需求，计算时间周期短，如1~3月；见效慢的需求，计算时间周期长，如3~6月。
4）用户价值
不同类型的用户价值需要分别计算。比如：普通用户和VIP用户对产品的贡献是有巨大差别的。
5）关联指标的负面影响
- 考虑效果时不仅要考虑正面收益，也要考虑需求实现对关联指标的负面影响。
- 计算收益要减去需求关联bug负面影响。比如：需求A可促活3000用户，bug可导致1000用户流失。所以预估效果应是促活2000用户。
- 特别需要注意需求实现付出的其他代价。比如：添加广告可以提升收益数据，但是会降低活跃等数据。
3. 需求的性价比
计算出需求价值后，按照价值高低排序就是我们要的需求优先级了吗？这样的想法依然过于片面。做决策不仅要考虑收益，也要考虑成本和性价比。
1）需求成本估算
这里的成本是指实现需求所需要投入的人力成本。同时为了计算方便，一般会将不同岗位的人力成本设定为同一个价格。用公式表达：人力成本 = 所需人天 x 单位人天费用。
比如：需求A实现需要产品设计3天、UI设计2天、研发测试5天，人力成本是500元/人天，则需要A的人力成本是5000元。
2）实现的性价比
最后一个步骤就是计算需要实现的性价比。根据性价比排序，性价比越高则排序越靠前。到此，完整的需求优先级才算制定完成。用公司表达：性价比 = 需求价值 / 人力成本
比如：需求A的需求价值50000元，实现需求的人力成本5000元，则性价比是10；需求B的需求价值20000元，实现需求的人力成本1000元，则性价比是20。综合来看，虽然需求A更有价值，但是需求B的性价比更高。因此需求B的优先级高于需求A。
附：“需求池”概况介绍
1、创建方式
需求池的创建方式并不固定，团队内保持一致即可，使用Excel或项目协同软件都行。比如：Teambition、禅道……
2、表单字段
需求池的具体字段可根据团队关注的要素自行调整，也可以把部分字段转移至关联文件中，比如在“产品版本”文件中记录各环节的负责人、计划用时和时间段、实际用时和时间段等信息。主要包含以下：
- 基础信息：需求方、提出时间、需求编号、需求概述、需求详情
- 需求属性：所属模块、所属功能、需求类型、需求状态、重要程度、紧急程度、需求等级、产品负责人、产品版本
3、补充说明
- 需求详情：完整需求的描述较多，通过图文等形式呈现，不便在excel上呈现。通常会用独立文档记录。通过“需求编号”检索查看“需求详情”。需求详情同时会记录需求方、提出时间等信息。
- 所属版本：版本规划属于项目管理内容，在对应“项目管理”表单中会标记需求实现各环节的负责人、交付物、计划和实际用时、开始和结束时间等信息。
本文由 @耳目不染 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
文章评论