并非所有沟通都需要开会。以全远程闻名的 GitLab，在公开的 Handbook 中明文规定以异步沟通为基础、不把会议当作默认选项的方针。正确设计同步与异步的区分使用，会议的数量本身就会减少，日程协调的负担可能大幅下降。

同步 vs 异步的判断矩阵

根据沟通的性质，区分使用同步（实时会议）与异步（文字 / 视频消息）。用以下矩阵来判断。

紧急 × 复杂

→ 同步（即时会议）

例：故障处理、投诉处理

非紧急 × 复杂

→ 同步（预定会议）

例：战略讨论、头脑风暴

紧急 × 简单

→ 聊天（即时）

例：审批请求、确认事项

非紧急 × 简单

→ 异步（文档）

例：信息共享、进度报告

向 GitLab 学习异步优先的原则

GitLab 的 Handbook（对外公开）中明文规定了以下原则。

能写的就写下来

不在会议上口头说明，而是写成文档共享。提问通过评论以异步方式受理

会议要录像

为了让无法参加的人之后能跟上，所有会议都录像并留下会议纪要

不要求立即回答

不期待对异步消息立即回复。也没有在工作时间外回复的义务，有时差的团队也能按各自的时间推进工作

不把会议当作默认选项

先考虑能否以异步方式推进，只有判断确有必要时才安排会议

例行的报告 / 共享类会议，有很大的余地可以替换为异步方式。尤其是以下会议，异步化的效果容易显现。

状态汇报会议

非常高

信息共享会议

高

评审 / 审批会议

高

头脑风暴

低（发散阶段同步更有利）

冲突解决

低（需要对话）

按会议类型看是否适合异步化

即使无法完全废止会议，充实会议纪要也能实现“异步参加”。在会议纪要中记录决定事项 / 行动项 / 讨论要点，建立让未参加者能跟上的机制，全员在同一时间聚集的必要性本身就会逐渐变弱。

引入异步沟通，直接关系到减轻远程会议日程安排的负担。作为引入的入口，选 1 个每周的信息共享会议，替换为在 Slack 或 Notion 上的异步报告，失败少，也容易感受到效果。