上週你和三個團隊一起畫出了完整的價值流，數據很殘酷：團隊 71% 的時間花在「等待」上，只有 29% 在真正做事。

但今天早上，你發現了一個更尖銳的問題。

那些「等待」，幾乎全部都在等同一個人。

場景：那個「什麼都找他」的人

他叫 Kevin，你的 Platform 團隊唯一一個真正懂整套 MLOps Pipeline 的工程師。

從 Feature Store 的 Schema 設計、模型訓練的分散式架構、到 Production 部署的金絲雀發布（Canary Release）邏輯——只有他能把這些全部串起來。

問題是，所有人都知道這件事。

你打開 Kevin 的工作佇列：

Kevin 的待辦清單（當前：2026/05/22）

• 【P0】修復 Production Model Serving Latency 問題
  • 細節：卡住線上服務，客訴處理中。
  • 預估時程：2 天。
• 【P1】審查 Data Team 的 Feature Pipeline 設計
  • 細節：AI Team 等待此設計以進行模型訓練。
  • 預估時程：半天。
• 【P1】協助 AI Team 排查模型部署環境權限問題
  • 細節：第三次部署失敗，原因未明。
  • 預估時程：3 小時。
• 【P2】設計新的 A/B Testing 基礎設施
  • 細節：CEO 要求的下一季關鍵功能。
  • 預估時程：1 週。
• 【P2】撰寫 MLOps 最佳實踐文件（Best Practices）
  • 細節：HR 表示下個月將有兩位新工程師加入。
  • 預估時程：2 天。
• 【P3】參加三場例會（架構審查、技術分享、跨組對齊）
  • 細節：每日例行行政與溝通會議。
  • 預估時程：4 小時。

• 📊 累積排隊工作量：約 11 個工作日
• 📅 Kevin 本週可用時間：5 天
• ⚠️ 結論：他至少要到兩週後才有空處理新需求。

這就是 2026 年版的 Brent。

Bill Palmer 在《鳳凰專案》裡花了很久才明白的事：Brent 不是救星，他是瓶頸。所有工作都在他面前排隊，整個組織的交付速度被他的產能上限卡死。

過去三個月，有 27 張票在「等待 Kevin 審查（Waiting for Review）」狀態下平均停留了 6.2 天。Data Team 抱怨：「Feature Pipeline 設計三週前做好，Kevin 還沒審。」AI Team 說：「每次部署都需要等他看權限。」

當整個組織的關鍵路徑都經過同一個人，你的交付速度就是他的處理速度。而現在，他的佇列已經排到兩週後。

兩難：塞滿他？還是保護他？

你站在 Kevin 的座位旁邊，看著他同時開著五個視窗：左邊在 Debug Production，中間在回 Slack 訊息，右邊在審 PR。

他看起來很忙，很有價值，產出很高。

但你腦中浮現兩條路：

如果是你，現在就要做決定。你要讓 Kevin 滿載發揮最大價值，還是刻意保護他讓他「閒下來」？

先別往下看

認真想三十秒。

你會選 A 還是 B？

為什麼？

翻牌：讓瓶頸滿載，是讓系統崩潰最快的方法

正確答案是 B。

這是 限制理論（Theory of Constraints, TOC）最反直覺的一課：

「瓶頸資源的利用率不該是 100%。」

聽起來很荒謬，對吧？你找到了團隊裡最強的人，怎麼能讓他「閒著」？

但這正是 Eli Goldratt 在《目標》裡告訴你的：高速公路一旦車流達到最大利用率，必然塞車。當利用率達到 97% 以上，任何微小的波動——例如一輛車變換車道、一個無意的煞車動作——都會引發連鎖效應，讓整條道路瞬間塞死。

滿載的系統沒有緩衝，無法應對任何波動。

在你的組織裡，Kevin 就是那條高速公路。當他的工作佇列已經排到兩週後，任何突發狀況——一個線上緊急 Bug、一個需要他的設計決策、一個新人卡住需要他指導——都會讓整條產線停擺。

Bill Palmer 在《鳳凰專案》裡學到的教訓就是這個：你不該讓 Brent 做所有事，你該保護他，讓他只做「真正需要他、無法被替代」的事。

這叫做「Exploit the Constraint」（充分利用瓶頸）：

不是「塞滿瓶頸」，而是「確保瓶頸不浪費時間在不該做的事上」。

Erik 告訴 Bill 的改善五步驟：

1. 🔍 識別瓶頸（Identify）：確認 Kevin 就是當前團隊的限制點。
2. ⚡ 充分利用瓶頸（Exploit）：保護 Kevin 的時間，確保他只做最關鍵且不可替代的事。
3. 🤝 讓其他資源服從瓶頸（Subordinate）：調整其他人的工作節奏以配合 Kevin 的產能，避免堆積更多半成品。
4. 🚀 提升瓶頸產能（Elevate）：培養第二位 Kevin、建立知識庫 runbook、自動化重複工作。
5. 🔄 回到第一步（Repeat）：當 Kevin 不再是瓶頸時，找出系統中新的瓶頸並重複循環。

現在你要做的是第二步：Exploit。

你決定保護 Kevin 的時間，把他的工作佇列分成三類：

Kevin 工作分流策略

• ✅ 只有 Kevin 能做的（保留，專注高價值）
  • Production Serving Latency 問題除錯。
  • A/B Testing 基礎設施架構設計。
  • 關鍵技術架構與設計決策審查。
• ⚠️ 可以由他人代勞的（分流，文件與自動化）
  • 環境權限問題 → 撰寫 Runbook 交由 Ops 團隊自主處理。
  • 重複性 Debug → 開發自助式診斷檢查工具。
  • 常規會議 → 只參加必須由他做決策的會議，其餘委派代表出席。
• ❌ 根本不該做的（拒絕，制度化排除）
  • 新人教育訓練 → 改用錄影存檔、技術文件與團隊 Buddy 導師制度。
  • 臨時性的「順便幫我看一下」 → 要求先由提問者自行照著清單排查後再來。

• 🎯 執行目標：將 Kevin 的待辦工作天數從 11 天壓低到 4 天，刻意保持 **30% 的緩衝產能（Buffer Capacity）**以應對突發狀況。

這代表 Kevin 的「利用率」從 100% 降到 70%。

但整個組織的交付速度反而會提升，因為：

• 其他工作不再在 Kevin 面前排隊。
• 突發狀況可以被即時處理。
• Kevin 有餘裕做「只有他能做」的關鍵決策。

瓶頸有餘裕，整體產出才會快。

如果有 AI Agent：把「不需要 Kevin」的工作自動分流

問題是，怎麼知道哪些工作「只有 Kevin 能做」，哪些可以分流？

如果全靠人工判斷，Kevin 會被「幫我看一下這個該不該給你」的請求淹沒——這本身就是浪費他的時間。

這時候，AI Agent 可以幫你做一件事：監測 Kevin 的工作佇列，自動分流「不需要他」的任務。

graph TD
    A[新任務進來] --> B{Agent 分類}
    B -->|環境/權限問題| C[查詢 runbook/FAQ]
    C -->|找到答案| D[直接回應做法]
    C -->|找不到| E[轉給 Ops Team]
    B -->|重複性 debug| F[執行診斷腳本]
    F -->|常見問題| G[自動修復 + 通知]
    F -->|新問題| H[標記給 Kevin:<br/>附診斷結果]
    B -->|架構/設計決策| I[直接進 Kevin 行列:<br/>標註優先級]
    B -->|訓練/會議| J[檢查是否可委派]
    J -->|可委派| K[建議替代方案]
    J -->|必須本人| I
    D --> L[Kevin 時間省下]
    E --> L
    G --> L
    K --> L

Agent 做的事其實是一個「Kevin 前置過濾器」：

1. 環境權限問題：先查 Runbook 和歷史 Ticket，80% 的權限問題都有標準解法，Agent 直接給答案或轉給 Ops 團隊。
2. 重複性 Debug：跑診斷腳本（檢查 Config、Log、相依性版本），把結果整理好，常見問題自動修復，新問題才轉介給 Kevin。
3. 訓練與會議：檢查是否可以用錄音/錄影、技術文件、或委派其他人代表。
4. 架構決策：這類核心工作才直接進入 Kevin 的工作排程，並標註清單與優先級。

假設 Kevin 原本每天收到 12 個請求，其中 8 個是「其實不需要他親自處理」的。Agent 幫他擋掉 6 個、把 2 個轉給其他人處理，Kevin 的實際佇列長度從 12 降到 4。

他的「利用率」從 100% 降到 70%，但整個團隊的交付速度提升了 60%，因為其他人不用再排隊等他審查了。

現場推演：那個被「幫個忙」淹沒的 Tech Lead

來看一個常見的情況（綜合改編，數字示意）。

想像一個 18 人的資料平台團隊，有一個資深 Tech Lead 叫 Alice。她是團隊裡唯一完整經歷過三代資料架構演進的人，從 Hadoop 到 Spark 到現在的 Lakehouse，只有她知道「為什麼當年這樣設計」和「現在該怎麼改」。

問題是，所有人都知道這件事。

每天平均有 15 個人找 Alice：

• 「這個 job 為什麼跑這麼慢？」
• 「可以幫我看一下這個 config 對不對？」
• 「能不能來這個會議給個意見？」
• 「新人想請教一下 data lineage 的設計邏輯。」

Alice 每天工作 11 小時，週末還在回 Slack。團隊的 Jira 板上有 9 張「等待 Alice 審查」的票，平均等待時間高達 8.5 天。

主管意識到問題後，做了三件事：

1. 建立 Alice 的「分流機制」：所有找 Alice 的請求都先進一個 Slack Channel，由一個資深工程師和 AI Agent 先過濾一輪。
   • 重複性問題 → 自動查閱內部 Wiki。
   • Config 檢查 → 用自動化腳本驗證。
   • 會議邀請 → 檢查議程，非必要不參加。
2. 培養備援線：挑選兩位資深工程師與 Alice 進行結對工作（Pair Work）半年，以承接「需要架構知識但不需要 Alice 最終決策」的常規事務。
3. 設定深度專注時段：每天上午 9-12 點為「深度工作時間」，不回 Slack、不開會，專注處理關鍵架構決策。

六週後：

• Alice 的每日請求從 15 個降到 5 個（其中 10 個被 Agent 與資深工程師分流）。
• 「等待 Alice 審查」的平均時間從 8.5 天降到 1.2 天。
• Alice 的每日工作時間從 11 小時降回健康的 8 小時。
• 團隊的整體交付速度提升了 55%（因為關鍵路徑不再卡在 Alice 一個人身上）。

主管在回顧會議上說：「我原本以為讓 Alice 滿載是最大化她的價值。結果我錯了——讓 Alice 有餘裕，才是最大化整個團隊的價值。」

瓶頸的利用率不是越高越好，而是要留出緩衝。

今日金句

「讓瓶頸滿載，是讓整條產線癱瘓最快的方法。最強的人不該做所有事，而該專心只做最關鍵的事。」

留給你的問題

你團隊最強的那個人，現在的工作佇列有多長？

那條佇列，就是你的交付速度上限。

如果他的佇列已經排到兩週後，你的問題不是「怎麼讓他做更多」，而是「怎麼讓其他人不要來找他」。

明天，我們會面對一個更大的困境：當 CEO 說「全部都優先」的時候，你敢不敢拒絕？

同時做十件事，就是同時做不完十件事。

這是 WIP（Work In Progress）限制的殘酷真相。

Day 14 見。