Day 15 · 2026.06.04

决策架构：让"谁拍板、怎么拍"不再靠运气

主题：Decision Architecture·4 个工具
"Disagree and commit." — Jeff Bezos, 2016 致股东信
本周的命题：技术 leader 上行的瓶颈，很少是"不会做技术决策"，而是组织里的决策机制坏了——没人知道谁拍板、可逆的小事走了重流程、重大不可逆的事反而被一句"先上再说"草草定了、决策后还在内耗。本期四个工具回答四个问题：这个决策值多重的流程（决策类型与机制）、谁拍板（RAPID）、怎么让日常决策快起来（DACI）、定了之后怎么让所有人真正执行（Disagree and Commit）。
TOOL 01

决策类型分层：先问这扇门能不能往回走 Type 1 vs Type 2 — Match Process to Reversibility

可逆性决策机制流程重量
一句话原则
决策前先分诊：双向门（可逆）就授权、快、容忍试错；单向门（不可逆）才值得慢、值得共识、值得你亲自上。流程的重量应当匹配决策的代价，而不是匹配你的焦虑。
名家原话
"Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly. But most decisions aren't like that — they are changeable, reversible — they're two-way doors." "有些决策影响重大且不可逆——单向门——必须有条理地、谨慎地、缓慢地做。但大多数决策不是这样——它们可改、可逆——是双向门。" — Jeff Bezos, Amazon 致股东信 2015
场景示范
情境：两个决策同时压过来——(1) 是否把核心订单服务从 MySQL 迁到一套新的分布式数据库；(2) 这个 sprint 用哪个日志库。
✗ 常见做法

你给两件事套了同一套流程：都开评审会、都要全员投票、都写长 RFC。结果日志库吵了两周；数据库迁移反而因为"大家都累了"被一句"先上线再说"草草拍了——把最危险的单向门走了最轻的流程。

✓ 修后做法（先分类，再选流程）

日志库（双向门）："错了一天就能换回来。我授权 X 自己定，今天就定，不开会。"

数据库迁移（单向门）："数据迁过去基本回不来。这个值得两周 RFC、值得拉 DBA 和 SRE、值得我亲自签字。"——把"慢"用在唯一该慢的地方。

决策前 30 秒分诊清单
  • 这个决策可逆吗？回滚成本是几小时、几周，还是不可能？
  • 它只影响一个团队，还是跨多团队 / 对外做了承诺？
  • 最坏情况能承受吗？（双向门即使错了也撑得住）
  • 我是不是在给可逆决策套了过重的流程？（决策瘫痪的头号来源）
  • 我是不是在给不可逆决策走了过轻的流程？（这个更危险）
双向门 · 可逆 · 回滚成本低（小时 / 天） · 默认授权，快速决策 · 容忍试错，错了就改 · 工具：DACI / 直接授权 · 例：选库、命名、配置参数 → 求快，别开会 单向门 · 不可逆 · 回滚成本极高或不可能 · 值得慢、值得共识 · 你亲自上、正式记录 · 工具：RAPID / RFC · 例：数据迁移、对外 API、选型锁定 → 求稳，慢慢来
常见错误
  • 一刀切流程。所有决策都要共识 = 把每扇双向门当单向门，团队慢死。
  • 用重流程规避担责。给小决策也加重审批，看似"严谨"，实则把"我拍板"摊薄成"大家一起拍"。
  • 把"难做"误当"不可逆"。工程量大不等于回不了头；很多大项目其实是可灰度、可回滚的双向门。
关键参考
Jeff Bezos, Amazon 致股东信（2015 / 2016）— "one-way / two-way door" 的原始出处，已成行业通用语。
TOOL 02

RAPID：给"谁拍板"一个明确答案 RAPID — Who Has the D?

决策权跨团队角色分配
一句话原则
当一个跨团队决策卡住，问题几乎从不是"信息不够"，而是没人知道谁拍板。RAPID 把决策拆成五个角色——Recommend（推荐）、Agree（同意，有否决权）、Perform（执行）、Input（输入）、Decide（拍板）。最关键的一条：D 必须是单独一个人。
名家原话
"Decisions are the coin of the realm in business. Every success, every mishap, every opportunity seized or missed is the result of a decision someone made or failed to make." "决策是商业世界的通货。每一次成功、每一次失误、每一个被抓住或错过的机会，都是某个人做了或没做某个决策的结果。" — Rogers & Blenko,《Who Has the D?》HBR, 2006
R Recommend 推荐 提出方案、搜集信息、驱动分析 A Agree 同意（有否决权） 少数人才该有——慎发 P Perform 执行 决策落地的人 I Input 输入 提供意见——但不投票 D Decide 拍板（唯一一人） 最终负责——绝不能是"两个 D"
字母 ≠ 流程顺序，只是助记；实际次序通常是 I→R→A→D→P。
场景示范
情境：三个团队要把一个单体服务拆成微服务，已经开了五次会没结论。
✗ 常见做法

每次会都是"大家觉得呢"，谁声音大听谁的，散会没人 own，下周原地重来。表面民主，实际是无人负责。

✓ 修后做法（会前发一张 RAPID）

"拆分边界方案由平台组 Lead Recommend；SRE 对可用性影响有 Agree（可否决）；DBA、各业务组 Input；Decide = 我（BigCat）；定了之后三个组 Perform。"

开场一句定调："今天这个会只有一个目的——听 Recommend、收 Input，然后我当场给 D。"

用 RAPID 前自检
  • 这个决策有没有恰好一个 D？（两个 D = 没有 D）
  • 每个 Agree（否决权）是不是真有正当否决理由？滥发 A 会让决策瘫痪。
  • Recommend 的人有没有被授予真正的话语权，还是只是"提案给领导改"？
  • Input 的人清楚自己不是在投票吗？要提前讲明，免得决策后觉得被忽视。
常见错误 + 女性视角
  • 把 A（否决权）发太多。每多一个 A 就多一个卡点，决策被"会签"拖死。
  • D 落到职位最高的人，而非最该负责的人。RAPID 的价值正是把"权"从职级解耦。
  • 让 Input 误以为自己在投票。决策后那群人会觉得"我的意见被无视了"。
Female Leader's Note 研究反复显示，女性更常被分配到 Recommend / Perform（做方案、落地执行），而 D 落到男性同事手里；同样，女性在会上的提议更容易被"重述"后归功他人。一个被验证有效的对策是 amplification（奥巴马时期白宫女性幕僚的做法）：当一位女同事提出关键建议，另一人立刻复述并点名"这是 X 的方案"。指派 RAPID 时把"谁是 Recommend、谁是 D"白纸黑字写下来，本身就是防止贡献被悄悄转移的机制。
关键参考
Paul Rogers & Marcia Blenko (Bain & Company),《Who Has the D? How Clear Decision Roles Enhance Organizational Performance》HBR, 2006 — RAPID 框架原始论文。
TOOL 03

DACI：工程团队的轻量决策权 DACI — Lightweight Decision Rights

轻量级单一 Driver日常决策
一句话原则
RAPID 适合重大、跨组、需要正式记录的决策；日常的团队内决策需要更轻的工具——DACI：Driver（驱动者，推进但不一定拍板）、Approver（批准者，唯一拍板，通常 1 人）、Contributors（贡献者）、Informed（知会者）。一页纸、一个文档、十分钟。
名家原话
"The whole decision-making process can be summed up in three phrases: free discussion, a clear decision, and full support." "整个决策过程可以归纳为三句话：自由讨论、清晰决定、全力支持。" — Andy Grove,《High Output Management》Ch.5
RAPID · 重大 / 跨多团队 / 不可逆 · 5 个角色，正式记录 · 较重，慎用 单向门用它 DACI · 日常 / 团队内 / 可逆 · 4 个角色，一页纸 · 轻快，可异步 双向门用它
场景示范
情境：团队每个小决策（用 axios 还是 fetch、要不要加 pre-commit hook、API 命名风格）都被拉到全员会上投票，工程师烦躁，决策越来越慢。
✗ 常见做法

你怕"不够民主"，所有事都全员讨论。一个 lint 规则吵了 40 分钟，资深工程师私下抱怨"什么都要开会"。共识文化反而成了效率黑洞。

✓ 修后做法（立 DACI 规范）

"团队内这类决策，提案人就是 Driver，写半页 doc：背景、选项、推荐。Approver 默认是我或我指定的 tech lead，一人。Contributors 在 doc 里异步评论 48 小时。到点 Approver 拍板、写下理由，给 Informed 一条广播。"

判断哪个工具：跨 3+ 团队 / 不可逆 / 要正式记录 → RAPID；团队内 / 可逆 / 求快 → DACI。

起一份 DACI 前自检
  • 这个决策真需要开会吗？还是一份 DACI doc + 异步评论就够？
  • Approver 是不是恰好一人？（不是"我们几个商量"）
  • Contributors 的输入窗口有没有截止时间？没有 deadline 的 input 会无限拖。
  • 决策记下来了吗？三个月后有人问"当时为什么这么定"，找得到答案吗？
常见错误
  • 把 DACI 用在重大不可逆决策上。轻量工具扛不住高风险——那种该升级到 RAPID + RFC。
  • Driver 和 Approver 是同一人却不自知。失去了"推进"与"把关"的分离，回到一言堂。
  • 决策不留记录。团队会在同一个问题上反复重新决策，每次都从零吵起。
关键参考
DACI 源自 Intuit，由 Atlassian Team Playbook（"DACI: a decision-making framework"）推广普及。
Andy Grove,《High Output Management》Ch.5 — "自由讨论 → 清晰决定 → 全力支持" 的决策三段论。
TOOL 04

Disagree and Commit：决策之后的纪律 Disagree and Commit — The Discipline After the Decision

异议执行团队承诺
一句话原则
异议属于决策之前，执行属于决策之后。一旦 D 拍了板，即使你不同意，也全力执行——而不是阳奉阴违、背后唱衰、或留一手等着说"我早说过"。这是高效团队与内耗团队的分水岭。
名家原话
"If you have conviction on a particular direction even though there's no consensus, it's helpful to say, 'Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?'" "如果你对某个方向有信念、即使没有共识，不妨说：'我知道我们意见不同，但你愿意陪我赌一把吗？求同存异、全力执行？'" — Jeff Bezos, Amazon 致股东信 2016
场景示范
情境：架构评审，你主张消息队列用 SQS（简单、够用），团队多数和老板倾向 Kafka。最终 D（老板）拍了 Kafka。
✗ 常见做法

你嘴上"行吧"，会后在团队群阴阳"反正不是我的决定"；Kafka 一出问题第一句"我早说了 SQS 更好"。团队学到的是：异议者会记仇、会等着看笑话——于是下次没人敢拍板。

✓ 修后做法（决策前清楚反对，决策后明确 commit）

决策前："我记录一下我的反对：SQS 运维成本低，我们的吞吐量两年内到不了 Kafka 的甜区。"

决策后："好，定了 Kafka。我不同意，但这是可逆的技术选型、不是单向门。我全力支持——迁移方案我来写，也会真心帮它成功，不会暗中盼它失败。"

承诺前自检
  • 我的异议在决策前充分、清楚地表达了吗？（决策后才说不算数）
  • 定了之后，我的言行是否一致地支持它？
  • 我有没有在背后用"我早说过"来收割？（团队毒药）
  • 如果这是不可逆且我判断有真实危害的决策——我是去 escalate 了，还是用"commit"来回避冲突？
边界（诚实承认）
Disagree and commit 不适用于"不可逆 + 高风险 + 你判断会造成真实伤害"的决策——那种要正式 escalate，不是默默 commit。把"求同存异"当成万能挡箭牌，等于放弃了你作为专业人士的责任。
常见错误 + 女性视角
  • 把沉默当成同意。没说反对 ≠ 真的认同，憋到决策后才爆发，最伤团队。
  • 用"disagree and commit"压制还没充分表达的异议。这是滥用，变成"闭嘴执行"。
  • 决策者把 commit 当"不许再讨论"。连新证据出现也不许翻案，就成了固执。
Female Leader's Note 女性表达异议时更容易被贴"不合群 / 难搞（not a team player）"的标签，同样的反对放在男性身上却是"有主见"。对策之一：把异议明确锚定在数据与共同目标上（"为了 SLA，我担心的是 X"），并在决策后第一时间、可见地表态支持。这套"清楚反对、然后明确 commit"的组合，反而能积累"靠谱、对事不对人"的声誉资本。
关键参考
Jeff Bezos, Amazon 致股东信 2016 — "disagree and commit" 出处。
Patrick Lencioni,《The Five Dysfunctions of a Team》— "Commitment is a function of clarity and buy-in"：承诺不等于共识，只需清晰 + 被听见。

本周习作 · Your Day 15 Action

本周你要做一件具体的事，不是反思也不是阅读：

选一个本周卡在你面前的决策。第一步，做 Card 1 的 30 秒分诊：单向门还是双向门？第二步，按规模选工具——跨团队就画一张 RAPID（白纸黑字写下唯一的 D 是谁）；团队内就起一份半页 DACI doc（一个 Driver、一个 Approver、48 小时异步 input 窗口）。本周内让这个决策真正"落地有人 own"。

会后记一行：这个决策从启动到拍板花了多久？比上次同类决策快了还是慢了？

深入思考

何时"单一 Decider"反而有害？
RAPID/DACI 都强调单一拍板者，但在高度专业、信息高度分散的决策里（比如安全架构、合规边界），单人拍板可能系统性漏掉关键信息。这类决策真正需要的不是"更多投票权"，而是结构化地把分散的知识汇集到 D 面前（如 pre-mortem、红队评审）。问自己：我是在追求决策速度，还是在用"单一 D"逃避把不同专业意见摊开来碰撞的麻烦？
RAPID/DACI 在强层级文化与扁平文化里落地有何不同？
在等级森严的组织（某些亚洲大厂、传统国企），把"D = 某个非最高职位者"写进文档，能否真正生效，取决于最高领导是否公开背书这套机制——否则纸面 D 会被"领导的一句话"覆盖。扁平文化的风险相反：人人都觉得自己有 input 权，反而无人愿当那个唯一的 D。框架是中性的，能不能落地取决于谁来撑腰。
"Disagree and commit" 与"明哲保身、随大流"的界线在哪？
两者外在行为相似（都支持了自己未必赞同的决策），区别在决策之前：真正的 commit 者会先清楚、有记录地表达异议，再全力执行；随大流者从头到尾不发声，是为了不担责。区分的检验：这个人在决策前有没有把反对意见摊在桌面上？如果一个人总是"事后才说早知道"，那不是 commit，是逃避。
决策速度 vs 决策质量，你的团队该往哪个方向调？
过去一年，是"决策太慢"伤害大，还是"决策太草率"伤害大？这个答案决定你该加流程还是减流程。常见误判：明明问题是"太慢"（双向门也走重流程），却因为一次草率决策翻车，反而给所有决策加审批——结果把整个团队拖进决策瘫痪。先诊断主要病因，再开药。
是否该强制每个决策都留"为什么"的两行记录？
决策日志（decision log / ADR）的长期价值常被低估：它让团队不必在同一问题上反复从零争论，也让新人快速理解"为什么我们当初这么选"。成本是每个 Approver 多写两行理由。问题是：在你的团队，不留记录导致的"重复决策"损耗，是否已经大到值得引入这点摩擦？多数成长中的工程团队，答案是值得。