第五部分 — 长远之局

小团队的运行原则

这本书里的一切，都写自并写向一个正在成为常态的约束： 严肃的受监管软件，由一个坐得进一张桌子的团队来构建。 小团队拼工作量拼不过大团队；它只能在决策上胜过对方。 本章讲的是一套操作系统——不是代码，而是习惯——让少数 几个人能运转一个信任产品，而不让自己成为它的瓶颈。

用书面形式做决定

小团队淹死的不是工作，而是悬而未决的工作。对策很 便宜：每一个有重大影响的决定——一次契约变更、一次重建 而非吸收、一次范围砍削——都留下一条简短的记录：背景、 选项、选择、后果。不是 wiki 坟场；而是一串有编号的记 录，新人一小时读完就能明白系统为什么长成今天这个样子。 检验一条决策记录的标准是：十八个月后，它是否仍能解释 系统的形状——以及团队能否分辨出现实何时已经跑在了它 前面、该写新记录了。

让系统去记忆

少数人的团队负担不起只活在脑子里的知识。利息最高的 习惯是：每一个来之不易的运维事实——某个数据源的怪癖、 某个端口被钉死的原因、某种故障模式的特征——在被学到 的那一刻就落进一份持久的文件里，结构化到下一个行动者 (人或机器)可以直接据此行动。同一个习惯的更冷峻版本： 每次事故都产生一段落长的条目——症状、根因、修复—— 编入索引，使下一次事故是一次查询，而不是重新发现。 这样做的团队会复利增长；不这样做的团队，每年都会重新 求解自己第三大的问题。

按节奏发布，每次发布必核验

小团队必须持续发布——大爆炸式发布是信任产品的葬身之 地，因为每次发布都变成一次重得无法重复的确认事件。信 任层本身正是这里的使能者：当每次渲染都对锁定参照做核 验时，频繁发布比稀少发布更安全，因为漂移在关口就被 抓住，而不是在暗地里累积。于是节奏成了一件质量仪器： 每周都有东西出厂，而比对机制就是那场永不疲倦的评审。

以用户为中心是调度策略，不是海报

"以用户为中心"只有在它能决定日历时才算数：下一个工作 单元，是能为某个真实用户解锁某个真实任务的那一件，如 果你叫得出名字，就追溯到那个具体的人。服务不了任何可 具名用户的功能，排队等着。对信任产品而言这加倍成立， 因为它的用户以怀疑为职业——你为一位 QA 评审员消除的 每一分摩擦，都会变成一个他在内部转述的故事，比任何营 销页面都有说服力。

保持身份狭窄

最后一个习惯最难：谢绝相邻的荣耀。新的分析类型、新的 治疗领域、新的仪表盘——相邻的机会无穷无尽，而每一个 都在稀释小团队唯一能守住的东西：狭窄的主张，绝对地 守住。"我们把临床输出背后的证据工业化"是一句市场记 得住、小团队守得真的话。当团队回答"你们是做什么的？" 需要一页幻灯片的那一刻，护城河就开始被填平了。

这些习惯里没有一条是英雄主义的。这正是要点。在受监管 软件里，英雄主义是一种气味——它证明上游某处的结构失 效了。那个安静的团队，手握契约、记录、关口和一句狭窄 的承诺，在任何有意义的时间尺度上，都会比没有这些的 聪明团队活得更久。

检验。 最后一条是自反的：一个胜任的陌生人，能否 只凭系统及其记录对自身所说的一切，明天就接手这本书 里的系统？ 如果能，团队就自由了，可以去建造只有他们 能建造的东西。如果不能，团队本身就是系统——而团队是 会死的。