需求评审会对于产品经理来说就像家常便饭，需求评审串起了前期的需求调研和分析、不同利益相关方的博弈，以及后续项目落地实施的计划，是产品在正式开发之前非常重要的一环。

需求评审也是产品经理建立个人影响力和威信，和开发建立信任关系的重要途径，所以产品经理一定要重视需求评审，在需求评审时展示足够的专业度，一旦研发小哥哥认可了你的能力，即使之后有小的需求变更，他们也不会拿刀或者二维码出来了。网上很多关于产品经理和开发互怼的段子，实际上产品和开发是最紧密的战友。

1.为什么要做需求评审

首先，需求评审可以让需求方明确你的需求分析与他们的要求是否一致，有时候可能是没有这个角色的，需求可能来自于产品经理自己的想法，这时候所有参会人员要有一个意识，假设用户在场，你做的每个决定是不是真的是从用户出发的。

亚马逊创始人杰夫·贝索斯在召开会议时，经常在会场上摆放一把黑色的空椅子，这个位置是留给消费者的，目的在于提醒参加会议的管理层，消费者作为最重要的人，也参加了这个会议。

其次，是让设计、研发、测试团队，也就是把需求落地的这些团队成员，明白他们为什么要来做这样一个东西，这个东西的价值是什么？这个东西将会长成什么样子。

最后，就是大家来找茬，每个人的思维都有其局限性，当局者迷、旁观者清，再有经验的产品经理也可能犯错或有思考不全面的时候。需求评审可以充分发挥团队成员的力量来完善产品的细节。当然这不意味着产品经理自己可以在尚未准备充分或者自己都没考虑清楚的情况下寄希望与大家来集思广益，那就是产品经理的不负责任啦。

2.开场前准备工作

开场前准备工作的自检清单：

1）确认你的需求、文档和原型都完成并发给相关参会人员了吗？

会议前一定要发出需求评审的材料，让大家可以提前熟悉一下评审内容。不过，这里也有一个问题，很多与会人员可能并不会提前阅读你的文档，特别是文档非常多页内容时。他们会想我已经这么忙了，反正产品经理在评审的时候也会讲，我就先不看了。

所以寄希望于把文档发出去别人会仔细阅读并给出反馈，也是不合理的期待。

这时候，产品在发材料的时候最好把要点和需要注意的重点提取出来，甚至你可以当面沟通或者针对不同的岗位单独指出他们需要关注的内容。因为设计、研发和测试的关注点一定是有差异的。

2）提前找核心人员小范围沟通，消灭掉大问题。

在需求评审之前可以找开发的负责人沟通一下，了解一下技术实现的成本，当前的产品架构是否支持，同时也给技术团队预研和构思设计的时间。

如果在会上才发现有根本性的分歧，如果不能短时间达成一致，也要果断暂停讨论，在想明白解决方案以后再次发起会议，不要当场陷入到具体细节里，长时间的无效讨论就会极大降低需求评审会议的效率。

3）和核心与会者确认可出席时间，至少提前1天发出会议邀请。

一般需求评审会邀请设计师、研发和测试参加，有时候也会有需求方、运营和其他的产品经理参加。每个人都有任务在身，所以一定要提前和核心与会者沟通好时间，并且提前预定好会议室并发出会议邀约。

如果有时间能提前演练一遍那就更好了，特别是对于产品经验不够丰富的人来说，做好充足的准备才能在需求评审时得心应手。

3.评审会现场

评审会现场：

讲解的流程一般如下：需求背景-用户和需求-功能模块-讲流程-原型与交互-数据指标-需要谁支持-预计上线时间。

切记，不要一上来就讲功能，要先讲解需求的背景，为什么要做这个需求，有什么价值，最好结合用户故事，某<角色>，在什么<场景>下，有什么样的<需求>，我们要做的这个产品刚好可以满足这个需求，从而体现<产品价值>。

产品经理也要学会给开发“画饼”，要将你的产品功能赋予一定的意义，团队实现起来才会更有动力。

具体如何去讲解需求就不展开讨论啦，记住讲需求要有节奏和条理，抓大放小，细节上不要争论，被人带偏了要及时回归正题，基本按照流程讲一遍就完事啦。在会议过程中，对于重要的争论点一定要做好记录，方便会后做会议纪要。

这里有两个需要特别说明的问题：注意知识的诅咒和为自尊争论。

知识的诅咒：当一个人知道一件事后，他就无法想象自己是不知道该这件事的情景。当人们预测他人的行为时，如果自己无法忽略自己拥有而对方缺乏的知识时，就会产生这种偏见。

在1990年的时候，斯坦福大学有一个心理学的博士生做了这样一个实验：把被试者分成两组（A组和B组），给A组的学生一个清单，单子上列出了一些大家耳熟能详的儿歌的名字。A组学生要做的是在桌子上把这个节奏给打出来，然后让B组的被试者猜对方敲打的节奏是什么歌？对于B组的人员来说，这个猜的过程并不容易，最后猜对的概率不足10%。有趣的是，A组的学生认为这些歌都好熟悉的呀，而且我这么认真地在“拍节奏”，这不是很明显的嘛，B组至少能猜中一半以上啊。

应用到需求评审会上，与会者可能没有你的背景知识，所以要想让与会者听明白你所讲的，一定要选择他们熟悉并且具像的事例来类比，从而让他们很快地理解你想要表达的内容。

此外，因为参与需求评审的人都是相关行业的从业者，可能某些在你们所有与会者潜意识里觉得理所应当的交互动作或者专业词汇，对产品的用户来说可能就一脸懵逼啦。所以在需求评审时，要时刻不忘切换为小白用户的思维角度去评估。

有时候需求评审就是一场撕B大会，争吵是不可避免的，无论是谁被人挑战都会不太舒服，本能地会为自己的方案和想法辩护，这时候产品经理一定要避免为自尊而开启战斗模式，如果是其他人员想争赢你，对话中已经明星混杂了情绪，产品经理也要及时引导回冷静讨论的范围中。千万不要忘记会议的本来目的，一旦有一方只是希望赢得辩论，就变成了抬扛了，争吵就变得毫无建设性，千万不要因为这样的事情浪费大家的时间。

4.评审后

1）评审会议开完以后，及时发出会议纪要，让与会人员看到会议讨论的结论。

2）整理遗留问题，并提出解决方案，将修改后的产品需求文档发出来，如果必要发起二次评审。

3）将需求拆分，找开发追排期。

兵法有云，不打无准备之仗，方能立于不败之地。需求评审会议是否高效和有价值基本上取决于产品经理，作为需求评审会的控场者，产品经理一定要重视并做好充分的准备。