昨天你說服三個團隊停下來，一起畫出「從需求到上線」的完整價值流。

畫完後，大家都很滿意。Data Lead 說：「我們這邊很快，清資料平均三天就完成。」AI Lead 也點頭：「模型訓練我們已經優化到一天內跑完，效率比以前提升 40%。」Platform Lead 補充：「部署自動化做好之後，上線只要 15 分鐘。」

三個團隊都說自己「很有效率」。

但你看著牆上的價值流圖，發現一個殘酷的事實：

從一個需求進來，到最後上線，平均要 38 天。

資料清洗 3 天、模型訓練 1 天、部署 15 分鐘——這三個加起來不到 5 天。其餘 33 天在哪裡？

你拿起白板筆，在圖上標出另一種顏色。

等待。

場景：每個人都在衝刺，整體卻在爬行

現在，你把整個價值流展開，標出每個步驟的「處理時間」和「等待時間」：

• 📥 需求提出 → [等待審查 5 天] → 📊 資料收集
• 📊 資料收集 → [處理時間 3 天] → [等待 Data 交付]
• 📦 Data 交付 → [等待 AI 排隊 6 天] → 🏷️ 特徵工程對齊
• 🏷️ 特徵工程 → [處理時間 2 天] → [等待 AI 開始訓練]
• ⚙️ 訓練啟動 → [處理時間 1 天] → 🧠 模型產出
• 🧠 模型產出 → [等待 Platform 環境 4 天] → 🐳 容器化開始
• 🐳 容器化 → [處理時間 0.5 天] → [等待部署審查]
• 🔍 部署審查 → [等待簽核 7 天] → 🧪 部署到 Staging
• 🧪 Staging 測試 → [處理時間 1 天] → [等待 Production 排程]
• 📅 排程等待 → [等待 5 天] → 🚀 部署上線

你在白板上加總：

📊 價值流時程總計：

• ⏱️ 端到端平均交付時間（Lead Time）：38 天
• 🛠️ 實際處理時間（Process Time）：8.5 天（僅占 22%）
• ⏳ 無效等待時間（Queue Time）：29.5 天（高達 78%）

八成的時間，什麼都沒在做，只是在等。

Data Lead 皺眉：「我們處理很快，三天就完成了，為什麼整體要 38 天？」

你指著「等 AI 排隊 6 天」那一段：「因為你交付之後，AI Team 手上還有四個案子在跑。你的車在隊列裡排了六天才輪到。」

AI Lead 也不服氣：「我們訓練只要一天，已經很快了。」

你指著「等 Platform 環境 4 天」：「但你訓練完，Platform Team 的 Staging 環境在跑另一個專案的測試。你得等人家測完才能進去。」

Platform Lead 反駁：「我們部署只要 15 分鐘！」

你指著「等簽核 7 天」：「但部署前要三方（Data、AI、Platform）都簽核，平均要排隊等回覆七天。簽核本身只要五分鐘，但等人就是一週。」

會議室裡一片安靜。

每個人都在衝刺，但交接處卡死。

局部最佳化 ≠ 整體最佳化

兩難：繼續優化各自的 KPI？還是正視整體流動？

散會後，Data Lead 私下找你：「我們可以再優化資料清洗流程，從三天壓到兩天。」

你看著價值流圖，腦中浮現兩條路：

如果是你，你會讓 Data Team 繼續優化那 3 天？還是把焦點放在那 29.5 天的等待？

先別往下看

認真想三十秒。

你會選 A 還是 B？

為什麼？

翻牌：大部分的時間都花在「等」

正確答案是 B。

但這是最難被接受的答案，因為它挑戰了每個人的直覺：「我做得這麼快，為什麼還說我是問題？」

答案是：「你不是問題，但你優化的地方不是瓶頸。」

《鳳凰專案》裡，Erik 帶 Bill 回工廠看到的第一課就是：局部效率 ≠ 整體流動。

工廠裡的切削機每分鐘能切 120 片，是全產線最快的。老闆很驕傲，還買了第二台切削機提升產能。

但 Erik 指著下一站——打磨機——說：「打磨只能磨 60 片/分鐘。你切得再快，半成品也只是堆在這裡等。」

瓶頸不在切削機，在打磨機。優化切削機只會讓庫存堆更多。

回到你的 AI 專案，情況一模一樣：

• Data Team 把清洗從 3 天壓到 2 天，資料更早交付——但 AI Team 手上已經有排隊的案子，你阻擋不了更早進入等待佇列，整體交付時間一天沒少。
• AI Team 把訓練從 1.5 天優化到 1 天——但接下來要等 4 天才有 Platform 環境可用，你省下的半天在佇列裡就被吃掉了。
• Platform Team 把部署自動化到 15 分鐘——但部署前要等簽核，簽核流程平均拖 7 天，你再快也改變不了什麼。

真正的瓶頸在交接點：等審查、等排隊、等環境、等簽核。

這就是 Value Stream Mapping 最殘酷的一課：當你把每個步驟的「處理時間」和「等待時間」畫出來，你會震驚地發現——

大部分的時間，東西在等待移動，而不是在被處理。

整條價值流的速度，不是由最快的步驟決定，而是由最慢的交接點決定。

Bill 在工廠學到的，2026 年的你要在價值流圖上再學一次。

如果有 AI Agent：把隱形的等待變成可見的數據

問題是，怎麼量測「等待」？處理時間很好抓：Git Commit、CI/CD 紀錄、Jira 狀態轉換。但等待是隱形的。

一個 Ticket 從「資料交付」到「AI 開始訓練」隔了六天——這六天無人紀錄、無人追蹤，只是靜靜過去了。

這時候，AI Agent 可以幫你做一件事：自動量測每個交接點的等待時間。

graph TD
    A[Jira ticket 狀態變化] --> D[Agent 追蹤時間軸]
    B[Slack 交接訊息] --> D
    C[Git PR 狀態] --> D
    D --> E[計算每個階段的處理 vs 等待]
    E --> F[資料清洗:處理 3 天]
    E --> G[Data+AI 交接:等待 6 天<br/>原因:AI Team 手上 4 個案子]
    E --> H[模型訓練:處理 1 天]
    E --> I[AI->Platform 交接:等待 4 天<br/>原因:staging 環境被佔用]
    E --> J[部署流程:處理 0.5 天]
    E --> K[簽核等待:等待 7 天<br/>原因:三方排隊簽名]
    F --> L[產出價值流熱圖:<br/>紅色=等待瓶頸]
    G --> L
    H --> L
    I --> L
    J --> L
    K --> L
    L --> M[每週 review:<br/>瓶頸在哪?能減少多少?]

Agent 做的事很直接：追蹤 Jira 狀態時間戳、Slack 交接訊息時間點、Git PR 開到 Merge 的間隔，扣除討論時間後就是「等待他人回應」的時間，然後產出「等待熱圖」：

過去一個月交付案例的等待時間分析報告

⏱️ 時程指標

• 平均 Lead Time：38 天
• 實際處理時間：8.5 天（22%）
• 無效等待時間：29.5 天（78%） 👈 關鍵改進空間

🔍 等待時間分解與根本原因

• Data → AI 交接等待：6 天
  • 原因：AI 團隊平均手上同時跑 4 個專案，新案子必須排隊。
• 部署審查簽核等待：7 天
  • 原因：需要三方簽核，平均每位關卡回覆間隔 2 天。
• AI → Platform 交接等待：4 天
  • 原因：Staging 測試環境為所有專案共用，經常被佔用卡住。
• 需求審查等待：5 天
  • 原因：需求審查會議每兩週開一次，新專案常卡在「等待下一次會議」。

💡 優化行動建議

• 限制 AI 團隊的 WIP 至 2 個 （參見 Day 14 主題）
• 將常規部署簽核改為自動化檢查 （參見 Day 18 主題）
• 將 Staging 測試環境進行 Namespace 隔離切割 （參見 Day 19 主題）
• 需求審查改為非同步審查機制

這就是 2026 年的做法：讓 Agent 把「隱形的等待」變成「可以討論的數據」。 拿著熱圖開會時，Data Lead 不會再說「我們已經夠快」，因為數據顯示：問題不在你快不快，而在交接後的排隊。

Systems Thinking 的第二步，就是看見瓶頸在交接。

現場推演：那個快到沒用的模型訓練

來看一個常見場景（綜合改編，數字示意）。

一個 12 人的機器學習團隊，AI Lead 驕傲地說：「我們用 Spot Instance + 分散式訓練，把訓練時間從 5 天壓到 2 天，成本降 60%。」

但業務抱怨：「提一個模型需求，平均等 11 週才上線。」

Tech Lead 不服：「我們處理明明很快！」於是請工程師寫了前面的 Agent，追蹤實際 Lead Time。四週後，數據讓所有人傻眼：

歷史交付案例診斷數據（平均 Lead Time：11 週 / 77 天）

• 🛠️ 實際處理時間：18 天（23%）
• ⏳ 無效等待時間：59 天（77%）

⚠️ 等待熱點細分

• 等待資料團隊提供乾淨資料：21 天
  • 原因：資料清洗排隊，且格式定義不明確，平均需來回 2 - 3 次確認。
• 等待特徵需求對齊會議：14 天
  • 原因：資料/AI/業務三方會商每兩週開一次，一旦錯過即需多等一輪。
• 等待 Staging 環境可用：9 天
  • 原因：全團隊僅有一套 Staging 環境，供 5 個專案輪流搶用。
• 等待部署審查簽核：15 天
  • 原因：需經安全、合規、業務三方主管手動簽名，平均每關需等 5 天。

模型訓練省下的 3 天，在 59 天的等待面前根本不痛不癢。

Tech Lead 拿著這份報告去找 CTO：「我們不需要更快的訓練，我們需要縮短等待時間。」

兩個月後，他們做了三件事：

1. 資料 Schema 設計前置：新專案啟動前，Data / AI 先對齊資料格式，減少溝通來回。
2. 砍掉一半的簽核關卡：把「橡皮圖章式簽核」改成「自動化檢查 + 例外事件才人工介入」。
3. Staging 環境隔離切割：從一套共用環境改成每個專案有自己的 Namespace 進行獨立測試。

平均 Lead Time 從 11 週降到 5 週，模型訓練速度一秒都沒變快。

因為瓶頸不在處理，在交接。

今日金句

「每個人都在自己的跑道衝刺，卻沒有人看見接力棒掉在地上的那幾秒。」

留給你的問題

你團隊的交付時間裡，真正在「動手」的比例有多少？其餘都在等什麼？

如果處理只佔兩成，你優化處理速度能改善什麼？

明天，我們會面對一個更殘酷的兩難：你的團隊裡有一個「什麼都找他」的人——他是最強的，也是最大的瓶頸。

你敢不敢讓最強的人「閒下來」？

這是 Theory of Constraints 最反直覺的一課。

Day 13 見。