每天的会议太多了，我都没有时间写代码了...
最近天天各种讨论，我有好多story都没测了...
在蓝鲸项目经常能够听到这样的声音。这也难怪，团队大了，总有各种会议和讨论，沟通成本上升不少。但是我们不能只是抱怨，如何提高开会的效率才是关键。
前同事李光磊写过一篇《极限会议》就是讲的怎么提高会议效率，写的非常好。但其中的原则要真正实践起来可能还是不那么容易让所有人都能快速理解并实施。
本文通过故事的方式分享日常会议的常见问题，并试图从会前、会中、会后三个阶段来列一些相对比较基础的、比较容易落地执行的规则。
会前
场景一：突如其来的会议
一天早上，小青看了看时间，已经是9点半，半个小时后有个面试，这是上周HR就约好了的，他把候选人的简历拿出来看了看，想提前准备一下。
“小青，咱们几个去开个会，头脑风暴一下下周跟客户的catch up XXX的内容！” 突然听到有人叫他，小青回头一看，原来是老王。
“大概要多久？我十点有个面试呢。 ”
“看进度吧，估计得一个多小时，我半个小时前给你们几个发了邀请了。”
“那我肯定不行！我只有半个小时，你不提前看下日历么？再说你现在才发邀请，也没有提前准备啊，我对XXX不是很了解，感觉我没啥可以输入的...”
“快来不及了，时间不好安排，最近大家都忙。要不你先参加半个小时吧！”
小青没办法，只好去参加会议了，大家陆陆续续来到会议室，等人都到齐已经是9:40了...
小青非常不爽，对于老王来说，似乎这一切很正常，因为这样的情形在项目上并不少见。
从这个场景，我们看到有几个方面的问题：
· 会议没有提前预定参与人员的时间，也没有查看参会人员的时间是否有冲突；
· 会议没有准时开始；
· 没有时间提前准备；
· 小青可能不是合适的参会人员
场景二：Feature kickoff
BA组织某个team做feature kickoff，这是一个在原来某个复杂feature上的功能扩展，由于业务需要，对原feature的设计有改动。在讲解新feature的设计过程中，大家发现BA目前提供的设计可能有些问题，于是大家开始讨论和澄清原来feature的相关设计是什么样的，时间过去了一个小时，还没有正式回到新的feature的kickoff上来...
这个场景存在这样的问题：
会议的目的是kickoff新的feature，但是新feature的设计并没有相关人员的确认（这种确认并不需要全team的人参加），而导致全team人都在的情况下，浪费了很多时间来讨论设计的合理性。这是会议之前没有足够准备的原因。
从前面两个场景的问题，我们来总结一下会前的规则有哪些：
· 确定会议目标：每次会议一定会有一个目标，只有明确目标，这是会议高效的前提。目标不明确的会议，可能没有开展的必要。
· 确定会议议程：根据会议目标，把会议议程定义清楚，这样才能在开会的时候严格按照议程，准时结束。
· 确定参会人员：尽量准确的确定参会人员。如果是讨论，要求参会人员都能有输入；如果是宣布某个决定，确保参会人员是需要被通知到的。如果邀请了不一定要在场的人员参会，对双方都是一个浪费。
· 提前通知参会人员：定好会议时间、地点，要尽早发出邀请，这样有利于参会人员提前安排好其他工作或会议。同时，在发出邀请的时候，需要告知参会人员是否需要有提前准备的内容，比如组织某个讨论可能要提前收集、思考讨论的素材，组织workshop需要提前准备环境或者相关知识等。
· 准备好会议需要的东西：不管是组织者还是参会人员，对要提前准备的材料、环境等都务必提前准备好，有时候可能还需要准备一些物料等。一旦有其中一人或者某一件东西没有ready，都会影响会议的高效开展。
会中
场景三： 某会议室10来人约两个小时的讨论
某team正在会议室开会讨论A话题，讨论已经进行到快两个小时，看得出来屋子里的人都有些疲惫，只剩下少数人还在说话讨论，其他有几个人在看手机或电脑，还有昏昏欲睡的。会开了这么久，原本要讨论的A话题没有得出结论，现在大家已经跑题到讨论B了。
“咱们原定时间是一个小时，现在超时太严重了！再这样下去也不会有结果...先结束吧！”终于有人受不了了。
组织者也发现大家有些失控，只好草草结束了会议...
小明本来很想参与A话题的讨论，但是跟另一个会议冲突，他没能参加。赶在会议结束时刻来到会议室，想了解一下大家讨论的结果。没想到并没有得出结论，想找组织者问问是否有大家发言的记录，他想整理一下看是否有什么发现，结果也令他失望，并没有记录...
从这个场景，我们可以看到会中的几个问题：
· 严重超时
· 没有控制大家的讨论范围
· 有部分人并没有全身心投入到讨论中
· 没有板书或者记录
· 会议草草结束，没有结论，没有下一步行动计划
因此，总结会中的规则如下：
· Timebox：严格控制每项内容的时间，避免会议超时。
· 如果会议不能围绕目标展开从而没有价值，组织者应该提前结束会议；如果某参与者贡献有限或者没有贡献，TA可以选择提前离开后者组织者请TA离开。
· 严格按照议程进行：讨论过程中很容易走偏，要注意及时拉回来，如果有新的需要讨论的内容，可以记下来下次再讨论。
· 集中精力参会：非必须要用的情况下，所有参会人员盖上电脑和手机，专心参与会议内容。既然已经承诺可以参会，就不要担心其他工作被此次会议耽误，修build也不是会上看电脑的理由。如果真的有比会议更紧急的事情，可以不参会。（经常有code review或者feature kickoff的时候，有同学带着电脑一直低头忙着，不知道是在听会议内容，还是在忙什么。这样的情况需要尽量避免。）
· 确定下一步行动计划：每次会议都需要在会上确定下一步行动计划，如果没有该次会议相关的下一步计划，也需要明确。
· 做好会议记录：清晰记录会议的内容很关键，不仅可以share给没能参会但需要了解的人，也可以作为后续参考用。最好是在开会期间有人直接记录，而不是会后会议再记，这样能够记得清晰也更省事。
会后
场景四：某team的回顾会议
按照惯例，回顾会议开始都先回顾一下上一次的action。今天的组织者是小树，他找了半天没有找到上次回顾会议的总结邮件，也不知道上次有什么action… 原来是上次的组织者在回顾会议结束之后，忘了发邮件了，好在当时拍的照片还在。对照着照片上的action，发现其中有两三个并没有完成...
这个场景的问题是：会议总结没有在会后发出，action也没有好好执行。
由此，我们可以得出会后需要遵循的规则有：
· 发出总结：组织者需要针对会议结果进行总结，并且发送给所有需要知晓的相关人员。总结需要包括会议讨论事项、讨论结果、action及其owner等内容。
· 执行相应的action事项：所有参会人员都要按照会上讨论的结果，执行好自己own的action，不要到下一次会议的时候发现action还没有做，这样非常影响会议的效果。
写在最后
大团队的沟通成本很高，高效沟通非常关键，而涉及多人的会议或讨论更是需要高效开展。前面描述的规则执行起来并不难，但是需要大家都能有这个意识，齐心协力，严格执行。