在許多導入 Kanban 的團隊中，Control Chart 往往是「看起來很專業、但沒人真的敢用來決策」的工具。
不是因為它太難，而是因為大家不知道該如何把圖上的統計訊號，轉譯成真實的軟體開發行為與管理判斷。結果就是：圖畫了、數據收了，但該加速的時候不敢動，該停下來檢討時卻視而不見。
事實上，Control Chart 在 Kanban 中的角色非常單純，它不是績效評比工具，而是一面鏡子，用來回答一個關鍵問題：
現在的交付流程，是正常運作，還是已經偏離了？
Control Chart 在 Kanban 中真正想解決的事
Control Chart 源自統計製程控制（SPC），它關心的不是「平均有多快」，而是：
- 流程是否穩定？
- 變異是正常的，還是異常的？
- 我們看到的是偶發事件，還是系統性問題？
在軟體開發的 Kanban 流程中，最常被放進 Control Chart 的指標是：
- Cycle Time
- Lead Time
- 有時也會是 Throughput
但重點而在於：當圖形出現某種樣貌時，你該怎麼解讀，又該怎麼行動。
(1) In Control：流程穩定，但不代表「沒有問題」
圖表上看起來是什麼樣子？
- 所有點都在 UCL / LCL 之內
- 數據在平均線附近隨機波動
- 沒有明顯趨勢或群聚
對應的軟體開發場景
想像一個 Kanban 團隊，他們的 User Story Cycle Time 大多落在 4～7 天之間，有快有慢，但整體分布很一致。
這通常代表：
- 團隊的工作方式已經固定下來
- 沒有明顯的阻塞或突發干擾
- 流程是可預測的
但這裡有一個很常見的誤判。
很多人看到這樣的圖，第一反應是：「既然這麼穩定，是不是可以再壓快一點？」Control Chart 在這裡其實是在提醒你相反的事：
如果流程是 In Control，問題不在個別卡片，而在系統本身。
想變快，不是盯著某張比較慢的 Story，而是要改 WIP、改切故事的方式、改跨職能協作的結構。
(2) 有點超過控制界限：不是變慢，而是「發生了不尋常的事」
圖表上的訊號
- 有一個點超過 UCL 或 LCL
- 不需要再看任何趨勢，這本身就是警訊
對應的軟體開發場景
例如：
- 平常 Cycle Time 都是 5～8 天
- 突然出現一張 25 天的 Story
這幾乎不可能只是「剛好比較複雜」，更常見的原因是：
- 被插入的緊急需求
- 卡在外部依賴（API、第三方、跨部門）
- 等審批、等資安、等法務
- 關鍵人被拉走救火
這時候 Kanban 的處理方式非常明確：
只檢討這一張卡片。
- 發生了什麼？
- 為什麼流程沒有及早暴露？
- 這種情況會不會再發生？
反而不該做的是：
- 立刻重算平均值
- 把它當成「本來就會有的例外」
Control Chart 的存在，就是為了避免團隊把異常當正常。
3️⃣ Zone Tests：系統正在悄悄漂移
圖表上的訊號
- 沒有任何點超出控制界限
- 但大量點集中在平均線同一側
- 落在 Zone B 或 Zone A 的比例異常
對應的軟體開發場景
這種情況在現場其實非常常見：
最近幾個 Sprint，事情好像都「慢了一點點」，但又慢得不夠誇張，大家也就先撐著。
背後常見的原因包括：
- 新類型需求比例變高
- 技術債開始累積
- 團隊被長期借調支援其他專案
- WIP 限制逐漸被忽略
這正是 Control Chart 在 Kanban 中非常有價值的地方，它能在「事情還沒爆炸前」，就提醒你系統正在改變。
(4) Nelson Rules：流程已經換了一個檔位
圖表上的訊號
- 連續 8 個以上的點在平均線同一側
- 或出現明確上升 / 下降趨勢
- 即使完全沒有超出控制界限
對應的軟體開發場景
這通常代表的是結構性改變，例如：
- 開發政策正式變複雜（多了一層審查）
- 長期人力流失或新人比例提高
- 產品策略改變，需求本質不同
- 技術平台進入維護期
這裡有一個很關鍵、但常被忽略的結論：舊的平均值，已經不能再拿來預測未來。
這不是工程師個人的問題，而是管理與系統設計的問題。
Control Chart 不是拿來催人加速的
在 Kanban 方法中，Control Chart 真正的價值，不在於「告訴你多快」，而在於幫助團隊分辨：
- 什麼時候該檢討單一事件
- 什麼時候該改整個系統
- 什麼時候該停止錯誤的管理介入
如果只看平均值，團隊很容易做錯事；但如果能正確解讀 Control Chart，Kanban 就不再只是一張板子，而是一套能夠指引決策的流程管理系統。
好的 Control Chart，不會讓你更焦慮，而是讓你更清楚「現在該不該出手」。
發表迴響