鳳凰專案 The Phoenix Project

📌 30 秒摘要（Layer 3）

用一本「IT 版的小說」講 DevOps：主角接手一個瀕臨崩潰的關鍵專案，靠著把製造業的原理（豐田生產、約束理論）搬到 IT，把混亂救回來。核心洞見：IT 工作就像工廠的生產線——要讓工作順暢流動、建立快速回饋、持續學習實驗（三步工作法）；先看清四種工作類型，找出並保護約束點（瓶頸），狠狠降低在製品（WIP）。

🗺 心智圖（Canvas）

鳳凰專案

🔥 鳳凰專案

The Phoenix Project

工具-三步工作法

🎯 什麼情境該想到我

當你想從「整體」改善研發到交付的流程（而不只是修單點），或想導入 DevOps 時的總框架。

⚙️ 怎麼用（三個方向）

1. 第一步・流動（左→右）：讓工作從開發順暢流到營運。縮短前置時間、降低批量與 WIP、讓瓶頸可見（見 工具-降低在製品WIP）。
   還有兩件同樣屬於第一步、卻最常被漏掉的事：

   • 真正理解 IT 所處的那個業務系統——Deming 稱為「appreciation for the system」。你得知道組織對外承擔了哪些沒人明講的承諾（見 工具-把業務目標接到IT風險）。
   • 把不必要的工作移出系統：

     “Being able to take needless work out of the system is more important than being able to put more work into the system.”
     （能把不需要的工作拿掉，比能把更多工作放進去更重要。）
     而且要記得「重要的是成果——不是流程、不是控制，也不是你完成了哪些工作」。

2. 第二步・回饋（右→左）：建立快速、持續的回饋。自動化測試、監控、把問題在源頭擋下，別讓缺陷往下游流。

   • 關鍵動作是讓等待時間可見：知道工作在誰的佇列裡躺了幾天，尤其是往回流（缺料、返工）的部分（見 工具-等待時間與閒置產能）。
   • 回饋要一路往前推到產品定義與設計的最早期，不是只在部署前才接上。

3. 第三步・持續學習與實驗：打造允許嘗試與從失敗學習的文化。這一步不是靠喊口號，書中有三個具體載體：

   • Improvement Kata：跑兩週一輪的改善循環。Mike Rother 用「kata（型）」這個字，是因為重複造成習慣，習慣才帶來精熟——每天練五分鐘，勝過一週練三小時一次。
   • 給預防性工作固定配額：書中最後 Bill 的團隊達成「15% 的時間投在預防性基礎設施專案」，並據此重構或汰換掉最脆弱的十個系統。
   • 主動注入故障：定期在系統裡注入故障，做得越頻繁就越不痛（書中最後真的部署了 Chaos Monkey，第一週天下大亂，幾週後系統才真的變得堅韌）。

   “Improving daily work is even more important than doing daily work.”
   （改善日常工作，比做日常工作本身更重要。）

   判準只有一個：改善什麼幾乎不重要，只要你在改善某個東西就好——因為不改善的話，熵保證你正在變差。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 三步大致有先後，但不必等前一步「做完」才開始下一步。 書中 Bill 是在剛開始掌握第一步（流動）的同時，就已經走在第三步的路上了——他只是在回顧會議上開始邀開發的人來參加故障檢討，那就已經是第三步。別把它讀成必須依序通關。
• 但反過來說也成立：完全沒有流動與回饋的基礎，光談文化與實驗會空轉。
• 第一步最容易被誤讀成「把東西推更快」。實際上它更常是把不該做的事拿掉——那比加速任何一段都有效。

🔗 相關工具

• 工具-四種工作類型 —— 第一步「流動」的前置作業：工作看不見就談不上優化流動，先把它分類攤開
• 工具-找出並管理約束點 —— 第一步「流動」的核心操作：不在約束點上的改善，對整體交付速度沒有幫助
• 工具-降低在製品WIP —— 第一步「流動」最容易上手的槓桿，也是最快能感受到效果的一招
• 工具-等待時間與閒置產能 —— 第二步「回饋」的具體動作：把等待時間算出來、畫出來，才知道要回饋什麼
• 工具-把業務目標接到IT風險 —— 第一步的前提：不理解自己所處的業務系統，就分不清什麼工作重要、什麼該拿掉

① 流動 工作由左到右順暢流動，縮短前置時間

② 回饋 建立由右到左的快速回饋，讓等待時間可見

③ 持續學習與實驗 兩週一輪的改善循環，並主動注入故障

「改善日常工作，比做日常工作本身更重要。」

🔄 三步工作法

工具-四種工作類型

🎯 什麼情境該想到我

當團隊「明明很忙，卻說不清在忙什麼、重要的事一直被擠掉」時。先把工作分類，讓它可見。

⚙️ 怎麼用

把所有工作歸到四類，攤在看板上讓它可見：

1. 業務專案：直接產生業務價值的專案。
2. 內部 IT 專案：基礎設施、自動化、還技術債。
   → 這一類永遠會被往後排，所以要給它固定的產能配額。書中用過 15–20%（解凍時分配 20% 的產能給內部改善專案，結局處實際守住的是 15% 的時間投在預防性基礎設施專案）。數字不是硬規定，「有一個明確的配額」才是重點。
3. 變更（Changes）：對系統的各種調整。這一類最容易寫成空話，書中的做法很具體：
   • 把每一個變更寫成一張索引卡貼在牆上，讓左手知道右手在做什麼。
   • 套 80/20 法則：20% 的變更帶來 80% 的風險——不要平均用力，只要盯住那 20%。
   • 預先定義「脆弱」清單：列出最脆弱的十個服務、應用與基礎設施，任何可能動到它們的變更請求一律自動升級、必須經過變更審查會核准才能排程實施。
   • 對這類變更預先安排待命：排定實施時段，讓關鍵人員（甚至廠商）在場待命，就像飛機迫降前先讓消防車在跑道邊等著。
4. 計畫外工作（Unplanned Work）：救火、故障、返工。這類是最貴的——它會擠掉前三類。
   • 更精確的名字是「反工作（anti-work）」，因為那更凸顯它的破壞性與可避免性。
   • 它的本質是復原工作（recovery work）：跟其他三類不同，它幾乎總是把你帶離目標，而不是推向目標。
   • 所以最重要的動作不是「更快救完火」，而是弄清楚你的計畫外工作到底從哪裡來。

看清比例後，重點放在減少計畫外工作（靠回饋與預防），把產能還給計畫內工作。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 計畫外工作不是「額外努力」，是「前面沒做好」的利息；要往上游治本。
• 第四類的統計比「有沒有變少」更有用的是「來源」。只記錄「這週救了幾次火」不會讓你變好；記錄「火從哪裡來」才會。
• 排內部 IT 專案的優先序時，書中用的是一個很銳利的分法：分成「需要瓶頸出手的」「能提升瓶頸產能的」「其他」三份清單——最重要的是第二份。

🔗 相關工具

• 工具-找出並管理約束點 —— 下一步，工作分類攤開之後才看得出瓶頸卡在哪一類
• 工具-降低在製品WIP —— 最常見的診斷結果：計畫外工作太多，多半是 WIP 過高造成的
• 工具-三步工作法 —— 上位框架，四種工作類型是第一步「流動」的前置動作

業務專案 / 內部 IT 專案 / 變更 / 計畫外工作（救火）

計畫外工作的本質是復原工作，永遠把你帶離目標——要追它從哪裡來

「未計畫的工作，是會殺死你的那種工作。」

👀 四種工作類型

工具-找出並管理約束點

🎯 什麼情境該想到我

當你「改了很多、加了人力，整體卻沒變快」，或發現所有工作都卡在某個人/某道工序時。

⚙️ 怎麼用（約束理論的五步驟）

在瓶頸以外做的任何改善，都是幻覺。 瓶頸決定整個系統的產出速度。

1. 找出約束點（identify）：工作大量堆積在哪之前？
   ⚠️ 約束點是「工作中心」，不是「人」。 書中 Bill 說瓶頸是工程師 Brent，被 Erik 當場譏諷（「所以 Brent 突然變成一台機器人熱處理爐了？這大概是我聽過最蠢的說法」），逼他自己改口：

   “Brent is a worker, not a work center,” I say again. “And I’m betting that Brent is probably a worker supporting way too many work centers. Which is why he’s a constraint.”

   Brent 之所以是約束，是因為他一個人支撐了太多個工作中心。這個區別會導向完全不同的行動。

2. 善用它（exploit）：確保瓶頸永遠不閒置、只做真正該它做的高價值工作。書中那套協定極具體，可以直接抄：

   • 建一個 level 3 工程師池負責所有升級案件，關鍵人物不在池內
   • 要找他，必須先取得主管核准，而且找的人要負責把學到的東西寫成文件
   • 同一個問題不准讓他做第二次，每週稽核，違者兩邊都要付出代價
   • 不准他碰鍵盤——只能口述、旁觀別人打；任何無法事後被文件化的動作一律不准
   • 每次事故結束就多一篇知識庫文章，以及多一個會修這問題的人

3. 一切配合它排程（subordinate）：整個系統的節奏跟著瓶頸走，別讓它前面堆料、後面挨餓。
   前置作業是建 bill of resources——「每項工作需要哪些工作中心、有哪些前置條件」的清單。有了它才知道哪些專案根本不需要動到瓶頸、可以安全放行。

4. 提升瓶頸產能（elevate）：把它的工作標準化／文件化／自動化／移轉出去。
   ⚠️ 在做完這件事之前，多招幾個一樣的人沒有用：

   “until you do this, no matter how many more Brents you hire, Brent will always remain your constraint. Anyone you hire will just end up standing around.”

5. 重複（repeat）：解除後，下一個瓶頸浮現 → 回到第 1 步。

進階：把瓶頸移到產線最前面

只保護瓶頸不被打斷還不夠。書中最反直覺的一招是把瓶頸放到隊伍最前端——讓他參與開發流程的最早期階段（如同《目標》裡把 Herbie 移到隊伍最前面）。
理由是：最懂技術債在哪、最懂怎麼寫出對維運友善的程式碼的人，如果永遠在下游救火，那些「非功能需求」就永遠只能事後補、而且補不進去。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 在瓶頸「之後」做改善無用（它會餓著等料）；在瓶頸「之前」加速只會堆更多料。
• 別把「人」誤認成約束點。說「某某是瓶頸」聽起來很順，卻會導向錯誤解法（叫他加班、招一樣的人）。正確問法是「他支撐了哪些工作中心？哪些可以移走？」
• 每次讓關鍵人物修好一個沒人能複製的問題，他就變聰明一點，而整個系統就變笨一點。 這是縱容英雄主義的真實代價。
• 即使某個資源不是瓶頸，只要利用率拉高又有多次交接，照樣拖慢交付（見 工具-等待時間與閒置產能）——別把「不是瓶頸」讀成「可以隨便塞滿」。

🔗 相關工具

• 工具-四種工作類型 —— 找瓶頸的前置作業：工作先分類、變可見，才看得出東西實際卡在哪道工序
• 工具-降低在製品WIP —— 保護瓶頸最直接的手段：少放料進系統，瓶頸前就不會堆積、也不會被切換打斷
• 工具-等待時間與閒置產能 —— 補足另一半：瓶頸解釋「系統整體產出的上限」，等待時間解釋「非瓶頸環節為什麼也在拖慢你」
• 工具-技術債功能凍結 —— 極端情境的配套：債大到動不了時，用一次性凍結把資源集中到約束點，並近乎誇張地保護它
• 工具-三步工作法 —— 上層框架，管理約束點屬於第一步「建立左到右的流動」；跳過去看解完瓶頸後接什麼

「在瓶頸之外所做的任何改善，都只是假象。」

⚠️ 約束點是工作中心，不是人；Brent 是支撐了太多工作中心的那個人

標準化與文件化之前，再招幾個一樣的人都沒用

🚧 約束理論・瓶頸

工具-降低在製品WIP

🎯 什麼情境該想到我

當你/團隊「同時開一堆事、每件都在進行中卻沒幾件完成」、一直被打斷切換時。

⚙️ 怎麼用

1. 限制同時進行的工作數量（WIP limit）：把看板每一欄的在製品設上限，滿了就不准再拉新工作進來。

2. 先完成、再開始（Stop starting, start finishing）：把卡住的先做完，而不是又開新的。

3. 減少多工與情境切換：切換的隱形成本極高，專注把件數壓低。

4. 保護瓶頸：別讓工作在瓶頸前無限堆積（見 工具-找出並管理約束點）。

5. 往上游走：縮小批量。這是比「限制件數」更根本的槓桿——

   「在任何工作系統中，理論上的理想是單件流，它讓產出最大、變異最小。而達成的方式是持續縮小批量。」

   反過來說，把發布間隔拉長、每次塞更多功能進去，是在做完全相反的事，最後連「控制版本間變異」的能力都會失去。

6. 拿掉不必要的工作，比少放工作進去更有效：

   “Being able to take needless work out of the system is more important than being able to put more work into the system.”

降低 WIP 會縮短前置時間、加快流動——這是三步工作法第一步的核心手段。

🧊 WIP 高到失控時的起手式：全面凍結 → 分批解凍

書中 Bill 面對「什麼都在做、什麼都做不完」，用的是最猛的一招：凍結所有專案。

• 效果：凍結後的七天內完成的事，比平常整整一個月還多。優先權衝突與惡性多工消失了，「從沒看過大家這麼專注」。
• 代價要先想好：專案發起人會強烈反彈，會有一堆主管來要豁免、或想私下偷跑；要有人（通常是更高層）擋在前面。
• 解凍要有節奏：目標是「把水龍頭慢慢轉開，開到夠喝但不會淹死」。書中的做法是先放行前五大業務專案，並用顏色把看板卡片分類（前五大業務專案／其他／內部改善），確保比例是刻意維持的、不是隨機的。
• 優先放行不需要動到瓶頸的專案——那些幾乎是免費的產出。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• WIP limit 會讓人「不舒服地閒下來」——那正是暴露瓶頸、逼出改善的重點。
  這不只是直覺，有數學撐腰：等待時間 ＝ 忙碌率 ÷ 閒置率，所以閒置是排隊時間的分母，把它壓到 0，等待時間就趨近無限大（見 工具-等待時間與閒置產能）。
• 真正的 WIP 大頭在跨部門的交接，不在你自己團隊裡。 部門內部的排序已經很難，跨部門至少難十倍——只優化自己這一段，看板會很漂亮，交付還是很慢。
• 別把它讀成「所有人都該閒著」。要壓的是同時在進行的件數，不是每個人的工作量。

🔗 相關工具

• 工具-三步工作法 —— 上位框架，降 WIP 是第一步「流動」最快見效的一招
• 工具-找出並管理約束點 —— 配套判斷，WIP 該壓在哪一段由瓶頸位置決定
• 工具-等待時間與閒置產能 —— 這張卡的數學依據：解釋「為什麼把人排滿反而更慢」，也是說服別人接受 WIP limit 最有力的材料
• 工具-四種工作類型 —— 前置作業，先把工作分類攤開才看得出 WIP 堆在哪一類

未計畫的工作會擠掉計畫內工作；降低 WIP 是關鍵解藥

更上游的槓桿是縮小批量，理想是單件流

失控時的猛藥：全面凍結專案 → 分批解凍

📉 降低在製品 WIP

工具-等待時間與閒置產能

🎯 什麼情境該想到我

當「明明大家都 100% 忙碌，交付卻慢得離譜」、或有人問「為什麼一個只要 30 秒的改動要等四週」時。
也用在你需要**說服別人「留白不是浪費」**的時候。

⚙️ 怎麼用（公式 → 算給人看）

1. 算單一資源的等待時間：

   等待時間 ＝ 該資源忙碌的百分比 ÷ 該資源閒置的百分比

   忙碌率	算式	等待時間
   50%	50/50	1 個單位
   90%	90/10	9 倍
   99%	99/1	99 倍

2. 乘上交接次數：真正的前置時間是「每一棒的等待」累加。書中 Bill 實算：一個任務經過 7 次交接、每個人都 90% 忙 → 9 小時 × 7 ＝ 63 小時純排隊，而實際動手只要 30 秒。

3. 推導出結論：每個人都必須有 slack（閒置時間）。沒有人有 slack，在製品就會卡在系統裡——更精確地說，卡在佇列裡乾等。

4. 把等待時間畫出來：這是三步工作法第二步的關鍵動作——讓工作在誰的佇列裡躺了幾天變成可見的，尤其是往回流（缺料、返工）的部分。

5. 優先砍交接次數，而不是催每一棒更快。部門「內部」排序已經很難，跨部門的協調難度至少十倍——真正的等待多半發生在 Dev ↔ Ops 的交界。

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意 / 什麼時候不適用

• 這是排隊理論的直覺化版本，不是精確模型（實務上還受批量大小、變異性影響）。它的價值在於說服力：把「應該留餘裕」從感覺變成可以在白板上算的數字。
• 別把它讀成「所有人都該閒著」。是高利用率＋多次交接的組合才致命；單一資源忙但沒有交接，不會產生這種爆炸。
• 反過來也要小心：閒置率趨近 0 時等待時間趨近無限大，所以不要用「利用率」當團隊績效指標。

🔗 相關工具

• 工具-降低在製品WIP —— 互為表裡：這張說明「為什麼 WIP 塞不下」，那張講「怎麼把 WIP 壓下來」；WIP limit 造成的「不舒服的閒下來」，數學依據就在這裡
• 工具-找出並管理約束點 —— 補充視角：即使某個資源不是瓶頸，只要利用率拉到 90% 以上、又有多次交接，照樣讓交付變慢
• 工具-三步工作法 —— 上位框架，「讓等待時間可見」是第二步「回饋」的具體動作

等待時間 ＝ 忙碌% ÷ 閒置% 90% 忙 → 等待是 50% 忙的九倍

七次交接 × 各 90% 忙 ＝ 63 小時純排隊，而實際動手只要 30 秒

結論：每個人都必須有 slack，否則 WIP 全卡在佇列裡

⏳ 等待時間與 slack

工具-把業務目標接到IT風險

🎯 什麼情境該想到我

當你「說不清楚自己在做的技術工作對公司有什麼用」、預算與人力永遠排在業務專案後面、
或需要跟財務長／高層溝通「為什麼要花錢在看不見的地方」時。

⚙️ 怎麼用（四欄表）

1. 先拿到對方的業務目標：不是你猜的，是去問業務端負責人「你今年要達成什麼、什麼事會危及它」。書中 Bill 拿到的是市占率、平均訂單金額、獲利回復、資產報酬率這類 CFO 語言的指標。

2. 畫出這張表，一列一個業務指標：

   ① 業務績效指標	② 依賴哪些 IT 系統	③ IT 出包會怎樣	④ 靠什麼控制來防
   掌握顧客需求	訂單輸入、庫存管理系統	資料不準、報表不即時、要重工	…
   產品組合	訂單輸入系統	資料不準	…

   欄位定義：第一欄是達成目標所需的業務能力與流程；第二欄是這些流程依賴的 IT 系統；第三欄是系統或資料可能出什麼錯；第四欄是你打算靠什麼控制去擋。

3. 把 IT 的維運指標翻譯成業務指標的「前導指標」。書中的類比：預防性換機油與保養之於車隊，等同於預防性的廠商修補與變更管理之於 IT——沒人會為「換機油」興奮，但所有人都在乎「貨有沒有準時到」。

4. 收斂成一句話講給高層聽：

   「IT 帶來的維運風險，需要像其他業務風險一樣被管理。換句話說，它們不是 IT 風險，是業務風險。」

5. 準備具體案例：找出過去「IT 出事實際害到哪個業務目標」的真實事件，帶著證據去談，別空泛講理念。

🧪 我實際套用的紀錄

• 2026-08-02：（待填）

⚠️ 注意 / 什麼時候不適用

• 這張表不能自己關起門來填。第一欄一定要從業務端訪談來，否則你只是把技術願望包裝成業務語言，對方一眼看穿。
• 反向的收穫同樣重要：書中 John 訪談稽核團隊後發現，有些他堅持多年的 IT 控制其實不需要，因為組織其他部分已經充分緩解了那個風險。這張表是用來「該加的加、該砍的砍」，不是拿來替既有工作背書。
• 它解決的是「溝通與定位」，不會讓交付變快——真正變快要靠流動面的工具。

🔗 相關工具

• 工具-遙測與監控 —— 分工不同：那張是技術層面「系統現在健不健康」的量測，這張是業務層面「這些量測對誰重要、為什麼」的對齊
• 工具-四種工作類型 —— 常見的下一步：這張表會逼出一批預防性的「內部 IT 專案」，接著要靠工作分類替它們爭取到固定產能
• 工具-三步工作法 —— 上位框架，「真正理解 IT 所處的業務系統」（Deming 說的 appreciation for the system）是第一步「流動」的前提

四欄表：業務指標 → 依賴的 IT 系統 → 會出什麼錯 → 靠什麼控制

把 IT 維運指標變成業務指標的前導指標（換機油之於準時到貨）

💼 IT 風險就是業務風險

把製造業原理（豐田生產、約束理論）搬到 IT

「能把不需要的工作拿出系統，比能把更多工作放進系統更重要。」

🏭 IT 就是生產線

Link to original

🧰 這本書給我的工具

• 工具-三步工作法 — 想從整體改善研發交付流程時
• 工具-四種工作類型 — 覺得團隊忙亂、看不清在忙什麼時
• 工具-找出並管理約束點 — 到處救火、改了卻沒變快時
• 工具-降低在製品WIP — 事情做不完、每件都卡住時
• 工具-等待時間與閒置產能 — 大家都滿載、交付卻慢得離譜時
• 工具-把業務目標接到IT風險 — IT 被當成成本中心、講不出價值時

✨ 關鍵重點（Layer 1–2）

• 三步工作法：① 讓工作由左到右順暢流動（縮短前置時間）② 建立由右到左的快速回饋 ③ 打造持續學習與實驗的文化。
• 四種工作類型：業務專案、內部 IT 專案、變更、計畫外工作（救火）——計畫外工作是最貴的殺手。更精準的名字是「反工作（anti-work）」，它的本質是復原工作，永遠把你帶離目標；所以真正該做的不是救火更快，而是追它從哪裡來。
• 約束理論：在瓶頸以外做的任何改善都是幻覺。⚠️ 約束點是「工作中心」，不是「人」——書中 Bill 說瓶頸是工程師 Brent，被 Erik 當面否定：Brent 是「支撐了太多工作中心的那個人」。這個區別很重要，因為在把他腦中的東西標準化、文件化之前，再招幾個一樣的人都沒用，新人只會站著發呆。
• 未計畫的工作會擠掉計畫內工作；降低 WIP 是關鍵解藥。而 WIP 高到失控時，最猛的一招是全面凍結專案再分批解凍——書中凍結後的七天做完的事，比平常整整一個月還多。
• 利用率與等待時間是非線性的，交接次數是隱形殺手：等待時間 ＝ 忙碌% ÷ 閒置%。90% 忙的資源，等待時間是 50% 忙的九倍；七次交接就是 63 小時純排隊，而實際動手只要 30 秒。結論是每個人都必須有 slack。
• 拿掉不必要的工作，比塞更多工作進系統更重要。判準是「這對業務目標有沒有幫助」——這是三步工作法第一步中最常被漏掉的那一半。
• 批量大小是比 WIP 更根本的槓桿：理論上的理想是單件流，達成方式是持續縮小批量。把發布間隔拉長、每次塞更多功能，是在做完全相反的事。
• IT 風險就是業務風險：把高層的業務指標連到 IT 依賴與失效模式，並把 IT 的維運/合規指標變成業務指標的前導指標——就像預防性換機油之於貨物準時送達。

💬 金句原文（Layer 0）

• 「在瓶頸之外所做的任何改善，都只是假象。」
• 「未計畫的工作，是會殺死你的那種工作。」
• 「你身為 IT 維運副總的職責，是確保計畫內工作快速、可預測、不中斷地流動，替業務創造價值，同時把計畫外工作的衝擊與干擾降到最低，好讓你能提供穩定、可預測且安全的 IT 服務。」

  “Your job as VP of IT Operations is to ensure the fast, predictable, and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure IT service.”

• 「能把不需要的工作拿出系統，比能把更多工作放進系統更重要。」

  “Being able to take needless work out of the system is more important than being able to put more work into the system.”

• 「每一次我們讓 Brent 修好一個沒有其他人能複製的問題，Brent 就變聰明一點，而整個系統就變笨一點。」

  “Every time that we let Brent fix something that none of us can replicate, Brent gets a little smarter, and the entire system gets dumber.”

• 「改善日常工作，比做日常工作本身更重要。」

  “Improving daily work is even more important than doing daily work.”

• 「如果你九個月才能開一次砲，就永遠打不中你瞄準的目標。別再想著南北戰爭時代的大砲了，想想防空機砲。」

  “You’ll never hit the target you’re aiming at if you can fire the cannon only once every nine months. Stop thinking about Civil War era cannons. Think antiaircraft guns.”

🔗 相關

• 「找 root cause 而非救火掩蓋」呼應 工具-區分修復與掩蓋症狀