8 ошибок в Kanban: Как не превратить доску в хаос
Kanban выглядит обманчиво просто: нарисуй колонки и двигай карточки. Но за визуализацией стоят строгие принципы управления потоком. Если их игнорировать, доска быстро станет кладбищем задач, а контроль над процессом исчезнет.
Большинство проблем возникает из-за нежелания команды ограничивать себя и привычки работать по старинке.
Системные ошибки и антипаттерны
1. Жизнь без лимитов WIP Команда создает колонки, но не ограничивает количество задач в них
- Результат: Все заняты всем сразу, задачи висят неделями, а время выполнения (Lead Time) растет.
2. Туманный поток (Flow) Колонки слишком общие (например, просто В работе). Непонятно, какие критерии должны быть выполнены, чтобы передвинуть задачу дальше.
- Результат: Путаница и скрытые заторы, которые никто не замечает.
3. Работа по принуждению (Push System) Менеджер «нарезает» задачи и вешает их на команду, даже если их лимит WIP уже забит.
- Результат: Нарушается главный принцип — вытягивание (Pull). Команда захлебывается в объеме работы.
4. Игнорирование блокировок Заблокированная задача (ждем ответа клиента, упал сервер) просто висит на доске.
- Результат: Она занимает место в лимите WIP, не давая взять новую работу. Поток останавливается.
5. Доска как отчет, а не инструмент Команда использует сложный софт, но заглядывает туда раз в неделю для отчета.
- Результат: Доска не отражает реальность. Это просто картинка для руководства, а не живой план действий.
6. Застывший процесс Команда боится менять колонки или лимиты, считая их священными.
- Результат: Процесс не адаптируется под реальные изменения. Идея непрерывного улучшения (Kaizen) умирает.
7. Погоня за количеством, а не за скоростью Команда считает только сколько задач закрыто (Throughput), но не смотрит, как долго они висели в работе (Cycle Time).
- Результат: Вы можете закрывать 100 задач в месяц, но клиент будет ждать свою фичу полгода. Это неэффективно.
8. Отсутствие пополнения (Replenishment) Нет регулярных встреч для отбора новых задач из бэклога.
Результат: Команда простаивает, потому что никто вовремя не подготовил входной билет для новой работы.
| Ошибка (Антипаттерн) | Причина | Готовое Решение (Действие) |
| Игнорирование WIP Limits | Страх, что команда не сможет взять всю работу. | Немедленно установите WIP-лимиты. Не существует идеальной формулы для старта. Лучшая практика — начать с того, что есть сейчас (визуализировать текущую нагрузку), и постепенно снижать лимиты. Хорошая стартовая точка — разрешить не более 1-2 задач на одного человека, чтобы сразу выявить, где возникает многозадачность, и затем калибровать лимиты на основе метрик потока. |
| Kanban как Push System | Привычка менеджеров назначать работу. | Пересмотр правил: работа вытягивается командой только после того, как освобождается место в колонке В процессе. |
| Отсутствие Четкого Потока | Слишком общие названия колонок. | Введите Definition of Done (DoD) для каждого этапа (колонки) и используйте более детальные колонки (например, “Разработка”, “Ревью Кода”, “Тестирование”). |
| Игнорирование Блокировки | Отсутствие ответственности за внешние зависимости. | Введите правило: заблокированная задача немедленно маркируется (красный стикер) и занимает место в WIP. Scrum Master или фасилитатор отвечает за устранение блокировки. |
| Неверное Использование Метрик | Фокус только на скорости. | Начните отслеживать Lead Time (время от Старт до Готово) и Cycle Time (время работы над задачей). Оптимизируйте систему для снижения Lead Time. |
Следовательно, устранение этих распространенных ошибок сводится к принятию фундаментальной философии Kanban: управление Потоком (Flow), а не людьми. Если команда четко соблюдает WIP Limits и использует Pull System, то проблемы становятся видимыми на доске, а не скрываются в отчетах. Kanban, в отличие от Scrum, не предлагает фиксированных ролей или мероприятий, но требует гораздо большей дисциплины в отношении правил рабочего процесса.
Однако, важно помнить, что внедрение Kanban — это процесс Непрерывного Улучшения (Kaizen), а не разовое событие. То, что сегодня является правильным лимитом WIP, завтра может стать затором. Поэтому регулярные встречи (Kanban Meeting/Ретроспектива) должны быть сфокусированы на анализе метрик (Lead Time и Throughput) и постоянной адаптации правил доски к меняющейся нагрузке и приоритетам.
Резюме: Управляйте потоком, а не людьми
Успех в Kanban — это дисциплина. Если лимиты WIP соблюдаются, проблемы сами выплывают на поверхность. Доска начинает кричать о заторах, и вам не нужны отчеты, чтобы понять, где всё сломалось.
Ключевой вывод: Не считайте Kanban просто инструментом визуализации. Это система управления. Перестаньте начинать новое и начните заканчивать начатое (Stop starting, start finishing). Только так вы превратите хаос в предсказуемый поток, который приносит ценность вовремя.
Часто задаваемые вопросы (FAQ)
Лучший способ — начать с правила “N-1”, где N — это количество человек в команде. Например, если в команде 5 разработчиков, начните с WIP Limit = 4 для колонки “В работе”. Это сразу заставит команду завершать задачи и снизит мультизадачность. Позже, на Ретроспективе, этот лимит можно скорректировать.
Это классическое сопротивление изменениям. Scrum Master должен объяснить PO, что назначение работы, когда WIP заполнен, увеличивает Lead Time (время до поставки), что противоречит целям Kanban. Используйте реальные данные (графики Lead Time), чтобы показать PO, как перегрузка негативно влияет на предсказуемость.
Нет. Лимиты должны отражать фактические производственные мощности этапа. Например, для этапа “Ревью Кода” лимит может быть меньше, чем для “Разработки”, если ревью проводят всего один-два человека. Установите лимит там, где чаще всего возникает заторы (Bottlenecks), чтобы сосредоточить на этом этапе внимание команды.
Структура доски должна меняться, когда команда обнаруживает, что текущие колонки неточно отражают рабочий процесс или не помогают выявить заторы. Kanban построен на Непрерывном Улучшении (Kaizen), поэтому если на Ретроспективе команда решает, что нужна новая колонка (“В ожидании PO”, “QA на стенде”), это нужно сделать немедленно.
Блокировка — это ситуация, когда внешняя, неконтролируемая командой причина (например, нерабочий внешний сервис) не позволяет двигать задачу. Ожидание — это часто внутренняя, контролируемая причина (например, задача ждет ревью от коллеги). В идеальном Kanban оба состояния должны быть минимизированы, но блокировка требует немедленного вмешательства Scrum Master’а.