🎯 什麼情境該想到我
當「明明大家都 100% 忙碌，交付卻慢得離譜」、或有人問「為什麼一個只要 30 秒的改動要等四週」時。
也用在你需要**說服別人「留白不是浪費」**的時候。
⚙️ 怎麼用（公式 → 算給人看）
-
算單一資源的等待時間：
等待時間 ＝ 該資源忙碌的百分比 ÷ 該資源閒置的百分比
忙碌率 算式 等待時間 50% 50/50 1 個單位 90% 90/10 9 倍 99% 99/1 99 倍 -
乘上交接次數：真正的前置時間是「每一棒的等待」累加。書中 Bill 實算：一個任務經過 7 次交接、每個人都 90% 忙 → 9 小時 × 7 ＝ 63 小時純排隊，而實際動手只要 30 秒。
-
推導出結論：每個人都必須有 slack（閒置時間）。沒有人有 slack，在製品就會卡在系統裡——更精確地說，卡在佇列裡乾等。
-
把等待時間畫出來：這是三步工作法第二步的關鍵動作——讓工作在誰的佇列裡躺了幾天變成可見的，尤其是往回流（缺料、返工）的部分。
-
優先砍交接次數，而不是催每一棒更快。部門「內部」排序已經很難，跨部門的協調難度至少十倍——真正的等待多半發生在 Dev ↔ Ops 的交界。
🧪 我實際套用的紀錄
- 2026-08-02：（待填）
⚠️ 注意 / 什麼時候不適用
- 這是排隊理論的直覺化版本，不是精確模型（實務上還受批量大小、變異性影響）。它的價值在於說服力：把「應該留餘裕」從感覺變成可以在白板上算的數字。
- 別把它讀成「所有人都該閒著」。是高利用率＋多次交接的組合才致命；單一資源忙但沒有交接，不會產生這種爆炸。
- 反過來也要小心：閒置率趨近 0 時等待時間趨近無限大，所以不要用「利用率」當團隊績效指標。
🔗 相關工具
- 工具-降低在製品WIP —— 互為表裡：這張說明「為什麼 WIP 塞不下」，那張講「怎麼把 WIP 壓下來」；WIP limit 造成的「不舒服的閒下來」，數學依據就在這裡
- 工具-找出並管理約束點 —— 補充視角：即使某個資源不是瓶頸，只要利用率拉到 90% 以上、又有多次交接，照樣讓交付變慢
- 工具-三步工作法 —— 上位框架，「讓等待時間可見」是第二步「回饋」的具體動作