需求|需求评审几个最常见的坑交易法|指控|联邦贸易委员会

编辑导语：某种意义上，需求评审会是产品经理传递需求的重要途径之一，而是否能开好需求评审会，也在于你对需求的洞察是否足够，以及你是否有充分的准备。那么，产品经理若想开好需求评审会，应当避开哪些坑呢？不妨看看作者的总结。

文章插图
佛家讲，一饮一啄，莫非前世注定。
对于产品同学来说，归因理论本应该属于基础的底层产品思维，不仅应该清楚需求如何去做，更要知道需求背后的原因。
同样的，评审会本身也可以理解为一个需求设计，而需求设计的核心就是成功开好评审会。
事实上，我一直觉得，对产品来说，核心的工作可简化为两块：一个是需求设计，一个是需求传递。
需求设计和需求传递又分别对应着产品的硬实力和软实力。
需求设计对应着硬实力，主要是指专业能力；需求传递对应着软实力，主要是指沟通协调能力。
这其中，需求评审会是需求传递的重要表现形式，绝大多数的需求有效传递，都需要依赖需求评审会。
从某种意义上来说，能否成功开展好需求评审会是优秀产品产品经理的重要衡量标准之一。
但，我发现，仍然有不少产品同学在需求评审时存在不少漏洞，效果并不理想，甚至有的需求评审会过于失败，中途叫停，直接影响产品的形象，一旦被贴上不专业的标签，后续的产品工作沟通就很麻烦。
所以，我们要用归因理论来复盘分析：
需求评审会最常见的坑有哪些？这背后的原因是什么？又应该如何来避免呢？
一、一上来就讲解原型设计我之前写过一篇文章，分享了需求评审会需要准备的提纲文件，也收到不少好评，文章中提到了需求评审的前提，以及应当准备的产品成果。
一般来说，需求评审应当准备好产品背景介绍方案、架构设计图、逻辑功能图、业务流程图、原型设计、需求说明文档。
这些功能成果是有助于目标用户（技术开发等人员）全方位地了解产品设计的前因后果，产品经理准备的越详细，评审会成功的概率就越大。
这里尤其要强调的是，评审会上来就讲原型设计是大忌，这是产品同学亲手给自己挖的坑：
一来，开发同学对产品设计的背景不清楚，没有全局的概念，接下来的评审效率自然不会高，会被反复问一些产品顶层设计的问题，甚至会错误理解产品方向；
二来，显得不够专业，没有结构化的思维，层次感不足，评审内容过于单薄，不要小看这些细节，你被开发打上“专业”或“不专业”的标签，对于后续的需求沟通效率影响很大。
现实中，不少刚入行的产品同学缺乏经验，有时会急于展示原型，反而得不偿失，所以一定要牢记：
要先把产品设计的背景、理念、功能价值等先介绍一下，让大家对产品有个熟识度之后，然后再去评审具体的产品内容。
二、没有需求文档上面已经说过了，最重要的产品成果就是“原型设计”和“需求说明文档”，按理说这两个文档必须都准备妥当，方能具备需求评审的基础。
原因也很简单，因为原型设计更多的是展示产品功能和交互跳转等，而需求说明文档则会对产品的逻辑规则、业务规则、数据规则等详细描述，技术需要依据这些来开发，测试也需要依据这些来写测试用例。
【需求|需求评审几个最常见的坑】但，现实中，不少公司产品人手不足，市场压力又很大，多条产品线，N个项目并行时，往往会进行所谓的“敏捷开发”，只需评审原型设计就行了，需求说明文档往往会后补，甚至缺失。