Kanban-доска — это способ выстроить управляемый поток задач, где команда ускоряет поставку за счёт WIP-лимитов и прозрачных правил входа/выхода; внятные улучшения обычно видны за 3–6 недель, но ключевой риск — «доска ради доски», когда статусы есть, а предсказуемости и скорости нет.

Hook: почему у вас «вечно занято», а релизы всё равно редкие

Боитесь внедрить Kanban, потратить месяц на настройку и получить… разноцветные стикеры вместо результата? Нормальный страх. Большинство досок умирает не от нехватки Jira, а от отсутствия потока: задачи заходят как хотят, зависают «на ревью», WIP без лимитов, а метрики — только “сколько закрыли”.

Kanban — не про «работаем без планирования». Он про экономику внимания: сколько задач команда может одновременно тянуть, где образуются пробки и что именно улучшать, чтобы сокращать время от “идея” до “в проде”.

1) Поток: сначала дизайн системы, потом колонки

1.1. Сначала определите «единицу потока» (что именно течёт)

Тезис: пока не ясно, что является «единицей работы», доска будет врать.

Практика: для продуктовой команды единица обычно — user story/задача, для платформенной — тикет изменения, для саппорта — обращение.

Вывод: фиксируйте минимальный «атом», который можно довести до Done без разрастания на неделю.

Подводный камень: таски размером “переделать архитектуру”. Это не задача, это роман в трёх томах. Делите.

1.2. Опишите классы обслуживания (Classes of Service)

Тезис: срочность должна быть правилом, а не криком в чате.

• Expedite — пожар, блокер, инцидент. Идёт вне очереди, но в ограниченном количестве.
• Fixed Date — дата важнее объёма (релиз, регуляторика). Заходит заранее.
• Standard — обычная работа.
• Intangible — улучшения, которые «пока не болит» (техдолг, автоматизация).

Вывод: классы обслуживания — это ваш анти-хаос: они объясняют, почему одна задача ждёт, а другая летит.

Подводный камень: когда у вас 70% задач — Expedite. Тогда это не “срочно”, это «система поломана».

1.3. Политики входа/выхода: Definition of Ready/Done на уровне колонок

Тезис: «перетаскивание карточек» должно быть формализовано, иначе статус — художественный.

Вывод: вы уменьшаете «полуработу», которая создаёт иллюзию прогресса.

Подводный камень: Done = «на моей машине работает». Нет, это “Almost Done”, только вы так колонку не назвали.

2) WIP-лимиты: не для контроля людей, а для психологии очередей

2.1. Где ставить лимиты

Тезис: лимиты нужны там, где возникает очередь и переключение контекста.

• На колонки с ручной проверкой: Code Review, Testing.
• На «In Progress», чтобы не плодить начатое.
• На весь поток (общий WIP), если команду разрывает.

Вывод: начните с 2–3 лимитов, а не с «ограничим всё». Kanban — хирургия, не ковровая бомбардировка.

Подводный камень: лимит стоит, а задачи всё равно «висят». Значит, его обходят — или политика входа/выхода фиктивная.

2.2. Как посчитать стартовые WIP-лимиты (работающий грубый метод)

Если команда из 6 человек:

• In Progress: 6 (по одной активной задаче на человека) — это уже «щадящий» режим.
• Code Review: 2–3 (иначе ревью превращается в кладбище PR-ов).
• Testing: 2–3 (или по пропускной способности QA/автотестов).

Вывод: лимиты должны быть слегка неприятными. Если лимит никогда не достигается — он декоративный.

Подводный камень: ставить лимит 1 на всё. Команда не станет «поточной линией», она станет «вечно простаивающей».

2.3. Что делать, когда лимит пробит

Тезис: пробитый лимит — это сигнал системе, а не повод искать виноватого.

1. Остановить старт новых задач.
2. Сфокусироваться на разгребании узкого места (ревью, тесты, деплой).
3. Если пробки повторяются — менять процесс: CI, правила PR, парное ревью, автотесты, размер задач.

Вывод: Kanban заставляет команду «доделывать», а не «начинать».

Подводный камень: героически расширять лимиты вместо устранения причины. Это как расширять кладбище вместо лечения.

3) Метрики: чем мерить эффективность, чтобы не получить KPI-карго-культ

3.1. Базовый набор метрик Kanban (минимум, который реально работает)

Вывод: метрики Kanban — про предсказуемость и узкие места, а не про «нагнуть команду».

Подводный камень: считать эффективность количеством закрытых задач. Тогда люди начнут пилить тикеты на «переименовать переменную».

3.2. SLE и прогнозирование: обещайте не «когда-нибудь», а вероятностями

SLE (Service Level Expectation) — ожидание по сроку с вероятностью. Пример: “85% задач класса Standard завершаются за 10 рабочих дней”.

Вывод: SLE превращает сроки из гадания на кофе в управляемую статистику. Рынок (и начальство) любит, когда вы прогнозируете как взрослые.

Подводный камень: рисовать SLE, пока у вас нет данных хотя бы за 4–8 недель стабильного потока.

4) Настройка доски: рабочий шаблон колонок для типичной продуктовой команды

5) Экспертный вердикт и инструмент: чек-лист настройки Kanban, который экономит месяцы

• 1) Вы договорились, что такое Done (не “в разработке закончили”, а “ценность доставлена”).
• 2) У каждой колонки есть вход/выход. Без этого метрики мусорные.
• 3) WIP-лимиты стоят на In Progress и на проверках (ревью/тесты).
• 4) У вас есть хотя бы 4 недели данных по cycle/lead time.
• 5) Вы обсуждаете пробки на регулярном replenishment/flow review (не только на стендапе).
• 6) Сроки даёте через SLE (процентили), а не через «кажется, к пятнице».
• 7) Политика Expedite ограничена и болезненна, иначе это будет “всё срочно”.

Частые вопросы

Если хотите, уточните: размер команды, тип работы (продукт/аутсорс/саппорт), есть ли QA и как релизитесь. Я соберу под это 2–3 варианта доски с конкретными WIP-лимитами и метриками под вашу реальность.