极客时间已完结课程限时免费阅读

13 | 白天开会,加班写代码的节奏怎么破?

13 | 白天开会,加班写代码的节奏怎么破?-极客时间

13 | 白天开会,加班写代码的节奏怎么破?

讲述:宝玉

时长11:49大小10.83M

你好,我是宝玉,我今天想与你讨论让很多程序员头疼的话题:开会。
说到开会,是很多人心中的痛,每天白天忙于参加各种会议,压缩了本来就少的可怜的工作时间。最可气的,有的人开完会工作就算完成了,而像我们写程序的,还得下班后加班加点赶进度!
所以一说到开会,程序员们往往如遇洪水猛兽一般,避之不及。

开会是有价值的

但我想说的第一个问题是:开会是有价值的。软件项目中有不少会议,其实有其价值所在,给你简单举例分析一下。
像评审会议,通过会议,可以让产品设计或架构设计在确定前,收集大家的意见,及时发现问题。
像每日站立会议,可以及时了解项目的进展,了解当前的困难和瓶颈,及时调整计划,解决问题。另外在会议上,每个人都要当众讲一下做过的事情和计划要做的事情,这也是一种无形的监督和约束。
像项目立项会议,可以创建一种仪式感,让每个人都知道项目的关键信息:
项目目标:这个项目是要干什么的,达到一个什么目标;
项目里程碑:项目的开始结束时间,项目的阶段划分,以及各个阶段的时间点;
角色分工:项目成员的分工和角色是什么,每个人知道自己的任务是什么,知道遇到问题该找谁;
流程规范:项目开发的主要流程是什么,基于瀑布还是敏捷。
像项目总结会议,团队成员可以一起总结一下项目的得失,把经验总结下来,帮助团队在下一次做的更好。
还有很多会议我就不一一列举。从上面可以看出,这些会议都是可以创造价值的。

开会是有成本的

开会的成本,就像房间里的大象,显而易见而很多人却有意无意无视它的存在。
我们做个简单的数学计算,假设一个程序员月薪一万元,如果他每天四分之一的时间在开会,那就相当于公司每月花了 2500 元在会议上。
这还只是一个人的成本,如果开会的人多,那么仔细算算,整体的会议成本其实很夸张的。所以我想说的第二个问题就是:开会其实是有成本的,而且还不低。

什么样的会议是有效率的?

其实软件项目中有些会议我是愿意参加的,因为是有价值的,高效的。比如说前面提到的每日站立会议,时间不长,但是收获很大。
再比如隔壁郑晔老师的《10x 程序员工作法》专栏中提到的“轻量级沟通”,其中建议的会议方式:人少,面对面沟通。这种小会通常也让我觉得很高效,经常能产生有价值的方案。
还有一些会议则让我觉得没什么价值,比如领导冗长的讲话,比如一堆人在偏离会议主题的讨论,比如跟我没什么关系却被迫参加的会议。
那么为什么这些会议给我的感觉完全不一样?这其实就是我想讲的第三个问题:会议是不是有效率,取决于它创造的价值是不是高于其成本。
我觉得像每日站立会这样的会议更有效率,其时间短、人数少,所以成本低,创造的价值高于其成本。而人数多,又偏离会议主题的讨论会则没有价值,这是因为人数多时间长,导致会议成本高,而其创造的价值远远不及成本。
那为什么还有那么多低效率的会议?因为有的会议,就不是为了创造价值。
比如说有的会议,花的成本不是组织者的,对他来说,得到他的会议价值就可以了。
你是砍柴的,他是放羊的,你和他聊了一天,他的羊吃饱了,你的柴呢?
还有很多会议,是因为组织者和参与者,都没有意识到开会其实是有成本的,所以浪费了成本还不自知。不过这种情况还好,还是可以想办法改进的。
接下来,我们来看看如何提高开会效率,破除避免白天开会,晚上还要加班写代码的节奏。

如何提高开会效率?

我们专栏有一篇文章《08 | 怎样平衡软件质量与时间成本范围的关系?》,很多同学看过里面讲的软件项目金三角理论后,直呼“醍醐灌顶”、“终于找到一套可以说服老板的说辞了”、“能够提高与产品经理打太极的水准”。
其实提高开会效率、提升开会价值的方法,就跟软件项目金三角的理论一样,只要从两个角度去想办法:减少开会的成本,增加开会创造的价值!
在具体探讨这两类方法之前,我们先要认识到一个前提:那就是要让大家意识到开会是有成本的,如果开会创造的价值不能大于其成本,就是浪费。
就像金三角理论,你得先让老板、项目经理明白三条边不可能都占,才好去沟通讨论。要提高开会效率,也需要大家先有这个意识,才能在具体措施上达成一致。
那么,有哪些方法可以减少开会的成本呢?
1. 砍掉一些没价值的会议
在日常工作中,还有很多会议其实并没有什么价值的。如果一个会议符合这些标准,你就要慎重考虑参加了:
没有目标的会议。大家都在随意发散,完全没有主题;
不能形成决策,没有会后行动。如果一场会议看完后都没有什么结果,那跟没开都没啥差别;
你属于可有可无的角色。如果一个会议,跟你其实没什么关系,你无法提供有效的反馈,对你也没什么价值,只不过是被人拉过去开会的,那不如把这个时间用来做一点对项目更有价值的事。
所以,你可以在每次要接受一个会议邀请之前,先问自己两个问题再做决定:这个会议我真的有必要参加吗?以及,有其他方式可以替代吗?
其实,很多问题并不是非要通过“会议”的方式解决。
以前我负责的一个服务,其他组需要调用,所以有一个组的同事想跟我组织一个会议,让我介绍一下服务,以及如何调用。我思考了一下,觉得准备这个会议我也要写一个 PPT,开会还得要时间,这时间我足够写一个详细的说明文档出来了,而且以后其他组再要用,也只要看文档就可以了。
于是我就跟他们说:“我们不用开会,我一会发一个文档链接给你们,如果有问题我们可以在聊天工具上沟通。”后来他们看完文档后,有几处不清楚的地方,在咨询过我以后,我将文档更新好,就没什么问题了,而且后面再不需要为这件事开会了。
2. 减少参与会议的人
会议的成本和两个因素相关:一个是人数,一个是时间。如果减少人数,就能减少成本。
减少人数好处还在于,人一少,每个人都会更投入,也更有效率,所以往往时间反而会少产出会高。而且,如果会议上要形成一些决议,人越多越难做决策,人越少越容易达成一致。要想有决议的话,先开几个小会,达成一致后再开大会,大会更多只是宣布一个结果。
像谷歌和 Facebook,他们对于会议的态度就是能不开就不开,无关的人不参与。Amazon 的规则也很简单:一场会议的人数,最多订两份披萨,如果超出这个规模,说明这个会议的人数太多了。
3. 缩短开会时间
减少开会成本的另一个方法就是缩短开会时间。缩短开会时间有很多成熟可靠的方案可以选择。
比如说站立会议,通过站立的方式逼着大家快点结束。
另外,麦肯锡开会上有些做法也值得借鉴:
每个成员有一张黄牌,用于喊停其他人会议中发散讨论无意义的话题;
有人控制节奏,大家快速发言;
PPT 不超过 3 张,鼓励大家预先准备,多讨论。
还有比如我们在前面敏捷开发介绍的例子,会议有人主持,当话题开始发散的时候,果断制止,放到“停车场问题”环节,也就是会议的最后专门讨论。
类似这样的缩短开会时间的办法,确实可以有效减少会议成本,这类提升效率的方法还有很多,你可以从这个角度多思考尝试一下。
4. 提升会议所创造的价值
如果能有效提升会议产出,也一样可以达到很好的效果。
比如说,每个会议要有明确的目的和主题,所有的讨论都要围绕会议目的展开。当你发现会议上一些问题的讨论偏离了会议的主题,例如一个需求评审会,结果架构师在讨论技术细节,这就完全偏离了主题。
你就应该站出来提醒一句:“现在既然是讨论需求,不如先不讨论技术上的问题,等到需求确定了,我们后面再慢慢讨论技术问题。”或者说:“不如这个问题我们另外组织一个会议讨论。”
还有开会后,要有明确的结论,有后续的待办事项,落实到个人,对待办事项有跟踪。
偷偷说一下,有时候一些没什么价值的会议,又必须要参加,我一般会参会前,用一个本子把一个技术难题、或者一篇博客主题,写下来。
开会的时候,把这个难题理清楚思路,把博客的提纲写出来,这样一个会议开完,我的问题也解决了,或者文章提纲也有了。同样也是收获满满,没有浪费太多时间。
这些都是提升会议价值的方式,相信你对会议成本有了概念以后,也可以找到很多可以帮助你提高开会效率、更好创造会议价值的方法。

总结

今天带你一起学习了解了开会的“道”,那就是开会是有价值的,开会是有成本,会议是不是高效,就看它创造的价值是不是高于其成本。
如果你想破除白天开会,加班写代码的节奏,就需要从缩减开会成本和提升开会价值的方向上去想办法,还需要让你的老板、项目经理都有“会议是有很高成本”的意识。
砍掉一些没价值的会议,减少开会的人数,缩短会议的时间,提高会议创造的价值。

课后思考

你在项目中,有哪些会议其实是可以不参加的?哪些会议是可以缩减人数的?哪些会议是可以缩短时间的?哪些会议是可以更好的提升价值的?或者你对上面的观点有哪些补充?欢迎在留言区与我分享讨论。
感谢阅读,如果你觉得这篇文章对你有一些启发,也欢迎把它分享给你的朋友。
分享给需要的人,Ta购买本课程,你将得18
生成海报并分享

赞 5

提建议

上一篇
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
下一篇
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
 写留言

精选留言(22)

  • 易林林
    2019-03-26
    会而不备、会而不议、议而不决、决而不行、行而无果本身就失去了开会的意义。 我认为会前准备是相当重要的,组织会议或者抛出问题的人,应该对整个会议的内容有深刻而清醒的认识,并且将思路整理成文(Word、PPT等),给参与会议的人一个明确的引导,让会议一开始就能很快进入状态,不需要过多的预热。 开会期间如果不讨论会议主题,只是聊一些边角料,去讲人生经历、讲感悟什么的,讲的人快活了,听的人郁闷了,但为了以示尊重,大伙儿还得专心致志听着,职场上也有不得已的地方。这里就会用到宝玉老师说的,会议组织者的场面掌控能力,什么时间、多长时间讨论某一问题,并控制参与者自由发言的节奏,及时拉回会议主题,保证会议的时效性。 如果因会议主题的讨论而衍生出的很多有用的信息,觉得这盘西瓜不错,那盘哈密瓜也不错,芝麻丢掉也可惜了,领导没决策,下属没主见(有主见也是从自己工作便利性上考虑),最终在会议结束的时候,留下了更多的问题,核心主题却没结果。个人觉得,每次会议的参与者都要达成共识,组织者是谁,决策者是谁,甚至有时候组织者要暗示决策者该表态了。 会议只是产生良好结果的前奏,相当于理论验证结果有了,剩下的就是去实际操作了。一旦决策者表态了,有了决定了,就该指定相应的负责人,定期汇报进度、展示阶段性的成果。最近就遇到旁边的一个部门,加班加点的修改方案,到客户那里去出差三天,回来了,本以为会有点动静,接下来一周都没啥动静,和大家聊天才知道,没指定谁来总览这件事,一直挂在相应副总经理名下,副总经理好像忘了似的,要么就是结果已经堪忧了。 行而无果,实际上是最让人绝望的,花了大量的人力物力,最后发现一切都是徒劳的,会前准备、会中讨论和决策、会后执行,好像每个环节都出了问题,没人有致命的错误,反正就是事儿没干成。 写这些,实际上是希望得到宝玉老师的指点,从专业的角度指点下我思维的误区,谢谢您。
    展开

    作者回复: 总结的非常好的👍 从课程的理论知识,结合了实际工作场景的案例👍 我不觉得思维上有任何问题:) 有一点意见可以参考:如果你需要别人给你意见,本质上跟开会一样,不宜主题太多太分散,不然别人抓不住重点。 下次你可以在总结完了后,针对一两个具体问题问,这样被提问的人更容易抓住重点,供参考。

    16
  • alva_xu
    2019-03-26
    老师今天的话题确实是我们大家在做项目中特别头疼要处理的问题。开会吧,怕耽误别人时间,不开会吧,怕别人的意见没有收集到,或者拍板了不算。我来谈谈我的学习体会: 1,会议组织者或者相关人员必须在会前确定好会议目标,并在线下预先和相关人员沟通准备材料,会后尽量要有一个会议纪要,特别是跨部门的会议(对于每日站会等scrum 中规定的常规性会议,已经形成了规范,相对好组织) 2,对于必须邀请领导(们)参加的会议,是最最考验组织者的。因为领导的发言可能是最不能受控的,这需要会议组织者的会议控制技巧,比如说事先给领导暗示时间,及时把领导发散出去的话题收回来,等等 3,在需要多人发言,征求多人意见的时候,用先发纸条各自写下自己的想法,然后再发言的形式会提高效率。 4,如果一些会议本身的话题比较多,可以考虑将议题分散成多个会议,大会拆成小会。 5,实在没办法必须开大会的时候,我作为组织者,鼓励大家带上笔记本电脑等工作工具,允许大家边工作边开会。这是,作为组织者,必须把握好哪些信息需要哪些人听或者反馈。 总而言之,会议组织者是最最重要的角色,除了考虑会议要达到的目的之外,还需要考虑节省与会者的时间。否则,参会人员的积极性会大打折扣,以后就没人来开你的会了。
    展开

    作者回复: 你这些宝贵经验对大家包括我都很有价值👍 我以前老板就特别能说,完全收不住😂

    10
  • aya
    2019-03-26
    老师【你是砍柴的,他是放羊的,你和他聊了一天,他的羊吃饱了,你的柴呢?】说的醍醐灌顶呀,人家还会说你的柴和我有什么关系...

    作者回复: 同一个会议,对不同的人价值是不一样的,别让自己当砍柴的陪放养的聊天:)

    10
  • 纯洁的憎恶
    2019-03-26
    提高会议效率,从成本收益入手。会议有成本,开会需谨慎,时长与人数和会议成本紧密相关。 主动做减法,减少会议数量,缩短会议时间,削减参会人数,降低会议成本。 努力做加法,明确会议目标,得出会议结论,落实后续责任,复用“听会”时间,提高会议价值。
    展开

    作者回复: 你这个简洁👍 本质上就是做加法和减法

    6
  • Felix
    2019-03-26
    我说一下我对开会的看法: 1. 要有主持人,之前遇到过没有主持人,就像没头苍蝇一样,特别容易脱离主题,尬聊,主持人控场,能够保持会议围绕议题进行 2. 要有书记员,当然书记员不是记流水账的,从同事那里学来,开会最重要一句话是"结论是什么",讨论半天没有结论,这会还不如不开,所以书记员重点记结论,会后将结论,即会议纪以邮件形式群发参会人以及抄送领导知晓 3. 如发现会议与自己无关了,要勇敢地离会,如需求评审,产品经常会邀请多方开发,如果已经确认剩下的议题与自己无关了,跟主持人确认后就可以离会,有同事跟我说他们会不好意思,我觉得大家都是做事的,应该能够互相理解,雷厉风行,不用不好意思😄
    展开

    作者回复: 对,我支持你的观点:有时候要勇敢离场,只要解释一下相信都能理解,毕竟会议之外创造的价值更大。

    4
  • williamcai
    2019-03-26
    看个人吧,作为程序员,我一般喜欢参加技术评审会,方案设计会,和代码评审,和我的职责息息相关

    作者回复: 是的,很多会议是有价值的👍

    4
  • hua168
    2019-03-26
    老师能说下,整个项目开始前到项目完全结束,一般都要开那些会议呀?目的是什么?

    作者回复: 我确实整理了一些,后来因为篇幅原因删减了,我和编辑商量一下,在下一次整理留言的时候放出来,作为这条回复。

    3
  • bearlu
    2019-03-26
    老师,能不能说说开会要留意些什么内容,我是个新手,每次开完会议,到开发的时候又找产品确认具体功能。

    作者回复: 我想你说的应该是需求评审会议或者需求讲解会议,对于这类会议,建议你会议前读一下文档,这样心中有数,同时对于文档中觉得不清楚或者有疑惑的地方记录下来,在会议中提出。 不同的会议重点不一样,开会之前你都可以实现了解下这次会议的主要目的是什么,然后事先准备一下,这样开会就会更有效率一些。 如果你是有具体某个类型的会议,也可以新开留言。

    3
  • 小老鼠
    2019-09-11
    1、老板无法接受项目三角形这么办?老板不听我话如何办? 2、所有会议有没有必要形成会议总结的必要?

    作者回复: 1. 帮助老板成长超出了你的职责范畴,让老板听话也超出了软件工程的范畴:) 2. 如果你加上“所有”,那么答案就是否定的,很多务虚的会议可能并不需要有会议总结。但开会之前有明确主题和目标,开会之后有结论、有后续行动和相应责任人、有总结,是很好的会议习惯。

    2
  • 果然如此
    2019-03-27
    正好有一个昨天开的产品会的案例,产品经理刚讲了不到一半,另一个技术人员就提了很多问题,有的是需求问题、有的是技术问题、还有的是这个产品的历史数据更新的问题,对于以上问题,由于产品只讲了一小部分,我觉得在这个时候提问题有点激进并且有的问题偏离了主题,所以在适当的时机,我及时打断谈话,并向产品经理询问是否全讲完了,答案当然是否定的,并请其继续讲完,在讲的过程我记录了一些问题,然后讲完之后,大家继续讨论和需求有关的话题。
    展开

    作者回复: 👍赞,这样的打断很有必要,不然很容易就偏离主题了!

    2
  • 青石
    2019-03-26
    组织会议,一定要有会议时间、地点、人员、主题,会前要有准备、会中讨论要有结果(指定干系人)、会后要跟踪。 没有主题、没有讨论结果、没有跟踪的会议,都属于无效会议。

    作者回复: 👍有价值的补充

    2
  • Jansen
    2019-04-17
    我们项目一般会开以下几个会议,老师看看我对它们的理解对不对: 1.每日站立会议。这个是很有价值的,可以把控项目进度、知道每个人的产出、每个人的计划、有哪些潜在的问题,偶尔还能意外学习到别人的研究成果。 2.需求分析会。这是产品经理将业务需求转换为开发人员能理解的系统功能的会议,对开发人员价值很大。但是需要产品经理事先自己充分理解需求的背景和细节,不然等到会议上发现需求问题是很影响开发人员对需求的理解的,因此会降低开会的价值,时间拖长了也会增加开会的成本。 3.开发设计方案评审会。这个是对需求中较难的点进行开发设计方案的确定,大家一起针对方案进行评估,给出自己的建议并最终达成一致,能有效避免个人思维上的盲点,从而造成测试阶段推翻原有方案大规模返工的风险。 4.代码评审会。每个人对自己的代码逻辑和规范进行讲解,时间冗长,大家很难保持长时间的注意力集中,而且会认为别人的代码与自己没什么责任关系,投入关注度不高。这个很头疼,不知道该怎么解决? 另外,老师还建议有什么别的类型的高价值会议?
    展开

    作者回复: 代码评审会我建议你可以改成Code Review。参考《06 | 大厂都在用哪些敏捷方法?(上)》中描述的。 也就是你每一个人写的代码,要合并到主分支之前,需要有人Review,Review的过程自然就需要去了解对方代码的逻辑和规范,也是个很好的相互学习的机会。 但这个必须要有配套的流程规范严格执行,要是流于形式就没有意义了。 需求分析会要拆开效果更好,先开一个大会概要性简单讲清楚整体需求,然后开小会和业务相关的开发人员沟通,这样更高效。 开发设计的评审会议要分多次开,一开始不要太细,先确定大方向,然后逐步细化。不然修改成本高,沟通难度大。 参考《21 | 架构设计:普通程序员也能实现复杂系统?》 还有一个很重要的会议就是迭代/项目回顾总结会议,在迭代或者项目结束后,大家一起讨论总结项目中得失,提出具体的改进意见。

    1
  • nicola
    2019-04-03
    本身项目在计划中进行着,但又有另外的任务插入需要占用很多时间,又要完成紧急任务又不对原来任务进行计划调整(按原计划进行),完完全全把责任推给开发者。

    作者回复: 这种确实不合理,如果有新任务插进来,那么就必须要对现有计划进行调整。 建议以后遇到类似临时插入任务的问题,当时就说清楚优先级,以及造成的影响和后果,当时就一起把计划做出调整。

    1
  • 舒偌一
    2019-03-26
    这个可以和第12节内容应用起来,会议也要有流程和规范。 个人认为之所以有一些没有价值的会议,是对会议成本不重视,党都对会议有严格要求了。 没有目标的会议不参加,没有会议资料的不参加,没有决策人参加的会议、不知道为啥邀请自己的最好不参加。 项目组自己的会议,不在工作计划中,都安排在下班前15分钟。
    展开

    作者回复: 👍很好的经验分享

    1
  • 远逝的栀子花
    2022-08-31 来自陕西
    关于高效会议的几个观点: 1、会议人数不要太多,人数多七言八语容易跑偏,且会议时间比较长,最后还达不成一致; 2、会议一定要有主持人,当出现跑题现象时,主持人及时将话题扳回; 3、提前预约主要与会人的会议时间; 4、会议一定要有会议结论,将会议得到的结论正式邮件发出来,遗留任务该分给谁就分给谁,遗留任务 、责任人、完成时间写明;
    展开
  • 李伟
    2022-08-18 来自浙江
    多面对面沟通,少开会
  • ifelse
    2022-06-23
    开会是有价值的,开会是有成本,会议是不是高效,就看它创造的价值是不是高于其成本。--记下来
  • Geek_34f2bd
    2021-07-04
    会开会,如何开会也是一个程序员的重要软技能,会议的发起者事前准备太重要了,尽量给参会的人选择题,而不是让参会者任意发挥的写一篇议论文也是一个能节省时间的重要方法。有些沟通其实可以会前就做好,大会也就是做一个宣讲。
  • 天天向上
    2020-01-24
    第一次开会容易,第二次就难了。所以要精心准备好会议(会议目标、会议预估时间,作为主持人要开门见山)及会议控制(会议偏移纠正和会后整理)
  • 天天向上
    2020-01-24
    投入与产出,如何平衡。国企会议多,产出还得另外算。