关于什么是需求评审，不在这里做解释与定义了，直接进入主题。

关于需求评审的几个原则：

1、需求评审不是谁要说服谁，而是我们要就某一个具体问题寻找到最优的解决方案。

我们有很多PM总是会抱着「我要说服研发」的态度来做需求评审，所以整个需求评审的基本氛围是辩论，是相互的寻找极端情况支撑自己的观点，试图让对方让步，这是非常错误的开局。

2、所有问题的讨论，都必须要先建立基本共识，然后基于这个共识再细化。

什么是基本共识呢？就是我们首先要把双方调整到一个频道上来。不要在不同的频道上相互努力，那没意义。比如，我们先要定义清楚什么是激活用户、什么是注册用户；比如我用到的这个名词指代的是什么这样的基础的小问题。

3、先不要在僵持不下的观点上浪费时间，先求同，后攻异。

在已经形成基本共识的基础上，如果一个小问题有分歧，且一时半会讨论不清楚，那就先放下，继续讨论其他的，等其他的解决了，再回来解决这个差异点上的问题。

关于需求评审的推进步骤：

1、先说我们这次需求的目标与目的。

简单说就是先讲明白我们要做什么，我们为什么要做这个。

就像是演讲的时候，先讲一个能够引起观众兴趣的故事或者观点，然后再提出一个在这个美好的故事中需要解决的难题。

这个问题是经常会产品经理忽略的，但也恰恰是需求评审中最最重要的，它的重要性甚至超过了后面所有的步骤！

我看过太多的产品经理在需求评审的时候，上来就打开画好的原型图，开始讲功能，讲流程。这是完全错误的。一定要花时间先讲为什么要做这个，要达到什么目标，并且一定要在这个目标上达成一致意见。

就像我之前说的，「设计师，别急着打开设计软件」，产品经理在需求评审之前，请别着急讲功能点与流程，这非常重要。

2、在目标与目的达成一致的基础上，再说你准备怎么做

在谈怎么做的时候，我们是默认为什么做大家达成了一致的。这个时候，不要再返回去讨论第一个问题了，聚焦在怎么做上。

在我们讨论问题的时候，在我们评审一个需求的时候，很多人会很着急，当你说要做这个的时候，他的思路会跑的很快，立刻就先跑到了想要是这么干，我们目前的架构会有什么问题，会存在什么潜在风险，已经跑到细节上了。

这样很不科学，也很不高效，很容易把问题混到一起去了，然后就会陷入到细节的争吵与辩论，然后就走偏了。这样的讨论也是低效的。

谈第一个层次问题的时候，就不要想第二个层次的事情，谈第二个层次的事情的时候，就不要再回去质疑第一个层次的结论了。

讲述你准备怎么做的过程，实际上就是要描述你的解答对解决问题而言的好处。

关于「准备怎么做」的讨论，会有2个结果：

2.1、你认同或者大部分认同我的方案

那么，就按照这个方案来执行，其中有一些不太认同的，我们坐下来讨论，看是否有更好的方案来做。

2.2、你不认同我的方案

那么，我们先回到第一个问题「关于我们要做这个事情的目标与目的」是否认同。如果认同目标了，那就是实现方案的问题了，我们可以坐下来研究。如果不认同这个目标，那这评审也就没得玩了，这个状态一般极少出现。

好，现在问题出在不认同方案上了，又有2个结果：

2.2.1、这个方案可以做基本的修正吗？

可以，那我们探讨如何修正

2.2.2、你是否有更好的解决方案呢，这个方案是否可以勉强执行？

可以，那好，先按照这个方案干。如果你有更好的方案，我们按照你的方案干。

2.2.3、我没有更好的方案，我也不认同你的方案

靠，你这完全不是一个团队合作的状态，赶紧换人。

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

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

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

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

总结一下，其实就是一个不断拆解的过程，

1. 先说我们的目标与目的，在为什么要做这个事情上达成一致；

2. 再说我是这么想的，你觉得方案是否可行，我们一起看看有没有更好的方案，在怎么做上达成一致；

3. 按照我们讨论的这个做法，看看我们现有的人手，具体怎么一步一步执行。

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

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

建议继续学习：

1. 不懂技术的人不要对懂技术的人说这很容易实现    (阅读：4432)
2. 关于架构的一句话，还有一个实例    (阅读：3592)
3. 用Unix的设计思想来应对多变的需求    (阅读：3609)
4. 百度PM万维雅：需求把握和正确决策    (阅读：2707)
5. 如何准确看清用户需求？    (阅读：2572)
6. 技术方案评审    (阅读：2416)
7. 用户的地图需求分析    (阅读：2408)
8. 如何媒体正确的看待：产品需求文档和产品需求    (阅读：2258)
9. 姐要的视频广告    (阅读：2256)
10. 分析用户需求：在场景中寻找“痛点”    (阅读：2073)