评审老被怼拆解评审会减少被怼

　　评审会是产品开发的重要环节，产品参与人需要在这个会上对关键要素达成一致，从而才能保证产品的顺利上线。那么，评审会该如何开呢？
　　被怼，只能减少不能消除，减少是可以有方法，本文就讲述了一个方法，人人可做到。
　　PRD的评审会，是一个方案的确认会，主要讲产品是什么，为后续环节怎么做提供依据。
　　本文通过将PRD评审会议过程进行结构化拆解，然后将执行过程标准化，以解决PRD评审会常见问题，提高评审效率和质量。
　　本文主要对如下几个环节的操作进行了说明：
　　PRD评审会目的；
　　会议的两大原则；
　　会前准备；
　　会议议程；
　　会后收尾。
　　一、会议目的
　　搞清楚目的是做事情的第一个步骤，因为有了目的才能有的放矢，确定原则，对方案进行取舍优化，对PRD的评审会议也是如此。
　　PRD评审会的会议目的有两个，一主一次：
　　最主要的是统一各方对产品方案的认知，以便项目组协同作战；
　　次要的方面是通过会议群策群力，查漏补缺。
　　如果主次弄混了，就会评审会变讨论会，讨论会是应该在方案确定之前进行的。
　　如果有大幅修改，不二审会有很大的认知不一致风险，进而给项目带来额外的成本和风险；进行二审不仅延误时间，同时还会让合作方对你能力产生怀疑。
　　如何评估PRD的评审会是开好了呢？
　　理想情况下，所有参会人员在三个方面都理解一致且认同了：方案的整体思路、关键点风险点、细节设计。
　　然而现实中大部分项目是不可能做到的，所以可行的标准是对产品方案：
　　整体思路理解一致且认同；
　　关键点风险点理解一致且认同；
　　对需要注意的详细设计点理解一致且认同，大部分的设计可以不记得，回头看PRD。
　　主要是需求目的，方案的实现思路、实现方式、实现程度、实现范围、时间计划、已知风险的理解达成一致。所谓认同，就是在对疑问进行质询后，认为方案可行。
　　二、会议两大原则
　　问题解决在会前；可能的问题，有预案；
　　就事论事，好的建议要吸收。
　　我们可以借助一个场景来理解：
　　有个大集团M，对某个功能的设计方案进行招标，产品方案就是针对这个招标进行的方案。
　　PRD评审会就是这个招标评审会，会议直接决定了你能不能拿到这个大集团合同，赚到钱。对方参与招标评审的是除产品经理外的相关方。
　　这时应该如何去做，才能最大可能的通过招标评审，拿下合同，限制条件是没有灰色行为。
　　总结起来，其实就是上面的两条。
　　三、会前准备
　　要将问题解决在会前，就需要充足的准备，一个会开的顺利不顺利，会前准备的工作可以占到80，另外20才是在会上取得的。
　　这个会前准备包括两个方面：沟通准备，资料准备。
　　如果我们要拿下上例中M集团的合同，对他们的关键人员提前接触是必须的，当好服务员，服务周到也是必须的。
　　1。沟通准备
　　是指要在开会前与关键人员就方案进行沟通，并有一致的认识。
　　1）包括与业务方进行沟通，对方案思路、关键点达成一致。
　　2）与项目执行人员（设计、开发、测试等）对方案进行建议和提出意见的人进行沟通，提前扫雷。有两个方式，一个是将产品方案邮件给相关人员，请他们将问题邮件发回来，你在针对每个问题进行回复；另外一个是一对一的进行沟通，可以微信、可以面对面。
　　3）提前建立微信或者QQ、钉钉等项目群，将核心人员拉入。
　　2。资料准备
　　1）将PRD文档上传至约定位置（如Teambition、leangoo等写作工具，也可能是直接邮件附件，各公司不一而论）；
　　2）提前至少一天发出PRD、原型等资料，尽量提前23天，如果大型项目还要提前。
　　目的是让项目成员有足够的时间了解方案，只有了解了，PRD评审会时，讲解时才容易理解，不会出现一些初级问题；同时只有了解了，才更可能进行有效的评判和提出一些有价值的问题。
　　收件人是所有与项目相关的成员，包括业务方、设计、开发、测试，抄送自己的主管、各方的直接主管；如果有约定，可以按约定抄送，比如有些公司要求小组（部门）负责人必须参会，就需要将其列入收件人而不是抄送人。
　　发送时机在与关键人员就方案基本达成一致之后。
　　3）预订会议室，并发送会议邀请。
　　会议室要提前订，没有会议室预订制度的公司，最好提前在会议室门上贴个纸条，说明占用时间。变更会议时间可能会导致人员不齐，或者影响项目成员原来的工作计划。
　　会议邀请的标题，要直接体现是什么项目的PRD评审，写清楚时间、地点、参与人员、附带PRD文档或者文档地址。实际操作中也大部分会将发送资料和发送会议邀请两件事，合二为一进行。
　　4）提前考虑好哪个地方需要重点说明、哪些地方容易被挑战，可能有什么问题会被扔出来。
　　5）指定会议的记录人员，正常情况下，是由产品经理自己记录。
　　6）如遇时间变更，及早通知参会人员；不要漏了，会被骂的。
　　四、会议议程
　　作为一个格式会议，会议的议程是固定且相对简单的，主要包括三个部分：
　　介绍项目背景、方案目标、期望时间；
　　介绍方案、答疑、讨论；
　　Review会议记录，会议成果确认。
　　1。介绍项目背景、方案目标、期望时间
　　介绍背景、方案目标有些同学不会去做，但这并不是一个可省略的环节。
　　因为项目背景和目标是方案思路的基础，包括了很多的限定条件，介绍后容易让参会人员理解你的设计思路，理解你设计出发点和设计终点，从而在视觉方案、技术、测试方案设计时，在大方向上能够有所遵循。
　　另外一个好处是，给参会者强调了共同目标，会形成站在一条战线上，如何去共同努力去实现目标的思维方向，而不是有略微对抗的思维。例如，没说明时，技术同学可能会跟你争，方案太差，工作量太多；但是说明目标后，技术同学的思维很可能转变为如何能更好的实现这个目标。
　　虽然工作量大，但是对目标有益，这就是站在一起了。
　　介绍方案时，要按照总分的顺序进行，先概要介绍一下思路、结构，再分块详细介绍。
　　正常情况下，各公司的PRD模板虽有所不同，但应该也都是按照总分结构设计的。有些同学喜欢在原型上讲，PRD辅助；有些同学喜欢在PRD上讲，原型辅助，都是可以的，看团队磨合情况，前一种情况多一些。
　　2。介绍方案、答疑、讨论
　　在讲的过程中，还要进行答疑。如果参会者有疑问，一般采用马上提出或者讲完一个模块再提问的方式，主讲人要进行答疑，这个过程中也可能会发生方案变更，如果变更就要记入会议记录。
　　如果答疑过程中产生了一些不能在会上立刻决策的问题，要在会解决，也要记入会议记录的未决事项，同时需要确定跟进人、反馈时间。
　　答疑环节容易发散，导致会议失焦，需要注意几个事情：
　　最经常的事情是讨论着就进入技术实现细节，这个要及时拉回，技术实现细节是技术方案环节的事情；还有可能进入的是设计细节，也需要及时拉回；还有可能遇到的是我觉得用户不是这样的，而是这样的类似对方案的挑剔问题，这时就是体现专业性的时候，拿出理由说服他。
　　除此外还需要从长远考虑，跟设计、技术有一个约定，产品设计环节双方都是感觉僵持不下时，应该听产品的，产品对设计方案负责。
　　但是这个过程要注意硬刚和拍脑袋决策，在确信自己方案的前提下进行，否则就应该作为未决事项，会后进行解决。
　　经过结果说明和答疑环节，会议记录应该有变更事项和未决事项的记录，对每个会议记录，所有参会者花几分钟一起进行一次确认。检查是否每个未决事项都有跟进人、反馈时间。
　　3。Review会议记录，会议成果确认
　　Review过会议记录后，需要让项目后续各方给出自己的反馈时间表。如果能当场确定完成时间的当场确定，不能的需要给出可确定的反馈时间。
　　例如，一个项目设计工作量小，但是开发大，这时设计可能直接给出设计稿评审时间是下周二，而技术则只能给出来周五给你技术方案完成评审时间。将各方后续的执行动作、跟进人、时间记入会议记录。
　　4。关于会议记录
　　所有会议都要记会议记录。记录的原则是：记不同、记结论。
　　记录与原来方案不同的地方，包括修改和补充；记录对某个问题的讨论结果；对只是疑问解答而未进行变更的无需记录；记录结果也可能是确定的问题解决方案，也可能包括后续跟进人，反馈时间等会议成果。
　　5。关于会上争论
　　评审会议相比复盘会、总结会是相对更好开的一个会，因为这个会不涉及敏感的责任划分。
　　如果出现争论，几乎都是对方案的讨论。对解决这种讨论，我总结了一个三步法，可以比较好地解决：
　　跳出争论细节，双方重新回归功能的设计目的，确认目的是相同的；
　　确认方案的基本原则，比如是安全优先，时间优先，还是先有后优等，简单需求这步是被省略的；
　　根据目的和基本原则进行方案取舍。
　　尽量不要出现我觉得用户XXX这样的用语，这个句子表达了自己两个状态特点：一个是我对这个事情没有考虑清楚；另外一个是这是我个人感觉，有猜测的成分。
　　如果想用这个句式，请将问题拆分的更细，从可观察的用户行为、事件上进行分析，以逻辑说服，或者用数据说服。
　　如果相持不下，可以这个问题我们先记下来，会后我再想想，到时还需要向你请教。
　　五、会后收尾
　　会议开完了，不代表PRD的评审工作已经结束，还需要做如下几件事情：
　　整理会议记录并发出，建议在24小时以内；注意变更、未决事项的跟进人、跟进时间；与会前PRD接收人相同，大体是所有参会人员、各方主管（视项目大小发到不同层级）。
　　对已确定需要方案修改的部分，进行修改；如果是方案未决，尽快与相关方确定掉；上传发出更新后的PRD文档；需要列出修改的内容，注意范围与第一个PRD要相同，只多不少；通知项目组PRD文档已经更新。
　　通知项目组PRD文档已经更新；至此PRD评审会议才算告一段落。