“总是做迫在眉睫的事情，会让人丧失目标”

引用《B端产品经理必修课》书中的一句话，简明扼要的说明了需求管理的目标和意义。

需求规划的意义，是通过需求筛选的方法选择出可以在恰当的时间开发上线的需求，使产品团队工作更条例，最大化利用开发资源，同时帮助个人、团队或公司产生间接价值。

产品经理日常工作每天接触大量的需求，成熟一点的团队、公司，也都有针对自己产品需求的管理方法，甚至从需求挖掘、筛选、规划优先级都也自己的一套方法论。

C端产品从0到1的时候，通常专注做MVP，这时产品的需求量其实并不大，只围绕产品目标和核心体验来发掘和规划需求。随着产品发展，有些产品改变了定位，不再满足做一个单纯的工具类产品，而是拓展成一个用户服务平台，通过各种功能来满足广大的各类用户群体。

功能越多，服务的用户也就越多，收到的需求反馈自然也就越多，当同时面对上百个、甚至上千个需求，如何快速进行优先级规划，自然就需要一些高效的方法了。

通用方法论并非万能

需求管理通识性的方法论，产品经理们应该大多都比较清楚，但是这些方法论，都多多少少会带有主观意愿。

比如运用SWOT分析需求的优缺点和竞争力时，对于这个需求，哪个优缺点才是客观的？又或者哪些点是真正有竞争力的？

在运用波士顿矩阵来对需求进行分类时，仅通过用户体验、公司战略两个维度，似乎又缺乏客观判断。再比如KANO模型可以对产品需求进行分类，有必备型、期望型、兴奋型、无差异型、反向型等需求类别，正常在需求管理时，可以根据这些分类再加上紧急重要程度来判断优先级即可……

有些方法论工具，为了强调需求规划的客观性，还会基于模型规划的需求进行打分评级策略，试图将这些需求的规划尽可能具备科学性、合理性。

但是，每个人的专业认知和想法都不同，一千个产品面对一千个需求就会有一千个观点，方法论模型没问题，只是运用模型的人要对产品的定位、目标用户相当熟悉甚至可以深刻洞察，才可以基于模型对需求进行准确的分类。就算是这样，往往也抵不过老板的一句话：“我不要你认为，我要我认为…”

当同时面对需求清单里的上百、上千个需求，想要对这些需求进行快速优先级规划。

试想一下，哪怕一个有着丰富经验的产品团队，直接套用以上方法论，再加上打分评级的步骤，或许可以完成，但也还是

需要比较大的时间成本，更不用说那些只有一个产品经理的公司。对于他们的工作来讲，除了要考虑工作效率，还要考虑需求管理的方法是不是很科学。

总之，这项看似基础的工作并不轻松。

需求优先级规划层级

产品开发流程里面有一个“门径管理流程”，通过设置多个阶段和多个筛选关口，将最初收集的产品创意通过层层筛选把控，在最后开发上市阶段，最大程度降低产品项目风险。

此处引用这个思路，通过以下优先级规划层级，可帮助产品团队成员快速、准确的筛选出可行性需求，并根据客观判断依据，对需求进行优先级排序，提高工作效率和产出价值。

该层面可以通过多个方面来体现需求的价值：

结合产品规划，判断该需求是否与现有版本规划同步，或该需求相关功能模块是否在规划内，通常符合规划的需求更容易被开发，也更容易进行需求验证；

同时围绕整体产品生命周期来判断这个需求的价值，同样的功能在产品不同运营阶段上线，产生的产品价值自然也不一样。还可以把当前需求放到产品的使用流程上，思考是想要完善体验来提升用户价值，还是修复bug来保证产品功能的完整性。

3. 可行性判断

将可行性判断放到价值考量之后，是为了促进产品的价值导向，从长期角度来看，更有利于通过开发更多有价值而不是比较容易的需求，来获得用户价值和产品价值。

经过上述判断，已经筛选了一类需求，当把既符合产品规划，又对当前产品有价值的需求筛选出来后，那么就要进一步思考这些需求的可行性。

该层面可通过宏观环境去判断当前需求的竞争力和投入产出比，同时判断这个需求如果开发上线后，有多大的影响面，可满足多少用户的核心利益，可对多少用户产生价值。

4. 需求分类

确定可行性后，就要对筛选出来的可行需求进行优先级排序，可先将需求分类，如紧急BUG解决、功能体验完善、新增亮点、未来规划，分别对应KANO模型中的必备、期望、兴奋、无差异、反向类需求。

通常紧急的产品BUG是最先需要解决的，同时因为是产品的必备型功能，对于用户来讲功能体验完善类的需求也是最应该解决的。新增的亮点可以满足用户的期望型需求，未来规划对于大多数用户来讲是无感知的，因此按照产品规划的节奏即可。

这个阶段需要特别注意无差异需求和反向需求，尤其对无差异需求的判断要谨慎认真，否则会不知不觉耗费大量的精力开发这种没有太大价值，且性价比低的需求。

最后分类出来的需求，还需要结合重要程度判断优先级，为保证客观准确，可针对同一级别、同一类型的需求进行打分，再次细分需求优先级。

5. 需求级别

判断出优先级后，就需要分别给需求进行标注级别，提供两种需求级别：P0-P3，P1-P10。

常规优先级级别是P0-P3，但是在目前实际操作中需求清单中需求太多，需求级别太少无法将需求分层细化，故还可以采用P1-P10。但同时缺点也比较明显，优先级层级较多时，就会导致越靠后的优先级定义越模糊。

如果给需求评级时没有清晰的优先级定义，那在具体执行时就比较费劲。因此建议可以采用优先级别较少的方法，如同一级别的需求较多，还可以按照以上方法再次分解，直至拆分出最小迭代单位。

总结

C端产品的规划思路是围绕核心路径打造极致产品体验，需求收集后，一个需求从确认到原型策划之前，需要经历需求甄别、筛选、判断、优先级排序等阶段，产品需求管理的工作基础但极具价值。

任何方法论模型都无法保证适应每种产品的需求规划，如何能让自己高效的进行需求管理，还需要在工作中不断地实践、融合、举一反三。

此篇文章希望通过建立一个需求规划层级，帮助我们在平时进行需求优先级分析时，可以有一个完善的、系统的思考方式，让产品工作更有序。

————————————————
版权声明：

本文@王曙 原创发布于人人都是产品经理。遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：http://www.woshipm.com/it/3412377.html