需求评审会对于产品经理来说就像家常便饭，需求评审串起了前期的需求调研和分析、不同利益相关方的博弈，以及后续项目落地实施的计划，是产品在正式开发之前非常重要的一环。
需求评审也是产品经理建立个人影响力，和开发建立信任关系的重要途径，所以产品经理一定要重视需求评审，在需求评审时展示足够的专业度，一旦研发小哥哥认可了你的能力，即使之后有小的需求变更，他们也不会愤怒。网上很多关于产品经理和开发互怼的段子，实际上产品和开发是最紧密的战友。.
一、为什么要做需求评审
首先，需求评审可以让需求方明确你的需求分析与他们的要求是否一致，有时候可能是没有这个角色的，需求可能来自于产品经理自己的想法，这时候所有参会人员要有一个意识，假设用户在场，你做的每个决定是不是真的是从用户出发的。
其次，是让设计、研发、测试人员，明白他们为什么要来做这样一个东西，这个东西的价值是什么？这个东西将会长成什么样子。
最后，就是大家来找茬，每个人的思维都有其局限性，当局者迷、旁观者清，再有经验的产品经理也可能犯错或有思考不全面的时候。需求评审可以充分发挥团队成员的力量来完善产品的细节。当然这不意味着产品经理自己可以在尚未准备充分或者自己都没考虑清楚的情况下寄希望与大家来集思广益，那就是产品经理的不负责任啦。
二、需求评审前
1、明确会议目标
明确这次会议的目的与目标，希望通过这次会议解决什么问题。这样在需求评审会议不会出现偏差，即使偏离主题，产品经理也能即使拉回来。
2、提前约好时间
在组织需求评审会议时，产品经理需要先明确需要哪些人员来参加这次评审，比如项目经理、研发人员、测试人员、业务方、设计师等。提前跟他们约好需求评审会议的时间，不是每个人都是刚好在某一时间有空的。我曾经约业务方参加需求评审，约了好几次才约到，甲方就是这么牛。即使临时有人有事没能参加会议，也要将会议纪要和评审结果发给缺席人员，再与其单独进行沟通，确保双方的理解是一致的。
3、提前沟通
提前把相关资料发给评审人员，很多时候研发人员不会去看什么产品需求文档的，（本人有一次将PRD发给研发人员，最后发现只有2个工程师看了），然后与评审人员逐一进行沟通，让对方在会议开始之前就对相关内容有所了解，同时也能提前了解相关人员的关注点在哪里。便于产品经理对这些问题做好准备。这样在评审时会更具有针对性、条理性。
三、需求评审会议中
讲解的流程一般如下：需求背景-用户和需求-功能模块-讲流程-原型与交互-数据指标-需要谁支持-预计上线时间。
切记，不要一上来就讲功能，要先讲解需求的背景，为什么要做这个需求，有什么价值，最好结合用户故事，某<角色>，在什么<场景>下，有什么样的<需求>，我们要做的这个产品刚好可以满足这个需求，从而体现<产品价值>。
产品经理也要学会给开发“画饼”，要将你的产品功能赋予一定的意义，团队实现起来才会更有动力。
具体如何去讲解需求就不展开讨论啦，记住讲需求要有节奏和条理，抓大放小，细节上不要争论，被人带偏了要及时回归正题，基本按照流程讲一遍就完事啦。在会议过程中，对于重要的争论点一定要做好记录，方便会后做会议纪要。
四、需求评审会议后
在需求评审会议，整理会议纪要，对遗留下来的问题，给出有效的解决方案，并抄送给参与评审人员。如有需求可以再进行一次需求评审。
追排期，将修改的文档发给评审人员之后，需要与相关人员进行确认，确认双方的理解一致，并敲定开发周期与时间节点。
五、总结
需求评审被怼是产品经理多多少少都会遇到的问题，这也是锻炼产品经理抗压的一种方式，不要轻易就失去自己的平常心，被怼证明自己考虑还不够周到，能力还能提升。
