法国健康保险公司 Alan 写过一篇讲他们如何做决策的文章，我反反复复看了好几遍。一句话概括：他们不订会议室，而是开一个 GitHub issue，把争论摆到文字里打。如今我自己也开始带团队了，这次是认认真真做了笔记。下面是我对他们这套系统的消化，夹带一些我自己的看法。
Alan 为什么放弃了开会#
他们的起点你一定不陌生：没人做准备，会议迟迟开不起来，嗓门最大的人不管对错总能拍板。一小时后，你比进会议室之前更糊涂，开始琢磨抽屉里还有没有止痛药。
Alan 一开始也想修好会议这台机器——最长 15 分钟、议程明确、必须产出决策。没用。讨论照样跑题，说过什么没人记得，缺席的和远程的同事干脆被排除在外。于是他们干脆把整件事搬进了文字里。
他们列举的好处我基本都认。写作逼你停下来真正思考，讨论因此更细致、论证更扎实；一切都有记录，不用靠七零八落的记忆；也不再是一场口才竞赛。而且论坛对全公司公开，谁都能参与讨论——不再只属于碰巧坐在会议室里的那几个人。
把 GitHub 当公司论坛用#
这个"论坛"就是 GitHub。一个本为代码评审而生的平台，被 Alan 理直气壮地挪作他用。搭建过程简单得有点不好意思：
- 注册一个 GitHub 账号。
- 建一个没有代码的私有仓库（他们的叫"Topics"）。
- 建一套标签体系，给对话分类。
- 用 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，但下面这个模板，马上就进我们的仓库。
提案模板#
范围#
- 这个issue的目标是…
- 这个issue不是关于…