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。大多数团队最后都是走到这一步，两样一起用。

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

先定好谁需要知道什么

#

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

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

#

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

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

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

工具和节奏

#

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

软的部分才是硬骨头

#

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

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

#

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

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

没人喜欢被问"进展怎么样了？"。可作为在公司带项目的人，我又不能不知道进展。我的折中办法是Git提交图：先看图，再决定要不要问人。大多数时候，答案已经在图里了。提交活动、分支、合并一眼可见，谁也不用为此开会。

从图里到底能看出什么

#

如果你没仔细看过：图上每个节点是一次提交，每条岔开的线是一个分支，整张图就是项目的时间线。这个布局里的信息量出乎意料地大：

• 扫一眼就知道有几个活跃分支、提交频率如何。
• 突然安静下来的分支，或者几个星期没合并的分支，多半是有人卡住了。这种预警很值钱。
• 合并频率反映团队的协作方式。合并勤快，说明工作在持续集成；分支活得太久，往往意味着有人在孤军奋战。

打扰更少，对话更好

#

明面上的好处是：不打断任何人也能掌握进度。更大的好处在真需要谈的时候：谈话从图出发，而不是从猜测出发。“这个分支从周二就没动过，有什么卡住了吗？“比"有什么进展吗？“强太多了。

把节奏挑明也有帮助。我的习惯是大多数早上扫一眼，每周认真看一次。团队知道这个节奏，所以谁也不会觉得突然。

别把它变成监控

#

这一条我得反复提醒自己。提交数不等于价值——一次深思熟虑的提交可能顶五十次刷存在感的提交。能看到每次提交，不代表有资格质疑每个决定；要信任团队，只在模式真正不对劲时才介入。而且把图带进谈话时，它是反馈的起点，不是起诉的证据。

在终端里看图

#

只要装了Git就行：

git log --graph --oneline --all --decorate

各个参数的作用：

• --graph：在左侧画出分支和合并的线。
• --oneline：每个提交只占一行，显示短哈希和提交信息的第一行。
• --all：显示所有分支和标签，包括远程分支，而不只是当前所在的分支。
• --decorate：把分支名和标签名标在它们指向的提交旁边。新版Git在输出到终端时默认就会显示，但加上这个参数，用管道传给别的命令时名字也不会丢。

每天早上敲一遍这么长的命令太累，设个别名：

git config --global alias.graph "log --graph --oneline --all --decorate"
git graph

历史长的仓库，整张图怎么滚都滚不到头。几种缩小范围的办法：

git graph --since="2 weeks ago"    # 只看最近两周
git graph -20                      # 只看最近20个提交
git log --graph --oneline main..feature                # feature有、main还没有的提交
git log --graph --oneline --left-right main...feature  # 两边都显示，用 < 和 > 区分

最后两条是对比两个分支。这里用的是普通的git log而不是别名，因为别名里的--all会把其他分支全都带回来。两个点显示feature有而main没有的提交；三个点加上--left-right，会把两边各自独有的提交都列出来，一眼就能看出一个长期分支已经跑偏了多远。

在VS Code里看图

#

VS Code自带提交图。打开源代码管理视图（Ctrl+Shift+G），里面有一个Source Control Graph分区，这是1.93版（2024年8月）加入的。默认只跟踪当前分支和对应的远程分支，用图标题栏上的分支选择器可以加上别的分支。随手看一眼的话，这就够了。

想一次看全所有分支，就装mhutchie开发的Git Graph插件（在扩展视图里搜"Git Graph”）。打开方式有三种：状态栏上的Git Graph按钮、源代码管理视图顶部的Git Graph图标，或者在命令面板里运行 Git Graph: View Git Graph (git log) 。点一个提交可以看它改了哪些文件；先点一个提交，再按住Ctrl/Cmd点另一个，就能对比这两个提交。不过这个插件从2021年起就没有发过新版本，所以自带的提交图也值得会用。

如果看不到Git Graph按钮，多半是插件没找到仓库。它默认只检查你打开的那个文件夹本身，不会往子文件夹里找。直接打开仓库所在的文件夹，或者在设置里调大git-graph.maxDepthOfRepoSearch就行。

其他工具

#

大多数Git工具都能看图。gitk --all是Git自带的历史浏览器。GitHub、GitLab、Bitbucket的仓库页面都有"network"或"graph"视图。桌面客户端里，SourceTree（Atlassian出的免费工具）、GitKraken、Tower，以及Windows上的TortoiseGit，也都能画提交图。

选哪个都行，目的只有一个：看懂进度，而不是数提交。