🎯 什麼情境該想到我
當你想從「整體」改善研發到交付的流程（而不只是修單點），或想導入 DevOps 時的總框架。
⚙️ 怎麼用（三個方向）
-
第一步・流動（左→右）：讓工作從開發順暢流到營運。縮短前置時間、降低批量與 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.”
（能把不需要的工作拿掉，比能把更多工作放進去更重要。）
而且要記得「重要的是成果——不是流程、不是控制，也不是你完成了哪些工作」。
-
第二步・回饋（右→左）：建立快速、持續的回饋。自動化測試、監控、把問題在源頭擋下，別讓缺陷往下游流。
- 關鍵動作是讓等待時間可見：知道工作在誰的佇列裡躺了幾天，尤其是往回流（缺料、返工）的部分（見 工具-等待時間與閒置產能）。
- 回饋要一路往前推到產品定義與設計的最早期，不是只在部署前才接上。
-
第三步・持續學習與實驗：打造允許嘗試與從失敗學習的文化。這一步不是靠喊口號，書中有三個具體載體：
- 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風險 —— 第一步的前提：不理解自己所處的業務系統，就分不清什麼工作重要、什麼該拿掉