Alan 为什么放弃了开会

#

他们的起点你一定不陌生：没人做准备，会议迟迟开不起来，嗓门最大的人不管对错总能拍板。一小时后，你比进会议室之前更糊涂，开始琢磨抽屉里还有没有止痛药。

Alan 一开始也想修好会议这台机器——最长 15 分钟、议程明确、必须产出决策。没用。讨论照样跑题，说过什么没人记得，缺席的和远程的同事干脆被排除在外。于是他们干脆把整件事搬进了文字里。

他们列举的好处我基本都认。写作逼你停下来真正思考，讨论因此更细致、论证更扎实；一切都有记录，不用靠七零八落的记忆；也不再是一场口才竞赛。而且论坛对全公司公开，谁都能参与讨论——不再只属于碰巧坐在会议室里的那几个人。

把 GitHub 当公司论坛用

#

这个"论坛"就是 GitHub。一个本为代码评审而生的平台，被 Alan 理直气壮地挪作他用。搭建过程简单得有点不好意思：

1. 注册一个 GitHub 账号。
2. 建一个没有代码的私有仓库（他们的叫"Topics"）。
3. 建一套标签体系，给对话分类。
4. 用 Issues 标签页：open 的是进行中的讨论，closed 的是已定的决策。

他们的 issue 已经超过 17,000 个。这意味着 17,000 场没必要开的会，而最让我心动的是：每一个决策为什么这么定，都留下了可搜索的历史。想推翻一个老决定？先去读读上次是哪些论据赢了。

什么时候开 issue

#

不是每个决策都配得上一个 issue。他们的过滤器是四个问题：谁会受影响？可逆性如何？急不急？做决定前还需要更多背景吗？

大体上，影响大、难回头的决策进论坛，其余留在 Slack。他们也用"单向门/双向门"的说法：单向决策（撤销代价太大，他们举的例子是涨价）走完整的书面流程；双向决策（撤销便宜，最坏不过损失点精力）就不必兴师动众。

LOCI：谁干什么

#

每场讨论都按 LOCI 模型分配角色——Lead、Owner、Consulted、Informed。

Lead 对决策的成败负责，确保决策背后的来龙去脉在团队里讲清楚。他会在讨论开头说明自己想介入到什么程度，之后信任 Owner、为团队的产出兜底，只在强烈反对时才出声。每场讨论只有一个 Lead。

Owner 拍最终的板，推着项目往目标走。他要保证每个参与者知情并按时发言，调查问题、收集答案、跟进进展，负责开 issue 也负责关 issue，最后做出决定并公之于众。碰到自己迈不过去的坎，就去找 Lead。每个决策也只有一个 Owner。

Consulted 是那些意见真正影响权衡的人。他们必须按时发言——哪怕只是一句"我没有补充"——如果认为决策错得离谱，就要拉响警报，最坏的情况上报给 Lead。Alan 把这个群体控制在六人左右，再多，进度就要付出代价。

Informed 通常在决策定了之后才被告知。沟通是单向的，不需要他们做任何事。通知谁，由 Owner 根据影响范围来定。

一个 issue 的解剖图

#

每个 issue 都用同一套模板。这既能磨利思路，也悄悄教会了初级同事怎么拆解问题：

• 范围——讨论的"为什么"，其中最被低估的一行是"这个 issue 不讨论……"
• 背景和材料——链接到之前的讨论和文档
• LOCI——谁是 Lead、Owner、Consulted、Informed
• 截止时间——发言截止日、issue 关闭日、必须拿出方案的日期
• 方案提议——推荐一个方案，或列几个供选择
• 提问——把具体的问题抛给具体的人，去证实或推翻具体的假设，免得 issue 变成一只"漂流瓶"

让讨论不拖沓的写作规矩

#

文字辩论拖起来一点不比口头的差，所以他们有规矩。首先是简洁——他们引用布瓦洛：“构思清晰的内容，表达也清晰。“写不简单，说明你自己还没想清楚。其次，每写一段都做一次"那又怎样？“测试：如果你这条评论的言下之意不明显，就把它写明白。

对 Owner 来说，开完 issue 之后的经营同样重要。让讨论始终对准那个"百万美元问题”——真正要紧的那一个卡点——别让它溶解在细节的海洋里；定期总结哪些已达成一致、哪些还悬着；Slack 提醒留作最后手段，只用于发言逾期或真正紧急的情况。

Owner 还可以隐藏那些没有推动对话的评论。另外，标题、脚注、表格、键盘快捷键这些 GitHub 排版功能，默认人人都要会用——在书面世界里，形式和内容几乎同等重要。

不搞共识，不养观众

#

有两条规矩防止这套系统沦为"委员会决策”。

第一，Owner 以 Alan 所说的"开明专制者"身份做决定。他去调研新想法、衡量风险、分析数据、追问同事——但不寻求共识，也没义务采纳听到的每一条建议。Alan 说得很直白：公司不是民主制。人人都是股东，公司利益排在团队和个人之前。当然他们也不要孤立、仓促、拍脑袋的决定。当 Owner 对这一注有了足够把握，就拍板，大家一起试；等影响逐渐清晰，再回头复盘，看下次怎么做得更好。

第二，控制参与人数。贝佐斯的"两个披萨"规则在异步世界照样成立：人越多，每个人的贡献越少。超过六个参与者，旁观者效应就开始冒头，参与质量随之下滑。通知也遵循同样的哲学，渐进式来——Alan 信任每个人都配置好了自己的 GitHub 通知（Settings 里把"Participating"和"Watching"下的"Web and Mobile"勾上），所以 issue 提问区里的 @ 能省则省。

我打算带走什么

#

一场会议的内容，永远没法向缺席的人复述完整；但一份写下来的决策，谁都能读。Alan 自己也说，这不是最好的、更不是唯一的方案，只是最合他们脾性的那一个：打断变少了，旁观者效应变淡了，做决策时能先退一步，事实也都写在纸面上。我不打算把团队的每个决定都搬进 GitHub issue，但下面这个模板，马上就进我们的仓库。

做成 GitHub issue 模板

#

把下面这段存成 .github/ISSUE_TEMPLATE/decision.md，放进你拿来当论坛的那个仓库，以后每次有人新建 issue，GitHub 都会把它列出来供选择。各个部分是 Alan 的，LOCI 那几行和标签是我加的。

---
name: 决策
about: 提出一个决策，以书面形式收集意见
title: "[决策] "
labels: decision
---

## 范围
- 这个 issue 的目标是……
- 这个 issue **不**讨论……

## 我为什么开这个 issue

## LOCI
- Lead：
- Owner：
- Consulted：
- Informed：

## 时间线
- 发言截止日：
- 决策截止日：

## 背景和材料

## 方案提议

## 提问

GitHub Issues 还是 GitHub Projects？

#

如果你在更大的范围里考虑拿 GitHub 做项目管理，这两样东西分工不同。Issues 承载讨论，关闭之后承载的就是决策本身。GitHub Project 则是铺在一个或多个仓库的 issue 之上的看板或表格，状态、负责人、截止日期这些字段都可以自己定义。像 Alan 这样的决策论坛，标签加上 issue 列表就够了。等你想把所有还没定的决策放在一个屏幕上、按必须拍板的日期排好序，或者开始在同一个地方跟踪交付工作时，再加一个 Project。大多数团队最后都是走到这一步，两样一起用。

我做过的项目里，最慢的从来不是代码，而是排队：一堆决策堵在某位经理的日程表前面，等一个三天后才到的点头。异步沟通和自主团队是标准解法，我也是信徒，但这场转变的本质，是一个披着工具外衣的信任问题。

为什么会变成事事签字

#

审批文化从哪来，值得公道地看一看。控制给人一种精确的错觉——每个决定都过经理的桌子，就好像什么都不会跑偏。一个错误决定不光砸项目，还砸经理本人的名声，所以恐惧出了大力。有时也确实是真心怀疑团队有没有足够的经验做判断。还有的时候纯粹是惯性：组织架构一直这么运转，于是继续这么运转。

注意，这四个原因里只有一个真的和团队有关，剩下的全是经理自己的事。

自主真正需要什么

#

没有对齐的自主，只是士气高昂的混乱。如果大家真的理解目标，各自独立做的决定大体会指向同一个方向——诀窍其实就这一条。培训也重要，因为一个装备齐全的人，比一个只有热情的人更容易被信任。边界要留着：确实有些决策应该留在管理层手里，把是哪些说出口，能避免最糟糕的意外。之后就让反馈循环转起来，把免不了的错误当学费，而不是当罪证。

如果信任已经受损——从审批文化里爬出来的团队，通常双向都受了损——那就没有捷径。开诚布公地把问题摆到桌面上，管理层先认下自己那份错，然后连续几个月无聊地保持言行一致。明确的分工和固定的沟通节奏，比任何轰轰烈烈的姿态都更能修复关系。

异步反而是容易的部分

#

工具的事三句话说完：Slack 或 Microsoft Teams 都够用。真正的功夫在文档——没人在同一间屋、同一个时区时，写下来的决定就是团队的记忆。定好响应规范，别让异步悄悄变成没人理；“一天之内”胜过“看情况”，这些规范应该和“谁收哪种更新”一起写进团队的沟通计划。另外要真的教大家写像样的异步更新：够做判断的上下文、需要的决定、截止时间。这个技能不是天生的。比如这样：

周四前需要拍板：支付重试
现在银行卡支付失败后，只会在 24 小时后重试一次；“我的订单怎么还没好？”已经成了最常见的客服咨询。
方案 A：24 小时内重试三次（大约半天工作量）。方案 B：维持现状，改为发邮件通知用户。
我建议选 A，细节和数据在附上的文档里。
如果周四下午 5 点前没人反对，我就按 A 开始做。

这样一条消息，早上 7 点看也好，晚上 11 点看也好，不管在哪个时区，都能不开会直接回复。

装一个 Slack 只要一下午。信任要花好几个月，而决定这一切成败的恰恰是信任。把目标讲清楚，让犯错的代价是一堂课而不是一份职业——做到这两点，异步那部分多半会自己长好。

我被拉去救火的那些项目，烂摊子多半不是烂代码造成的，而是该知道的信息没能及时传到该知道的人那里。在公司开始带项目之后，我一直在记笔记：如果哪天坐上CTO的位置，沟通该怎么管。这里整理出来。

先定好谁需要知道什么

#

不起眼但打底的东西是沟通计划：谁需要被告知、需要什么信息、多久一次、走哪个渠道。每个项目开始时就该定下来，而且要落到具体人头上——沟通一旦成了"大家的事"，就成了没人管的事。利益相关方也一样：理清谁真正关心这个项目，摸清每个人喜欢的汇报方式。发给CEO的更新，不能跟发到开发频道的一模一样。再定几条明文规则：多久之内该回复、什么算紧急、哪个渠道干什么用。所谓"沟通问题"，多半只是没说出口的期待对不上。

一份软件项目的沟通计划示例

#

这是我会先拿来用、再按项目调整的版本。每一行是一类受众，不是一场会议：

表格下面写规则，越直白越好：紧急指的是挡住了发版或者影响到客户，这时候直接打电话，别发消息；问题在聊天里问，决定记进任务跟踪系统；一个工作日内回复。决策日志我用的是决策文档，以GitHub Issues的形式保存，跟具体的工作放在一起。

这种计划能不能转起来，关键在两点：每一行的最后一列都写着一个具体的人；给管理层的更新是写下来的，不是口头说的，这样转发出去也不会丢信息。

工具和节奏

#

工具没有大家争论的那么重要。聊天用Slack，任务用Trello，需要见面聊就开Zoom——选个适合团队的，赶紧翻篇。更要紧的是节奏：敏捷团队就每日站会，周期长的项目就每周同步，然后真的坚持下去。还有，把东西写下来。决定、变更、待办事项，记进Notion或Jira，当成流程的一部分，而不是事后补的作业。半年之后，大家唯一的记忆就是那份文档。

软的部分才是硬骨头

#

上面说的都是机械层面。更难的在后头：问问团队现在的沟通方式到底管不管用，不管用就改。还有培养人——团队成员背景各异，有的人还没见过一个运转良好的项目长什么样。认真听别人说话，而不是等着轮到自己说；冲突要趁小趁早处理。而且这些问题解决一次不算完，上个季度好使的办法会悄悄失灵，只能定期回头检查。

分布式、异步开发团队怎么协作

#

如果你的团队是远程或以异步为主，这个演讲值得一看：

这些我自己也没全做到——没人能全做到。但回头看，进展顺利的项目大都占齐了这几条，而让人头疼的项目至少缺了三条。