如何搞砸1个需求评审？这3步，请拿捏住...

佛家讲，一饮一啄，莫非前世注定。

对于产品同学来说，归因理论本应该属于基础的底层产品思维，不仅应该清楚需求如何去做，更要知道需求背后的原因。

同样的，评审会本身也可以理解为一个需求设计，而需求设计的核心就是成功开好评审会。

事实上，我一直觉得，对产品来说，核心的工作可简化为两块：一个是需求设计，一个是需求传递。

需求设计和需求传递又分别对应着产品的硬实力和软实力。

需求设计对应着硬实力，主要是指专业能力；需求传递对应着软实力，主要是指沟通协调能力。

这其中，需求评审会是需求传递的重要表现形式，绝大多数的需求有效传递，都需要依赖需求评审会。

从某种意义上来说，能否成功开展好需求评审会是优秀产品产品经理的重要衡量标准之一。

但，我发现，仍然有不少产品同学在需求评审时存在不少漏洞，效果并不理想，甚至有的需求评审会过于失败，中途叫停，直接影响产品的形象，一旦被贴上不专业的标签，后续的产品工作沟通就很麻烦。

所以，我们要用归因理论来复盘分析：

需求评审会最常见的坑有哪些？这背后的原因是什么？又应该如何来避免呢？

1、一上来就讲解原型设计。

我之前写过一篇文章，分享了需求评审会需要准备的提纲文件，也收到不少好评，文章中提到了需求评审的前提，以及应当准备的产品成果。

一般来说，需求评审应当准备好产品背景介绍方案、架构设计图、逻辑功能图、业务流程图、原型设计、需求说明文档。

这些功能成果是有助于目标用户（技术开发等人员）全方位地了解产品设计的前因后果，产品经理准备的越详细，评审会成功的概率就越大。

这里尤其要强调的是，评审会上来就讲原型设计是大忌，这是产品同学亲手给自己挖的坑：

一来，开发同学对产品设计的背景不清楚，没有全局的概念， 接下来的评审效率自然不会高，会被反复问一些产品顶层设计的问题，甚至会错误理解产品方向；

二来，显得不够专业，没有结构化的思维，层次感不足，评审内容过于单薄， 不要小看这些细节，你被开发打上“专业”或“不专业”的标签，对于后续的需求沟通效率影响很大。

现实中，不少刚入行的产品同学缺乏经验，有时会急于展示原型，反而得不偿失，所以一定要牢记：

要先把产品设计的背景、理念、功能价值等先介绍一下，让大家对产品有个熟识度之后，然后再去评审具体的产品内容。

2、没有需求文档。

上面已经说过了，最重要的产品成果就是“原型设计”和“需求说明文档”，按理说这两个文档必须都准备妥当，方能具备需求评审的基础。

原因也很简单，因为原型设计更多的是展示产品功能和交互跳转等，而需求说明文档则会对产品的逻辑规则、业务规则、数据规则等详细描述，技术需要依据这些来开发，测试也需要依据这些来写测试用例。

但，现实中，不少公司产品人手不足，市场压力又很大，多条产品线，N个项目并行时，往往会进行所谓的“敏捷开发”，只需评审原型设计就行了，需求说明文档往往会后补，甚至缺失。

但这些貌似省掉的工作，不仅可能会让你在评审会时招架不住，也会在后续的开发过程中反复折磨你。

所以，敏捷的是思想、是形式，但核心的工作内容一定不可少， 要学会灵活变通。

一般这种情况下，我都推荐产品一定要写一个敏捷版的需求说明文档，不必在意形式是否合规，核心就是把主要的产品功能所涉及到字段规则、业务规则等表达清楚。

要牢记，只有把这个敏捷的需求文档写出来之后，再启动召开评审会才能成功，否则，一定会得不偿失的。

3、原型设计没有彩排。

事实上，需求评审前产品同学都需要彩排演练一遍，将准备的产品工作成果都提前准备好，会议室、会议通知等等，都需要提前安排妥当。

但还是特别想强调下，产品同学在原型设计上的彩排缺失所带来的被动不利局面，因为，这个坑出现的频率很高，这背后的原因，一是没有准备意识，二是缺乏科学方法。

所谓原型设计彩排，是自己要实地演示，最好去会议室实地操作一遍，因为有时候环境影响你的发挥，一般来说，在工位心里默念不如去会议室效果好。

其次，原型演示时，要掌握技巧：

1. 可以先整体快速浏览下原型页面，让大家对本次产品开发工作有个感性认知。
2. 按照业务流程，逐一演示产品功能，要有章法，不要想到哪儿就说到哪儿。
3. 页面演示时，页面元素要讲解到位，尤其是像 “数据来源”、“数据状态值”、“数据记录”、“计算规则” 等等，这些是开发必问的内容，自己必须要搞得很清楚，可以在原型上加上注释。
4. 原型设计演示时，存在有争议时，要学会搁置争议，不要抓着不放，可以先记录，回头再解决。
5. 针对存在的问题，不要避讳，要讨论充分。

这些技巧能有效帮助我们开好评审会，缺失则会往往带来失误，影响需求评审的效率和产品经理的形象。

比如，上次我们评审时，一个产品同学对于列表数据的数据来源、数据状态没有完全搞清楚，对于数据什么时候展示，什么时候消失等理解不够透彻，结果可想而知，自然不够理想。

事后产品复盘，发现他原型设计并没有提前演练，只是简单翻看一下，所以也就漏掉了这个页面的把控。

总之，原型设计一定要提前演练，提前按照方法去演练，且演练要高效、到位。

事实上，需求评审时有很多坑，也有很多避坑指南，但归根结底来说，凡是都有因果，需求评审会存在失误的背后一定是有其失误原因的。

对于我们来说，重要的事，不是完全避免问题，而是找到问题的原因并解决掉，并且不断反复练习、总结复盘。

唯有此才能从根本上避免失败，才能开成功每一场需求评审会。

因为，古人说过：

扬汤止沸，莫如釜底抽薪。