Начать нельзя закончить: зачем нужны WIP-лимиты

Фраза, которую каждый из нас слышал или даже говорил: «Начну с понедельника». Начать — легко. Начать приятно. Начало дает ощущение движения, новизны, контроля. А вот довести начатое до ожидаемого результата — уже совсем другая история. Поэтому дома у нас лежат недочитанные книги, коробка «разобрать потом», а в компьютере — недопройденный онлайн-курс и десяток задач, застывших в статусе «In progress».

Иронично, что мы продолжаем брать новые задачи — они будоражат, обещают результат и постепенно отправляются туда же… в кладовую незакрытых дел.

В статье разбираемся с WIP-лимитами: что это и зачем, как подобрать лимит для команды, проверить его эффективность и всем ли вообще нужно ограничивать параллельную работу.

Работа кипит, а результата нет — причины

🧠 Старт вознаграждает ощущением прогресса. Новое дело обещает результат еще до того, как потребует всей работы по его достижению. Исследования нейробиологии показывают, что дофаминовая система участвует в формировании и обновлении ожиданий будущей награды (Schultz, Dayan & Montague, 1997). Поэтому нам так легко увлечься новым, еще не начатым делом.

🧠 Незавершенная работа продолжает занимать ресурс. Чем больше открытых дел удерживает человек, тем сильнее они расходуют внимание. Ранее подробно описали, «Как быть с незавершенными задачами».

🧠 Видимость движения вместо движения. Задача может месяцами числиться активной, но фактически не приближаться к завершению. Такое происходит, когда один из этапов процесса не успевает обрабатывать весь поступающий объем работы. Этот этап становится узким местом, или «бутылочным горлышком», а перед ним постепенно накапливается очередь. Чем дольше она растет, тем дольше приходится ждать каждой следующей задаче.

Как следствие

Результат приходит позже. При прочих равных, чем больше работы одновременно находится в процессе, тем дольше она проходит систему.
Сроки становятся менее предсказуемыми. Чем больше открытых задач, тем сложнее понять, когда конкретная будет готова.
Растут очереди. Перед узкими местами накапливается работа, и каждая следующая задача ждет дольше.
Растет стоимость переключений. При переходе между задачами приходится восстанавливать контекст вместо того, чтобы двигать работу вперед.

Начнем с WIP. Work in Progress, буквально — «работа в процессе». Также используется расшифровка Work in Process. В производственном контексте work in process называют продукцию, которая находится на разных стадиях изготовления и еще не стала готовым изделием. Oracle, Work in Process Glossary.

В Kanban Method WIP — это рабочие элементы (work items), которые находятся в процессе в определенный момент времени. Рабочим элементом может быть задача, заявка, ошибка, функция продукта, проект или другой объект, который проходит через рабочий процесс. Kanban University, The Official Guide to The Kanban Method.

🚦 Все и сразу — плохая стратегия

Почему количество незавершенных задач значимо? Потому что у процесса есть определенная скорость завершения работы. Например, команда в среднем закрывает 20 задач в неделю. При WIP в 20 задач среднее время их прохождения составляет около недели, а при WIP в 60 — около трех недель.

Эту связь формализует закон Литтла. В 1961 году Джон Литтл установил зависимость между количеством объектов в системе, скоростью их прохождения и временем пребывания в системе:

Throughput — средняя скорость завершения работы. Ее определяют по количеству рабочих элементов, завершенных за выбранный период. Например, если за месяц команда завершила 80 задач, ее средняя скорость завершения составляет 20 задач в неделю.

Lead Time — среднее время прохождения рабочего элемента через систему: от момента его попадания в систему до завершения. Для его расчета измеряют время прохождения завершенных элементов за выбранный период и находят среднее значение.

Закон Литтла применим при выполнении условий стационарности системы и существовании соответствующих средних значений. Little, 1961, Operations Research.

🚦 Сначала скажите «нет»

Как управлять объемом незавершенной работы? Один из ответов Kanban — ограничить WIP.

Допустим, у команды есть этап «Тестирование», и на нем установлен WIP-лимит 3. Три задачи уже находятся на тестировании — разработчики не передают туда четвертую. Сначала нужно завершить одну из текущих задач. Так команда не накапливает больше работы, чем следующий этап способен обработать.

Так WIP-лимит связывает поступление новой работы с доступной пропускной способностью процесса. Пока лимит достигнут, следующий рабочий элемент ждет. Когда появляется свободная способность, работа может быть передана на этот этап.

Такой принцип в Kanban называют pull, или «вытягиванием» [в противовес push — «выталкиванию»], при котором работа поступает в процесс по мере появления свободной способности принять ее. В результате следующий этап как бы «вытягивает» работу с предыдущего, когда готов ее принять.

В результате получается такая цепочка:

ограниченная способность завершать работу → накопление незавершенной работы → увеличение времени ее прохождения → ограничение WIP → работа поступает по мере освобождения способности → более управляемый поток работы.

🚦 Как подобрать WIP-лимит?

Если вы решили ограничить WIP, начните с текущего состояния процесса.

Зафиксируйте текущий WIP.
Посчитайте, сколько рабочих элементов одновременно находится в системе и на каждом этапе.
Найдите место накопления.
Посмотрите, перед каким этапом постоянно образуется очередь. Это участок, где текущая способность не справляется с поступающей работой.
Для начала ограничьте один этап.
Установите WIP-лимит на выбранном этапе ниже его текущего уровня. Важно, чтобы лимит реально ограничивал поступление новой работы и заставлял команду освобождать место, завершая уже начатую.
Сравните результат с исходным состоянием.
После введения лимита за выбранный период посмотрите на WIP, скорость завершения работы, время ее прохождения и размер очереди. Если работа проходит систему быстрее, а объем завершенной работы не снижается, ограничение дает нужный эффект.
Настройте лимит.
Если очередь продолжает расти, лимит не решает проблему или ограничение стоит не там. Если этап регулярно простаивает, ограничение может быть слишком жестким. Меняйте лимит постепенно и снова сравнивайте результат.

WIP-лимит не рассчитывают один раз или по количеству сотрудников. Его задают как ограничение пропускной способности и настраивают по фактическому поведению потока. Такой подход соответствует принципу Kanban: начинать с существующего процесса и постепенно улучшать его на основе данных.

Лимит установлен, но новая задача все равно оказывается в работе. Обычно для нее быстро находится уважительная причина.

Срочно. «Надо сделать прямо сейчас». Задача получает приоритет и проходит в работу поверх остальных.
Недолго. «Там всего на полчаса». Маленькая задача кажется безобидной, но тоже занимает место в WIP.
Ждем. Текущая задача ждет информации, согласования или другого участника. Вместо того чтобы разбираться с ожиданием, команда берет следующую.
Blocked. Задача заблокирована внешней зависимостью или проблемой и продолжает числиться в работе.

Каждое исключение выглядит разумным отдельно. В сумме они превращают WIP-лимит в цифру, которую можно постоянно обходить.

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

После введения WIP-лимита важно посмотреть, что произошло с потоком работы. Для этого сравнивают один и тот же участок процесса до и после изменения и смотрят на несколько показателей.

WIP — сколько задач одновременно находится в работе.
Throughput — сколько задач завершается за выбранный период.
Lead Time — сколько времени задача проходит от попадания в систему до завершения.
Распределение Lead Time — насколько различается время выполнения разных задач. Оно показывает предсказуемость потока.
CFD (Cumulative Flow Diagram) — показывает, сколько задач находится на каждом этапе и как это количество меняется со временем. Расширение области этапа означает накопление работы.
Blockers — причины, из-за которых задачи не могут двигаться дальше: например, ожидание информации, внешняя зависимость или техническая проблема.

СЦЕНАРИЙ №1. Например, до введения лимита на этапе «Разработка» одновременно находилось в среднем 12 задач. Команда завершала 20 задач в неделю, а средний Lead Time составлял 15 дней.

После введения лимита WIP снизился до 7–8 задач, Throughput сохранился на уровне 20 задач в неделю, а средний Lead Time сократился до 10 дней. Очередь перед следующим этапом тоже перестала расти.

Поток стал быстрее при меньшем объеме незавершенной работы.

В taskITnow, например, такую динамику можно увидеть на накопительной диаграмме (CFD). Она показывает, как распределяется работа между этапами процесса. Если одна из областей постепенно расширяется, стоит проверить причину накопления работы на этом этапе.

СЦЕНАРИЙ №2. WIP снизился с 12 до 7 задач, команда стала завершать 12 задач в неделю, а Lead Time почти не изменился. В такой ситуации команда просто работает с меньшим количеством задач, сохраняя прежнюю скорость прохождения работы.

Поэтому важно смотреть на распределение времени выполнения. Если одни задачи завершаются за три дня, а другие идут месяц, среднее значение мало описывает реальный поток. Если большинство задач укладывается примерно в один диапазон, сроки становятся более предсказуемыми.

В taskITnow это можно посмотреть с помощью спектральной диаграммы: она показывает распределение задач по времени выполнения и помогает увидеть разброс сроков.

После введения WIP-лимита можно задаться такими вопросами:

— WIP снизился?
— Throughput сохранился?
— Lead Time сократился и стал более предсказуемым?
— Очереди и блокировки уменьшились?

Если изменения идут в эту сторону, лимит помогает управлять потоком. Если WIP снизился вместе с Throughput или время прохождения осталось прежним, стоит искать причину глубже: возможно, ограничение установлено не на том этапе или проблема находится в самом процессе.

WIP-лимит — управленческое решение, которое проверяют на практике и корректируют по результатам.

Нет. И это важнее сказать прямо, чем делать вид, что инструмент универсален.

WIP-лимит решает конкретную задачу: не дать работе копиться в потоке быстрее, чем она завершается.

Лимит уместен, где есть поток: задачи приходят, проходят этапы и завершаются. Разработка, поддержка, согласования, производство, контент-конвейер. Чем больше участников и длиннее цепочка этапов, тем заметнее эффект.

Где он почти не работает. Там, где задача одна и длинная: исследование, сложная разработка с высокой неопределенностью, творческая работа, которую сложно разбить на последовательные шаги. Здесь WIP и так равен единице или двум, и ограничивать особенно нечего.

Где он вредит. Там, где его вводят ради цифры. Если команда не понимает, зачем нужен лимит, и не договорилась о правиле «стоп», он превращается в формальность: его либо обходят, либо перестают замечать.

Лимит не заменяет приоритеты. Если команда ограничила WIP, но выбрала не те задачи, она просто аккуратнее делает не то. Сначала нужно понять, что важно, потом — сколько этого держать в работе.

— «Начать нельзя, закончить»
— «Начать, нельзя закончить»

Заголовок этой статьи читается двояко. Выбор, где поставить запятую, — это и каламбур, и развилка, на которой каждый день оказываются человек, команда, целые компании: начать новое или наконец закончить то, что уже начал?

WIP-лимит — один из инструментов, помогающих поставить запятую в правильном месте.

А где сегодня запятую поставите вы?