先講一個大家都遇過的場景。老闆問：「技術債為什麼永遠還不完？」誠實的答案是：因為它永遠排不進去。新功能有業務在催、線上問題有客戶在燒，技術債沒有人催——於是每次排優先序，它都排在「下次一定」。
上一篇: KMM 系列 (5)「什麼時候可以好？」終於有了誠實的答案
https://agile3uncles.com/2026/07/27/kmm-level3/
Maturity Level 4，Risk Hedged，風險對沖，處理的就是這一類問題：那些不做不會立刻痛、但風險持續累積的事，怎麼在制度上保護它們的產能。以及更廣義的問題——當多個服務、多種需求、多方風險搶奪同一批資源時，怎麼用資料而非嗓門來分配。
ML4 的定義
KMM 對 ML4 組織的描述是：能夠視覺化並成功管理多個服務與多種服務類別，而且這些服務共用資源。產能依組織的目標或策略分配給各個服務，並且產能配置被靈活地當作風險對沖機制使用——用來應對無法預測、波動的計畫外工作。
有一點值得先說：從 ML4 開始，KMM 的重心從板型設計轉向管理實務本身。ML0 到 ML3 的躍遷大多看得到板子的變化，ML4 的躍遷更多發生在會議節奏（Kanban Cadences）、決策方式和風險思維上。板子還在，但主角換成了掛在板子上的那些數字和政策。
三個關鍵詞：產能配置（capacity allocation）、延遲成本（cost of delay）、機率式預測（probabilistic forecasting）。下面用案例一個一個講。
長什麼樣子？五個實際案例
案例一：技術債的保障名額。還記得 ML2 那個發現「線上問題吃掉一半產能」的電商團隊嗎？他們的 ML4 版本長這樣：把產能明文分配——新功能 60%、線上問題 20%、技術債與無形成本 20%，各泳道有自己的 WIP 上限。關鍵在第三條泳道：重構、依賴升級、資安修補這些「不做不會立刻痛」的事，第一次有了制度保護的名額，不用每次跟新功能搶。配額數字用歷史資料設定，每季檢討一次。老闆那句「技術債為什麼還不完」，答案從苦笑變成一張配置表。
圖 1：產能配置的板——三條泳道各有配額與 WIP 上限，紫色泳道用制度保護「不做不會立刻痛」的工作
案例二：配額是避震器。同一個團隊三個月後遇到大促檔期，線上問題暴增。以前的劇本：全員救火、功能全面停擺、檔期後補進度補到過年。現在的劇本：暫時把配額調成 40／40／20，撐過檔期再調回來。差別在哪？以前是失控地被打斷，現在是有意識地調整配置——而且調整有留下紀錄，季度檢討時看得到「我們一年被迫調整幾次、為什麼」。KMM 說產能配置是對沖計畫外工作波動的機制，講的就是這件事：配額的價值不在固定，在可控地變動。
案例三：延遲成本——比大小，別比大聲。兩個專案搶同一批人。A 是法規案，晚一個月上線罰款加商譽損失估計數百萬；B 是新產品線，早一個月上市能多吃一個季度的市場窗口。以前這種會開三小時，結論取決於誰的主管職級高。導入延遲成本（Cost of Delay）的思考後，會議改問兩個問題：每個案子晚一週的代價是多少？做完各要多久？把延遲成本除以工期，數字大的先做。估算當然不精確——但一個粗糙的數字，勝過一場精緻的政治。
案例四：Monte Carlo——「什麼時候能全部做完」的誠實答法。業務問：「這批 30 張卡的需求，什麼時候能全部交付？」以前的答法是找工程師逐張估工時再加總，花兩天估出一個沒人信的日期。ML4 的答法：拿過去六個月每週實際完成幾張卡的紀錄，讓電腦隨機抽樣模擬一萬次「照這個節奏做完 30 張要幾週」，得到一個分佈——50% 機率 7 週內，85% 機率 9 週內。對外承諾用 85% 那條。整個過程十分鐘，而且比逐張估算準，因為它用的是團隊真實的交付節奏，不是人的樂觀。
圖 2：Monte Carlo 模擬——用歷史吞吐量隨機抽樣一萬次，回答「30 張卡什麼時候能全部完成」，對外承諾用 85 百分位
案例五：非軟體版本——顧問公司的接案組合。一家二十人的顧問公司，收入八成來自兩個大客戶。老闆睡不好——任何一家抽單，公司立刻危險。他們的做法本質上就是 ML4：把接案產能明文配置成大型長約 50%、中小型案 30%、新領域探索與自有產品 20%。頭兩年，第三條泳道帳面上是虧的；第三年，其中一個探索案長成新的營收支柱。風險對沖的本質從來不是報酬最大化，是活下來的機率最大化——投資組合的道理，用在工作上一樣成立。
常見的坑
配額變成鐵律。配置表訂了之後一年不動，市場變了配置沒變。配額要有節奏地檢討（季度是常見選擇），檢討時看資料：實際比例跟配置差多少、被迫臨時調整幾次。
餵垃圾資料的 Monte Carlo。模擬的品質取決於歷史吞吐量資料的品質。如果團隊流程還不穩定——卡片大小忽大忽小、完成的定義浮動——模擬出來的分佈只是精緻的亂數。這就是 KMM 強調順序的原因：ML4 的預測能力建立在 ML2 的流程一致性和 ML3 的資料紀律上，跳級直接玩模擬，得到的是數學包裝的猜測。
風險劇場。延遲成本算得漂亮、風險矩陣畫得專業，然後決策照舊看職級。工具的意義在改變決策方式；如果數字只是會議簡報的裝飾品，那比不算還糟——它給了壞決策一層科學的皮。
AI coding 時代的 ML4
照例標注：這一段是我的實務觀點，KMM 官方沒有對應內容。
對沖的新對象：AI 本身。前幾篇談的都是「怎麼用流程接住 AI 的產出」，到了 ML4 可以問一個更上層的問題：AI 的使用本身，要不要對沖？我的答案是要。AI 產出的風險不均勻——內部工具寫壞了重跑就好，金流模組寫壞了是事故。所以 AI 的參與深度應該依風險分級：核心金流與個資模組，人主導、AI 輔助，配最重的驗證政策；一般功能，AI 產出、人掛名驗證；內部工具與低風險腳本，AI 全自動，自動測試把關加定期抽驗。這其實就是 KMM 產能配置思維的直接延伸：類別不同，政策不同，而分類的軸是風險。
圖 3：依風險等級配置 AI 的使用——風險越高的泳道，人類參與越深、驗證政策越重
驗證容量也要配置。ML3 那篇說過：交付的天花板是人類驗證吞吐量。到了 ML4，這個稀缺資源同樣需要明文配置——多少驗證容量給 AI 產出的一般功能、多少保留給高風險模組的深度 review、多少留給急件。沒有配置的話，結局可以預測：大量低風險 AI 卡塞滿驗證欄，高風險模組的深度 review 被排擠，而後者恰恰是最不能省的那部分。
新的依賴風險：你的供應商是模型。ML4 管理依賴風險的思維（對依賴的服務建立 SLA、限制暴露程度），AI 時代多了一個新對象：模型服務本身。模型 API 有配額和斷線的風險、模型改版可能悄悄改變行為、價格政策會變。對策跟管理其他關鍵依賴一樣：關鍵流程有備援方案、模型更版納入變更管理（更版後跑回歸評測再切換）、避免把整條交付流水線押在單一供應商的單一模型上。這是字面意義的「不把雞蛋放在同一個籃子」。
Monte Carlo 的新變數。延續 ML3 的提醒：AI 改變了吞吐量結構，所以模擬要用導入 AI 之後的新資料。多做一步的話，把模擬的瓶頸變數從「團隊每週完成幾張卡」改成「驗證欄每週流出幾張卡」——AI 時代，後者才是決定交付日期的那個數字。
資料來源
・Anderson, D. J. & Bozheva, T., Kanban Maturity Model（ML4 管理多服務共用資源、產能配置作為對沖計畫外工作波動的機制之描述出自書中章節；ML4 重心從板型轉向管理實務與 Kanban Cadences 的說明參考 Businessmap 的 KMM 導覽：https://businessmap.io/kanban-resources/kanban-software/kanban-maturity-model）
・Berriprocess Agility（Bozheva 的公司），Upgrading your project management process step by step with KMM：https://berriprocess.com/en/upgrading-your-project-management-method-step-by-step-with-kmm/
・五個案例為作者輔導與觀察經驗，細節經過改寫去識別化；文中三張圖為示意圖，圖 2 的分佈為模擬資料
發表迴響