Как настроить WIP‑лимиты: опыт разных команд

Канбан учит нас одному простому, но мощному принципу: работа должна быть ограничена. Именно это и есть суть WIP‑лимитов — ограничения количества задач, находящихся в работе (Work In Progress). Без них Канбан‑система теряет эффективность: команды перегружаются, задачи затягиваются, фокус расплывается.

Разберёмся, как настроить WIP‑лимиты, какие есть подходы и как это делают команды с разным уровнем зрелости.

Что такое WIP‑лимит и зачем он нужен?

WIP‑лимит — это максимальное число задач, которые команда или конкретная колонка на Канбан‑доске может обрабатывать одновременно.

Примеры:

• В колонке «В работе» стоит лимит 3 — значит, одновременно в ней может быть максимум три карточки.

• Весь поток может иметь совокупный лимит — например, не более 7 активных задач на всю команду.

Зачем это нужно?

• Уменьшает многозадачность

• Повышает скорость завершения

• Делает процесс прозрачным

• Позволяет быстрее выявлять узкие места

• Улучшает фокус и качество

3 подхода к настройке WIP‑лимитов

1. Эмпирический (пробный)

Команда начинает с удобных чисел — например, «2–3 задачи на человека» — и постепенно адаптирует лимиты, наблюдая за потоком.

Пример:
Команда из 4 человек ставит лимит на «В работе» = 6. Через месяц замечает, что фактически справляется с 4 — и корректирует лимит.

2. От загрузки команды (capacity‑based)

WIP‑лимиты задаются, исходя из текущей доступности людей и типа работы.

Пример:
У двоих участников отпуск, один — на онбординге. Вместо обычного лимита 8 задач, устанавливается 5.

3. По потокам (workflow‑based)

WIP‑лимиты ставятся на каждую колонку, а не на весь процесс. Это помогает контролировать перегрузку в конкретных фазах: анализ, разработка, тест.

Пример:

• Анализ — лимит 2

• В разработке — лимит 3

• На тестировании — лимит 2

Как это делают разные команды

Junior‑команды

• Начинают с общего лимита (например, 5–7 задач)

• Часто боятся «пустых» колонок

• Делают ретроспективы каждые 2–3 недели, корректируют лимиты

Опытные команды

• Используют лимиты на конкретные этапы

• Поддерживают кросс‑функциональность (если «тест» простаивает — разработчики помогают)

• Используют метрики (Cycle Time, Throughput) для оценки влияния лимитов

Продуктовые команды

• Могут вводить WIP‑лимиты по классам обслуживания

• Используют политики: «при превышении лимита — сначала заверши старое»

• Делают визуальные алерты: колонка краснеет при перегрузке

Типичные ошибки

1. Фиктивные лимиты — поставили, но не соблюдают.

2. Слишком высокие лимиты — не решают проблему фокуса.

3. Нет командной дисциплины — каждый делает «своё», не думая об общем потоке.

4. Игнорирование узких мест — перегруз в тестировании, но все продолжают «вкидывать» задачи.

5. Паника при «пустой» доске — а ведь это признак здоровья, не простоя.

Как внедрить WIP‑лимиты: пошагово

1. Проведите воркшоп или ретроспективу — зачем нам это нужно?

2. Начните с одного лимита на всю колонку «В работе»

3. Договоритесь, что превышение лимита — исключение, а не правило

4. Отслеживайте метрики: как изменился цикл задач?

5. Корректируйте лимиты по ходу развития команды

Заключение

WIP‑лимиты — это не про ограничения ради ограничений. Это способ разгрузить команду, ускорить поток и повысить качество. Они дают Канбану дыхание: когда меньше задач — быстрее результат.

Именно через WIP‑лимиты команды начинают по-настоящему думать о процессе, а не просто перетаскивать карточки по доске. Это шаг от визуализации к управлению.