WIP-лимиты: почему меньше задач = больше результат

TL;DR: WIP-лимиты (Work In Progress limits) — ограничение числа задач в одновременной работе — ключевой механизм канбан-метода. Команды, которые берут меньше задач одновременно, завершают их быстрее. Это контринтуитивный, но математически обоснованный принцип.

Автор: Артур Нек
Рецензент: Мила Петрова

Что такое WIP-лимит

WIP (Work In Progress) — объём незавершённой работы: задачи, которые начаты, но ещё не завершены. WIP-лимит — максимально допустимое количество таких задач в конкретной стадии или у конкретного исполнителя одновременно.

Пример: если WIP-лимит колонки «В разработке» равен 3, команда не имеет права взять четвёртую задачу в работу до тех пор, пока одна из трёх не будет завершена. Это кажется ограничением, но на практике ускоряет поток.

Почему меньше = больше: закон Литтла

Математическое обоснование WIP-лимитов — закон Литтла (1961), изначально сформулированный для теории очередей. В применении к командам он звучит так: среднее время выполнения задачи (Lead Time) = WIP / Throughput (пропускная способность).

Из этой формулы следует: если команда хочет уменьшить Lead Time (время от постановки задачи до её завершения), она должна либо увеличить пропускную способность, либо снизить WIP. Увеличить пропускную способность сложно: нужны люди, компетенции, время. Снизить WIP — управленческое решение, которое можно принять сегодня.

Почему это важно для руководителя

Большинство руководителей интуитивно стараются загрузить команду «под 100%»: все чем-то заняты — значит, работают эффективно. Эта логика ломается при любом системном анализе. Команда, ведущая 30 задач одновременно, не в 10 раз производительнее, чем ведущая 3 — она в 10 раз медленнее завершает каждую.

Исследования Toyota и последующие работы по теории ограничений (Элияху Голдратт) последовательно показывают: узкое место в системе определяет скорость всей системы. Снижение WIP позволяет выявить и устранить узкое место вместо того, чтобы наращивать нагрузку на других участников процесса.

Как определить правильный WIP-лимит

Эмпирическое правило

Начальная формула: WIP-лимит = (количество участников стадии) × 1.5. Для команды из 4 разработчиков стадия «В разработке» получает лимит 6. Это стартовая точка, а не постоянное значение — лимиты корректируются по мере наблюдений.

Метод наблюдения

Если Cycle Time растёт при добавлении каждой новой задачи — WIP уже превышен. Если задачи завершаются быстро и очередь в следующую стадию не растёт — лимит можно немного увеличить. Цель — найти точку, при которой поток максимально стабилен, а не максимально загружен.

Как применять: пошаговый алгоритм

  1. Визуализируйте текущий WIP — подсчитайте, сколько задач сейчас в активной работе. Большинство команд обнаруживают цифру, которая их удивляет.
  2. Установите первый лимит — не идеальный, а практический. На 20–30% меньше текущего WIP.
  3. Введите правило «Stop starting, start finishing» — когда WIP-лимит достигнут, команда не берёт новые задачи, а помогает завершить текущие.
  4. Наблюдайте за поведением системы — отслеживайте Cycle Time и Throughput в течение 2–4 недель.
  5. Скорректируйте лимит — снизьте, если очереди продолжают расти; поднимите, если команда простаивает.

Частые ошибки

  • «У нас все задачи срочные» — если всё срочно, то ничто не срочно. WIP-лимиты требуют реальной приоритизации, а не декларативной.
  • Лимиты без поддержки руководителя — команда не может удерживать WIP-лимиты, если руководитель продолжает добавлять задачи сверх лимита. Это системное решение, а не командное.
  • Слишком низкий лимит — простои появляются там, где есть зависимости: один ждёт другого. Лимит должен учитывать реальные зависимости в процессе.
  • Лимит установлен и забыт — WIP-лимиты нуждаются в регулярном пересмотре по мере изменения размера команды и типа задач.

Итого

  • WIP-лимит — ограничение числа задач в одновременной работе
  • Закон Литтла доказывает: снижение WIP снижает Lead Time
  • Стартовая формула: WIP = (число участников) × 1.5
  • Главное правило: «Stop starting, start finishing»
  • Лимиты без поддержки руководителя не работают — это системное решение

Проверьте свою управленческую зрелость: Пройти диагностику RuForge →

Связанные материалы

— Приоритизация задач руководителя: метод 15 минут
— Яндекс.Маркет: Cycle Time −67% через WIP-лимиты и канбан-поток
— SMART-цели: почему не работают и что делать вместо