原创不易，求分享、求一键三连
会议是工作中最重要的组成部分，因为他需要解决两个核心难题：
- 信息传递；
- 达成一致；
有效的信息传递是战略落地的前提条件，更多的认知统一更是可以加速成功的发生。但无论是信息传递还是达成一致，都不是一件简单的事情，特别是会议中人多嘴杂，更是加大了这种难度。
所以，如何设计会议，是我们今天要讨论的话题。
时间杀手
无效会议已经成了我们最大的时间杀手，比如我的日程：
因为我更偏向于执行层，如果所有会议都参加那么可以认为所有会议都没参加，如此密集的会议会导致两个问题：
- 没有时间独立思考；
- 没有精力跟进执行；
那么为什么会有这么多会呢？
规避决策成本
一方面会议的目的是传递信息，另一方面会议还有两个不光彩的目的：
- 求助；
- 规避责任；
比如50个会里面，有三分之二是外部门邀请参加，一些是业务方周会，一些是项目例会，一些根本不知道是什么会，总体而言，这些会不外乎是他们不想决策，希望我给出专业意见，最好可以帮他决策或者是需要我的帮助，最好是白嫖研发资源...
举个例子，公司手里有1000w某服务商代金券即将到期，现要求我在一个月使用出去，这种临时代金券的使用多半有大坑，我当然不能随心所欲，于是就拉几个业务方一起开会：
- 首先提供供应商提供的服务和对应成本；
- 其次问他们结合自己业务有哪些要采买的，免费；
这个阶段，业务负责人会以为是白嫖资源，欣然参与，但list出来后，把采买需求人填上去后，他们显然就有点不愿意了，如果再加一列风险说明或者ROI说明，几个业务负责人就想离场了...
我这里拉会的目的可以说是求助，也可以认为是规避责任的行为，这里也引出会议要点之一：
会议要点：责任归属到个人
有责任归属，才会考虑成本，决策有成本才会减少决策错误。规避责任对于个人而言是好事，但对于公司而言就会产生很多无用会议，并且会议时间会特别冗长，这种规避责任的会议会吃掉人们大量时间。为了避免大家互相推诿的情况发生，也会引出另一个会议要点：
会议要点：重要会议需要有能拍板的人
主题偏移
但是，有时候就算责任人就位，能拍板的人也在，但如果主题被带偏，很多会依旧又臭又长。这里有两个要点：
会议要点：一事一议
会议要点：主持人控制节奏
一事一议，并不是说一次会议里面只能讨论一件事情，而是说会议中讨论事情聚焦，不要东拉西扯。
另一方面，面对会议主题偏移的情况下，主持人必须站出来，将众人导入正轨。
举个例子：之前Java和Go需要做技术栈二选一合并，如果主题是Java和Go选那一个，优劣是什么？
如果一个资深架构师，大谈特谈PHP是世界上最好的语言，那么在这次会议上都不能让他得逞，可以在这次技术栈选择结束后，比如已经选了Java后，再新开一个话题使用PHP会不会收益更高。
这就是主题聚焦，我们如果说产品体验就不要强调实现难度，我们如果聊实现难度，就不要扯微信怎么行，主持人要控制节奏。
工匠精神
也会有些Leader，虽然也是在同一主题深入，但是他的尺度拿捏也会导致大家很痛苦，这里引出一个要点：
会议要点：不要在多人会议上追求完美的问题解法
举个例子，线上出了一个BUG，分析下来是因为并发没加锁，这个时候可以更进一步讨论Code Review的重要性，以及流程如何设置是正确的，或者准备出一个并发的培训也毫无问题。
但是主持人进一步想讨论CodeReview的流程该如何设计或者并发有几个技术点，每个技术点到底是怎么样的，那么就是浪费大家时间了...
因为，为了更好的落地，流程机制的设计要考虑很多场景；其次并发的培训材料也需要整理很多资料和案例，这些都不是一次会议的内容，如果要继续展开，首先是准备不足质量低，其次未必是所有参会人都感兴趣。
另一个场景是，项目负责人工作比较细致，在过项目进度时候，总喜欢连续问各个端口的细节，导致会议时间过长，这虽然也是围绕项目进度展开，但如果依次讨论各个端口细节，会导致其他人的时间被浪费，这种工匠精神也要注意。
上层角色如果时间无规划、工作无条理，生活无规律，就会陷于细节导致各种混乱，最终结果可能是眉毛胡子一把抓，那真正的全局事物可能就没精力关注了。
主题过大
比主题偏移更恼火的是主题过大，主题过大首先容易导致讨论无法开始，无病呻吟会导致会议冗长无结果，更重要的是容易演变成一场散播焦虑的会，这里的点是：
会议要点：不要在会议室提出主题过大的话题，也不要在人多的会上散播焦虑
举个例子，如果问题是如何将1000w代金券花完，不能每次会议一开始就，怎么办，时间马上就到了，1000w还不知道怎么花？这种极容易变成散播焦虑。
取而代之，我们需要分解这些问题，比如：
- 供应商提供哪些服务，成本怎么样；
- 我们当前有什么需求，什么需求可以又服务替代；
- 我们有多少费用是确定的，多少是不确定的，有没有兜底方案；
问题过大便无从着手，问题过小便陷入细节，只有问题被切割的足够大小才能很好的解决问题。
走神
还有些Leader，比如项目负责人，在别人汇报时候总喜欢玩手机、回微信，当别人寻求帮助时候又不得不重复重复再重复，这里的点是：
会议要点：开会就要认真听！
会上不认真听，会后抱怨会议没效果，不认真听还想有结果，做梦呢...
总结一下，会议之所以是时间杀手，主要原因是：
- 一些会议的目的是用来规避责任的，如果没人拍板就容易扯皮；
- 一些会议主题不聚焦，东拉西扯，自然耗时费力；
- 一些会议关注的问题过于细碎，这会浪费大量时间；
- 一些会议讨论的主题过大，不仅无从讨论，还可能引发焦虑；
- 还有一些会议内容没问题，但是由于会议纪律不好而导致效率低下；
所以怎么办呢？
会议设计
会议精神
尽量少开会、开短会，确保每次会议有结果，结果有人跟，结果有反馈，反馈有失效。一般来讲，组织会议管理有五项原则：
- 能躲就躲
根据重要紧急四象限，不重要、不紧急的会议就不开，必须要参加的会议少开。
举个例子，会议人数越多，会议意义越低，比如技术团队大了后，周会更像是求助、同步，很难在这种大会上决策什么重要事情，所以超过30人的周会可以由单周会变成双周会。
取而代之的是由部门负责人组成10人以内的部门月会，将需要决策的事项放月会上集中处理。
这里需要注意的是，日会变周会、周会变双周会甚至月会，并不是之前的周会不开了，而是作为大Leader参与的会议质量需要更高，而每个小组的周会，每个项目组的日会依旧要各自负责进行。
- 明确会议主题
一个会议有几个议题，每个议题负责人是谁，提前通知到，到时候就一事一议，甚至分批进入，最大程度节约时间。
- 会议纪律
重要会议要认真，关手机、不准使用电脑，罚款之类的都可以，保证会议质量。
- 会议节奏
每个会议都需要指定主持人，需要控制时间，控制话题。
- 权威发言
重要会议必须有可以拍板的人，如果是权威者需要最后发言，也必须发言。
会议类型
从信息目的和结果会议可以分为：
1）项目会议：保障项目成果执行；获取项目信息；
2）OKR会议：保障OKR成果执行；获取OKR信息；
3）团队周会：管理层保障团队健康运转；获取所有项目信息，解决跨部门协作问题；
4）团队月会：管理层保障团队发展方向正确；获取团队总体信息，收集抽象类团队问题；团队重点事项决策；
5）CaseStudy+项目复盘会：管理层保障团队错误规避；获取团队执行类错误信息，收集工程或组织问题；
6）干训班会议：管理层保障leader认知对齐；团队文化输出；
7）专项问题讨论会：为解决具体事项而召开的专题讨论会，如底层框架确定，移动框架选择，评优设计等；
8）半年汇报会：管理层保障团队健康运转；让全员了解团队发展状况，未来发展方向，制度宣发；
暂时只能想到这些，需要大家补充。
通用会议模型设计
效率高的会议大同小异，一般由几个要素组成：
1）明确的会议主题，要解决的问题；
2）能把握节奏的强力主持人，信息量较全（聪明点的）的会议纪要者；
3）明确的会议结论或者会议后续；
4）有时间、唯一负责人的todolist；
5）有对会议结论持续追踪的机制；
6）控制会议总时间，最好不要超过2小时（1小时最佳）；
这里以大家最熟悉的周会为例，做一个demo，这里需要回答的第一个问题是周会的主题是什么？
PS：注意，不同团队对会议的定义不一样，这里只是打样，不可完全套用。
一般来说，周会是每个团队一定会存在的一个会议，他是帮助团队了解团队情况的重要且不可替代的会议，也是一些项目及跨团队问题暴露的重要场所，所以：
周会是同步团队信息，包括项目信息，暴露团队问题包括项目问题并求助的重要会议
如果对周会目标的定义是同步信息、暴露问题及风险，那么就不能在周会上大谈解决方案是其一，其中产生的问题，无论是团队问题或是项目风险问题或是工程建设问题，都应该指定到相关领域的专家，写定todolist，每次周会跟进执行情况即可，我们现在周会模板大概是这样的：
特殊会议
在权责利不清的时候，在上层打架的时候，会产生很多扯犊子的事情，比如：
1）一个项目中会有负责人由于某种原因“缺失”的时候；
2）也有两个部门之间由于资源问题（可能是内卷，也可能是不想吃亏）而来回拉扯，而项目都岌岌可危的时候；
在参与这种会议或者这种时候，你如果是其中的关键角色，虽然这么说未必很好，请一定做好会议纪要，并且跟多方确认，发出邮件，留下“证据”，这类项目失败的风险极高，要留下一些材料免责...
节奏控制不好的项目容易耗时费力效率低，并且多数人一头雾水，这个大家应该有所感受，这类不再赘述。
领导力的另一个关键也是能不能把一件大的事情分解为几个小的模块，让多数的人有事可做，并且产生好的结果。
战略意图暴露
信息通畅是好事，但是关键战略泄露或者说私密信息泄露，也会非常致命，特别是对于很多有协调者或者外交家属性的leader，这里要分轻重，有些信息还是不能完全告诉对方，所以在会上不要乱说话！不同团队对于信息泄露的标准不一，反正注意就好。
另一方面，公司层面要做一些技术或者说基建防止公司信息（业务信息）泄露，甚至是代码泄露，一个是防堵一个是找补，真的当这类信息泄露了的应对措施是什么需要提前定义。
月会
如前所述，月会跟周会的目标又不一样，周会更关注日常事务，一般不涉及人事问题，因为周会一般是第一圈层+第二圈层，人数较多，公开评价某人如何如何很不好，一些业务上敏感的信息也不能完全透传，容易引发恐慌，毕竟真相可能不好看。
月会一般是团队第一圈层少数人参与，比例在5%左右，目标有：
1）暴露业务问题，跨团队问题，甚至公司问题，管理层的压力会部分下放到这个圈层，把业务风险赤裸裸的放出来；
2）暴露团队人员类风险，梯队问题，核心人员离职问题；
3）业务建设、工程建设情况，在月会中占有很重的比例，而且必须持续投入；
4）问题项目复盘，团队问题暴露，与周会大体相同，但是这里会更彻底一些，可能会将遮羞布扯下来，也会讨论应对方案，好的案例会作为干训班材料；
按照以上目标做材料整理，会更希望做数据化的呈现而不是空口无凭，总之月会规格会高很多。
总结
最后总结几个会议要点是：
- 会议todolist责任归属到个人；
- 需要决策的会议需要有能拍板、敢于拍板的人；
- 一事一议，并且主持人要控制节奏；
- 不要在多人会议上追求完美的问题解法；
- 不要在会议室提出主题过大的话题，也不要在人多的会上散播焦虑；
- 重要会议就要认真听！
好了，今天的分享就到这，喜欢的同学可以四连支持：
想要更多交流可以加微信群：
