讀完這章你要能回答：一個技術決策該由誰拍板、誰被諮詢、誰能否決？我的團隊是卡在「沒人敢決定」還是「決定了沒人支持」？

架構決策記錄（ADR）解決的是「決策被寫下來」，但更前面的問題是「決策怎麼被做出來」。模糊的決策權，是工程組織最大的隱形成本——它讓討論永遠開不完，讓責任無人承擔。

結構化決策的六個問題#

在做任何重要技術決策前，先把這六個問題答清楚。它把「誰決定」拆成可分配的角色，避免「大家都覺得別人會決定」。

模糊是決策的大敵。沒有明確的「誰來決定」與「何時之前」，討論會無限發散、責任會無人認領。寧可指定一個未必完美的決策者，也不要讓決策懸空。

由誰決定：最低勝任層級與 peer-plus-one#

決策權該下放到「最低的勝任層級」——既要有足夠的技術深度看懂方案，也要有足夠的後果意識承擔影響。把所有決策都上推到高層，會讓組織反應遲緩；下放給沒有後果意識的人，則會累積風險。

• 最低勝任層級：在「有技術深度 + 有後果意識」的前提下，盡量靠近執行端。
• peer-plus-one：決策由同儕層級加上一位上級背書即可，不必層層上報。
• RACI 而非共識投票：用「誰當責、誰諮詢」分清角色，而不是靠舉手表決——共識投票會稀釋責任。

討論 → 決策 → 全力支持#

健康的決策文化有三段式節奏，缺一不可：

flowchart LR
    A[🗣️ 自由討論<br/>充分表達異議] --> B[⚖️ 明確決策<br/>由當責者拍板]
    B --> C[🤝 全力支持<br/>disagree and commit]

    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#e8f5e9

• 自由討論：在拍板前，鼓勵所有人提出反對意見與替代方案。
• 明確決策：到了截止點，由當責者做出清楚的決定，不留模糊。
• 全力支持：決策一旦做出，即使你原本反對，也要全力執行（disagree and commit）。沒有這一步，前面的討論只會變成事後扯後腿的彈藥。

預先對齊：even-over 與 nemawashi#

重大決策不該在會議現場「驚喜開獎」。兩個實務手法能讓拍板更順：

• even-over statements：用「我們選 A 甚過 B（even over）」的句式，把團隊的優先序明文化（例：「我們選長期可維護性，甚過短期交付速度」）。當具體決策出現衝突時，這些陳述就是裁決依據。
• nemawashi（根回し）：在正式決策前，私下逐一與關鍵關係人對齊，先消化異議、爭取支持。等到正式會議時，決策已是水到渠成，而非當場硬碰硬。

把這套流程接到 架構設計與決策 的 ADR 上：六問釐清「怎麼決」、ADR 記錄「決了什麼與為什麼」，兩者合起來才是完整的決策閉環。

本章要點#

1. 六問先答：什麼 / 何時前 / 誰決定 / 諮詢誰 / 誰可否決 / 通知誰。
2. 最低勝任層級：技術深度 + 後果意識，盡量下放、peer-plus-one。
3. RACI 不是投票：分清角色，別用共識投票稀釋責任。
4. 三段式節奏：自由討論 → 明確決策 → 全力支持（disagree and commit）。
5. 模糊是大敵：寧可指定不完美的決策者，也別讓決策懸空。
6. 預先對齊：用 even-over 陳述定優先序，用 nemawashi 提前消化異議。