Kanban: кейс, как доска сократила время поставки фич в 2 раза

Kanban — это способ управлять потоком задач через визуальную доску и лимиты незавершённой работы (WIP), где реально сократить lead time фич в 2 раза за 6–10 недель, но ключевой риск — «повесить стикеры» и не менять правила работы: без WIP, измерений и политики приоритизации доска превращается в красивую обойку.

Hook: почему “мы внедрили Kanban” почти всегда звучит как “мы купили коврик для йоги”

Чаще всего Kanban “внедряют” так: рисуют колонки, перетаскивают карточки, радуются, что стало «прозрачно». А потом внезапно выясняется, что фичи всё равно едут по 20–40 дней, баги сжирают спринт, а бизнес злится: «Почему задача висит в Review неделю?». Если вы сейчас в этом кино — вы не одиноки.

Проблема не в том, что “Kanban не работает”. Проблема в том, что доска — это только интерфейс. Сокращение сроков даёт не дизайн колонок, а управление очередью и пропускной способностью: WIP-лимиты, явные правила, метрики и регулярная калибровка узких мест.

Контекст кейса: что было “до”

Кейс собран из типовой практики продуктовой разработки (встречается у команд 6–10 человек: бэкенд, фронт, QA, аналитик/PM). Сфера не важна — физика потока везде одинаковая.

• Команда: 8 человек (4 dev, 2 QA, 1 аналитик, 1 PM)
• Поставка: 2 релиза в месяц “как получится”
• Главная боль: фичи “почти готовы” неделями, контекст переключается, качество плавает
• Процесс: формально Scrum, фактически — бесконечный срочный поток + хвост незавершёнки

Симптомы, из-за которых lead time раздувается

• Начинают слишком много задач одновременно (“чтобы все были заняты”).
• Review и тестирование — не этапы, а очередь без владельца.
• Приоритеты меняются в середине работы → часть задач “замораживается”.
• Нет явной политики “что считается готовым” на каждом шаге.

Практический вывод: если у вас много “почти готово”, то вы платите процентами по кредиту незавершёнки. Kanban как раз про то, чтобы закрыть этот кредит.

Что сделали: Kanban не как доска, а как система

Шаг 1. Сняли базовые метрики (без них “в 2 раза” — просто желания)

Из трекера выгрузили последние 30–50 завершённых задач и посчитали:

• Lead time (с “Committed/To do” до “Done”).
• Cycle time (с “In Progress” до “Done”).
• Throughput (сколько задач/фич закрываем в неделю).
• WIP (сколько задач одновременно “в работе” по факту).

Подводный камень: многие меряют “скорость разработки” и игнорируют хвост (P85/P95). А бизнес живёт именно в хвосте: когда “эта фича должна была быть на прошлой неделе”.

Шаг 2. Пересобрали доску под реальные очереди

Доска стала отражать не “как красиво”, а где реально теряется время. Типовая структура:

• Discovery (опционально)
• Ready for Dev
• Dev
• Code Review
• Ready for QA
• QA
• Ready for Release
• Done

Практический вывод: если у вас нет отдельных колонок под Review/QA/Release, вы не увидите очередь. А если не видите — не управляете.

Шаг 3. Ввели WIP-лимиты (и это было больно)

Ограничили незавершёнку по ключевым узким местам:

• Dev: WIP 4
• Code Review: WIP 2
• QA: WIP 3

Как только WIP упирался в лимит — новое не начинали. Да, звучит как “мы запрещаем работать”. На деле это заставляет заканчивать: помогать с review, чинить флейки, дописывать тесты, разгребать зависшие задачи.

Подводный камень: “Мы поставили WIP, но всё равно начинаем новое, потому что срочно”. Поздравляю: вы не внедрили Kanban, вы сделали вид. Срочное должно попадать через явное правило expedite (см. ниже), а не через истерику в чате.

Шаг 4. Явная политика приоритизации + отдельная дорожка для “пожара”

Команда зафиксировала правила:

• Commitment point: задача считается “в работе” только после входа в Ready for Dev.
• Definition of Ready: есть критерии приёмки, мок/скрин, зависимости, оценка риска.
• Expedite lane: максимум 1 задача одновременно, только с согласием PM+техлида (иначе “срочное” станет нормой).

Практический вывод: Kanban без правил — это демократия в очереди в поликлинику. Формально все равны, фактически рулят громкие.

Шаг 5. Поставили два коротких регулярных ритуала вместо “ежедневного стендапа ради стендапа”

• Ежедневный flow-review (10–12 минут): идём справа налево: что блокирует выпуск? где очередь? кого подключить?
• Еженедельная сервисная ретро (30 минут): смотрим метрики, меняем WIP/политики, убираем системные блокеры.

Подводный камень: обсуждать “кто чем занимается” вместо “что мешает потоку”. Kanban — про поток, а не про отчётность.

Почему получилось “в 2 раза”: механика, без магии

Сокращение lead time почти всегда достигается не ускорением разработки, а снижением ожиданий. Большая часть времени задачи умирает в очередях: ждёт review, ждёт теста, ждёт релиза, ждёт уточнений. Когда вы режете WIP, вы уменьшаете очереди. Это чистая теория очередей, такой скучный раздел математики, который внезапно экономит недели жизни.

Коммерческие факторы: сколько стоит внедрение (спойлер: не лицензия)

Если вы думаете, что стоимость Kanban — это тариф Jira/Trello, вы пропускаете главный счёт.

• Стоимость: 2–4 недели на настройку доски, правил и метрик + 6–10 недель на стабилизацию (обычно параллельно с работой).
• Кто платит: команда временем на договорённости и перестройку привычек.
• Скрытая цена: первое время будет ощущение “мы стали медленнее”, потому что вы перестанете стартовать новое и начнёте разгребать хвост. Это нормально. Неприятно, но нормально.

Экспертный вердикт и инструмент: как повторить кейс без религиозных войн

Kanban сокращает сроки там, где есть очереди и хаос приоритетов. Если у вас уже идеальная предсказуемость — поздравляю, вы редкий вид. Всем остальным пригодится короткий чек-лист.

Чек-лист: 7 вопросов перед тем, как “делать Kanban”

1. Вы можете назвать текущий средний lead time и P85 хотя бы примерно?
2. На доске видны отдельные колонки для Review и QA, или это всё “в разработке”?
3. Есть WIP-лимиты хотя бы на 2–3 узких места?
4. Есть правило, что считается готовым к разработке (DoR) и готовым (DoD)?
5. Как вы обрабатываете “срочное”: отдельная дорожка с лимитом или паника?
6. Кто владеет очередью перед QA/Release (кто её разгребает)?
7. Раз в неделю вы меняете политику на основе данных, или просто смотрите на доску и грустите?

Стратегии по профилю

• Если вы меняете профессию в IT: учите Kanban через метрики (lead/cycle time, throughput, WIP). Это то, что отличает “читал книжку” от “понимаю, почему оно работает”.
• Если вы junior–middle (1–3 года): прокачайте навык фасилитации flow-review и настройку политик Ready/Done. Это быстрый способ стать человеком, который “делает поставку”, а не только двигает таски.

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