需求评审环节是产品经理阐述自己的需求设计思路和结果的一个重要环节，也是需求从设计环节到开发环节转化的中间桥梁。需求评审可以起到承上启下的作用，如果在这个环节不能让相关方理解你的设计思路，要么需要进行二次评审，要么在后续的开发测试过程中会出现很多待确定的事项。
需求评审是需求落地相关的人员审核需求设计结果的过程，用于评审的需求是经过产品经理分析整理后的。需求评审的重要性体现在如下几个方面：
- 与相关方达成统一认知。任何一个团队想要做好一件事情，都需要所有团队成员达成统一认知，这样才能力出一孔，劲往一块使。
- 需求评审过程本身也是一个知识传递过程，相关人员可以与产品经理一起讨论需求设计的前因后果，这有助于相关人员获得用户需求的前期认识。
- 需求评审过程中可能发现不明确的或者遗漏的需求，这需要产品经理进行二次确认。
- 需求评审过程中可能发现某些间接需求或隐藏的问题，参与评审的相关人员可以群策群力共同思考解决问题的方式。
- 当局者迷、旁观者清。再有经验的产品经理也可能犯错或思考不全面，评审人员可以提出更合理或者更有建设性的想法供产品经理参考。
需求评审会的相关参与方
通常会包含如下人员：
1、业务方代表或用户代表，即需求提出人员或最终的使用人员。业务部门直接提出的需求，需要业务方代表进行评审确认；业务部门间接提出的需求（如A部门提的需求最终是B部门使用），则需要功能使用人员进行评审确认。一般来讲比较难邀请到用户代表，用户沟通会也不会和需求评审会议放在一起，因此以业务方代表为主；
若是产品经理自发产生的需求，则邀请最终功能使用人员进行评审。若是直接面向用户的，可以考虑邀请对应的运营人员参与。
2、开发人员，包括系统设计人员、实际开发人员，需求范围较大的情况下，可以叫上开发团队的各级负责人一起参与评审；
3、测试人员，最终参与测试的成员和测试团队的负责人；
4、相关的产品经理，如跨产品线或产品的，业务有关联的产品经理；
5、项目经理，若有；
6、运营人员，若是面向用户的功能需求，需要上线后负责运营的相关人员参与。
需求评审的重点是明确需求背景和实现的价值
在需求评审的开始阶段，首要讲解的不是具体的需求设计结果和功能点，而是要让参与评审的相关人员先明确需求产生的背景。要让大家知道需求产生的来龙去脉，这有助于大家建立初步的认知。从用户那边收集过来的，老板提出来的，业务部门提出来的，还是产品经理团队自己发掘出来的，以及需求产生的过程。
其次要让大家知道需求实现的价值，这时更多都是预估的，若有相关的数据分析支撑，会更有说服力。价值能够量化的情况下尽量量化，用相对科学的方式去计算预估。不能量化的情况则需要定性的描述，把实现的目标和完成的标志说明清楚，这样大家就清楚的知道去实现的意义，价值越大，实现的必要性越高。
需求评审的目的是让大家达成统一的认知
需求评审的过程和普通的开会没什么区别，产品经理陈述需求设计结果，评审人员思考或者提问，以取得对需求设计结果有一致的理解，这是一个互动的过程，可以适当的营造轻松的氛围，有助于大家充分思考。
需求评审很多时候也是一个迭代过程，很多情况下不能一步到位，事实上，这并不是什么坏事。我们都知道，需求失真发现的越早，修复成本越低。评审人员在多次迭代的评审过程中，或许能够发现解决现实问题更好的方案，而且他们对每次评审中出现的情况也比较清楚，知道哪些问题导致评审不通过，哪些需求可能还会有进一步变更等等。
对系统设计人员、开发人员来说，需求理解的越透彻，开发实现的完成度就越高，越不容易偏离需求设计结果。只不过产品经理要控制一下进度，不能无限制的召开多次评审会，要用最快最有效率的方式完成评审，这就需要产品经理在前期需求设计时要充分考虑各方面的影响。
需求评审的过程需要尽量高效
需求评审过程的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后面越马虎。要适当的控制需求评审的节奏，让大家集中注意力进行评审。
需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。
开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。
开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就是坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。争吵还会导致各方分不清楚自己究竟是“坚持真理”还是“固执己见”，毫不妥协或者轻易妥协都不是好办法。
我们应当养成良好的沟通习惯，不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。
总之，需求评审环节是衔接需求设计结果和需求实现过程的桥梁，需求评审环节的好坏，会影响实际需求实现的完成度和实现偏差，产品经理一定要在需求评审环节让大家达成统一的认知。
