🔥 鳳凰專案

🎯 什麼情境該想到我

當你想從「整體」改善研發到交付的流程（而不只是修單點），或想導入 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 過高造成的
• 工具-三步工作法 —— 上位框架，四種工作類型是第一步「流動」的前置動作

🎯 什麼情境該想到我

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

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

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

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 —— 保護瓶頸最直接的手段：少放料進系統，瓶頸前就不會堆積、也不會被切換打斷
• 工具-等待時間與閒置產能 —— 補足另一半：瓶頸解釋「系統整體產出的上限」，等待時間解釋「非瓶頸環節為什麼也在拖慢你」
• 工具-技術債功能凍結 —— 極端情境的配套：債大到動不了時，用一次性凍結把資源集中到約束點，並近乎誇張地保護它
• 工具-三步工作法 —— 上層框架，管理約束點屬於第一步「建立左到右的流動」；跳過去看解完瓶頸後接什麼

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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 堆在哪一類

🎯 什麼情境該想到我

當「明明大家都 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% 以上、又有多次交接，照樣讓交付變慢
• 工具-三步工作法 —— 上位框架，「讓等待時間可見」是第二步「回饋」的具體動作

🎯 什麼情境該想到我

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

⚙️ 怎麼用（四欄表）

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）是第一步「流動」的前提