很多产品经理谈到需求评审都会心理咯噔一下，面色不大好，因为总被虐的不要不要的，阴影面积不知道有多大。而相反有些产品经理却对需求评审情有独钟，享受与各路大侠切磋、舌战群雄的快感，大有三国诸葛亮舌战群儒，排除众议之势。

接下来，先看下需求评审是什么？

需求评审简单来说就是一个评议、审查、明确需求、统一思想并确定实现过程的会议，俗称撕逼大会、挑刺大会、逼死产品经理大会，是产品经理不得不面对的大会。

产品经理在大会中，要对需求及方案进行讲解，并解答市场、运营、设计、技术、测试提出的各种疑问，最终号召大家一起往一个产品目标努力奋斗。

那么为什么要进行需求评审呢？

1.让与会者明确需求是什么，做这次需求对应的业务背景和目的是什么，处于什么样的战略位置，重要性如何

2.让市场、运营、设计、技术、测试等各工种对需求的实现过程和方法达成一致，避免后续的撕逼

3.让市场和运营提前了解项目，提前进行后期市场的推广及运营的准备

4.让技术和测试对产品方案有详细的了解，对有问题的点进行提前提问质疑，以便后续能进行高效的开发

5.让设计、技术及测试评估各自的工作内容及工时以确定方案实现的周期，并和市场及运营确定业务的重要性，看是否要进行模块拆分，分期进行

所谓知己知彼者，百战不殆，所以一定要明白各与会人员的需求，具体整理如下：

明确上面三个问题后，接下来从“评审会前、评审会中、和评审会结束”三阶段如何做好对应的工作。

一、需求评审前

1.和市场及运营再次明确需求，及对应的解决方案是否满足业务的需要

2.将需求、实现方法和核心人员小范围提前沟通，提前消灭掉核心问题，保证整体方案没有出现方向性错误

3.确认需求文档、流程图、原型是否都有完成，是否已经自查没有问题

4.和核心与会人员进行时间的调解及确定

5.至少提前2天发出会议邀请，定好会议室（注：会议邀请要附需求文档、流程图、原型图等相关资料）

6.提前到会议室，过一遍讲述流程，对可能被问到的点进行整理

二、需求评审中

产品新人在进行需求评审时经常犯的错有：

1.一上来就开始讲具体功能

2.什么功能都讲，满面开花

3.对别人提出的质疑，不能给出实际解决方案就开始互怼

针对上面的问题，我们如何进行解决呢？

1.会议开始时一定要先讲需求背景和目的

很多产品经理在会议一开始就直接说功能或方案细节，这个功能实现了什么，那个方案具体怎么实施。试问，如果看一本书，直接看某一页，你知道整本书是要说什么？

所以，开头一定要提纲挈领，说明需求的背景和目的，引导大家进入正题。让大家都知道，为什么产品要进行该方案的设计。

2.要懂得抓大放小，重主干轻枝干

如果你满面开花，首先是时间肯定不允许；其次参会人员会很不耐烦；更重要的是不能针对核心问题深入讨论，确定解决方案。

所以，一定要针对主干流程和核心功能进行详细讲解，对次要的比较常见的功能一笔带过。比如电商类产品，要对用户购买支付流程及订单流程进行详细讲解，对于简单的签到、密码修改等小模块一句带过就好。

3.短时间解决不了的可以记录，会后进行讨论

正常情况，核心功能是要在会前小范围讨论确认过的，会议上不会出现这样情况。但是，不排除会出现之前遗漏的情况。

面对这样的情况，就比较考验产品经理临场发挥能力，能解决的直接会上说出自己的解决方案，一起讨论。如果暂时没有想到合适的方案，而且需要会后进一步和其他部门确定的，可进行记录，会后讨论。

千万不要不懂装懂，和别人互怼。这会直接让自己的信任度直接受到10000点暴击，让其他人觉得这产品经理不专业、不靠谱。

当然，作为会议，肯定是有一套标准的会议流程作为讲解指南，这样才可以从大方向把控产品的节奏，不至于被别人带跑偏。下面的会议流程图，作为参考：

三、需求评审后

是不是审核后，没啥事了呢？

童鞋该醒醒了，还有一大堆内容要你去处理呢，哪有开会后不总结整理的道理。我们在评审会议后需要做的内容有：

1.整理遗留问题，找相关人员沟通解决，给出对应的解决方案

2.发出会议记录，每个问题都要有行动计划

3.发出修改后的需求文档、原型

4.明确责任人及反馈排期

注：如果需求评审涉及到方案的大改，则需要重新针对新的方案进行评审。

说起来容易，做起来难，还是需要童鞋们在理论和实践中不断去磨练和提高。在不断被虐之后，我们的沟通能力、思考能力、统筹协调能力都会不断的提高。

相信哪天你也可以和诸葛先生一样，舌战群雄，想想就觉得自己牛逼的不要不要的。

作者：紫川君(产品设计及生活感悟随笔作者)              公众号：产品设计星球