管理大师德鲁克曾说，“若经理人将25%的时间用在开会上，那么这个组织就可能出了问题。”产品经理亦是如此。

前段时间人人都是产品经理社区发布了《2017产品经理白皮书》，其中有调查到产品经理日常三件事为：内部沟通（32%）、开会（21.3%）、写文档(13.2)。开会、与技术沟（si）通(bi)、和老板沟通是产品经理最头疼又糟心的事情。产品经理作为产品迭代的发起人和执行推动人，是绝对无法避免开会的，但我们可以让会议更有效率。

总结下我的产品经理工作日常中需要开的会及频次：

• 上下级沟通会，不定期
• 产品组会议，一周一次
• 项目部会议，二周一次
• 产品预研讨论会，随版本周期随时
• 版本评审会，随版本周期随时
• 功能讨论会，随时
• 头脑风暴会，随时
• 需求实现细节讨论会，随时
• …

归纳下上述会议的性质，其实可以分为两类：

• 一类是过程导向的会议，事先规划、主题明确，例如上述的上下级沟通会、产品组会议、项目部会议、预研讨论会、评审会这些；
• 一类是任务导向会议，随时召开、产生决策，例如功能讨论会、头脑风暴这些；

不同类型的会议虽然目的和形式不一，但总的来说最关键的一点都是会议发起人，因为这个人是会议的组织者、引导者、推进者以及后续的跟进者，鉴于产品经理的工作性质及内容，一般这个角色都是产品经理担任，那么作为产品经理的我们如何才能更熟稔地召开会议，并提高开会效率呢？

开会前

明确会议主题

解决什么问题、制定什么决策、达成什么目的。

过程导向型会议一般主题固定且明确，任务导向型会议由于解决问题大多属于突发性质，因此最好事先和相关人等明确会议希望达成的决策和目的，方便大家知道问题的解决进度——需开会确定。

参会人员及会议时间

明确和会议相关的所有人等，并确定各自的空闲时间。

这个过程看似简单却相当繁杂，尽量以核心相关人员的时间为准，其他人需尽量配合，而且会议时间最好在问题提出的两天内，越早越好，避免产生连锁反应，导致其他开发进度的延期。

对于具体的开会时间点，若是过程导向型的大会，笔者一般习惯定在上午10点半，或者下午4点左右，一方面在这两个开始时间点，大家都进入了工作状态，开会效率较高，另一方面也预留了充足的后续讨论时间（午饭前和下班前）。若是任务导向型的小会，笔者一般习惯是即刻解决，可以在会议室或工位处。

预约会议室

根据参会人员的时间安排，预约都能参加的时间段会议室。

当然是要提前预约啦，特别是需要视听设备的会议。若是一些任务导向型会议，例如需求实现细节的讨论会，在涉及人员不多的时候，甚至不需要会议室，直接在工位或某个休息区就及时讨论敲定了。

会议召集

通知参会人员会议时间、会议主题。

若是需要提前准备材料的会议，则需提醒相关人等提前准备并拷贝。当然，也要提醒大家要准时到会。

会议准备

开会前10分钟左右前往会议室调试视听器材，若会议时间较久，还需准备饮用水；若是脑暴、分享之类的会议，也可准备一些零食，营造轻松氛围，方便大家轻松自如地进行讨论。

开会中

维持会议纪律

首要便是要求参会人员准时到达，避免浪费大家时间。其次，若会议中有人交头接耳讨论与会议无关的话题，则需当即打断并给与警告。再者，若会议讨论出现胶着或意见相左无法达成一致时，会议主持者需及时中断论战，引导以避免扰乱会议氛围。

引导会议流程

低效率的会议一定是开会目的不明确，而依然滔滔不绝讨论的。因此，会议主持人在开会中，一定要根据事先明确的会议主题，引导会议流程按照预期进行。若大家讨论的问题已偏出主题，则需及时制止，引导解决议题问题。若出现无法达成一致的问题或另外新的未能确定的问题，则需及时中断，可放在会后另行组织相关人等继续讨论。

此外，会议主持人需调动大家的讨论热情，特别是针对一些开放性的问题，需要以身作则地抛出一些观点带动自由讨论。

明确决策及排期

在提案讨论过程中，会议主持人需注意观察与会人员的反应，确保大家听懂了提案内容，或在决策后确保大家持同意态度，或是大家是否已觉得无聊需尽快结束会议。

对于会议产生的决策，会议主持人一定要确保相关人等都持赞同意见，在意见得到统一后即需趁热打铁，协调相关人等的排期，明确问题得到彻底解决的预估时间。

会议记录

好记性不如烂笔头。对于有很多讨论结果或建议的会议，例如需求评审会，大家对需求原型、交互细节、实现方式等可能会有各种各样的建议，因此产品经理需及时记录下来，方便会后整理并调整。另外，记录这种行为本身也反映了你会重视这些意见，是一种对意见提出者的尊重。

开会后

会议整理和通知

会议结束后，需尽快将会议中做出的决策——相关事项谁处理、怎么处理、处理排期等进行整理，越详细越好，方便问题追踪和会议备忘。

整理后则需尽快发送给相关人等，一般是会议当天就可周知到所有人，方便大家及时处理相关问题，可以很好地督促他们去解决，也方便会后有文档备案及通知备案，避免后续扯皮。

一般来说，过程导向型会议只能处理80%的事情或问题，剩下的20%还需要靠任务导向型会议来解决，因为前者主要是知识技能与信息交流，而后者就是为了解决某些特定问题。在产品经理的工作日常中，像组内会议项目组会议需求评审会这些相对大型、参与人数众多的过程导向型会议，主要解决较为宏观的问题，以确定方向，频次上一般不会太多，而像功能或需求实现方式讨论会这些则是相对小型、参数人数较少的任务导向型会议，主要解决的便是细枝末节的执行问题，正是这类问题，才是产品经理与程序猿们撕逼的主战场，这时候更考验产品经理的应对能力及处理效率。

管理大师德鲁克曾说，

“若经理人将25%的时间用在开会上，那么这个组织就可能出了问题。”

同样，如果产品经理将超过25%的时间用在应急的任务导向型会议上，那么他的工作效率也可能出了效率，因为在进行过程导向型会议时，产品经理并没有考虑到所有问题，因此就造成细节问题不得不通过任务型会议去解决。希望所有的产品同仁们，都能熟练开会套路，提高会议效率，更快更好地推进产品迭代。

#专栏作家#

陆庄羽，微信公众号：看风景的人，人人都是产品经理专栏作家。擅长用户分析和原型设计，目前关注内容、社交、算法推荐、人工智能等方向，爱好骑行户外的伪文青一枚。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Pixabay，基于 CC0 协议