今天，和大家聊聊开会这件事，看似简单实则很难的一件事。

作为一名产品经理，工作中会涉及各种各样的会议。和老板的会、和运营的会、和设计的会、和技术的会，还有产品内部的各种会。所以开会对于产品经理来讲，是一项很重要的技能。

说实话，我自己刚开始是个特别恐惧开会的人，尤其是自己主持的会议，怕hold不住全场，怕冷场。随着开会次数越来越多，不断碰壁踩坑，也算总结了一些经验。今天分享给大家，希望对大家有所帮助。

产品经理的日常会议包括哪些？

我们先来看看产品经理的日常会议有哪些，比如：需求沟通会、需求评审会、设计评审会、需求排期会、需求宣讲会、项目复盘会等等等（每个公司对于会议的称呼可能不同）。

接下来简单给大家介绍几个会议：

• 需求沟通会：主要是产品和老板、运营之间沟通需求的会议。经常沟通的内容包括产品版本需求、运营后台的需求、还有一些活动需求。这样的会议，在一个需求确定前，可能需要反反复复开几次。产品运营多多沟通，可以有效降低需求理解偏差。
• 需求评审会（运营）：当我们产品人员把需求转化为具体的功能界面后，便需要再和运营/老板/技术去开会，看看是否满足需求。这个会议，可以让我们从多方维度来思考这个功能的设计，让其更加完善。
• 设计评审会：设计师主导的会议，召集大家评审设计图，确定定稿方案。这个会议可以有效降低设计图改改改的次数，让公司各部门对上线后的效果有预期。
• 需求宣讲会：产品主导的会议，参会人员是技术人员。这个会议主要是为开发讲述接下来版本要做的功能，让大家对功能有心理预期，以便于接下来的工作量评估。会议内容包括需求背景介绍，功能流程讲解，数据的来龙去脉，一些特殊状态限制条件等。
• 需求排期会：这个会议一般是和需求宣讲会在同一天完成，技术针对宣讲会上的需求，进行工作量评估，最终确定人员排期以及预计上线时间。版本上线时间确定了，一来可以让团队进度更可控，二来可以让公司各部门更好的安排工作计划。
• 项目复盘会：这个会，相信不用我多说什么了。大家都知道复盘的重要性，通过复盘，我们可以发现每个版本过程中的问题，找到解决方案，让团队协作更高效。

其实，上述大大小小的会议，均涵盖在2类会议中：一个是自己主持的会议，一个是自己参与的会议。在这2类会议中，自己所处角色不一样，所需具备的技能也不一样。

怎么主持会议？

主持会议，这真是我工作后的一大难关。

作为会议主持人，全场的焦点聚集在你的身上，要负责把控整个会议的进度，调节会议气氛。听着好像不难，但在实际会议中，因参会人数较多，你一不留神就…跑题了，就要想办法把讨论内容重新拉回正轨，还会有冷场啊，会议时间无限拖延啊等情况。所以想要主持好一次会议，还是需要不断的练习和总结经验。

接下来，我们先来看看那些低效会议是怎样的，存在哪些问题，以及自己的一些建议。

低效会议1：缺乏背景介绍，直接开始讲细节

我们先来看看这种开会场景，如下：

事例中讲到的是一次技术需求宣讲会，产品经理在没有做任何功能背景介绍的前提下，一上来就说xx功能需求是怎样的，涉及的改动点有哪些。

从技术需求的角度来看，开发人员确实最想了解的是下个版本增加修改了哪些功能，涉及哪些改动，自己的工作量如何等。但是如果这些细节的改动脱离了需求背景，便很可能导致会议只围绕细节功能点去讨论，而忽略用户真实使用场景和流程，最终很容易导致有些场景技术上考虑不全。

（或许你会感觉上述场景似曾相识…）这是我刚开始参加工作的时候，时常犯的一个错误。结果就是，给大家讲的一脸蒙圈…还需要反反复复再沟通几次，大家才理解需求。

因为参会人员没有参与之前的需求讨论，如在会议开始时，我们不做需求来源和整体性的介绍，便会导致大家对全局没有概念，缺乏对产品功能宏观层面的理解，容易钻进细节之中，导致遗漏。

建议：在会议开始时，需要做一些背景介绍，流程介绍，让大家有整体感，做到心里有数。因为这样，大家思考的维度就不会局限于功能本身，会更开阔更全局的去思考问题。

低效会议2：缺乏会议主线和计划

我们先来看看这种开会场景，如下：

这次会议，是给我印象很深的一次会议。记得当时给我的打击很大，开会之后整个人就很低落。因为会议时间比预计的长了将近2个小时，最后大家都无心在听产品方案了。虽然会议结束确定了最终方案，但是回想整个会议过程，会议失控的让自己想找个旮旯儿钻进去…

好了，我们来说说这个会议的问题吧。

首先，会议缺乏计划

在会议开始前，我并没有想清楚整个会议的每一步该如何进行，没有在脑海中演练过一遍。作为会议主持人，如果脑子很混乱，那么一场会议又怎么可能会清晰呢？

所以对于临场发挥能力不是很强的各位，在开会前，务必要把整体流程过一遍，让自己的思路清晰。只有这样，才能更清晰的传达给其他参会人员。

其次，会议缺乏主线

在会议中，逐一讨论了各部门的计划和方案，但是缺乏一个核心。既然是产品主持的会议，核心肯定是沟通产品方案。所以在会议开始时，需要首先表达自己的观点和立场，这样大家可在此基础上去做延伸和建议，而不像上述会议中那样，有很多天马行空的跑题和无效讨论。

建议：

（1）会议开始前，制定会议计划

会议开始前，在脑中过一遍会议流程，预计的发展是怎样的，每一步每个节点要做什么，如何讲述才能让大家清晰明了。这些，都是需要在会议前想好的，否则会议失控的让你想找个旮旯儿钻进去。当然，除了失控的场面，还有可怕的冷场，最怕空气突然安静，空气中充满着尴尬。如何化解冷场，这就要看会前资料准备情况和临场发挥了。

（2）会议开始前，确定每个议题的预计时长

如会议中，大家在某个议题上讨论时间过久，便要中止讨论，以免造成会议时间延长过多。毕竟大家有自己的每日工作计划，如你的会议比预期时间延长了很多，一是耽误大家的工作，引来不满，二是会议效率较低。

（3）会议开始时，明确会议主线

作为会议主持人，在会议开始时，要首先表达自己的观点。不然就会被动的跟着别人的思路走，便很容易失控（具体看会议目的是什么，需具体问题具体分析）。

低效会议3：会议目标不够明确／目标过多／目标太大

在会议前，没有想清楚会议目标是什么，即本次会议要达到什么样的效果，得出什么结论。如果这些没有明确，那么很可能导致开了很久的会议，最终却无结论。整个会议等于白开了，制定不了下一步的工作计划。

如果会议目标太多，便很可能导致每一个目标都讨论不完整，不够清晰。而会议目标太大，会导致讨论很久都迟迟定不了结论，因为目标过大，所以涉及的内容必定会很多，便没办法当下拍板确定。

建议：

1. 在制定会议时，便要想清楚，召开这个会议的目的是什么，要达成什么效果，得出什么结论。
2. 每个会议达成一个主要目标即可，切记不要目标过多，因为目标过多，很可能导致最终没有一个完成。
3. 会议目标不要太大，太大的目标让人感觉很空，范围很大，且可讨论的内容很多，在一次会议上很可能讨论不出结论。每次会议制定可落地的小目标即可，如想达成的目标很多，那就分几次会议，这样会更高效一点。

通过如上几个真实会议场景，给大家讲述了主持会议的一些建议。当然，会议基本的提前邀约（会议目的、流程&议题、时间、地点、参与人员等），会后会议纪要就不在这里赘述了。

如何参与会议？

是不是有时候在会议上一脸蒙逼？搭不上话？当被会议主持人Q到的时候，大脑一片空白，不知道该讲些什么？听会议上其他人讲述观点，自己也没什么好的想法？

这说明一个问题，会前没做准备，没思考！！

你以为大家会上滔滔不绝的言论都是临时想到的吗？

大部分可以在会上表达自己想法的人，多多少少都是在会前做了准备，仔细研究了会议议题。只有这样，才能更好的理解议题，因为在会前有充足的时间去思考。

所以，想要在会上没有那么丢人，老老实实在会前研究和思考下会议议题吧。这也是对于会议的尊重。

总结

一场低效混乱的会议，简直是噩梦，而且浪费大家的时间。所以我们在主持会议和参与会议时，要扮演好自己的角色，让会议更高效。

主持会议

（1）会议前

• 提前邀约：发送会议时间、地点、目的、流程、议题、资料文件、与会人员等信息；
• 做好充足准备：包括明确会议目标、制定会议主线和计划，明确会议流程，确定每个议题时间等。

（2）会议中

• 先做整体性介绍，包括背景介绍、流程介绍等；
• 注意把控每个议题的时间和进度，防止跑题；
• 当某个议题进行不下去或讨论时间过久时，需考虑跳过，留作会后讨论或思考。

（3）会议后

发送会议纪要，明确下一步工作计划。

参与会议

• 会议前，详细查看和思考会议议题；
• 会议中，积极表达自己的观点，参与讨论。

如上内容，是自己工作这几年对于会议的总结，希望对你有所帮助。开会是产品经理甚至每个职场人的必备软技能之一，想灵活运用这门技能，就需要不断的去练习和踩坑积累经验。

大家加油吧～

相关阅读

如果你不知道交互说明怎么写，推荐阅读：

一份完整的交互说明包含什么（上）

一份完整的交互说明包含什么（下）

如果你对原型排版有疑惑，推荐阅读：

 什么样的原型更受开发欢迎？

作者：拾月，4年产品交互设计经验，微信公众号：用户体验研究所（ID：PM_Cynthia）

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

题图来自 Pixabay，基于 CC0 协议