需求评审，对于绝大多数产品经理来说再熟悉不过了。
而这个评审会，往往也给产品经理带来不少烦恼：
在会议上，直接被研发工程师怼方案不合理，技术无法实现;
参与人员没有围绕评审会的目标去讨论，而是衍生到其他问题，导致效率不高;
需求评审会议顺利结束，但在实际开发中却不断发现漏洞，导致不能按照计划顺利执行;
......
如何高效做好需求评审，对于产品经理来说，也是一个很大的挑战。
将需求评审能做到更规范，减少评审过程出现的问题，是产品经理必备的技能。
下面就依照需求评审“是什么、做什么、怎么做”的逻辑，讲述一下：
什么是需求评审
简单点来说，就是在产品规划完之后，把团队聚集一起讨论方案的会议。
如方案通过，则按规划的方案，继续往下实施;
如方案不通过，根据意见进行改善;
需求评审的参与人员有哪些？
每个公司的团队结构不一致，但通常包括：
产品经理/项目经理
开发工程师(前端、后端);
测试工程师;
设计(UI、UE);
需求提出方;
需求评审能做什么
确认将要实现的内容，以及要达到什么样的目的;
确认方案的可行性，查漏补缺;
让参与人员了解自己所负责的内容，并解决疑问;
确认交付内容的时间目标，目标达成一致;
需求评审流程是什么
评审会议前
1、至少提前1天通知参与人员
可以通过“邮件”、“项目组群”等方式通知参与人员，通知内容包括：
具体时间
给出预计时间，一方面，这样可以让参与人员得知你对整个需求评审会议内容的掌控;
另一方面，参与人员能根据时间安排手头上的其他任务，以致于节奏不被打乱。
会议地点
会议主题
提前明确会议目标，可以让参与人员做好相关资料的准备。
2、提前发送资料
资料大概包括：
相关的原型
产品需求文档(PRD文档)
流程图
对于复杂的功能，可以提前查看流程图，来初步判断是否有遗漏的地方。
计划表
根据计划表，找到自己所负责的功能，可以提前整理疑问。
讨论问题的针对性较高，以减少在后续执行过程中出现的问题。
3、提前和相关负责人沟通需求
对于可能存在的问题，先提前思考自己想要确认的东西是什么。
思考完之后，再带着问题提前与相关负责人进行沟通，确认自己方案的可行性。
在评审前，解决一些自己不确定的问题，可以增加自己的信心。
在评审过程也可以减少一些不必要的纠纷，确保会议顺利进行。
评审会议中
1、注意讲解的流程
需求背景，为什么要做
目的是让参与人员了解这个需求是怎么产生的，是为了解决什么样的问题。
需求概述，需求提出方想实现什么
描述该产品方案能如何解决需求。
功能模块以及人员安排
根据计划表，明确要完成的功能是什么，以及相关人员的分工。
让每个人清楚自己要做的内容，找到会议的注意点。
讲解业务流程
让参与人员了解是涉及改动的模块，判断是否会牵一发而动全身。
展示原型
在展示原型时，重点讲核心功能;一些简单的小功能，简要描述。
在讲解功能的时候，不是讲越细就越好。
因为人在短时间之内，能获取并且记忆的内容有限。
如果所有功能都事无巨细地讲：一方面，时间会难以把控;另一方面，容易错过重点内容，不能针对核心问题进行讨论。
最后，说明内容的预计交付时间
确认内容以及时间目标，与参与人员在目标上达成一致，确保计划顺利执行。
需求评审通常流程：
2、移情聆听
在需求评审会议上，总需要解决一些疑问。
当有人对方案提出异议时，不要急于反驳，不要觉得别人在否决你。
否则容易导致双方情绪高涨，最后不欢而散。
可以试着站在对方的立场去聆听，了解其提出这个问题的目的是什么，再来思考如何去回答。
遇到问题时，学会回答问题，而不是逃避问题或者找借口为自己辩解。
需求评审的目的是为了解决问题，大家的目标是为了让产品做得更好，而不是辩论谁对谁错。
3、做好会议记录
在会议过程中，随时记录下争论的遗留问题：
记录会议过程重点讨论的问题，以及讨论结果;
记录会议过程中讨论过，但却没有讨论出结果的问题;
4、方向不要偏
如果不是会议的重点问题，可以会后再自行讨论。
例如：
按钮的样式、提示语的文案，等等;
评审会议后
1、整理并发送会议记录
将在会议上做的记录整理好后，及时同步给参与人员。
2、发送修改后的方案
根据参与人员提出可行性建议，调整好原型、流程图等方案，并及时同步。
3、评估是否需要再次召开
如果方案涉及到较大的调整，建议再次召开会议，重新针对新的方案进行评审。
4、执行计划
如产品方案可行，则落实到具体执行，开始跟进计划。
写在最后
在工作中，不同岗位的人都有自己关心的问题，产品经理要面面俱到也是很困难的。
我们产品经理能做的是通过不断学习，这样才可以尽可能减少出错。
对于每次需求评审会议，要学会总结在需求评审会议发生的问题。
可以尝试记录每个岗位关心的内容，在每次评审的时候，准备好相关的资料。
这样在往后的需求评审会越来越顺利，大家也会越来越认可自己。
