13 | 白天开会，加班写代码的节奏怎么破？
讲述：宝玉
时长11:49大小10.83M
你好，我是宝玉，我今天想与你讨论让很多程序员头疼的话题：开会。
说到开会，是很多人心中的痛，每天白天忙于参加各种会议，压缩了本来就少的可怜的工作时间。最可气的，有的人开完会工作就算完成了，而像我们写程序的，还得下班后加班加点赶进度！
所以一说到开会，程序员们往往如遇洪水猛兽一般，避之不及。
开会是有价值的
但我想说的第一个问题是：开会是有价值的。软件项目中有不少会议，其实有其价值所在，给你简单举例分析一下。
像评审会议，通过会议，可以让产品设计或架构设计在确定前，收集大家的意见，及时发现问题。
像每日站立会议，可以及时了解项目的进展，了解当前的困难和瓶颈，及时调整计划，解决问题。另外在会议上，每个人都要当众讲一下做过的事情和计划要做的事情，这也是一种无形的监督和约束。
像项目立项会议，可以创建一种仪式感，让每个人都知道项目的关键信息：
- 项目目标：这项目是要干什么的，达到一个什么目标；
- 项目里程碑：项目的开始结束时间，项目的阶段划分，以及各个阶段的时间点；
- 角色分工：项目成员的分工和角色是什么，每个人知道自己的任务是什么，知道遇到问题该找谁；
- 流程规范：项目开发的主要流程是什么，基于瀑布还是敏捷。
像项目总结会议，团队成员可以一起总结一下项目的得失，把经验总结下来，帮助团队在下一次做的更好。
还有很多会议我就不一一列举。从上面可以看出，这些会议都是可以创造价值的。
开会是有成本的
开会的成本，就像房间里的大象，显而易见而很多人却有意无意无视它的存在。
我们做个简单的数学计算，假设一个程序员月薪一万元，如果他每天四分之一的时间在开会，那就相当于公司每月花了 2500 元在会议上。
这还只是一个人的成本，如果开会的人多，那么仔细算算，整体的会议成本其实很夸张的。所以我想说的第二个问题就是：开会其实是有成本的，而且还不低。
什么样的会议是有效率的？
其实软件项目中有些会议我是愿意参加的，因为是有价值的，高效的。比如说前面提到的每日站立会议，时间不长，但是收获很大。
再比如隔壁郑晔老师的《10x 程序员工作法》专栏中提到的“轻量级沟通”，其中建议的会议方式：人少，面对面沟通。这种小会通常也让我觉得很高效，经常能产生有价值的方案。
还有一些会议则让我觉得没什么价值，比如领导冗长的讲话，比如一堆人在偏离会议主题的讨论，比如跟我没什么关系却被迫参加的会议。
那么为什么这些会议给我的感觉完全不一样？这其实就是我想讲的第三个问题：会议是不是有效率，取决于它创造的价值是不是高于其成本。
我觉得像每日站立会这样的会议更有效率，其时间短、人数少，所以成本低，创造的价值高于其成本。而人数多，又偏离会议主题的讨论会则没有价值，这是因为人数多时间长，导致会议成本高，而其创造的价值远远不及成本。
那为什么还有那么多低效率的会议？因为有的会议，就不是为了创造价值。
比如说有的会议，花的成本不是组织者的，对他来说，得到他的会议价值就可以了。
你是砍柴的，他是放羊的，你和他聊了一天，他的羊吃饱了，你的柴呢？
还有很多会议，是因为组织者和参与者，都没有意识到开会其实是有成本的，所以浪费了成本还不自知。不过这种情况还好，还是可以想办法改进的。
接下来，我们来看看如何提高开会效率，破除避免白天开会，晚上还要加班写代码的节奏。
如何提高开会效率？
我们专栏有一篇文章《08 | 怎样平衡软件质量与时间成本范围的关系？》，很多同学看过里面讲的软件项目金三角理论后，直呼“醍醐灌顶”、“终于找到一套可以说服老板的说辞了”、“能够提高与产品经理打太极的水准”。
其实提高开会效率、提升开会价值的方法，就跟软件项目金三角的理论一样，只要从两个角度去想办法：减少开会的成本，增加开会创造的价值！
在具体探讨这两类方法之前，我们先要认识到一个前提：那就是要让大家意识到开会是有成本的，如果开会创造的价值不能大于其成本，就是浪费。
就像金三角理论，你得先让老板、项目经理明白三条边不可能都占，才好去沟通讨论。要提高开会效率，也需要大家先有这个意识，才能在具体措施上达成一致。
那么，有哪些方法可以减少开会的成本呢？
1. 砍掉一些没价值的会议
在日常工作中，还有很多会议其实并没有什么价值的。如果一个会议符合这些标准，你就要慎重考虑参加了：
- 没有目标的会议。大家都在随意发散，完全没有主题；
- 不能形成决策，没有会后行动。如果一场会议看完后都没有什么结果，那跟没开都没啥差别；
- 你属于可有可无的角色。如果一个会议，跟你其实没什么关系，你无法提供有效的反馈，对你也没什么价值，只不过是被人拉过去开会的，那不如把这个时间用来做一点对项目更有价值的事。
所以，你可以在每次要接受一个会议邀请之前，先问自己两个问题再做决定：这个会议我真的有必要参加吗？以及，有其他方式可以替代吗？
其实，很多问题并不是非要通过“会议”的方式解决。
以前我负责的一个服务，其他组需要调用，所以有一个组的同事想跟我组织一个会议，让我介绍一下服务，以及如何调用。我思考了一下，觉得准备这个会议我也要写一个 PPT，开会还得要时间，这时间我足够写一个详细的说明文档出来了，而且以后其他组再要用，也只要看文档就可以了。
于是我就跟他们说：我们不用开会，我一会发一个文档链接给你们，如果有问题我们可以在聊天工具上沟通。后来他们看完文档后，有几处不清楚的地方，在咨询过我以后，我将文档更新好，就没什么问题了，而且后面再不需要为这件事开会了。
2. 减少参与会议的人
会议的成本和两个因素相关：一个是人数，一个是时间。如果减少人数，就能减少成本。
减少人数好处还在于，人一少，每个人都会更投入，也更有效率，所以往往时间反而会少产出会高。而且，如果会议上要形成一些决议，人越多越难做决策，人越少越容易达成一致。要想有决议的话，先开几个小会，达成一致后再开大会，大会更多只是宣布一个结果。
像谷歌和 Facebook，他们对于会议的态度就是能不开就不开，无关的人不参与。Amazon 的规则也很简单：一场会议的人数，最多订两份批萨，如果超出这个规模，说明这个会议的人数太多了。
3. 缩短开会时间
减少开会成本的另一个方法就是缩短开会时间。缩短开会时间有很多成熟可靠的方案可以选择。
比如说站立会议，通过站立的方式逼着大家快点结束。
另外，麦肯锡开会上有些做法也值得借鉴：
- 每个成员有一张黄牌，用于喊停其他人会议中发散讨论无意义的话题；
- 有人控制节奏，大家快速发言；
- PPT 不超过 3 张，鼓励大家预先准备，多讨论。
还有比如我们在前面敏捷开发介绍的例子，会议有人主持，当话题开始发散的时候，果断制止，放到“停车场问题”环节，也就是会议的最后专门讨论。
类似这样的缩短开会时间的办法，确实可以有效减少会议成本，这类提升效率的方法还有很多，你可以从这个角度多思考尝试一下。
4. 提升会议所创造的价值
如果能有效提升会议产出，也一样可以达到很好的效果。
比如说，每个会议要有明确的目的和主题，所有的讨论都要围绕会议目的展开。当你发现会议上一些问题的讨论偏离了会议的主题，例如一个需求评审会，结果架构师在讨论技术细节，这就完全偏离了主题。
你就应该站出来提醒一句：“现在既然是讨论需求，不如先不讨论技术上的问题，等到需求确定了，我们后面再慢慢讨论技术问题。”或者说：“不如这个问题我们另外组织一个会议讨论。”
还有开会后，要有明确的结论，有后续的待办事项，落实到个人，对待办事项有跟踪。
偷偷说一下，有时候一些没什么价值的会议，又必须要参加，我一般会参会前，用一个本子把一个技术难题、或者一篇博客主题，写下来。
开会的时候，把这个难题理清楚思路，把博客的提纲写出来，这样一个会议开完，我的问题也解决了，或者文章提纲也有了。同样也是收获满满，没有浪费太多时间。
这些都是提升会议价值的方式，相信你对会议成本有了概念以后，也可以找到很多可以帮助你提高开会效率、更好创造会议价值的方法。
总结
今天带你一起学习了解了开会的“道”，那就是开会是有价值的，开会是有成本，会议是不是高效，就看它创造的价值是不是高于其成本。
如果你想破除白天开会，加班写代码的节奏，就需要从缩减开会成本和提升开会价值的方向上去想办法，还需要让你的老板、项目经理都有“会议是有很高成本”的意识。
砍掉一些没价值的会议，减少开会的人数，缩短会议的时间，提高会议创造的价值。
课后思考
你在项目中，有哪些会议其实是可以不参加的？哪些会议是可以缩减人数的？哪些会议是可以缩短时间的？哪些会议是可以更好的提升价值的？或者你对上面的观点有哪些补充？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
精选留言(15)
kirogiyi2019-03-26 7会而不备、会而不议、议而不决、决而不行、行而无果本身就失去了开会的意义。
我认为会前准备是相当重要的，组织会议或者抛出问题的人，应该对整个会议的内容有深刻而清醒的认识，并且将思路整理成文（Word、PPT等），给参与会议的人一个明确的引导，让会议一开始就能很快进入状态，不需要过多的预热。
开会期间如果不讨论会议主题，只是聊一些边角料，去讲人生经历、讲感悟什么的，讲的人快活了，听的人郁闷了，但为了以示尊重，大伙儿还得专心致志听着，职场上也有不得已的地方。这里就会用到宝玉老师说的，会议组织者的场面掌控能力，什么时间、多长时间讨论某一问题，并控制参与者自由发言的节奏，及时拉回会议主题，保证会议的时效性。
如果因会议主题的讨论而衍生出的很多有用的信息，觉得这盘西瓜不错，那盘哈密瓜也不错，芝麻丢掉也可惜了，领导没决策，下属没主见（有主见也是从自己工作便利性上考虑），最终在会议结束的时候，留下了更多的问题，核心主题却没结果。个人觉得，每次会议的参与者都要达成共识，组织者是谁，决策者是谁，甚至有时候组织者要暗示决策者该表态了。
会议只是产生良好结果的前奏，相当于理论验证结果有了，剩下的就是去实际操作了。一旦决策者表态了，有了决定了，就该指定相应的负责人，定期汇报进度、展示阶段性的成果。最近就遇到旁边的一个部门，加班加点的修改方案，到客户那里去出差三天，回来了，本以为会有点动静，接下来一周都没啥动静，和大家聊天才知道，没指定谁来总览这件事，一直挂在相应副总经理名下，副总经理好像忘了似的，要么就是结果已经堪忧了。
行而无果，实际上是最让人绝望的，花了大量的人力物力，最后发现一切都是徒劳的，会前准备、会中讨论和决策、会后执行，好像每个环节都出了问题，没人有致命的错误，反正就是事儿没干成。
写这些，实际上是希望得到宝玉老师的指点，从专业的角度指点下我思维的误区，谢谢您。展开作者回复: 总结的非常好的👍
从课程的理论知识，结合了实际工作场景的案例👍
我不觉得思维上有任何问题：）
有一点意见可以参考：如果你需要别人给你意见，本质上跟开会一样，不宜主题太多太分散，不然别人抓不住重点。
下次你可以在总结完了后，针对一两个具体问题问，这样被提问的人更容易抓住重点，供参考。- alva_xu2019-03-26 5老师今天的话题确实是我们大家在做项目中特别头疼要处理的问题。开会吧，怕耽误别人时间，不开会吧，怕别人的意见没有收集到，或者拍板了不算。我来谈谈我的学习体会：
1，会议组织者或者相关人员必须在会前确定好会议目标，并在线下预先和相关人员沟通准备材料，会后尽量要有一个会议纪要，特别是跨部门的会议（对于每日站会等scrum 中规定的常规性会议，已经形成了规范，相对好组织）
2，对于必须邀请领导（们）参加的会议，是最最考验组织者的。因为领导的发言可能是最不能受控的，这需要会议组织者的会议控制技巧，比如说事先给领导暗示时间，及时把领导发散出去的话题收回来，等等
3，在需要多人发言，征求多人意见的时候，用先发纸条各自写下自己的想法，然后再发言的形式会提高效率。
4，如果一些会议本身的话题比较多，可以考虑将议题分散成多个会议，大会拆成小会。
5，实在没办法必须开大会的时候，我作为组织者，鼓励大家带上笔记本电脑等工作工具，允许大家边工作边开会。这是，作为组织者，必须把握好哪些信息需要哪些人听或者反馈。
总而言之，会议组织者是最最重要的角色，除了考虑会议要达到的目的之外，还需要考虑节省与会者的时间。否则，参会人员的积极性会大打折扣，以后就没人来开你的会了。展开作者回复: 你这些宝贵经验对大家包括我都很有价值👍
我以前老板就特别能说，完全收不住😂 
aya2019-03-26 4老师【你是砍柴的，他是放羊的，你和他聊了一天，他的羊吃饱了，你的柴呢？】说的醍醐灌顶呀，人家还会说你的柴和我有什么关系...作者回复: 同一个会议，对不同的人价值是不一样的，别让自己当砍柴的陪放养的聊天：）
纯洁的憎恶2019-03-26 3提高会议效率，从成本收益入手。会议有成本，开会需谨慎，时长与人数和会议成本紧密相关。
主动做减法，减少会议数量，缩短会议时间，削减参会人数，降低会议成本。
努力做加法，明确会议目标，得出会议结论，落实后续责任，复用“听会”时间，提高会议价值。展开作者回复: 你这个简洁👍
本质上就是做加法和减法- Felix2019-03-26 3我说一下我对开会的看法：
1. 要有主持人，之前遇到过没有主持人，就像没头苍蝇一样，特别容易脱离主题，尬聊，主持人控场，能够保持会议围绕议题进行
2. 要有书记员，当然书记员不是记流水账的，从同事那里学来，开会最重要一句话是"结论是什么"，讨论半天没有结论，这会还不如不开，所以书记员重点记结论，会后将结论，即会议纪以邮件形式群发参会人以及抄送领导知晓
3. 如发现会议与自己无关了，要勇敢地离会，如需求评审，产品经常会邀请多方开发，如果已经确认剩下的议题与自己无关了，跟主持人确认后就可以离会，有同事跟我说他们会不好意思，我觉得大家都是做事的，应该能够互相理解，雷厉风行，不用不好意思😄展开作者回复: 对，我支持你的观点：有时候要勇敢离场，只要解释一下相信都能理解，毕竟会议之外创造的价值更大。
williamcai2019-03-26 3看个人吧，作为程序员，我一般喜欢参加技术评审会，方案设计会，和代码评审，和我的职责息息相关作者回复: 是的，很多会议是有价值的👍
青石2019-03-26 2组织会议，一定要有会议时间、地点、人员、主题，会前要有准备、会中讨论要有结果（指定干系人）、会后要跟踪。
没有主题、没有讨论结果、没有跟踪的会议，都属于无效会议。作者回复: 👍有价值的补充
bearlu2019-03-26 2老师，能不能说说开会要留意些什么内容，我是个新手，每次开完会议，到开发的时候又找产品确认具体功能。作者回复: 我想你说的应该是需求评审会议或者需求讲解会议，对于这类会议，建议你会议前读一下文档，这样心中有数，同时对于文档中觉得不清楚或者有疑惑的地方记录下来，在会议中提出。
不同的会议重点不一样，开会之前你都可以实现了解下这次会议的主要目的是什么，然后事先准备一下，这样开会就会更有效率一些。
如果你是有具体某个类型的会议，也可以新开留言。
果然如此2019-03-27 1正好有一个昨天开的产品会的案例，产品经理刚讲了不到一半，另一个技术人员就提了很多问题，有的是需求问题、有的是技术问题、还有的是这个产品的历史数据更新的问题，对于以上问题，由于产品只讲了一小部分，我觉得在这个时候提问题有点激进并且有的问题偏离了主题，所以在适当的时机，我及时打断谈话，并向产品经理询问是否全讲完了，答案当然是否定的，并请其继续讲完，在讲的过程我记录了一些问题，然后讲完之后，大家继续讨论和需求有关的话题。展开作者回复: 👍赞，这样的打断很有必要，不然很容易就偏离主题了！
天之大舒2019-03-26 1这个可以和第12节内容应用起来，会议也要有流程和规范。
个人认为之所以有一些没有价值的会议，是对会议成本不重视，党都对会议有严格要求了。
没有目标的会议不参加，没有会议资料的不参加，没有决策人参加的会议、不知道为啥邀请自己的最好不参加。
项目组自己的会议，不在工作计划中，都安排在下班前15分钟。展开作者回复: 👍很好的经验分享
hua1682019-03-26 1老师能说下，整个项目开始前到项目完全结束，一般都要开那些会议呀？目的是什么？作者回复: 我确实整理了一些，后来因为篇幅原因删减了，我和编辑商量一下，在下一次整理留言的时候放出来，作为这条回复。
Jansen2019-04-17我们项目一般会开以下几个会议，老师看看我对它们的理解对不对：
1.每日站立会议。这个是很有价值的，可以把控项目进度、知道每个人的产出、每个人的计划、有哪些潜在的问题，偶尔还能意外学习到别人的研究成果。
2.需求分析会。这是产品经理将业务需求转换为开发人员能理解的系统功能的会议，对开发人员价值很大。但是需要产品经理事先自己充分理解需求的背景和细节，不然等到会议上发现需求问题是很影响开发人员对需求的理解的，因此会降低开会的价值，时间拖长了也会增加开会的成本。
3.开发设计方案评审会。这个是对需求中较难的点进行开发设计方案的确定，大家一起针对方案进行评估，给出自己的建议并最终达成一致，能有效避免个人思维上的盲点，从而造成测试阶段推翻原有方案大规模返工的风险。
4.代码评审会。每个人对自己的代码逻辑和规范进行讲解，时间冗长，大家很难保持长时间的注意力集中，而且会认为别人的代码与自己没什么责任关系，投入关注度不高。这个很头疼，不知道该怎么解决？
另外，老师还建议有什么别的类型的高价值会议？展开作者回复: 代码评审会我建议你可以改成Code Review。参考《06 | 大厂都在用哪些敏捷方法？（上）》中描述的。
也就是你每一个人写的代码，要合并到主分支之前，需要有人Review，Review的过程自然就需要去了解对方代码的逻辑和规范，也是个很好的相互学习的机会。
但这个必须要有配套的流程规范严格执行，要是流于形式就没有意义了。
需求分析会要拆开效果更好，先开一个大会概要性简单讲清楚整体需求，然后开小会和业务相关的开发人员沟通，这样更高效。
开发设计的评审会议要分多次开，一开始不要太细，先确定大方向，然后逐步细化。不然修改成本高，沟通难度大。
参考《21 | 架构设计：普通程序员也能实现复杂系统？》
还有一个很重要的会议就是迭代/项目回顾总结会议，在迭代或者项目结束后，大家一起讨论总结项目中得失，提出具体的改进意见。
nicola2019-04-03本身项目在计划中进行着，但又有另外的任务插入需要占用很多时间，又要完成紧急任务又不对原来任务进行计划调整（按原计划进行），完完全全把责任推给开发者。展开作者回复: 这种确实不合理，如果有新任务插进来，那么就必须要对现有计划进行调整。
建议以后遇到类似临时插入任务的问题，当时就说清楚优先级，以及造成的影响和后果，当时就一起把计划做出调整。- 一路向北2019-03-27把开会当做一个项目来看待，开会前就把开会需要解决的问题，以及开会的流程，开会的人员都确定好，确实很关键。从老师的这次课中学到很关键的一点是，不管是作为组织开会的人，还是需要参与的人，都应该对这次的会议做一定的分析，觉定如何开会，是否应该参会等，而不是盲目的去开会。
作者回复: 👍有收获就好
也谢谢补充 
dancer2019-03-27提升会议价值的方法主要有缩短时长和控制人数。首先是明确会议的相关议题，这样可以缩小参会人员范围；其次是事先相关人对议题有所准备，发言要简洁有效，避免议题过度发散；最后是会议结束后相关议题要有结论以及落实细节并存档。作者回复: 👍很好的经验分享
