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