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

产品老司机手把手教写文档,10天线上课程,零基础掌握产品经理必备7大文档撰写法。了解一下>

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

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

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 协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
评论
欢迎留言讨论~!