Почему команда с загрузкой 100% начинает работать медленнее: как ограничивать WIP

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

Почему полная загрузка не означает высокую производительность

Представим команду из четырёх человек. У каждого есть несколько активных задач, в календарях почти нет свободного времени, а на доске постоянно что-то находится в работе. По загрузке всё выглядит хорошо.

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

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

Каждое такое решение выглядит рационально на уровне одного сотрудника: зачем сидеть без дела, если можно начать что-то ещё? Но на уровне всей системы незавершённой работы становится всё больше.

Именно её количество называют WIP — Work in Progress, или объём незавершённой работы.

Бесплатная канбан-доска как способ проверить принцип WIP

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

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

Саму работу при этом можно организовать средствами Канбано:

• разделить будущие, активные и завершённые задачи по статусам;
• назначить исполнителя каждой карточке;
• поставить даты там, где срок действительно важен;
• использовать метки для разных типов работ, проектов или приоритетов;
• разбить крупную задачу на шаги с помощью чек-листа;
• прикрепить к карточке необходимые файлы и материалы;
• отфильтровать доску по исполнителю, статусу, дате или меткам и отдельно посмотреть нужный участок работы.

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

Что происходит, когда WIP растёт

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

Если одновременно в работе находится десять задач, внутри системы накоплен примерно один недельный объём работы. Если активных задач уже тридцать, а пропускная способность команды не изменилась, работы внутри системы становится примерно на три недели.

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

Эта связь описывается законом Литтла:

WIP = пропускная способность × время выполнения.

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

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

Многозадачность добавляет ещё одну потерю

Большой WIP увеличивает не только очередь. Людям приходится чаще переключаться между контекстами.

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

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

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

Поэтому ограничение WIP не означает «пусть люди работают меньше». Оно означает: пусть команда раньше заканчивает начатое, прежде чем создаёт следующую очередь работы.

WIP-лимит ограничивает не бэклог, а активную работу

Важно не путать незавершённую работу со всеми задачами команды.

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

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

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

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

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

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

Сначала посмотрите фактический объём активной работы. Допустим, у команды из четырёх человек одновременно открыто двенадцать задач.

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

После этого в течение одной-двух недель наблюдайте:

• стало ли больше завершённых задач;
• сократилось ли среднее время выполнения;
• где чаще всего достигается ограничение;
• какие задачи дольше остальных занимают место;
• стало ли больше ситуаций, когда сотрудник помогает завершить чужую работу вместо запуска своей;
• появились ли этапы, перед которыми постоянно формируется очередь.

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

Что делать, когда лимит достигнут

В этом и находится основная ценность метода.

Без WIP-лимита сотрудник видит, что его текущая задача ждёт коллегу, и открывает следующую. Система скрывает проблему внутри растущего количества работы.

С ограничением новую задачу начинать нельзя. Значит, сначала приходится посмотреть на уже начатые.

Полезная последовательность выглядит так:

• можно ли самостоятельно завершить одну из текущих задач;
• можно ли помочь коллеге довести его задачу до результата;
• можно ли снять блокирующий вопрос или ускорить проверку;
• есть ли работа, которую начали слишком рано и стоит вернуть обратно;
• только после освобождения места брать новую задачу.

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

Не превращайте лимит в формальный запрет

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

Если ограничение регулярно нарушается, это полезный сигнал.

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

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

Самое простое решение — увеличить лимит до семи. Но тогда очередь просто становится официально разрешённой.

Гораздо полезнее сначала выяснить, почему работа не выходит из этапа достаточно быстро.

Локальная эффективность может замедлять всю команду

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

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

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

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

Иногда лучший вариант — не ускорять сильный этап, а временно уменьшить количество новой работы, которую он создаёт. Освободившееся время можно использовать для подготовки будущих задач, помощи соседнему этапу или улучшения процесса.

Пример: команда делает контент

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

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

Другой вариант — договориться, что одновременно в производстве может находиться не больше шести материалов.

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

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

Цель не найти красивое число. Цель — добиться ситуации, когда результаты покидают систему быстрее, чем внутри неё накапливается новая работа.

Какие показатели смотреть после введения лимита

Для проверки достаточно трёх показателей:

• Throughput — сколько задач команда завершает за период;
• Cycle time — сколько времени проходит от начала задачи до её завершения;
• WIP — сколько задач одновременно находится в активной работе.

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

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

Сотрудники при этом могут выглядеть менее «загруженными». Это нормально, если система стала быстрее доводить задачи до результата.

Когда WIP-лимиты не решат проблему

Ограничение незавершённой работы не исправит плохо поставленные задачи, неизвестные приоритеты или постоянную зависимость от недоступного внешнего согласования.

Но оно сделает эти проблемы заметнее.

Если команда дошла до лимита в пять активных задач, а четыре из них стоят из-за клиента, запуск ещё десяти задач не исправит ситуацию. Придётся менять правила согласования, сроки ответа или способ формирования очереди.

Именно поэтому WIP-лимит иногда сначала вызывает дискомфорт. Он перестаёт позволять маскировать системную проблему новой работой.

Хорошее ограничение WIP не заставляет людей физически работать быстрее. Оно меняет другое: вместо максимального количества начатой работы команда начинает оптимизировать количество законченной. Для большинства проектов именно это и имеет значение.