编辑导读：作为产品经理，一定会经历需求评审，你是否被怼的哑口无言过？你的团队是否昏昏欲睡过？你们是否不欢而散过？怎样开一场需求评审呢？本文作者分享了他的几点看法，希望对你有所帮助。

一、需求评审是什么？

要想开一场完美的需求评审会，必须明白需求评审的目的，只有明确目的后，做好相关的准备工作才能够事半功倍！

1. 需求评审的目的

• 检视需求的合理性与完整性，降低需求风险。
• 与项目干系人对项目目标、需求达成一致，方便其他工作人员能够了解工作任务，从而增强团队协作能力。
• 能够对产品进行全方位的论证，验证或更改自己的想法、获取更多的想法，进行头脑风暴，完善产品需求。头脑风暴的作用有以及几点，不仅仅试用与需求评审也适用于其他方面。

头脑风暴

1. 让参与者敞开思想集体讨论，相互启发激励，以弥补知识缺陷
2. 引起创造性设想的连锁反应，产生尽可能多的设想，并使各种想法在相互碰撞中激起脑海中创造性风暴
3. 再对设想进行客观，连续的分析
4. 从而找出解决难题的黄金方案

如果没有需求评审将会产生什么后果呢？

1）需求严重的失真性！

2）增加项目成本，项目成员对需求的意见没有保持一致，不清楚自己要做什么，也不知道做成什么样子，什么时候交付，严重影响项目的进度。

3）思维角度分歧，产品经理和工程师各自的视角不一样，工程师代表的是技术思维，而产品经理代表的是产品和用户思维，这两种思维天然就存在一些冲突和矛盾。

2. 成功的需求评审

一场成功的需求评审会。是能够完整，清晰传递产品目标，产品功能，能获得团队认同，并且会后团队能够配合实施的，从而能有效推动产品进度的会议。

• 产品目标：能够讲明白，我们要做什么产品，为什么要做，做这个产品的意义，能解决什么问题。
• 产品功能：能够说出产品功能实现的意义和规则，涉及到哪些方面，前端、后台、UI、UE、运营、测试，并且向团队指出为了完成该需求应该怎么做，合理的分配任务。
• 产品实施：解决会上提出的问题，输出会议纪要及项目计划表。

二、如何做好需求评审？

1. 评审会前准备

（1）邮件通知

任何形式的沟通，都必须以邮件（公司联系方式）来确认，邮件的内容包括一下几个方面。

项目背景介绍，如果是新项目，要输出 BRD 和市场调研分析， 用户画像，老项目要输出数据分析、用户反馈，竞品状况，也就是需求来源等，让团队成员对需求评审会的项目有个大致准备，每个人都可以在会前有思考的过程，方便各成员能做好相关的会议准备。

输出项目目标，本次项目，你要达到什么目的，评估标准，作为产品经理可以提前通过该种方式让团队成员知道自己的观点和想法，提前输出，方便会议时能够更好的理解。

输出项目文档，BRD/MRD、PRD、流程图、结构图、原型图、以及与之相关的所有文档。不做无准备的仗，只有文档的输出才能让团队成员能够全方位的了解项目。

邀请人员：测试、开发（前端、后端、客户端、运维）、UI、UE、运营、以及Boss和确定开会的时间和地点。因为不是所有人的时间都是一致的，只有提前确定时间，才能确保会议的正常进行，必要时，需要会前多次通知及确认。

（2）提前预演

预演不需要太多人，项目相关的核心人员（产品经理、前端主管、后台主管）即可。

从他们的角度看有没有漏洞，证需求文档的主要逻辑没有问题，从而明确需求能不能实现

为了获取认同，获得会议的支持者，提前通个气，这样可以能减少很多不必要的矛盾，甚至是领导的肯定，那么接下来的项目推进，就会非常轻松，在遇到争议性较大的议题时，这一点会非常有效。

（3）自我的会前准备

产品经理作为需求评审会的核心成员，必须对该项目有深层次的了解，

例如需求背景，需求的来源，目标用户，市场现状，遇到的问题，调研结果，要解决问题的深入分析和思考。

通过自我的思考和准备进行改进和完善，通过准备工作发现要评审的产品方案的不足并加以修正，在需求评审会上提高需求评审通过的概率。

只有在会前有过准备和思考并且能够在会议时了然于胸，才能立于不败之地，不然会被其他人员怼的哑口无言。

2. 会议中

你穿上了一身破烂T恤，打开会议室的门，连接好投影仪，睁开一夜未眠的双眼，这场战斗才刚刚开始。

那么，这个会要怎么开？

开会有时候就是靠着你这一张三寸不烂之舌，征服大家。

作为产品经理，要有良好的表达能力，描述项目时需要有逻辑，有条理的叙述，明确的说出自己的想法及项目的相关内容，但是我们需要以事实为依据，以数据做基础，不能凭空想象，无中生有。

首先不要想当然的认为别人和自己具有一样的背景，比如设计人员不知道如何开发，开发人员不熟悉具体的业务知识，在阐述一个需求的时候要考虑到大家都是来自不同背景的，用大家都能理解的方式进行需求。

在进行需求评审时前不要忙着讲解用户操作流程，演示原型图，

我们应该对需求的价值进行说明，然后说明需求的背景以及需求想要实现什么目标、解决什么问题，这样的话大家对需求的理解才能更深刻，才不会在后期质疑是否需求的必要性。

尽量用举例子、讲故事的方式来说明需求。在讲解用户操作时可以结合具体的业务场景，与每一块的负责人确认排期时间是否有疑义。

产品经理不仅要会说而且还要会听，善于倾听他人意见和想法。

作为一个团队，每个所对应的岗位不同，思考的维度就会不同，工程师考虑的是技术，UI考虑的是交互，老板考虑的是商业价值等等。

例如产品经理和工程师，产品经理在陈述完产品设计思路后，工程师就会对产品设计提出意见，然后产品经理会回应工程师的意见，这个过程中的讨论经常转变成一场无关主题的争论。

比如对于登录功能的设计，是否需要在密码中支持特殊符号，产品经理的意见是需要支持。

因为不同人对于密码的要求不一样，有很多用户会使用特殊字符设置密码，不能通过特殊字符设置密码会给用户一种不安全感。

工程师认为特殊字符过于复杂，产品可以定义一个统一的规则例如只支持数字和字母，这样产品规则就简单了。

注意，在这个过程中，大家讨论的焦点并不是产品的技术实现解决方案，而是对产品的设计和对用户的理解，如果产品经理能够把握住这个差别，应该耐心地询问工程师这两种设计方式在实现上有没有区别，如果没有区别，则建议选择让用户更具安全感的支持特殊字符的方式；

如果在技术实现上有区别，那么再来衡量具体实施工作量，看投入产出是否合适。通过对问题的区分可以化解争论。

产品经理要在这个过程中要善于倾听，倾听别人的意见和想法，站在别人的角度思考问题，理解当事人的观点，从而沟通出最合理的方案。

产品经理不仅要会说会听还要会记

需求评审会时，一定一定要安排产品助理进行会议记录，如果没有助理自己准备录音笔，需求评审会，会遇到很多问题和想法，不可能当时就解决，优先解决重点内容，记录会议内容可以防止问题的遗漏，对于细节问题，可以私下单独联系解决。一份会议记录可以帮助你回忆整个会议内容，事后可以针对性的进行内容整合分析。

3. 会议后

会议开完了就完了吗？那可不是的，一天的战斗才刚刚开始，会议后依旧十分的重要。

会议后需要对会议记录进行整理，对于没有解决的问题及时的处理，需求需进行修改，并且修改好以后，把会议修改的内容全部发出来，达成一致的、修改的、疑问的一一列举出来，并输出反馈时间表，要及时同步给大家，并且在群里进行简要提醒和说明。如果遇到自己解决不了的问题，可以找相关人员进行私聊解决，或者小团队讨论。

做好会议总结：通过总结分析今天会议自己的不足，以及整个会议遇到的问题，和会议得到的结论和观点，及时的反思优化，避免下一次发生同样的错误，为项目的进一步推进做好准备。

跟进各个角色：配合测试输出用例，配合运营输出运营需求，配合UI输出UI需求，配合UE输出UE需求，配合开发输出功能列表。进行项目管理，输出时间节点完成日期落实到责任人，以及后续评审日期，上线全环节跟进，并整理需求。

总结

产品需求不会是百分百正确，我们要客观面对需求，及时止损，及时改变。

需求评审会也不是一次就能解决问题的，我们需要与时俱进，随时更新，面对新需求不畏惧，面对需求评审会，评审会议不要纠结交互细节和设计细节，而是判断产品方面、研发流程、时间成本、完善产品功能，对大方向进行决策。

做好会前准备，合理通知，体验预演，自我思考，掌握会议的整体局势

会中实施，通过沟通，倾听，记录，把握会议的脉搏

会后总结，及时整理认真反思，解决会议问题，开始项目跟进，推进项目实施。

本文由 @心如草木 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。