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

Если вы только заходите в IT или уже джун со стажем 1–3 года, канбан кажется простым: To Do — In Progress — Done, и можно идти пить кофе. А потом приходит реальность: 5 параллельных проектов, согласования, ожидание юристов, релизы, инциденты, зависимость от аналитиков и «а давайте ещё вот это маленькое». И доска превращается в кладбище стикеров, где “Done” — единственный остров стабильности.

Проблема не в Kanban. Проблема в том, что kanban-доска часто используется как трекер задач, а не как система управления проектом. Точнее… управления сервисом/потоком работ, но для большинства проектных команд это и есть “проектная жизнь”. Ниже — как использовать kanban так, чтобы он помогал управлять сроками, рисками и нагрузкой, а не просто красиво раскрашивал карточки.

Kanban для проектов: что добавляется сверх «задачника»

1) WIP-лимиты: лекарство от «всё делаем одновременно»

Тезис: Kanban начинает работать, когда вы ограничиваете количество задач “в работе”. Без этого доска — визуализация хаоса.

Обоснование: Любая команда с многозадачностью платит “налог на переключение”: контекст теряется, растёт число незавершённых задач, увеличиваются очереди на ревью/тест/согласование. В канбане это лечится WIP (Work In Progress) лимитами на колонках.

Практический вывод: поставьте WIP-лимит хотя бы на “В работе” и “На ревью”. Пример: команда 5 человек — WIP=5–7 на “В работе”. Всё, что выше, должно болеть.

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

2) Классы обслуживания (Class of Service): проекты не равны

Тезис: Kanban для проектов важен тем, что вы вводите правила приоритета, а не просто сортируете карточки “по ощущениям”.

Обоснование: В потоке работ всегда есть разные типы: срочные инциденты, регуляторные изменения, фичи, техдолг. В канбане это задаётся Class of Service — “Expedite” (срочно), “Fixed date” (к дедлайну), “Standard” (обычно), “Intangible” (техдолг без явного дедлайна).

Практический вывод: заведите 3–4 класса обслуживания и отдельные правила: сколько “срочных” можно одновременно, что вытесняется, кто подтверждает срочность.

Подводный камень: если всё становится Expedite, значит у вас проблема не в доске, а в управлении ожиданиями и входящим потоком.

3) Политики на колонках: “готово к…” — это не магия, это договор

Тезис: Хорошая kanban-доска — это не визуальные колонки, а явные правила перехода между ними.

Обоснование: Люди спорят не про работу, а про определения. “Готово к тесту” — это когда? Есть тест-кейсы? Собрано? Документация обновлена? В Kanban это фиксируют policies: чек-лист на вход/выход колонки (Definition of Ready/Done по месту).

Практический вывод: для 2–3 ключевых колонок (например, “В разработке”, “Ревью”, “Тест”) добавьте короткие политики: 3–6 пунктов.

Подводный камень: превращать политики в бюрократию на 30 пунктов. Это не ГОСТ, это страховка от типовых косяков.

4) Управление зависимостями: “ждём” должно быть видно

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

Обоснование: Многие “задержки проекта” — это не разработка, а ожидание: ответа бизнеса, доступа, закупки, безопасников, контрагентов. Если это не видно на доске, команда выглядит “медленной”, хотя она стоит в очереди.

Практический вывод: добавьте состояния типа “Blocked/Ожидание” или отдельную дорожку (swimlane) для заблокированных. И правило: блокер должен иметь причину + владельца + дату следующего шага.

Подводный камень: блокеры без владельца — это не блокеры, это оправдания.

5) Прогнозирование по метрикам: сроки из данных, а не с потолка

Тезис: Kanban умеет отвечать на главный проектный вопрос: “когда будет готово?” — на основе факта прохождения задач, а не оптимизма.

Обоснование: В канбане используют две базовые метрики:

• Cycle Time — сколько задача реально проводит времени “в работе” (от старта до Done).
• Throughput — сколько задач команда закрывает за период (неделя/спринт/месяц).

На их основе строят прогноз: сколько времени займёт бэклог из N элементов при текущей пропускной способности. В более продвинутой версии — Monte Carlo симуляции (без мистики: просто вероятностный расчёт).

Практический вывод: начните с простого: фиксируйте дату входа в “В работе” и дату “Done”. Через 3–4 недели у вас появится распределение cycle time и первый честный прогноз.

Подводный камень: пытаться прогнозировать по “story points”, когда команда ещё не калибрована. Для новичков points часто превращаются в гадание на кофейной гуще.

Как использовать kanban-доску: минимальная «проектная» настройка

Скелет доски (не для красоты, а для управления)

• Backlog (входящий поток, не “свалка”)
• Ready (готово брать в работу)
• In Progress (разработка/выполнение) + WIP
• Review (код-ревью/согласование) + WIP
• Test (проверка) + WIP
• Done
• Blocked (или пометка/дорожка)

Еженедельный ритуал, который реально окупается

1. Проверка WIP: где перегруз, что стопорит поток.
2. Разбор блокеров: владелец, следующий шаг, срок.
3. Пополнение Ready: чтобы команда не простояла завтра.
4. Мини-ретро по метрикам: cycle time вырос — почему?

Это не “созвон ради созвона”. Это техобслуживание вашей системы доставки результата.

Таблица: «доска задач» vs «kanban для проектов»

Кейсы из практики: когда канбан спасает (и когда нет)

Кейс 1 (удачный): «релиз каждый месяц, а ощущение — вечный пожар»

Команда вела продукт в Яндекс Трекере: куча задач, статус “В работе” растянут на всё, ревью накапливалось, тестировщики жили в конце цепочки. Поставили WIP на “В работе” и “Ревью”, ввели отдельный класс Expedite только для инцидентов, добавили политику “готово к тесту”. Через месяц выяснилось неприятное, но полезное: узкое место — ревью и согласование изменений. Решение оказалось не “нанять ещё разработчика”, а перераспределить ответственность за ревью и сделать ревью частью ежедневной нормы. Cycle time по типовым задачам упал, а главное — прогноз стал предсказуемым.

Кейс 2 (неудачный): «доска есть, а проекты всё равно тонут»

В другой компании сделали красивую kanban-доску в Kaiten, но оставили один статус “В работе” и не ввели политики. Итог: задачи стояли неделями, блокеры прятались в переписке, а менеджмент продолжал “ускорять” добавлением ещё задач. Канбан тут не виноват: если не ограничивать WIP и не фиксировать правила переходов, вы просто повесили на стену зеркало, которое честно отражает бардак.

Кстати, больше разборов про практику управления работой, карьерные траектории в IT и прикладные методологии — на https://itokno.ru. Без лозунгов, с цифрами и разбором рисков.

Экспертный вердикт и инструмент: чек-лист «проектный канбан за 1 день»

• 1) Сформулируйте поток: какие 5–7 статусов реально происходят между “идея” и “готово”.
• 2) Поставьте 2 WIP-лимита: на “В работе” и на самый проблемный этап (часто ревью/тест).
• 3) Введите 3 класса обслуживания: Standard, Fixed date, Expedite — и правила, кто их назначает.
• 4) Сделайте видимыми блокеры: причина, владелец, следующий шаг, дата.
• 5) Начните считать cycle time: хотя бы вручную по датам старта/финиша.

Если после этого вам всё ещё “непонятно, почему сроки плывут” — значит проблема уже не в инструменте, а в входящем потоке (слишком много задач), в зависимостях (внешние команды/подрядчики) или в неопределённости требований. И это тоже нормально: канбан хорош тем, что он быстро показывает, где именно болит.

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