很多产品经理谈到需求评审都会心理咯噔一下，面色不大好，因为总被虐的不要不要的，阴影面积不知道有多大。而相反有些产品经理却对需求评审情有独钟，享受与各路大侠切磋、舌战群雄的快感，大有三国诸葛亮舌战群儒，排除众议之势。
接下来，先看下需求评审是什么？
需求评审简单来说就是一个评议、审查、明确需求、统一思想并确定实现过程的会议，俗称撕逼大会、挑刺大会、逼死产品经理大会，是产品经理不得不面对的大会。
那么为什么要进行需求评审呢？
1.让与会者明确需求是什么，做这次需求对应的业务背景和目的是什么，处于什么样的战略位置，重要性如何。
2.让市场、运营、设计、技术、测试等各工种对需求的实现过程和方法达成一致，避免后续的撕逼。
3.让市场和运营提前了解项目，提前进行后期市场的推广及运营的准备。
4.让技术和测试对产品方案有详细的了解，对有问题的点进行提前提问质疑，以便后续能进行高效的开发。
5.让设计、技术及测试评估各自的工作内容及工时以确定方案实现的周期，并和市场及运营确定业务的重要性，看是否要进行模块拆分，分期进行。
所谓知己知彼者，百战不殆，所以一定要明白各与会人员的需求，具体整理如下：
明确上面三个问题后，接下来从“评审会前、评审会中、和评审会结束”三阶段如何做好对应的工作。
一、需求评审前
1.和市场及运营再次明确需求，及对应的解决方案是否满足业务的需要。
2.将需求、实现方法和核心人员小范围提前沟通，提前消灭掉核心问题，保证整体方案没有出现方向性错误。
3.确认需求文档、流程图、原型是否都有完成，是否已经自查没有问题。
4.和核心与会人员进行时间的调解及确定。
5.至少提前2天发出会议邀请，定好会议室。（注：会议邀请要附需求文档、流程图、原型图等相关资料）
6.提前到会议室，过一遍讲述流程，对可能被问到的点进行整理。
二、需求评审中
产品新人在进行需求评审时经常犯的错有：
1.一上来就开始讲具体功能。
2.什么功能都讲，满面开花。
3.对别人提出的质疑，不能给出实际解决方案就开始互怼。
针对上面的问题，我们如何进行解决呢？
1.会议开始时一定要先讲需求背景和目的
很多产品经理在会议一开始就直接说功能或方案细节，这个功能实现了什么，那个方案具体怎么实施。试问，如果看一本书，直接看某一页，你知道整本书是要说什么？
所以，开头一定要提纲挈领，说明需求的背景和目的，引导大家进入正题。让大家都知道，为什么产品要进行该方案的设计。
2.要懂得抓大放小，重主干轻枝干
如果你满面开花，首先是时间肯定不允许；其次参会人员会很不耐烦；更重要的是不能针对核心问题深入讨论，确定解决方案。
所以，一定要针对主干流程和核心功能进行详细讲解，对次要的比较常见的功能一笔带过。比如电商类产品，要对用户购买支付流程及订单流程进行详细讲解，对于简单的签到、密码修改等小模块一句带过就好。
3.短时间解决不了的可以记录，会后进行讨论
正常情况，核心功能是要在会前小范围讨论确认过的，会议上不会出现这样情况。但是，不排除会出现之前遗漏的情况。
面对这样的情况，就比较考验产品经理临场发挥能力，能解决的直接会上说出自己的解决方案，一起讨论。如果暂时没有想到合适的方案，而且需要会后进一步和其他部门确定的，可进行记录，会后讨论。
千万不要不懂装懂，和别人互怼。这会直接让自己的信任度直接受到10000点暴击，让其他人觉得这产品经理不专业、不靠谱。
当然，作为会议，肯定是有一套标准的会议流程作为讲解指南，这样才可以从大方向把控产品的节奏，不至于被别人带跑偏。下面的会议流程图，作为参考：
三、需求评审后
是不是审核后，没啥事了呢？
童鞋该醒醒了，还有一大堆内容要你去处理呢，哪有开会后不总结整理的道理。我们在评审会议后需要做的内容有：
1.整理遗留问题，找相关人员沟通解决，给出对应的解决方案。
2.发出会议记录，每个问题都要有行动计划。
3.发出修改后的需求文档、原型。
4.明确责任人及反馈排期。
注：如果需求评审涉及到方案的大改，则需要重新针对新的方案进行评审。
说起来容易，做起来难，还是需要童鞋们在理论和实践中不断去磨练和提高。在不断被虐之后，我们的沟通能力、思考能力、统筹协调能力都会不断的提高。
相信哪天你也可以和诸葛先生一样，舌战群雄，想想就觉得自己牛逼的不要不要的。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
