▍上一篇
KMM系列(1): 你的 Kanban 板貼滿了便利貼，然後呢？—認識 Kanban Maturity Model
https://agile3uncles.com/2026/07/24/kanban-maturity-model-00/
上一篇介紹了 KMM 的整體架構。這一篇從最底層開始：Maturity Level 0，Oblivious，渾然不覺。
先講一個場景。我問一個團隊的主管：「你們的工作是怎麼流動的？」他愣了一下，回答：「就⋯⋯客戶或老闆說要做什麼，我就找人做。做完就做完了。」我再問：「現在手上有幾件事在進行？」他說要回去查一下，可能十幾件吧。實際盤點之後是三十七件。
這就是 ML0。
ML0 的定義
KMM 對 ML0 的描述是：組織對「需要一套流程」這件事渾然不覺，對管理方法或政策的價值抱持無所謂的態度。沒有協作式的工作方式，就算偶爾有協作，也沒有人意識到那是協作——它是曇花一現的，靠運氣發生的。
注意關鍵字：「渾然不覺」。ML0 的組織缺的東西很多，但最缺的是「意識到自己缺什麼」。你問他們流程在哪，他們會覺得這個問題很奇怪——事情不就是來了就做嗎？
圖 1：ML0 的工作流動——需求從四面八方進來，散落各處，沒有人看得到全貌
長什麼樣子？五個實際案例
ML0 的樣貌比你想像的多元。它出現在新創，也出現在大公司裡的角落。
案例一：口頭需求的軟體團隊。八人的開發團隊。需求來源有三個：老闆走過來講、業務用 Line 丟、客戶直接打給工程師。誰先被抓到誰做。有一次兩個工程師各自做了同一個功能，做到一半才發現，因為需求是同一個客戶分別跟兩個人講的。
案例二：三人新創。三個共同創辦人，全靠默契運作。每天講話講不停，感覺協作很順。但問他們「上週答應投資人的那份文件誰在做」，三個人互看——每個人都以為是另一個人。這裡的重點：ML0 的協作是靠感覺，感覺很好和實際有協作是兩回事。
案例三：大公司裡的行政部門。公司本身有 PMO、有制度，但行政部門的工作全在 email 和口頭交辦裡流動。一位資深同仁請假兩週，整個部門有一半的事情停擺，因為只有她知道哪些事情在等哪些人。組織成熟度看的是實際運作的單位，公司整體有制度，某個部門仍然可以是 ML0。
案例四：一人接案者。Freelancer 同時接四個案子，所有承諾記在腦中和四個不同的通訊軟體裡。某天早上醒來想起有個交付日是昨天。ML0 也適用於個人層級——事實上 KMM 給 ML0 的入門實務就是從個人開始的，等下會講。
案例五：有 Jira 的 ML0 團隊。這個最容易被誤判。團隊有 Jira，票也開了，但票的狀態三個月沒更新，實際工作在會議和私訊裡流動，Jira 是「應付稽核用的」。有工具和有流程是兩回事。判斷成熟度要看行為，看實際怎麼運作，工具擺在那裡沒有意義。
ML0 有錯嗎？
沒有。這點很重要。
KMM 的作者觀察到，很多新生的、規模還小的企業就處在 ML0，而且活得好好的。兩個人的公司靠默契運作，溝通成本趨近於零，硬要導入一套流程反而是浪費。
ML0 的問題出在規模。默契能支撐的協作大概到三、五個人，工作項目到幾十件、利害關係人變多之後，這些症狀會開始出現：
・承諾跳票，而且不知道為什麼跳票
・同一件事兩個人做，或是一件事沒人做
・誰喊得大聲誰的事先做，急單永遠插隊
・關鍵資訊只在某個人腦中，那個人請假就停擺
・老闆以為 team 沒在忙，team 覺得自己忙到爆炸——雙方都看不到工作在哪裡
如果這些症狀看起來很眼熟，恭喜，你已經開始「有覺」了。從 ML0 往上爬的起點正是這個瞬間：意識到痛是流程缺席造成的。
第一步怎麼走：從個人看板開始
KMM 對 ML0 組織的建議非常克制：從視覺化個人工作開始，也就是 personal kanban。
具體做法：一個人，一塊板子（實體白板或任何數位工具都行），三個欄位——待辦、進行中、完成。把自己手上所有的事寫成卡片放上去。就這樣。
圖 2：個人看板——三個欄位就夠，重點在把散落各處的工作全部變成看得見的卡片
不要小看這一步。前面案例四的那位 freelancer 做完這件事之後跟我說，光是「把四個通訊軟體裡的承諾全部變成卡片」就花了他一個下午，然後他發現自己同時進行中的工作有十一件——難怪每件事都很慢。
這裡刻意不做的事情同樣重要：
・不要一開始就設 WIP 限制——先看見，再管理
・不要一開始就要求全團隊統一流程——會被抵抗
・不要導入複雜的工具和欄位設計——三欄就夠
KMM 把這個原則講得很清楚：實務要配得上成熟度。ML2、ML3 的實務放到 ML0 的組織，會被排斥、被陽奉陰違，最後變成案例五那種「應付用的 Jira」。上一篇講的 overreaching 失敗模式，最常發生的位置就在這裡。
AI coding 時代的 ML0
照例先標注：這一段是我的實務觀點，KMM 官方沒有對應內容。
AI coding 工具讓 ML0 出現了兩個新現象。
現象一：一人公司變多，而且淹得更快。Vibe coding 讓一個人能做出以前要一個團隊才能做的產品。這些一人團隊天生就是 ML0——沒有流程，也不覺得需要。以前這樣沒事，因為一個人打字的速度就是天花板。現在一個人可以同時開三個 agent 平行工作，晚上睡覺前再丟兩個任務。工作的產生速度是以前的好幾倍，但那顆用來記住所有事情的腦，還是同一顆。案例四的 freelancer 如果用上 AI coding，他的十一件 WIP 會變成三十件。
現象二：agent 的工作是隱形的。人的工作至少開會時看得到人在忙。agent 在背景跑的工作，不視覺化就完全隱形。我看過的實際情況：工程師忘記自己昨天讓 agent 開了一個重構任務，今天自己又動了同一批檔案，合併時衝突炸開。這是案例一「兩個工程師做同一個功能」的 AI 版本，只是其中一個工程師換成了 agent，而且它不會在茶水間跟你聊到「欸我最近在改那個模組」。
圖 3：AI 時代的個人看板——agent 的工作用不同顏色的卡上板，agent 做完的產出還要經過人類驗證才算完成
所以 personal kanban 這個 ML0 的老實務，在 AI coding 時代價值反而變高了：板子上除了自己的卡，多放一種「agent 進行中」的卡。你要看得見你的 agent 在做什麼，就像你要看得見自己在做什麼一樣。起點還是那塊三欄的板子。
資料來源
・Anderson, D. J. & Bozheva, T., Kanban Maturity Model（ML0 定義出自書中 Understanding Kanban Maturity Levels 章節；beta 版節錄可在 InfoQ 取得：https://res.infoq.com/articles/book-review-kanban-maturity-model/en/resources/KMM_Excerpt_InfoQ-1524573067668.pdf）
・Businessmap, Applying the Kanban Maturity Model：https://businessmap.io/kanban-resources/kanban-software/kanban-maturity-model
・五個案例為作者輔導與觀察經驗，細節經過改寫去識別化；文中三張圖為示意圖
發表迴響