🎯 什麼情境該想到我
當你「改了很多、加了人力，整體卻沒變快」，或發現所有工作都卡在某個人/某道工序時。
⚙️ 怎麼用（約束理論的五步驟）
在瓶頸以外做的任何改善，都是幻覺。 瓶頸決定整個系統的產出速度。
-
找出約束點（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 之所以是約束，是因為他一個人支撐了太多個工作中心。這個區別會導向完全不同的行動。
-
善用它（exploit）：確保瓶頸永遠不閒置、只做真正該它做的高價值工作。書中那套協定極具體，可以直接抄：
- 建一個 level 3 工程師池負責所有升級案件，關鍵人物不在池內
- 要找他，必須先取得主管核准，而且找的人要負責把學到的東西寫成文件
- 同一個問題不准讓他做第二次，每週稽核，違者兩邊都要付出代價
- 不准他碰鍵盤——只能口述、旁觀別人打；任何無法事後被文件化的動作一律不准
- 每次事故結束就多一篇知識庫文章，以及多一個會修這問題的人
-
一切配合它排程（subordinate）：整個系統的節奏跟著瓶頸走，別讓它前面堆料、後面挨餓。
前置作業是建 bill of resources——「每項工作需要哪些工作中心、有哪些前置條件」的清單。有了它才知道哪些專案根本不需要動到瓶頸、可以安全放行。 -
提升瓶頸產能（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.”
-
重複（repeat）：解除後，下一個瓶頸浮現 → 回到第 1 步。
進階：把瓶頸移到產線最前面
只保護瓶頸不被打斷還不夠。書中最反直覺的一招是把瓶頸放到隊伍最前端——讓他參與開發流程的最早期階段（如同《目標》裡把 Herbie 移到隊伍最前面）。
理由是：最懂技術債在哪、最懂怎麼寫出對維運友善的程式碼的人，如果永遠在下游救火，那些「非功能需求」就永遠只能事後補、而且補不進去。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 在瓶頸「之後」做改善無用（它會餓著等料）；在瓶頸「之前」加速只會堆更多料。
- 別把「人」誤認成約束點。說「某某是瓶頸」聽起來很順，卻會導向錯誤解法（叫他加班、招一樣的人）。正確問法是「他支撐了哪些工作中心？哪些可以移走？」
- 每次讓關鍵人物修好一個沒人能複製的問題，他就變聰明一點，而整個系統就變笨一點。 這是縱容英雄主義的真實代價。
- 即使某個資源不是瓶頸，只要利用率拉高又有多次交接，照樣拖慢交付（見 工具-等待時間與閒置產能）——別把「不是瓶頸」讀成「可以隨便塞滿」。
🔗 相關工具
- 工具-四種工作類型 —— 找瓶頸的前置作業：工作先分類、變可見，才看得出東西實際卡在哪道工序
- 工具-降低在製品WIP —— 保護瓶頸最直接的手段：少放料進系統，瓶頸前就不會堆積、也不會被切換打斷
- 工具-等待時間與閒置產能 —— 補足另一半：瓶頸解釋「系統整體產出的上限」，等待時間解釋「非瓶頸環節為什麼也在拖慢你」
- 工具-技術債功能凍結 —— 極端情境的配套：債大到動不了時，用一次性凍結把資源集中到約束點，並近乎誇張地保護它
- 工具-三步工作法 —— 上層框架，管理約束點屬於第一步「建立左到右的流動」；跳過去看解完瓶頸後接什麼