评审会是产品开发的重要环节，产品参与人需要在这个会上对关键要素达成一致，从而才能保证产品的顺利上线。那么，评审会该如何开呢？

被怼，只能减少不能消除，减少是可以有方法，本文就讲述了一个方法，人人可做到。

PRD的评审会，是一个方案的确认会，主要讲产品“是什么”，为后续环节“怎么做”提供依据。

本文通过将PRD评审会议过程进行结构化拆解，然后将执行过程标准化，以解决PRD评审会常见问题，提高评审效率和质量。

本文主要对如下几个环节的操作进行了说明：

1. PRD评审会目的；
2. 会议的两大原则；
3. 会前准备；
4. 会议议程；
5. 会后收尾。

一、会议目的

搞清楚目的是做事情的第一个步骤，因为有了目的才能有的放矢，确定原则，对方案进行取舍优化，对PRD的评审会议也是如此。

PRD评审会的会议目的有两个，一主一次：

1. 最主要的是统一各方对产品方案的认知，以便项目组协同作战；
2. 次要的方面是通过会议群策群力，查漏补缺。

如果主次弄混了，就会评审会变讨论会，讨论会是应该在方案确定之前进行的。

如果有大幅修改，不二审会有很大的认知不一致风险，进而给项目带来额外的成本和风险；进行二审不仅延误时间，同时还会让合作方对你能力产生怀疑。

如何评估PRD的评审会是开好了呢？

理想情况下，所有参会人员在三个方面都理解一致且认同了：方案的整体思路、关键点风险点、细节设计。

然而现实中大部分项目是不可能做到的，所以可行的标准是对产品方案：

• 整体思路理解一致且认同；
• 关键点风险点理解一致且认同；
• 对需要注意的详细设计点理解一致且认同，大部分的设计可以不记得，回头看PRD。

主要是需求目的，方案的实现思路、实现方式、实现程度、实现范围、时间计划、已知风险的理解达成一致。所谓认同，就是在对疑问进行质询后，认为方案可行。

二、会议两大原则

1. 问题解决在会前；可能的问题，有预案；
2. 就事论事，好的建议要吸收。

我们可以借助一个场景来理解：

有个大集团M，对某个功能的设计方案进行招标，产品方案就是针对这个招标进行的方案。

PRD评审会就是这个招标评审会，会议直接决定了你能不能拿到这个大集团合同，赚到钱。对方参与招标评审的是除产品经理外的相关方。

这时应该如何去做，才能最大可能的通过招标评审，拿下合同，限制条件是没有灰色行为。

总结起来，其实就是上面的两条。

三、会前准备

要将问题解决在会前，就需要充足的准备，一个会开的顺利不顺利，会前准备的工作可以占到80%，另外20%才是在会上取得的。

这个会前准备包括两个方面：沟通准备，资料准备。

如果我们要拿下上例中M集团的合同，对他们的关键人员提前接触是必须的，当好服务员，服务周到也是必须的。

1. 沟通准备

是指要在开会前与关键人员就方案进行沟通，并有一致的认识。

1) 包括与业务方进行沟通，对方案思路、关键点达成一致。

2) 与项目执行人员（设计、开发、测试等）对方案进行建议和提出意见的人进行沟通，提前扫雷。有两个方式，一个是将产品方案邮件给相关人员，请他们将问题邮件发回来，你在针对每个问题进行回复；另外一个是一对一的进行沟通，可以微信、可以面对面。

3) 提前建立微信或者QQ、钉钉等项目群，将核心人员拉入。

2. 资料准备

1) 将PRD文档上传至约定位置（如 Teambition、leangoo等写作工具，也可能是直接邮件附件，各公司不一而论）；

2) 提前至少一天发出PRD、原型等资料，尽量提前2-3天，如果大型项目还要提前。

目的是让项目成员有足够的时间了解方案，只有了解了，PRD评审会时，讲解时才容易理解，不会出现一些初级问题；同时只有了解了，才更可能进行有效的评判和提出一些有价值的问题。

收件人是所有与项目相关的成员，包括业务方、设计、开发、测试，抄送自己的主管、各方的直接主管；如果有约定，可以按约定抄送，比如有些公司要求小组（部门）负责人必须参会，就需要将其列入收件人而不是抄送人。

发送时机在与关键人员就方案基本达成一致之后。

3) 预订会议室，并发送会议邀请。

会议室要提前订，没有会议室预订制度的公司，最好提前在会议室门上贴个纸条，说明占用时间。变更会议时间可能会导致人员不齐，或者影响项目成员原来的工作计划。

会议邀请的标题，要直接体现是什么项目的PRD评审，写清楚时间、地点、参与人员、附带PRD文档或者文档地址。实际操作中也大部分会将发送资料和发送会议邀请两件事，合二为一进行。

4) 提前考虑好哪个地方需要重点说明、哪些地方容易被挑战，可能有什么问题会被扔出来。

5) 指定会议的记录人员，正常情况下，是由产品经理自己记录。

6) 如遇时间变更，及早通知参会人员；不要漏了，会被骂的。

四、会议议程

作为一个格式会议，会议的议程是固定且相对简单的，主要包括三个部分：

1. 介绍项目背景、方案目标、期望时间；
2. 介绍方案、答疑、讨论；
3. Review会议记录，会议成果确认。

1. 介绍项目背景、方案目标、期望时间

介绍背景、方案目标有些同学不会去做，但这并不是一个可省略的环节。

因为项目背景和目标是方案思路的基础，包括了很多的限定条件，介绍后容易让参会人员理解你的设计思路，理解你设计出发点和设计终点，从而在视觉方案、技术、测试方案设计时，在大方向上能够有所遵循。

另外一个好处是，给参会者强调了共同目标，会形成站在一条战线上，如何去共同努力去实现目标的思维方向，而不是有略微对抗的思维。例如，没说明时，技术同学可能会跟你争，“方案太差，工作量太多”；但是说明目标后，技术同学的思维很可能转变为“如何能更好的实现这个目标”。

虽然工作量大，但是对目标有益，这就是站在一起了。

介绍方案时，要按照总-分的顺序进行，先概要介绍一下思路、结构，再分块详细介绍。

正常情况下，各公司的PRD模板虽有所不同，但应该也都是按照总-分结构设计的。有些同学喜欢在原型上讲，PRD辅助；有些同学喜欢在PRD上讲，原型辅助，都是可以的，看团队磨合情况，前一种情况多一些。

2. 介绍方案、答疑、讨论

在讲的过程中，还要进行答疑。如果参会者有疑问，一般采用马上提出或者讲完一个模块再提问的方式，主讲人要进行答疑，这个过程中也可能会发生方案变更，如果变更就要记入会议记录。

如果答疑过程中产生了一些不能在会上立刻决策的问题，要在会解决，也要记入会议记录的未决事项，同时需要确定跟进人、反馈时间。

答疑环节容易发散，导致会议失焦，需要注意几个事情：

最经常的事情是讨论着就进入技术实现细节，这个要及时拉回，技术实现细节是技术方案环节的事情；还有可能进入的是设计细节，也需要及时拉回；还有可能遇到的是“我觉得用户不是这样的，而是这样的……”类似对方案的挑剔问题，这时就是体现专业性的时候，拿出理由说服他。

除此外还需要从长远考虑，跟设计、技术有一个约定，产品设计环节双方都是感觉僵持不下时，应该听产品的，产品对设计方案负责。

但是这个过程要注意硬刚和拍脑袋决策，在确信自己方案的前提下进行，否则就应该作为未决事项，会后进行解决。

经过结果说明和答疑环节，会议记录应该有变更事项和未决事项的记录，对每个会议记录，所有参会者花几分钟一起进行一次确认。检查是否每个未决事项都有跟进人、反馈时间。

3. Review会议记录，会议成果确认

Review过会议记录后，需要让项目后续各方给出自己的反馈时间表。如果能当场确定完成时间的当场确定，不能的需要给出可确定的反馈时间。

例如，一个项目设计工作量小，但是开发大，这时设计可能直接给出设计稿评审时间是下周二，而技术则只能给出来“周五给你技术方案完成/评审时间”。将各方后续的执行动作、跟进人、时间记入会议记录。

4. 关于会议记录

所有会议都要记会议记录。记录的原则是：记不同、记结论。

记录与原来方案不同的地方，包括修改和补充；记录对某个问题的讨论结果；对只是疑问-解答而未进行变更的无需记录；记录结果也可能是确定的问题解决方案，也可能包括后续跟进人，反馈时间等会议成果。

5. 关于会上争论

评审会议相比复盘会、总结会是相对更好开的一个会，因为这个会不涉及敏感的责任划分。

如果出现争论，几乎都是对方案的讨论。对解决这种讨论，我总结了一个三步法，可以比较好地解决：

1. 跳出争论细节，双方重新回归功能的设计目的，确认目的是相同的；
2. 确认方案的基本原则，比如是安全优先，时间优先，还是先有后优等，简单需求这步是被省略的；
3. 根据目的和基本原则进行方案取舍。

尽量不要出现“我觉得用户XXX”这样的用语，这个句子表达了自己两个状态特点：一个是我对这个事情没有考虑清楚；另外一个是这是我个人感觉，有猜测的成分。

如果想用这个句式，请将问题拆分的更细，从可观察的用户行为、事件上进行分析，以逻辑说服，或者用数据说服。

如果相持不下，可以“这个问题我们先记下来，会后我再想想，到时还需要向你请教”。

五、会后收尾

会议开完了，不代表PRD的评审工作已经结束，还需要做如下几件事情：

• 整理会议记录并发出，建议在24小时以内；注意变更、未决事项的跟进人、跟进时间；与会前PRD接收人相同，大体是所有参会人员、各方主管(视项目大小发到不同层级)。
• 对已确定需要方案修改的部分，进行修改；如果是方案未决，尽快与相关方确定掉；上传/发出更新后的PRD文档；需要列出修改的内容，注意范围与第一个PRD要相同，只多不少；通知项目组PRD文档已经更新。
• 通知项目组PRD文档已经更新；至此PRD评审会议才算告一段落。

公众号：qusujiyuan；微信号：qusujiyuan2151

本文由 @曲速纪元 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议