客戶問「這個功能什麼時候可以好」，你聽過幾種答案？「應該下週吧」（然後跳票）、「我回去問工程師」（然後沒下文）、「你要的話我們加班趕」（然後品質炸掉）。這三種答案有一個共同點：都不是根據資料講的。
上一篇: KMM系列(4): 客戶終於出現在板子上了
https://agile3uncles.com/2026/07/26/kmm-level2/
Maturity Level 3，Fit for Purpose，符合目的。這一級的核心能力用一句話講：對客戶做出可靠的承諾，而且是用資料做的承諾。
ML3 的定義
KMM 描述 ML3 引入的實務，目的是確保幾件事：一致的工作流程、可預測性、達成想要的成果、有效率地滿足服務水準協議（SLA）。到了這一級，組織有能力同時管理多個專案或共用服務。
拆開來看，從 ML2 到 ML3 有兩個關鍵的擴展：
擴展一：從團隊的板到端到端的服務。ML2 的板管好了團隊自己的流程，但客戶感受到的交期是從「提出需求」到「拿到東西」的完整旅程——包括進入團隊之前的等待，和離開團隊之後的部署。ML3 把板往上下游延伸，覆蓋整條服務。
擴展二：從蒐集資料到用資料承諾。ML2 開始有了基本流動資料，ML3 把資料變成承諾的依據：lead time 分佈、交付率、服務水準期望（SLE）。決策方式從 ML1 那種情緒驅動、qualitative 的判斷，走向用資料說話。
長什麼樣子？五個實際案例
案例一：85% 這句話是怎麼來的。團隊把過去三個月完成的卡片 lead time 全部撈出來畫成分佈圖，發現中位數 7 天、85 百分位 12 天。從此客戶問「什麼時候好」，答案變成：「這種規模的需求，85% 的機率 12 天內交付。」注意這句話誠實的地方——它承認了那 15%。客戶一開始不習慣，後來反而喜歡：一個 85% 可靠的 12 天，比一個 50% 可靠的「下週」有用得多，因為前者可以拿去做規劃。
案例二：端到端之後，兇手不是開發。另一個團隊被罵「開發太慢」，交期動輒一個月。把板延伸到端到端之後解剖 lead time：30 天裡，需求在上游等澄清 9 天，開發加測試 8 天，做完等每月一次的部署窗口 10 天。開發只占三成不到。過去所有的改善力氣都花在叫工程師加快，而真正的改善點是：需求進來前先做好澄清、部署從每月一次改成每週一次。這兩個改變一行程式碼都不用寫。
圖 1：板子延伸到端到端之後，lead time 的解剖——紅色的等待欄吃掉三分之二的時間，黃框是團隊原本唯一看得見的範圍
案例三：服務類別——不是每張卡都生而平等。保險公司的 IT 團隊，需求分三種服務類別：固定日期類（法規要求某日前上線，遲了直接罰款）、標準類（一般功能）、急件類（線上事故）。三種類別政策不同：固定日期類提前依風險排程、標準類先進先出、急件走快速通道。以前所有需求用同一種方式排隊，法規需求跟改按鈕顏色的需求搶資源；分類之後，資源分配第一次跟風險對齊。
案例四：阻塞分析——從怪人變成怪原因。團隊規定：卡片卡住就貼紅色標籤，寫上卡住的原因和日期。月底把紅標籤全部撕下來聚類，結果一目瞭然：一半的阻塞是「等外部金流廠商回覆」。以前檢討會的劇本是「這張卡為什麼延誤」（然後負責的人低頭），現在變成「這類阻塞為什麼一再發生」（然後去跟廠商簽 SLA、建立測試沙盒）。把追究從人身上移開、放到系統上，這是 ML3 文化面最重要的變化。
案例五：非軟體版本——法務合約審查。法務團隊把合約分成標準合約和客製合約兩類，各自量 lead time，然後對內部客戶公告 SLE：標準合約 90% 在 5 個工作天內完成，客製合約收件時個案評估。業務部門從此不用每天追問「我的合約看完沒」，因為期望被明確管理了。符合目的（Fit for Purpose）的意思就在這：服務的交付水準，符合客戶拿它去做事的目的——業務要的其實不是最快，是可以規劃。
承諾用哪個數字？平均值陷阱
ML3 最容易踩的坑，是用平均值或中位數做承諾。中位數 7 天的意思是：一半的卡會超過 7 天——用它承諾，每兩張卡就有一張跳票。所以承諾要用高百分位（常見用 85），並且把它變成一句完整的話：「85% 的機率，N 天內交付」。剩下的 15% 不是失敗，是誠實——真正的失敗是假裝它不存在。
圖 2：同一個團隊的 lead time 分佈——用中位數承諾，一半的卡跳票；承諾要用 85 百分位那條線
另一個坑：SLE 變成鞭子。指標一旦拿來懲罰個人，資料立刻開始灌水——卡片會被提早關掉再開新卡、時間會被動手腳。指標的用途是改善系統和管理客戶期望，不是考核個人。這條線一踩過去，ML3 的資料地基就塌了。
AI coding 時代的 ML3
照例標注：這一段是我的實務觀點，KMM 官方沒有對應內容。
第一件事：你的歷史資料剛剛過期了。ML3 的承諾能力建立在 lead time 分佈上，而 AI coding 改變了這個分佈的結構：寫程式的段大幅縮短，驗證的段變長、而且變異更大。用導入 AI 之前的資料做承諾，會系統性失準——而且失準的方向不一定是「變快」，因為驗證塞車時，整體 lead time 可能不動甚至變長。解法直接：從導入 AI 那天起重新收集資料，舊資料只留作對照。
圖 3：AI 改變 lead time 的結構——寫程式的段縮短、驗證的段變長，舊分佈做的承諾會系統性失準
第二件事：分開量產出時間和驗證時間。AI 時代只看整條 lead time 會誤判。把它拆成兩段各自追蹤：產出時間（從開工到進驗證欄）和驗證時間（從進驗證欄到真正完成）。多數團隊拆開之後看到的畫面：產出時間縮成原本的幾分之一，驗證時間占比過半——這張圖就是你跟老闆解釋「為什麼要投資測試自動化和 review 容量」時最有力的一頁。
第三件事：承諾的上限是驗證吞吐量。案例二的邏輯在 AI 時代有了新版本：交付速度的天花板已經不在產碼，而在人類驗證的吞吐量。做交付承諾時，真正該問的問題從「工程師做得完嗎」變成「驗證得完嗎」。如果你答應客戶的交付速率超過驗證吞吐量，那不是承諾，是排隊——PR 會在驗證欄前面排成長龍，而客戶感受到的就是跳票。
第四件事：不同類型，各自的分佈。延續 ML2 的工作項目類型：AI 產出類的卡和人寫的卡，lead time 分佈長得不一樣（AI 卡產出快、驗證時間變異大）。SLE 要分類型各自計算，混在一起算等於什麼都沒算。
資料來源
・Anderson, D. J. & Bozheva, T., Kanban Maturity Model（ML3 引入一致工作流程、可預測性、有效滿足 SLA 與管理多專案／共用服務的描述出自書中章節；beta 版節錄：https://res.infoq.com/articles/book-review-kanban-maturity-model/en/resources/KMM_Excerpt_InfoQ-1524573067668.pdf）
・Kanban Tool, The Kanban Maturity Model（ML3 聚焦交付一致性、可預測性與基本流動指標）：https://kanbantool.com/kanban-guide/kanban-maturity-model
・五個團隊案例為作者輔導與觀察經驗，細節經過改寫去識別化；文中三張圖為示意圖，圖 2 的分佈為模擬資料
發表迴響