在产品的工作中，沟通和开会可能占到工作时长的70%，真正做产品写方案的时间也许还不到30%，可以说对于会议和沟通技巧的掌握直接决定了产品工作进展是否顺利。
围绕着一个产品的标准工作周期有非常多的会议，有些会议是流程节点关键会议，有些是问题解决沟通会议，而对于产品同学来说，最有主导地位和关键产出的会议就是PRD（产品需求文档）评审会议。
近期在参加几位同学的PRD评审会议时，发现了一些共性的问题，比如线下已知问题放在会上讨论、会议讨论话题零散无引导等等，会议的氛围不是火药味十足，就是聊着聊着就跑偏了，总之会有些低效和混乱。
分析下这些问题产生的原因，其实一部分是来源于会前准备不足，一部分是会议掌控不够。
那么，想要开一个如丝般顺滑的PRD评审会，产品同学应该如何做呢？下面给大家四点建议。
第一，我们要明确PRD评审的会议目的：不是问题解决会，而是方案确认会。
其核心就是，所有已知的待讨论问题，尤其是复杂的待讨论问题，应该在会前沟通完毕，并体现在PRD方案中。
因为已知问题很可能会影响整体方案的设计，如果在PRD评审会议上讨论，可能会导致整个方案无法继续评审，同时在会上针对一个点沟通，会导致会议主线跑偏和低效。
PRD评审会的核心目的是和项目核心成员（技术、测试、业务）在方案投入正式开发之前，最后一次同步和检查，保障大家的理解一致和没有遗漏，所以这一定是在线下针对问题多方沟通确认的基础上进行的。
第二，对于关键研发同学，我们要在PRD撰写过程中就让对方参与进来，实现共创。
这么做一方面是，我们在撰写PRD的过程中，需要确认方案的实现具有可行性；另一方面，我们需要有意让研发同学在方案评审之前对项目实现的大概思路有一定的了解。尤其是当我们遇到一些设计困难时，要主动找研发一起商量，这样会让研发同学有很强的代入感，在方案评审的时候自然不会有大的意见分歧。
第三，产品同学对于方案要完全做到了然于心，对于方案设计的背景和思考要有充足的准备。
产品和研发是死对头这个江湖传闻一般就来源于PRD评审会上的激烈争执，研发会不断提出产品设计和需求背景的质疑：你为什么要做这个事儿，能不能不做，为什么要这么做，有什么更好实现的方式。看起来，研发对产品提出的问题都非常的致命，听起来都不怎么友好。如果产品自己还说不清楚，那么就会招致更加猛烈的炮火。
其实仔细分析下，研发这是出于资源有效性利用的角度来提问的，所以产品不能只想着做需求，不管资源如何最高效的利用，如果我们在事先也思考过这些问题，那么其实产品和研发就不是对立的。
作为产品我们要清楚，就算研发不提这些问题，我们也还是要想清楚这些问题，否则就可能会做一些伪需求和无用功。所以，在方案设计的时候，我们要思考清楚，做这件事是解决什么业务问题，问题的严重程度，问题解决的必要性，如果要砍需求那些是能砍的，那些是不能砍的。这样才能在评审会上做到游刃有余。
第四，产品要学会掌控会议的节奏，避免低效和跑偏。
在PRD评审会上，研发都是带着如何实现的思考来听产品同学讲方案的，所以就会不断的抛出一些实现的问题，甚至会开始探讨如何实现的思路。这时候，我们要适当的把控下节奏，分清楚哪些问题可以会后讨论，哪些需要在会上探讨。
大的原则就是，如果影响产品方案的设计的，尽量在评审会上明确，如果仅是技术方案待讨论不影响产品的设计，这样的话题就可以留在会后探讨。
如果一些业务规则或者外部合作方的情况不明确，导致方案可能会变动，那么这样的问题也可以遗留和搁置，放在会后确认。
PS：当然这种问题，尽量在会前识别清楚，因为在技术PRD评审之前，产品还需要跟核心业务沟通明确方案，在这个过程中就应该把问题整理清楚并在会前得到解答。
以上，就是给产品同学针对PRD评审会议的四点建议，希望大家能通过PRD评审会加深与研发的合作和信任，收获个人威信实现产品能力的提升。
网友评论