轻量级沟通:你总是在开会吗
核心命题
会议是组织协作的必要手段,但会议过多是沟通效率低下的症状而非解药。轻量级沟通的核心是将信息同步与决策制定分离——信息同步通过异步工具完成,会议仅用于需要实时交互的决策与讨论。程序员的深度工作需要长段不受干扰的时间,而频繁会议是**心流状态(Flow State)**的最大破坏者。
1. 会议过载的根因与代价
1.1 会议类型的混淆
| 会议类型 | 目的 | 时长 | 参与者 | 更优替代 |
|---|---|---|---|---|
| 信息同步 | 传递状态 | 无需开会 | 全员 | 异步文档/消息 |
| 决策制定 | 做出选择 | 30-60 分钟 | 决策者 + 信息提供者 | 会议(无替代) |
| 问题解决 | 协作攻克难题 | 60-120 分钟 | 相关专家 | 结对编程/Workshop |
| 头脑风暴 | 生成创意 | 30-60 分钟 | 多元视角者 | 异步脑暴工具 |
| 进度汇报 | 向上级汇报 | 30 分钟 | 管理层 | Dashboard/周报 |
核心问题:组织中 60-70% 的会议属于"信息同步"和"进度汇报"类型,本可通过异步工具完成。
1.2 会议对深度工作的破坏
上下文切换的认知成本:
- 每次中断后,平均需要 23 分钟 重新进入深度工作状态(Gloria Mark, UC Irvine 研究)
- 一天 3 次会议打断 → 损失约 1-1.5 小时 的有效编码时间
- 程序员"晚上效率高"不是因为夜晚更适合编码,而是因为没有会议打断
1.3 轻量级沟通原则
| 原则 | 实践 | 衡量标准 |
|---|---|---|
| 能异步不同步 | 用文档/消息替代信息同步会议 | 同步会议数量减少 50% |
| 能短不长 | 25/50 分钟会议(而非 30/60) | 平均会议时长 < 30 分钟 |
| 能少不多 | 仅邀请必要参与者 | 每场会议 < 5 人 |
| 有议程有结论 | 会议前发议程,会议后发结论 | 每场会议有书面产出 |
| 有准备无空谈 | 参会者提前阅读材料 | 会上只讨论+决策,不"汇报" |
2. 异步优先的沟通架构
2.1 沟通工具的选择矩阵
| 紧急度 \ 复杂度 | 低复杂度 | 高复杂度 |
|---|---|---|
| 高紧急 | 即时消息(Slack/Teams/Lark) | 快速站会(15 分钟) |
| 低紧急 | 文档/邮件/PR Review | 定期会议(30 分钟 + 议程) |
2.2 现代异步协作工具链
| 工具类型 | 典型工具 | 替代的会议类型 | 适用场景 |
|---|---|---|---|
| 文档协作 | Notion/Confluence/Google Docs | 信息同步会 | 状态更新、知识共享 |
| 代码协作 | GitHub/GitLab PR Review | 技术评审会 | 代码质量、方案讨论 |
| 项目协作 | JIRA/Linear/Asana | 进度同步会 | 任务状态、依赖管理 |
| 即时消息 | Slack/Teams/Lark | 日常沟通会 | 快速问答、通知 |
| 视频录制 | Loom/Vidyard | 演示/培训会 | 异步演示、操作指南 |
| 白板协作 | Miro/FigJam | 头脑风暴会 | 架构设计、流程梳理 |
2.3 异步沟通的写作规范
异步沟通的效果取决于信息密度与结构化程度:
| 原则 | 说明 | 反模式 |
|---|---|---|
| 结论先行 | 第一句给出结论/请求 | 铺垫半天不说重点 |
| 结构化 | 用标题/列表/表格组织信息 | 大段无格式文本 |
| 可操作 | 明确期望读者的行动 | 模糊的"大家看看" |
| 自包含 | 包含所有必要上下文 | 需要追问才能理解 |
PR Review 作为异步技术评审的典范:代码变更 + 描述 + 评论 → 比会议评审更高效(可异步、可追溯、可搜索)。
3. 会议治理的实践框架
3.1 会议审计
定期对团队会议进行审计:
| 审计维度 | 检查项 | 目标 |
|---|---|---|
| 数量 | 每周会议总时长 | < 10 小时/人/周 |
| 时长 | 平均会议时长 | < 30 分钟 |
| 参与度 | 平均参与人数 | < 5 人 |
| 产出率 | 有书面结论的会议比例 | > 90% |
| 必要性 | 可被异步替代的会议比例 | < 20% |
3.2 无会议日(No-Meeting Day)
| 实践 | 公司 | 效果 |
|---|---|---|
| No-Meeting Wednesday | Shopify | 开发者满意度显著提升 |
| Maker's Monday | Asana | 深度工作时间增加 30% |
| Focus Friday | Meta | 代码提交量增加 |
3.3 站会的轻量化
传统站会(15 分钟 × 全员)的问题:大部分人只关心自己的部分。
| 改进方式 | 做法 | 优势 |
|---|---|---|
| Walk the Board | 看板上每张卡讨论,而非每人发言 | 聚焦工作项,减少冗余 |
| 异步站会 | Slack/Teams bot 收集更新 | 节省同步时间 |
| 按需站会 | 仅在有阻塞项时召开 | 减少无信息量会议 |
4. 总结
核心要义:能异步不同步,能短不长,能少不多。会议是昂贵资源,应仅用于需要实时交互的决策与问题解决。保护深度工作时间,是程序员效率的根基。
延伸阅读
- Cal Newport, Deep Work (2016): 深度工作与心流状态
- Jason Fried & DHH, Remote: Office Not Required (2013): 异步协作实践
- Gloria Mark, "No Task Left Behind?": 上下文切换研究
- Shopify No-Meeting Policy: https://shopify.engineering/shopify-no-meeting-policy
原文存档
以下为郑晔原文完整内容,保留作为参考。
22 | 轻量级沟通:你总是在开会吗?
今天我们来探讨一个很多程序员日常工作中,经常碰到却会带来困扰的话题:开会。
头疼的开会
有一次,我听到两个程序员在聊天。一个资深程序员说:“还是晚上好,我可以一门心思写代码”,另一个年轻程序员不解地问:“你白天也可以写啊。”
资深程序员很无奈,“我倒是这样想,可是白天参加那么多会,哪有工夫啊!我的代码就只能加班写了。”
这段对话听上去让人有点心酸,但这种现象,确确实实广泛存在于程序员的日常工作中,尤其是你经验丰富又在一个大组织中工作,这几乎成了你的宿命。在这些程序员的认知中,开会太多影响了他们写代码。
你以为我想讨伐开会吗?并不是,开会本身并没有错,因为开会的本意是将大家组织起来解决问题。但请你回想一下,你参加的会议有多少解决了问题呢?
开会是为了解决问题,但真实情况却是开了会又没有解决多少问题,这真是一个奇特的矛盾。
回想一下,你参加过的会议里面,有没有效果特别好的呢?在我职业生涯中, 凡是效果特别好的会议,基本上都是用来做信息同步的。 比如,领导宣布一个事情,这种会议几乎不会浪费时间。宣布消息,大家收到消息,结束。
那效果不好的会议是什么样呢?几乎都是那些讨论会,你一言我一语,每个会几乎无一例外,都有几个擅长打岔的,这个会基本上都会跑偏,时间就会这样一分一秒地流逝了。
我给你举个例子,我之前参加过一个上线计划的评审会,这个团队的负责人要把相关利益方都召集起来,其中包括上下游可能会受影响的团队、测试、运维等等,一个不大的会议室里挤满了人。
这个负责人刚开始讲方案没几分钟,下游团队的负责人就站出来问:“这个方案为什么要这么做?我担心会对我们系统造成影响。”讲方案的人只好停下来解释。结果是越解释,细节越多,双方你来我往,一个方案评审会,就转变成一个技术讨论会了。
测试和运维的同事本来是想来听技术方案,以便为后续的工作做准备的。看着双方的讨论,一脸无奈,因为他们知道,方案没确定好,所有的事情还是下回再说吧!
怎么样?是不是很熟悉的感觉。为什么会这样? 因为他们选错了沟通方式。
开会是一种重量级的沟通,几乎是我们日常工作中最重的。它有很强的仪式感,所以,大家相对来说会很重视。而且会议通常会牵扯到很多人,尤其是与这个事情相关度不那么高的人。
你可以想一下,有多少次开会,你是在精力集中的?如果你是高度集中的,那恭喜你,你是高效地参与其中。但更多时候,你可能神游天外,因为讨论的内容可能与你关系不大,或者你已经听不懂了,你坐在那里的唯一原因是,主持人还没宣布会议结束。
用开会这种重量级的方式讨论问题,就好比杀鸡用了牛刀,这是不恰当的。那该怎么解决这个问题呢?很简单,杀鸡用鸡刀。
轻量级沟通
实际上,真正在会议上能够积极参与讨论的人并不会觉得会议是浪费时间,因为高度参与其中,人是进入到心流状态的,时间流逝很快。觉得浪费时间的,往往是没有参与其中的人。
换句话说,会议之所以给人留下如此不堪的印象,一个重要的原因是,真正参与讨论的人并不多。所以,我们换个角度思考一下,只要把这些真正参与讨论的人拉到一起讨论不就好了?
所以,改善会议的第一个行动项是,减少参与讨论的人数。
有人会说,我这个讨论有好几个议题,每个议题要不同的人参与,那你要做的是,分别找这几个人专门讨论,而不是把大家放到一起。
不知道你发现没有,在讨论行动项的时候,我用的是“讨论”,而没有提到“会议”两个字。我之前说过了,会议是一种重量级的沟通方式。所以,我们会倾向于选择一种轻量级的沟通方式,比如面对面沟通,这样一来,每个人的压力就会小很多。
相比于会议的形式,面对面沟通因为注意力有限,参与的人数不可能太多。也因为参与的人数相对少一些,每个人的投入也会更多一些。
所以,我们的第二个行动项是,如果你要讨论,找人面对面沟通。
一旦理解了这些改进方式,我们就可以改进自己的行为方式。如果有一个问题需要讨论,我要做的是,分别找到相关人针对关心的主题进行讨论,然后,我把讨论的结果汇总再去征求大家意见。如果大家达成一致了,我才会选择开会。
这个时候,开会的目的不再是讨论,而是信息同步:我准备这么干了,相关各方已经同意了,知会大家一下,结束。
站立会议
我前面说过了,开会并非都是不好的,一些信息同步的会还是有必要的。
举个例子,有一种实践叫站会(Standup)。很多公司都在实践它,站会甚至成为每天的开工仪式。一般的做法是,早上大家来上班了,先开一个站会,让大家同步一下昨天的工作,然后开始今天的工作。
有的人一听到站会这个形式就会皱起眉头。如果是这样,多半是你的团队“站”错了。
你知道,这个会为什么是“站”会吗?因为按照一般人的习惯,站的时间不会太长,因为站的时间长,累啊!所以,如果站会超过10分钟,你的站会一定是错的。
也许你会说,这点时间恐怕不够给我们站会吧?因为每个人都有一大堆要说的。请问,你觉得其他人说那么多,你关心吗?现实是,一旦一个人说多了,跟你关系又不大,你就开始思维发散了。
所以,在总长固定的情况下,每个人发言的时间一定是有限的。在有限的时间内,你能说什么呢?我建议你只说三件事:
- 我昨天做了什么?
- 我今天打算做什么?
- 我在过程中遇到了什么问题,需要请求帮助。
“做了什么”,是为了与其他人同步进展,看事情是否在计划上。一旦偏离计划,请主动把它提出,这样,项目经理可以过问,因为这会涉及到是否要调整项目计划;
“要做什么”,是同步你接下来的工作安排。如果涉及到与其他人协作,也就是告诉大家,让他们有个配合的心理准备;
“问题和求助”, 就是与其他人的协作,表示:我遇到不懂的问题,你们有信息的话,可以给我提供一下。
这三件事都是与别人相关的,几句话快速说完,结束。因为这些事情与别人相关,所以,大家的注意力可以相对集中一些。
你或许会问,如果我的问题很复杂,需要讨论该怎么办。对不起,那是另外一件事,你可以在站会结束之后,找相关人去讨论,不要在这个会上浪费大家时间。在站会上,你只要在问题和求助中告诉大家,你有一个问题,需要相关人讨论,结束。
为了让大家保持注意力集中,我的一些团队还用过发言令牌的方式。比如,找一个毛绒玩具,谁拿到“令牌”谁发言,然后,随机地扔给一个人,一旦这个人走神,大家一下子就能发现了。
一些有趣的方式、短暂的时间,以及与所有人相关的事情,因为满足了这三点,所以普遍来说,这种站会效果还可以。
关于站会,有一个典型的错误是,有些团队把站会开成了汇报会。项目负责人指定一个个轮流发言,说的人都向负责人在汇报工作,其他人自然就容易走神了,因为事情与己无关。
还有一点你可能会有疑问,我所在的团队比较大,一个人几句话时间也会很长。
当团队很大时,更应该做的是把团队拆分了,因为你不太可能与20个人紧密地工作在一起。沃顿商学院曾经做过一项研究,5-12个人是一个恰当的团队规模,每个人在其中都能发挥自己的重要作用。
总结时刻
开会是很多程序员的困扰,太多的会议甚至会影响到你工作的进展。开会的本意是为了解决问题,但实际上,大多数会议并不能很好地解决问题。因为会议是一种重量级的沟通方式,很多人参加会议时,并不能很好地参与其中。
如果你想用会议的形式与别人讨论问题,最好放弃这种打算,面对面的沟通是最好的方式。因为面对面沟通很轻,人数相对少,每个人参与度就会高很多。基于这种改进,我们可以把大部分会议都改成信息同步的会,效率就会得到提高。
我还给你介绍了一种特殊的会议:站会。之所以采用站会的方式,就是要控制时间。在站会上每个人说什么,我给了你一个建议的格式:
- 我昨天做了什么?
- 我今天打算做什么?
- 我在过程中遇到了什么问题,需要请求帮助。
如果你经常组织别人开会,请你想一下,是不是自己没有利用好开会这件事;如果你经常被别人组织开会,不妨把这篇文章转发给他,让他别总是开会“讨论”问题。
如果今天的内容你只能记住一件事,那请记住: 多面对面沟通,少开会。
最后,我想请你思考一下,你在工作中,还遇到过哪些因为开会带来的问题呢?欢迎留言与我写下你的想法。
感谢阅读,如果你觉得这篇文章对你有帮助的话,也欢迎把它分享给你的朋友。