最近一直在参与各种需求评审会，接触了很多产品新人，发现好多刚入门的产品新人不太擅长需求评审会，常常是会议时间不受控，结果也未达到预期。趁此机会，将自己的经验做一个小的复盘，一来形成SOP，二来为产品新人提供一下思路。本次拟从评审前、评审中、评审后三个方面进行描述，希望每位产品经理都能成长为独挡一面的风云人物。

一、评审前：不打无准备之杖

参加PM培训课程时，讲师说过这么一句话：会议的目的是通过沟通就相关问题达成一致。

需求评审会议也是如此，最重要的目的是确保研发、测试甚至是领导等相关人员对需求的解决方案理解一致。既然是会议，那么组织会议之前一定要明确以下事宜：会议的背景、主题、时间、与会人员，需要讨论的重点等，其中会议的主题、时间、与会人员等大家都知道，此文章不再赘述。本文重点梳理产品新人就“会议的背景”及“需要讨论的重点”进行解释。

1） 通知与会方并发送相关资料。

会议之前我们往往会提起通知相关与会方，在通知到大家之后，皮皮建议大家把本次需求评审会用到的：需求业务场景、业务流程图、页面线框图、状态描述图等一起发送给大家，确保大家知道此次评审的内容是什么，并可以借助资料快速在大脑中串联出业务或提前梳理出自己的疑惑或感兴趣的点，评审时才能跟上产品经理的思路。

如果时间允许，还可以提前收集好大家有疑惑的内容、未覆盖的特殊场景，准备好方案，会议统一讨论。

2） 提前抛出重点要讨论的方案或场景。

需要讨论的重点是指本次需求中可能有一些场景由于技术、资源或者其余限制无法明确是否需要采用该种方案。这种一定要在会议前整理出来，并且确保团队中相关核心人员都知道这是本次讨论的重点，方便大家提前准备思路，避免出现讨论时同事们有一种“What is he doing”的疑惑。

3）就整体设计思路与方案与主管达成一致。

组织过需求会议的产品儿都知道评审会议常常是跨部门的，把那么多人的时间协调在一起很不容易，所以会议最重要的就是效率。如何提高效率呢？所谓“擒贼先擒王”，组织大家上会前，我们一定要把本次评审你的设计思路、困难和解决方案等统统与相关领导达成一致。

提前搞定boss的好处数不胜数。

• 避免领导在会议上直接对你“发难”，影响你的心态及后续的发挥，而且有时搞定boss，他也会在评审时帮你舌战群儒。
• 用领导做背书，研发等同事基本会直接“赞同”你的方案，听起来是有点“狐假虎威”的感觉，但是工作的首要目标是完成任务；
• 有了同盟之后，你的每次会议基本都会比较顺利，久而久之你自己也会信心大增，越来越得心应手。

二、会议时：自上而下，逐步深入

经历过之前的准备工作，基本我们已经成功了40%，接下来只需要在评审时注意以下几点即可。

1. 会议前我们已经将相关资料发送给参会人员，为避免大家没有看或时间较久，已经遗忘，我们应该在正式进入功能细节之前先快速梳理本次需求的业务目标。
2. 确保大家明确业务目标之后，进而对业务逻辑进行串联，注意这个环节需要串联的是业务逻辑，而非你的页面功能逻辑。该过程如果涉及到专有名词或特殊场景应该进行着重解释。
3. 梳理完业务逻辑之后，还需要对此次业务涉及到的角色或岗位进行描述，旨在让大家明确该业务涉及多少岗位或角色，每个人负责什么。
4. 梳理完业务之后，才应该进入本次的需求设计，进入详细设计之前，产品经理应该先对页面组进行串联和解释。
5. 经过上述几个环节，所有人对需求及角色、页面等的关系网已经构建了初步形态，接下来我们要做的，是本次需求评审的重点部分，也是最耗费大家精力的部分——各页面、各功能的细节评审。

通常我在评审页面时会按照如下思路：

1） 首先描述该页面需要实现的业务目标是什么，通过这个页面用户要完成那些工作，实现什么效果。其次描述哪些人都会操作这个页面，这些人通过这个页面功能都做什么事，页面是否需要做数据权限控制。

大多时候我们也会把几个事情混合在一起说，如果准备充分，角色或业务复杂时，大家可以列一个简单的用户画像表格，说清楚角色、功能、数据之间的关联关系即可。很多种方法，大家选择自己擅长的即可，目的是把事情说清楚。

总之这个环节不要一进来就陷入细节介绍。就好像展台上放了个大黑块，台下的人还不知道这个大疙瘩是啥呢，你就开始说里边的按钮了，最终导致的结果就是“鸡同鸭讲，貌合神离”，这也是很多小伙伴疑惑的明明评审时大家都没有问题，开发实施时怎么突然就各种说不通的原因。

2）重中之重：逐个讲解各个功能需求！！！

在讲解功能时，产品可以先讲解这个功能的场景，再讲解其操作先决条件，再说做了这个操作之后，系统应该有什么响应或处理，如果涉及到状态改变，还应该描述其状态变更情况。

以讲解一个新增发货单的功能为例，我常说的话术是这样：

库存操作人员线下收到销售的发货单之后会登录系统，创建发货申请，点击：【新增】按钮，逐步填入发货及收货信息相关字段，校验全部信息填写通过后进行保存，保存时如果不符合需求文档描述的规则，按照文档所述给出提示。

保存成功后，该发货单的状态更新为“待提交”。

另外重点补充下，操作人所选货物库存不足时，系统应在添加货物不足提示时，同步告知该货物的库管员及采购人员联系方式，方便其电话沟通。这一点在需求文档中也有说明。

3） 补充整体说明

当前页面全部功能描述结束后，如果该页面有一些别的补充规则，应该同步进行描述，比如：列表排序规则，界面适配颜色要求，字体要求，涉及三方接口等。

4） 答疑及讨论

以上环节都结束后，该页面的需求基本已经结束，我们再进入答疑环节，询问大家对需求是否有异议或者不理解的地方，逐步解答。如果有会议前收集到的疑问或需要重点讨论的内容，也可以放在这个环节。

新的产品儿在评审时一定要不断告诉自己：我是古希腊掌管需求的神，他们得先听我说。我最近参与的好几次评审，新人都是不断被打断，常常讲这个功能时，别人在问那个场景的问题，节奏完全被打乱，自己讲的很痛苦，同事听的也很云里雾里。

三、评审后：查漏补缺，完美收官

相信前两部分结束了之后，很多产品人悬着的心终于放下了，毕竟我们的需求评审会议已经完成了90%，但是也别忘记要善始善终哦。

评审会议结束了，但是需求评审还没结束。产品经理还需要快速根据各方的意见对需求细节进行修改，并将结果同步给相关方。这里有个小建议就是速战速决，避免拖延导致遗忘部分内容。

四、全文总结

最后对全文做一个总结，组织一场好的需求评审会主要关注以下几点：