事先制定规则可以在需求管理工作中取得极大的便利性，也可以很大程度上减少后期与运营沟通的成本。

在需求收集和需求排期阶段，通过事先制定规则，过滤掉一部分无效需求，可以大大减少后期与运营的需求沟通成本。

我在负责需求管理的初期，经常陷入需求沟通的窘境：运营大堆地提需求过来，很多时间花在过滤无效需求上；制定需求排期，大多运营都不满意。后来通过规范需求流程、制定需求调研规则，并坚持落实下去，渐渐达到了需求高效沟通的目的。

将需求流程分为以下四个阶段，每个阶段都有一个主要目标。

一、需求记录

运营按照需求管理表格填写需求。表格中大致包含以下信息：需求名称、需求描述、提出者、提出时间、重要度、紧急度等。

这个过程中，运营可以从3个方面考虑需求的性价比：

1. 需求是否能够解决成本问题：是否可以减少金钱支出、降低沟通成本、减少时间花费。比如增加批量操作功能，可以减少运        营在重复性工作上花费的时间。
2. 需求能够解决百分之几的问题：如果只有3%的人遇到了问题，这个需求做与不做区别不大。
3. 需求所能解决的问题是长期的还是短期的：如果问题是短期的，需要综合技术开发时长考虑需求该不该做。

运营在边写边想的过程中，能培养评估需求轻重缓急意识，无关紧要的需求甚至不会再提上来了。

二、运营内部需求评审会

每个运营组需要开展组内需求评审会，主要确定两点：

1. 探讨运营所提出的需求，是否有其他不需要依附于产品的解决方案：通常组内运营的工作都是类似的，也许这个运营遇到的问题，别的运营早就摸索出了解决方案。
2. 确定必要的需求，并集思广益产出更优方案。
3. 确定组内的需求优先级，便于产品经理辨识需求。

内部评审实际上是给了组员之间沟通的机会，达到工作信息互通的目的，进而帮助产品经理过滤掉部分非必要需求。

也许有人会觉得这样的要求对于运营来说会比较高，或者考虑需求性价比、出需求方案明明是产品经理该干的事儿。

但是我认为，需求的评估是层层筛选的，所有的需求都一股脑汇总到产品经理那儿，势必增加了与运营撕x“为什么这个需求不能做”的沟通成本。前期让运营对自己的需求形成清晰的认识，是可以过滤掉部分无效需求的，后期的需求沟通才能够更加高效。

三、运营与产品需求评审会

1. 会前准备

产品经理在这个阶段需要做好需求调研的四个步骤：需求收集、需求挖掘、需求评估、需求分析。

① 需求收集：运营内部需求汇总至产品经理处。

② 需求挖掘：对需求进行需求挖掘，与需求方一对一交流，探讨需求本质，排除无效需求，对必要需求输出MVP版方案和完整方案。

③ 需求评估：根据KANO需求模型及当前业务方向，分析需求的重要性和紧急度，定下初步的需求排期。

④ 需求分析：结合技术资源，对排期的需求作出需求分解。

比如：“这个功能耗时太多，技术人太少，做出来也不确定能不能解决当前遇到的问题，就先做个MVP版的功能试试吧”；“这个功能不是很复杂，而且的确做出来挺有用的，直接一步到位没什么大问题”。

2. 会中讨论

每个运营组出一个需求对接人，与产品开展需求评审会，主要确定4点：

① 工作信息互通：不同组别的运营负责的工作内容差别较大，必要的信息同步很重要，这样才能让大家知道每个部门都有各自的难处，才能促进相互理解。

② 一致明确公司目前主要的业务方向，围绕业务去开展需求排期。

③ 产品经理讲解需求排期结果和需求方案。

④ 假如对排期不满意，运营可以提出意见，产品经理评估合理后，再作出排期调整。不合理的需求要坚决说不，并给出让人信服的理由。

3. 会后结论

产品经理将会议的排期结果和需求方案同步给各个运营组。

四、产品与技术的需求评审会

1. 会议成员：产品、技术、运营（必要时可以让运营参与）。
2. 会议要点：产品与技术讨论需求细节，得出最终的需求排期和需求方案。运营旁听，可以实时了解需求排期过程，不需要产品经理会后再次讲解需求排期调整的原因和结果。

执行需求流程一开始会碰上一屁股的钉子，坚持不断沟通、积累经验后，就能发现效果越来越明显了。但还会碰上一两颗钉子，因为需求永远都解决不完，没有完美的需求排期，只有更好的需求排期。

本文由 @fin 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自作者。