В подкасте Алекс Цыбульник и Алексей Пименов разобрали одну из ключевых, но часто непонятых практик Канбана — ограничение незавершенной работы, или WIP-лимиты (от Work in Progress).
Что такое WIP и WIP-лимит?
WIP (Work in Progress) — это количество рабочих элементов, которые одновременно находятся в процессе выполнения. Это могут быть задачи, проекты, запросы клиентов — всё, что в работе.
WIP-лимит — это искусственное ограничение количества таких элементов. Не просто «чтобы было поменьше», а с конкретной целью: улучшить поведение производственной системы. И вот здесь начинается путаница.
Частые заблуждения:
- WIP = WIP-лимит. Нет, сам по себе факт наличия элементов в работе это WIP. А лимит это способ сказать «стоп».
- Лимиты должны быть как можно меньше. Необязательно. Лимит подбирается под оптимизационную цель — например, уменьшить время производства или повысить предсказуемость.
- На человека — максимум две задачи. Это отсылка к когнитивным ограничениям, но в реальной производственной системе важен не человек, а поток работы. Подход «2 задачи на человека» не масштабируется и может мешать.
- Как найти правильный лимит?
Универсальной формулы нет. Копировать лимиты между командами гиблое дело. Рабочие ограничения находятся эмпирически, исходя из анализа потока и цели. В разных продуктах и стадиях жизненного цикла оптимальный лимит может отличаться. Где-то надо поднажать, где-то наоборот, ослабить.
Что даёт соблюдение лимитов?
На уровне системы:
- Повышается предсказуемость: становится ясно, сколько времени занимает выполнение единицы работы.
- Можно управлять временем производства и варьировать его, подбирая лимит.
- Появляется возможность анализировать: какие лимиты улучшают поток, а какие мешают.
На уровне команды и исполнителя:
- Снижается риск выгорания: человек не хватается за всё сразу, а работает по очереди.
- Появляется slack capacity — время на осмысление, обучение, улучшения.
- Повышается качество трекинга задач: если работа не двигается, она не висит в статусе In Progress «для галочки».
А если задачи сыпятся со всех сторон?
Это реальность. Один приносит задачу, второй требует срочно, третий просит «пять минуточек». Что делать:
- Завести входной буфер. Всё, что прилетает, складывается туда. Пусть полежит, пока не освободишься.
- Не бросать начатое. Новая задача — не повод ронять текущую. Если это критично нужен диалог, а не саботаж.
- Визуализировать очередь. Когда видно, сколько задач ждёт, и сколько простаивает, с руководством можно говорить на языке фактов. «Вот задача, которую вы мне дали. Она прождала X дней, потому что до этого вы дали Y и Z». Работает гораздо лучше, чем «я не успеваю».
Командный уровень и end-to-end процессы
Как подойти к WIP-лимитам на уровне команды?
Первый шаг — рассчитать текущий объем работы. Сколько задач в среднем находится в работе сегодня, вчера, неделю назад? Построив график, можно обнаружить, что команда интуитивно уже не превышает определённый порог. Причины могут быть разные:
- Руководитель или сама команда осознанно ограничивает объём.
- Продакт-менеджер оценивает загрузку и не даёт новых задач.
- У заказчика закончились задачи.
Этот порог можно зафиксировать в виде WIP-лимита — формализовать то, что и так работает. Это не вызовет сопротивления: цифра уже укладывается в привычную практику.
Как понять, что лимит стоит понижать?
Если задачи лежат долго и никто ими не занимается — значит, в системе слишком много работы. Это легко выявить на статусных встречах. По каждой задаче достаточно задать два вопроса:
- Что нужно, чтобы сдвинуть задачу дальше?
- Что было сделано с момента прошлого собрания?
Если задача давно не обновлялась значит, она простаивает. Это сигнал, что лимит превышен, и его стоит сократить.
Какие инструменты использовать?
Любой task-трекер с визуализацией. Jira, например, позволяет построить CFD (Cumulative Flow Diagram), где цветная диаграмма показывает объем незавершенной работы. Нужно понимать, где начинается и заканчивается работа команды, и смотреть на высоту «бутерброда» на графике.
А как быть с end-to-end процессом?
WIP-лимиты можно устанавливать на любом уровне зрелости. Главное понимать, где именно в цепочке возникает перегруз.
Кто отвечает за лимиты в e2e-системе:
- Если есть Service Delivery Manager — ответственность на нём.
- Если его нет — стоит ввести такого человека.
- Если культура зрелая — командная ответственность. По скраму, например, команда сама отвечает за то, чтобы всё, что взяла, было доделано. Решения могут приниматься консенсусом или голосованием.
В проектном управлении и декомпозиции
WIP-лимиты работают не только в продуктовой разработке. Проект — это набор требований, которые можно представить как «камушки» в мешке. Эти элементы проходят через стандартные этапы: анализ, разработка, тестирование.
За всё это отвечает Project Manager, и он же часто выступает как фактический Service Delivery Manager.
Зачем декомпозировать требования:
- Снижение неопределенности. Мелкие задачи проще понять и начать делать.
- Видимость прогресса. Даже если клиентская ценность ещё не достигнута, видно, что работа идёт.
- Удобство распределения. Команде проще брать в работу небольшие куски.
Но есть и тёмная сторона: потеря фокуса. Если каждый клиентский запрос разбить на 200 задач, можно годами показывать бурную активность, но не завершать ни один проект.
Как сохранить фокус?
Грамотная визуализация. Доска должна показывать не только задачи, но и к каким клиентским запросам они относятся. Тогда на статусных встречах можно отследить: мы начали распылять усилия на 10 запросов сразу и ничего не довели до конца. Это повод скорректироваться.
На каком уровне вводить лимиты: таски, сториз или эпики?
Чтобы ответить на этот вопрос, важно понимать, для кого и с какой перспективы мы хотим получить предсказуемость.
- Таски — мелкие единицы, которые может выполнить один-два человека. Лимиты на этом уровне позволяют сделать работу команды более предсказуемой, особенно если внедрять их грамотно, например, с помощью алгоритма STATIK.
- Стори — пользовательские истории, несущие ценность клиенту. Лимиты на этом уровне помогают обеспечить предсказуемость клиентского сервиса.
- Эпики — стратегические инициативы. WIP-лимиты на уровне эпиков позволяют управлять загруженностью крупных проектов и лучше видеть стратегическую картину.
С чего начать внедрение WIP-лимитов
- Определить цель. Что вы хотите улучшить: предсказуемость на уровне команды, продукта или организации?
- Оценить полномочия. Можете ли вы сами ввести лимит? Или нужно договариваться?
- Посмотреть на культуру. Есть ли поддержка и вовлечённость? Если да — можно вводить коллегиально. Если нет, возможно, придётся двигаться постепенно, от прецедентов и управленческих решений.
- Не ставить лимит ради лимита. WIP-лимит — это не обязательно маленькое число. Он должен соответствовать контексту и быть понятен участникам.
Если команда сильная, но сопротивляется — ищите совместные решения. Если люди перегружены — покажите, как лимиты помогут. Если нужен эксперимент — начните с текущего положения, легализуйте как есть и постепенно корректируйте.
Главное
WIP-лимиты — не про жёсткие рамки и контроль. Это способ сделать систему управляемой и предсказуемой. Они работают не потому, что так написано в книге, а потому что дают данные, с которыми можно работать.
Ваша команда, ваши цели — значит, и лимиты должны быть вашими. Не универсальными, а осмысленными. Иначе — просто цифры на доске
