需求|需求评审几个最常见的坑 rpg|英特尔|艾尔登法环|黑暗之

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

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