🎯 什麼情境該想到我
當你「為了上一次線要開一堆會、開一堆工單，而沒有人說得出這些流程當初為什麼存在」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：把耗時數月的審批流程重新設計掉，讓交付價值更快也更安全——因為漫長的審批不只拖慢交付，還可能提高組織目標的風險。
Adrian Cockcroft 給的可公布指標：
- 「一個很棒、值得廣泛公布的指標是：完成一次發布，總共必須開幾場會、開幾張工單——目標是無情地減少工程師完成工作並交付給客戶所需的心力。」
- 也就是說：先把「會議數」與「工單數」量化並公開，才有辦法談減少。
手法：
- 用「五個為什麼」（the five why’s）追問這個流程存在的理由——一路問到「為什麼這個流程一開始會存在？」為止。
- 若團隊願意承擔該技術的營運責任（書中 Target 的例子明列為 service support、integration、availability、security），就可以豁免於原本的審批流程，不必依賴 Operations 團隊。
案例一：Capital One「Got Goo?」（Dr. Tapabrata Pal，技術院士）
- 一個專責團隊，負責移除阻礙工作完成的障礙——包括工具、流程與審批。
案例二：Disney「Join The Rebellion」（Jason Cox，系統工程資深總監，DevOps Enterprise Summit 2015）
- 目標是從日常工作中移除 toil 與障礙。
案例三：Target 的 TEAP-LARB（2012）
- 背景：Technology Enterprise Adoption Process（TEAP）與 Lead Architecture Review Board（LARB）合起來，讓任何人想引進新技術都要面對複雜、漫長的審批。任何人想提案採用新技術（新資料庫、新監控技術等）都要填 TEAP 表單；被評估為合適的才會排進每月一次的 LARB 會議議程。
- Heather Mickman（開發總監）與 Ross Clanton（維運總監）在推動 Target 的 DevOps 運動。Mickman 為了一個事業線的專案需要引進 Tomcat 與 Cassandra，但 LARB 的決定是 Operations 當時無法支援。
- 她的對策：既然她深信這項技術是必要的，就提議由她的開發團隊自己承擔服務支援、整合、可用性與安全的責任，不依賴 Operations 團隊。
- 用五個為什麼追問下去：「我想更了解為什麼 TEAP-LARB 流程要走這麼久……最後問到『為什麼 TEAP-LARB 一開始會存在？』令人意外的是，除了『我們需要某種治理流程』這種模糊概念外，沒有人知道答案。許多人知道多年前發生過某種災難、絕不能再發生，但也沒有人記得那場災難到底是什麼。」
- 她的結論：只要她的團隊承擔該技術的營運責任，這個流程對她的團隊就不是必要的；她並宣告未來由她們支援的任何技術都不必再走 TEAP-LARB 流程。
- 結果：Cassandra 成功導入 Target 並最終被廣泛採用；TEAP-LARB 流程最終被廢除（dismantled）。她的團隊頒給她「終身成就獎」，表彰她移除障礙、讓技術工作在 Target 得以完成。
書末呼應（John Allspaw 對一位新進資淺工程師的回答）：當她問「我可以部署這個小小的 HTML 變更嗎？」，Allspaw 回：「我不知道，可以嗎？」接著問：你的變更有人審過了嗎？你知道這類變更最適合問誰嗎？你有沒有做到一切你絕對做得到的事、去確信這個變更會在生產環境中按設計運作？如果有，那就別問我——直接改。 重點是提醒她：變更的品質由她自己完全負責；如果她已經做到讓自己有信心的一切，就不需要向任何人請求核可。
原文：「As Adrian Cockcroft observed, “A great metric to publish widely is how many」（L9906，接 L9907「meetings and work tickets are mandatory to perform a release—the goal is to」）
原文：「the first place. The surprising thing was that no one knew, outside of a vague」（L9940，接 L9941「notion that we needed some sort of governance process.」）
原文：「eventually widely adopted. Furthermore, the TEAP-LARB process was」（L9952，接 L9953「eventually dismantled.」）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 豁免是有代價的：Mickman 能繞開 TEAP-LARB，是因為她的團隊真的接手了營運、可用性與安全的責任。沒有承擔就砍流程，只是把風險丟給別人。
- 「沒人記得為什麼存在」是該追問的訊號，不是「所以一定沒用」的證明；五個為什麼是為了問出真正的目的，而不是為了得到想要的答案。
- 書中的結尾明說，這類工作需要高信任文化；在低信任環境裡自行豁免，會被讀成違規而非改善。
- 砍掉審批之後必須有東西頂上——同儕審查與自動化控制，見 同儕審查取代變更審批、保護部署管線。
🔗 相關工具
- 同儕審查取代變更審批（砍掉審批後，用同儕審查頂上）
- 把變更重歸類為標準變更（讓低風險變更根本不必進審批流程）
- 價值流圖（先量出「幾場會、幾張工單」與前置時間，才知道要砍哪裡）
- 程式碼審查準則（自行負責品質的具體判準）
- 工具-心理安全感（高信任文化是自主豁免能成立的前提）
- 工具-三步工作法（移除障礙、加速流動正是第一步）
- DevOps手冊