话不多说，直接上干货。

本文主要分为四部分：

1. 需求评审的标准
2. 需求评审面临的困难及小技巧
3. 需求评审的原则
4. 需求评审的具体步骤

一、需求评审的标准

1、需求评审要细到什么程度？

严格地讲，需求评审应当检查需求文档中的每一个需求，每一行文字，每一张图表。

2、评判需求优劣的主要指标

正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。

二、需求评审面临的困难及小技巧

1、需求评审的一个通病是“虎头蛇尾”

需求评审特别地乏味，在刚开始评审时，大家都比较认真，进行的越往后越马虎。尤其是当需求文档很长时，几乎没人能够坚持到最后，别说你能，我不信！

小技巧：

1. 事先强调重点模块；
2. 评审时间长时，建议隔时间段休息；
3. 如果系统大文档长时，可细分成不同的部分或模块分别进行讨论；
4. 严格控制每次评审的文档规模及评审时间。

2、需求评审涉及的人员可能比较多

将这么多人聚到一起开会是非常不容易的，例如某些人可能在出差，某些人可能在进行别的事物···

小建议：

1. 不要把所有事情挤在一起做，需求评审可以分段进行，这样每次评审的时间及与会人员都会少一些；
2. 其次将《需求规格说明书》进行不同的标记，如草稿状态、评审状态、最终状态等，要对需求的最终状态进行更加严格的评审。

3、需求评审会议会经常跑题

有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。

小技巧：

1. 控制话题，避免讨论与主题无关的东西；
2. 不需要深入讨论具体的执行，适可而止；
3. 尽可能的阐述事实与证据，而并不是如何努力地说服别人。

三、需求评审的原则

1、不是谁要说服谁，而是就某个问题找出最佳解决方案

很多时候产品经理都是抱着“我要说服研发”的态度，这就会导致需求评审变成了一场辩论赛，大家都疯狂的相互寻找极端的情况来支持自己的观点，试图让对方进行让步，然而这恰恰是最错误最可怕的情况。

2、先建立基本的共识，在基于共识进行细化

不要盲目的、随心所欲的发言，首先要现金礼基本共识，通俗的说就是建立一个主调，把大家都拉倒同一个频道上来，不然就会导致大家在不同的频道上巴拉巴拉，互不相让，其实完全不是在说同一件事情，驴唇不对马嘴。

3、先求同，后攻异

在已经形成基本共识的基础上，若对其中的小问题存在分歧时，如果一时半会讨论不清楚，可以暂时记录下来，继续讨论其他的，最后在对有分歧的小问题进行讨论。但是当这个问题是产品主要功能或流程上的问题时，尽量不要跳过。

四、需求评审的具体步骤

1、明确目标与目的

通俗的说就是先说清楚我们要干什么。

看过太多的产品经理在需求评审时，上来就打开原型，巴拉巴拉的讲功能，将流程，这是完全错误的，一定要先明确目标，并一定要在目标上完全达成一致。

2、目标达成一致后，说说怎么做

在讨论怎么做时，很多人就已经把话题带到了如果这么做，我们的架构有什么问题，有什么风险等细节上了，这很容易让大家陷入细节的争吵与辩论，越跑越偏。

在讨论第一次的问题时，不要去想第二个层次的细节问题；在讨论细节问题时，不要再去质疑第一个层次的结论。

通常在讨论总会这两种结果：

1. 大部分认同这个方案：我们通常是按照这个方案来执行，对于其中的一小部分不太认同的部分，在进行讨论，看是否有更好的方案。
2. 不认同这个方案：首先再次确认，目标是否认同，如果目标都不认同，那这次评审也就gg了，这种情况一般不会出现；如果目标认同，那就是解决方案的问题了，可以坐下来研究，通常是：

（1）这个方案可以做基本的修正吗？

如果可以进行修正，那么探讨如何修正；如果不可以进行修正，那么重新寻找方案。

（2）是否可以勉强执行？你是否有更好的方案？

如果可以勉强执行，那就先按照这个方案干；如果有更好的方案，那就按照这个更好的方案干。

（3）我没有好的方案，也不认同你的方案

这种人完全不是做事情的态度，也不是团队合作的状态，赶紧让他卷铺盖走人···当然不排除有特殊情况，就是这个方案真的有很大的问题，完全不能用。

3、方案达成一致了，开始做排期与风险及收益预估

为什么做这个事情，都清楚了，也认同了；

是不是可以这么干，也基本达成一致了；

剩下的就是排期，安排人员，具体去执行了，这是一个新的话题，不展开了。

总结一下：

• 先说我们的目标与目的，在为什么要做这个事情上达成一致；
• 再说我是这么想的，你觉得方案是否可行，我们一起看看有没有更好的方案，在怎么做上达成一致；
• 按照我们讨论的这个做法，看看我们现有的人手，具体怎么一步一步执行。

讨论问题与需求评审一样，是一个解决问题的过程，解决问题的最合理方式就是不断拆解问题，拆解到不能再拆解了，然后分别地寻找解决方式。

另外，相比情商，智商反而有时候显得不是最重要的。

作者：黄色先生

来源：http://www.jianshu.com/p/9d848ff54751

本文由 @黄色先生 授权发布于人人都是产品经理，未经作者许可，禁止转载。