话不多说，直接上干货。
本文主要分为四部分：
- 需求评审的标准
- 需求评审面临的困难及小技巧
- 需求评审的原则
- 需求评审的具体步骤
一、需求评审的标准
1、需求评审要细到什么程度？
严格地讲，需求评审应当检查需求文档中的每一个需求，每一行文字，每一张图表。
2、评判需求优劣的主要指标
正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。
二、需求评审面临的困难及小技巧
1、需求评审的一个通病是“虎头蛇尾”
需求评审特别地乏味，在刚开始评审时，大家都比较认真，进行的越往后越马虎。尤其是当需求文档很长时，几乎没人能够坚持到最后，别说你能，我不信！
小技巧：
- 事先强调重点模块；
- 评审时间长时，建议隔时间段休息；
- 如果系统大文档长时，可细分成不同的部分或模块分别进行讨论；
- 严格控制每次评审的文档规模及评审时间。
2、需求评审涉及的人员可能比较多
将这么多人聚到一起开会是非常不容易的，例如某些人可能在出差，某些人可能在进行别的事物···
小建议：
- 不要把所有事情挤在一起做，需求评审可以分段进行，这样每次评审的时间及与会人员都会少一些；
- 其次将《需求规格说明书》进行不同的标记，如草稿状态、评审状态、最终状态等，要对需求的最终状态进行更加严格的评审。
3、需求评审会议会经常跑题
有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。
小技巧：
- 控制话题，避免讨论与主题无关的东西；
- 不需要深入讨论具体的执行，适可而止；
- 尽可能的阐述事实与证据，而并不是如何努力地说服别人。
三、需求评审的原则
1、不是谁要说服谁，而是就某个问题找出最佳解决方案
很多时候产品经理都是抱着“我要说服研发”的态度，这就会导致需求评审变成了一场辩论赛，大家都疯狂的相互寻找极端的情况来支持自己的观点，试图让对方进行让步，然而这恰恰是最错误最可怕的情况。
2、先建立基本的共识，在基于共识进行细化
不要盲目的、随心所欲的发言，首先要现金礼基本共识，通俗的说就是建立一个主调，把大家都拉倒同一个频道上来，不然就会导致大家在不同的频道上巴拉巴拉，互不相让，其实完全不是在说同一件事情，驴唇不对马嘴。
3、先求同，后攻异
在已经形成基本共识的基础上，若对其中的小问题存在分歧时，如果一时半会讨论不清楚，可以暂时记录下来，继续讨论其他的，最后在对有分歧的小问题进行讨论。但是当这个问题是产品主要功能或流程上的问题时，尽量不要跳过。
四、需求评审的具体步骤
1、明确目标与目的
通俗的说就是先说清楚我们要干什么。
看过太多的产品经理在需求评审时，上来就打开原型，巴拉巴拉的讲功能，将流程，这是完全错误的，一定要先明确目标，并一定要在目标上完全达成一致。
2、目标达成一致后，说说怎么做
在讨论怎么做时，很多人就已经把话题带到了如果这么做，我们的架构有什么问题，有什么风险等细节上了，这很容易让大家陷入细节的争吵与辩论，越跑越偏。
在讨论第一次的问题时，不要去想第二个层次的细节问题；在讨论细节问题时，不要再去质疑第一个层次的结论。
通常在讨论总会这两种结果：
- 大部分认同这个方案：我们通常是按照这个方案来执行，对于其中的一小部分不太认同的部分，在进行讨论，看是否有更好的方案。
- 不认同这个方案：首先再次确认，目标是否认同，如果目标都不认同，那这次评审也就操蛋了，这种情况一般不会出现；如果目标认同，那就是解决方案的问题了，可以坐下来研究，通常是：
（1）这个方案可以做基本的修正吗？
如果可以进行修正，那么探讨如何修正；如果不可以进行修正，那么重新寻找方案。
（2）是否可以勉强执行？你是否有更好的方案？
如果可以勉强执行，那就先按照这个方案干；如果有更好的方案，那就按照这个更好的方案干。
（3）我没有好的方案，也不认同你的方案
这种人完全不是做事情的态度，也不是团队合作的状态，赶紧让他卷铺盖滚蛋···当然不排除有特殊情况，就是这个方案真的有很大的问题，完全不能用。
3、方案达成一致了，开始做排期与风险及收益预估
为什么做这个事情，都清楚了，也认同了；
是不是可以这么干，也基本达成一致了；
剩下的就是排期，安排人员，具体去执行了，这是一个新的话题，不展开了。
总结一下：
- 先说我们的目标与目的，在为什么要做这个事情上达成一致；
- 再说我是这么想的，你觉得方案是否可行，我们一起看看有没有更好的方案，在怎么做上达成一致；
- 按照我们讨论的这个做法，看看我们现有的人手，具体怎么一步一步执行。
讨论问题与需求评审一样，是一个解决问题的过程，解决问题的最合理方式就是不断拆解问题，拆解到不能再拆解了，然后分别地寻找解决方式。
另外，相比情商，智商反而有时候显得不是最重要的。