Kanban открывают, когда работа команды идёт не ровными итерациями, а непрерывным потоком: задачи приходят разного размера, приоритеты могут меняться чаще, а управляемость теряется не из-за отсутствия спринта, а из-за перегруженных очередей, WIP и неочевидных узких мест.
Что это за подход
Kanban полезен как flow-based delivery-подход. Для PM он особенно ценен там, где нужно сделать видимым поток работы: что где застряло, где очередь разрастается, где команда берёт слишком много, а где проблема в самом процессе, а не в людях.
Когда он нужен
- работа идёт непрерывным потоком;
- задачи приходят неравномерно и разного типа;
- важно управлять WIP, очередями и bottlenecks;
- команде не нужен жёсткий спринтовый cadence.
Когда он не нужен
- когда команде полезнее короткий итерационный цикл с review результата;
- если Kanban пытаются свести только к колонкам на доске;
- если нет готовности управлять политиками потока, а не только перемещать карточки.
Что из него реально применимо для PM
- визуализация потока и очередей;
- ограничение незавершённой работы;
- диагностика bottlenecks и blocked work;
- более спокойный контур управления при изменчивом входящем потоке.
Какие артефакты, ритуалы и правила важны
- доска потока;
- явные правила колонок и переходов;
- лимиты WIP;
- отдельный обзор blocked work и aging items.
Какие ошибки чаще всего делают при внедрении
- называют Kanban любую доску без flow-политик;
- не ограничивают незавершёнку;
- используют потоковую модель, но продолжают управлять как пакетным проектом;
- не разбирают системно, почему работа застревает.
Чем можно заменить или упростить
- Scrum, если нужен более жёсткий итерационный ритм;
- Scrumban, если нужен гибридный контур;
- простой операционной доской, если поток маленький и прозрачен без formalized Kanban-практики.