Kanban Maturity Model: уровни зрелости Kanban-команд
Kanban Maturity Model помогает понять, какие изменения команда уже способна поддерживать, а какие пока останутся формальностью. Модель сопоставляет наблюдаемое поведение, применяемые практики и результаты работы. Поэтому её полезно использовать не как экзамен с оценкой, а как карту: сначала определить текущее состояние, затем выбрать ближайшее улучшение.
Если команда только завела доску, ей рано копировать практики зрелой организации с несколькими сервисами и общими рисками. Сначала нужно добиться, чтобы карточки отражали реальную работу, правила переходов были понятны, а начатые задачи завершались. Следующий шаг выбирают по проблеме, которую команда действительно видит.
Что такое Kanban Maturity Model
Kanban Maturity Model, или KMM, — это модель эволюционного развития организаций, использующих Kanban. На официальной странице модели оценку связывают с тремя группами признаков: поведением людей, глубиной внедрения практик и достигнутыми бизнес-результатами. Эти признаки помогают выбрать следующий безопасный эксперимент.
Модель описывает семь уровней — от ML0 до ML6. Название уровня не заменяет диагностику: две команды могут использовать одинаковую доску, но по-разному принимать решения, управлять ожиданиями заказчика и работать с рисками. Важен не набор терминов, а устойчивость поведения в обычной работе и под нагрузкой.
KMM также не требует одномоментной перестройки. Kanban предполагает эволюционные изменения: команда сохраняет работающие способы, делает проблему видимой и постепенно меняет правила. Если новая практика не решает текущую проблему, её наличие не делает систему зрелее.
Семь уровней зрелости Kanban
Уровни KMM показывают, как фокус постепенно расширяется: от реакции на отдельные задачи до управления несколькими сервисами, рисками и способностью организации адаптироваться. Практический смысл каждого уровня — в характерных признаках и ближайшем направлении развития.
ML0 — Oblivious: работа остаётся невидимой
На нулевом уровне организация почти не управляет потоком. Приоритеты меняются в личных сообщениях, работа распределена по блокнотам и таблицам, а перегрузку замечают по сорванным срокам. Люди заняты, но связать занятость с завершённым результатом трудно.
Первое изменение здесь — увидеть фактическую работу. Соберите активные задачи в одном месте, назовите ответственных и отделите начатое от ожидающего. Не проектируйте идеальный процесс: достаточно общего представления о том, что команда уже обещала выполнить.
ML1 — Team Focused: команда управляет своей работой
На первом уровне отдельная команда визуализирует задачи, обсуждает блокировки и начинает ограничивать одновременную работу. Доска используется регулярно, однако правила могут зависеть от конкретного руководителя, а взаимодействие с заказчиками и соседними командами остаётся неявным.
Следующий шаг — сделать правила работы общими. Опишите, когда карточка переходит на следующий этап, что считается завершением и как команда берёт новую задачу. Материал о том, как описать рабочий процесс, поможет связать колонки доски с реальными событиями, а не с удобными названиями.
ML2 — Customer Driven: поток ориентирован на заказчика
На втором уровне команда управляет уже не только своей загрузкой, но и сервисом для заказчика. Появляются понятные типы запросов, ожидания по обслуживанию, обратная связь и регулярный разбор причин задержек. Приоритет объясняется ценностью и риском, а не только громкостью запроса.
Ближайшее улучшение — сформулировать обещание сервиса. Определите, какие запросы вы обслуживаете, где начинается и заканчивается ответственность команды и что заказчик может ожидать. Для разных типов работы могут понадобиться разные правила; сначала полезно выбрать классы обслуживания.
ML3 — Fit for Purpose: сервис соответствует назначению
На третьем уровне организация проверяет, действительно ли сервис подходит своему назначению. Команда сопоставляет время, качество и предсказуемость с ожиданиями разных групп заказчиков. Решения об улучшениях опираются не на одну внутреннюю метрику, а на пригодность результата для пользователя.
Следующий шаг — связать данные потока с обратной связью. Например, сокращение времени выполнения полезно лишь тогда, когда заказчик получает нужный результат в подходящий момент. Настройте регулярный разговор о качестве сервиса и проверяйте, какие сегменты запросов требуют разных условий.
ML4 — Risk Hedged: организация управляет рисками
На четвёртом уровне несколько сервисов согласуют зависимости и управляют рисками на уровне организации. Решения учитывают вариативность спроса, стоимость задержки, пропускную способность и последствия отказа. Локальное ускорение одной команды не должно создавать очередь у другой.
Ближайшее улучшение — увидеть сквозной поток и зависимости. Отметьте, где работа передаётся между сервисами, какие ожидания чаще всего нарушаются и какие риски требуют отдельной политики. Аналитика должна помогать принимать решения, а не просто украшать отчёт; начать можно с материала, который помогает разобрать метрики Kanban.
ML5 — Market Leader: организация опережает рынок
На пятом уровне организация использует развитые механизмы управления, чтобы быстрее замечать изменения спроса и создавать конкурентное преимущество. Потоки, портфель решений и обратная связь связаны между собой. Эксперименты оценивают не только по локальной скорости, но и по влиянию на рынок и клиентов.
Следующий шаг — повышать качество прогнозов и стратегической обратной связи. Организация сравнивает варианты инвестиций, прекращает слабые инициативы и перераспределяет возможности туда, где меняется спрос. Это уже не задача одной доски или одного менеджера.
ML6 — Built for Survival: организация сохраняет адаптивность
На шестом уровне организация умеет перестраиваться при резких изменениях среды и сохранять жизнеспособность. Важны не отдельные процедуры, а способность видеть новые риски, быстро учиться и менять структуру принятия решений без разрушения ключевых сервисов.
Ближайшее улучшение здесь нельзя свести к универсальному чек-листу. Организация проверяет собственные механизмы адаптации: насколько быстро замечает слабые сигналы, может ли перераспределить ресурсы и сохраняет ли обратную связь между стратегией и фактической работой.
Как определить текущий уровень без самообмана
Определяйте уровень по повторяющемуся поведению, а не по наличию артефакта. Доска сама по себе не подтверждает ML1, если задачи обновляются перед совещанием. Метрики не подтверждают ML3 или ML4, если команда не принимает на их основе решений.
Проведите короткую диагностику по четырём вопросам:
- Видна ли вся принятая работа и совпадает ли доска с реальностью?
- Понимают ли участники правила переходов, приоритетов и завершения?
- Есть ли явное обещание сервиса и обратная связь от заказчика?
- Меняются ли решения при появлении данных о задержках, качестве и рисках?
Соберите конкретные примеры за последние недели. Фраза «мы ограничиваем WIP» слабее наблюдения «при достижении лимита команда перестаёт брать новое и помогает завершить начатое». Если правило действует только при спокойной нагрузке, оно ещё не стало устойчивой привычкой.
Полезно отдельно посмотреть, как команда реагирует на срочный запрос. Зрелость проявляется не в отсутствии исключений, а в понятном способе их обсуждать: что отложено, кто принял решение и когда последствия будут пересмотрены.
Как выбрать следующее улучшение
Выбирайте одно изменение, которое устраняет заметное препятствие на текущем уровне. Если карточки не отражают работу, не начинайте с портфельной аналитики. Если поток команды стабилен, но заказчик не понимает сроков, улучшайте сервисные ожидания, а не оформление доски.
Сформулируйте эксперимент в четырёх частях: проблема, изменение правила, ожидаемый сигнал и дата проверки. Например: «Задачи задерживаются на согласовании; назначаем согласующего до начала работы; через две недели проверяем, осталось ли ожидание без владельца». Такой формат отделяет улучшение от бессрочного обещания «работать лучше».
Чтобы организовать общий поток, разместите рабочие задачи по фактическим стадиям и договоритесь, когда обновляется статус. Инструмент поддерживает договорённость, но не заменяет её: правила переходов и признаки завершения команда определяет сама.
Если нужен простой старт, Канбано помогает показать этапы работы и обсудить, где скапливаются карточки. После этого ограничьте одну проблемную очередь и проверьте результат на реальных задачах.
Какие ошибки мешают развитию
Не используйте KMM для рейтинга сотрудников или публичного сравнения команд. Модель описывает организационные способности, а не личную ценность людей. Если оценка превращается в соревнование за высокий уровень, участники начинают демонстрировать артефакты вместо проблем.
Не внедряйте практики верхнего уровня ради статуса. Сложная аналитика не помогает, если данные в карточках неточны. Корпоративные политики не работают, если команды по-разному понимают начало и завершение задачи. Сначала укрепите ближайшее слабое звено.
Не пытайтесь изменить всё одновременно. Один проверяемый эксперимент даёт больше знаний, чем новый регламент на десятки страниц. После изменения посмотрите на поток, обсудите опыт участников и решите: сохранить правило, изменить его или отказаться.
Kanban Maturity Model полезна, когда возвращает разговор к наблюдаемой работе. Определите устойчивые признаки текущего состояния, выберите ближайшую проблему и проведите ограниченный эксперимент. Практический разбор помогает внедрять Kanban постепенно, не копируя чужой набор ритуалов. Когда новое поведение станет обычным, переходите к следующему препятствию — именно так зрелость растёт без имитации трансформации.
