总结一下，其实就是一个不断拆解的过程
关于什么是需求评审，不在这里做解释与定义了，直接进入主题。
关于需求评审的几个原则：
1、需求评审不是谁要说服谁，而是我们要就某一个具体问题寻找到最优的解决方案。
我们有很多PM总是会抱着「我要说服研发」的态度来做需求评审，所以整个需求评审的基本氛围是辩论，是相互的寻找极端情况支撑自己的观点，试图让对方让步，这是非常错误的开局。
2、所有问题的讨论，都必须要先建立基本共识，然后基于这个共识再细化。
什么是基本共识呢？就是我们首先要把双方调整到一个频道上来。不要在不同的频道上相互努力，那没意义。比如，我们先要定义清楚什么是激活用户、什么是注册用户；比如我用到的这个名词指代的是什么这样的基础的小问题。
3、先不要在僵持不下的观点上浪费时间，先求同，后攻异。
在已经形成基本共识的基础上，如果一个小问题有分歧，且一时半会讨论不清楚，那就先放下，继续讨论其他的，等其他的解决了，再回来解决这个差异点上的问题。
关于需求评审的推进步骤：
1、先说我们这次需求的目标与目的。
简单说就是先讲明白我们要做什么，我们为什么要做这个。
就像是演讲的时候，先讲一个能够引起观众兴趣的故事或者观点，然后再提出一个在这个美好的故事中需要解决的难题。
这个问题是经常会产品经理忽略的，但也恰恰是需求评审中最最重要的，它的重要性甚至超过了后面所有的步骤！
我看过太多的产品经理在需求评审的时候，上来就打开画好的原型图，开始讲功能，讲流程。这是完全错误的。一定要花时间先讲为什么要做这个，要达到什么目标，并且一定要在这个目标上达成一致意见。
就像我之前说的，「设计师，别急着打开设计软件」，产品经理在需求评审之前，请别着急讲功能点与流程，这非常重要。
2、在目标与目的达成一致的基础上，再说你准备怎么做
在谈怎么做的时候，我们是默认为什么做大家达成了一致的。这个时候，不要再返回去讨论第一个问题了，聚焦在怎么做上。
在我们讨论问题的时候，在我们评审一个需求的时候，很多人会很着急，当你说要做这个的时候，他的思路会跑的很快，立刻就先跑到了想要是这么干，我们目前的架构会有什么问题，会存在什么潜在风险，已经跑到细节上了。
这样很不科学，也很不高效，很容易把问题混到一起去了，然后就会陷入到细节的争吵与辩论，然后就走偏了。这样的讨论也是低效的。
谈第一个层次问题的时候，就不要想第二个层次的事情，谈第二个层次的事情的时候，就不要再回去质疑第一个层次的结论了。
讲述你准备怎么做的过程，实际上就是要描述你的解答对解决问题而言的好处。
关于「准备怎么做」的讨论，会有2个结果：
2.1、你认同或者大部分认同我的方案
那么，就按照这个方案来执行，其中有一些不太认同的，我们坐下来讨论，看是否有更好的方案来做。
2.2、你不认同我的方案
那么，我们先回到第一个问题「关于我们要做这个事情的目标与目的」是否认同。如果认同目标了，那就是实现方案的问题了，我们可以坐下来研究。如果不认同这个目标，那这评审也就没得玩了，这个状态一般极少出现。
好，现在问题出在不认同方案上了，又有2个结果：
2.2.1、这个方案可以做基本的修正吗？
可以，那我们探讨如何修正
2.2.2、你是否有更好的解决方案呢，这个方案是否可以勉强执行？
可以，那好，先按照这个方案干。如果你有更好的方案，我们按照你的方案干。
2.2.3、我没有更好的方案，我也不认同你的方案
靠，你这完全不是一个团队合作的状态，赶紧换人。
3、方案达成一致了，开始做排期与风险及收益预估
为什么做这个事情，都清楚了，也认同了；
是不是可以这么干，也基本达成一致了；
剩下的就是排期，安排人员，具体去执行了，这是一个新的话题，不展开了。
总结一下，其实就是一个不断拆解的过程，
先说我们的目标与目的，在为什么要做这个事情上达成一致；
再说我是这么想的，你觉得方案是否可行，我们一起看看有没有更好的方案，在怎么做上达成一致；
按照我们讨论的这个做法，看看我们现有的人手，具体怎么一步一步执行。
讨论问题与需求评审一样，是一个解决问题的过程，解决问题的最合理方式就是不断拆解问题，拆解到不能再拆解了，然后分别的寻找解决方式。
另外，相比情商，智商反而有时候显得不是最重要的。