Команда KT-Team из 12 разработчиков закрывала 8 задач за спринт. Средний Cycle Time — больше 20 дней. Люди работали, доска была заполнена, переработки стали нормой. Проблему искали в мотивации, в квалификации, в процессах планирования. Нашли в другом: в каждый момент времени один разработчик вёл в среднем 15 задач одновременно.
После того как ввели WIP-лимиты по ролям — около 2–3 задач на разработчика и 1 на QA — команда стала закрывать 11 задач за спринт, а Cycle Time упал до 10 дней. Никого не уволили, не наняли, процессы разработки не меняли. Изменилось одно: количество задач, которые можно было держать в работе одновременно.
Проблема была в количестве одновременно открытых задач. Точка.
Руководитель, у которого команда тонет в параллельных задачах, имеет дело с проблемой потока. WIP-лимиты решают именно её. В этой статье — три формулы расчёта лимитов с конкретными числами, два реальных кейса с метриками до и после, и чек-лист пересмотра процессов, который помещается в одну встречу. Если вы ещё выбираете между Kanban и другими подходами, посмотрите сравнение диаграммы Ганта и Kanban — там разобрана логика выбора.
Почему 15 задач на человека — это не продуктивность, а иллюзия занятости
Откройте Kanban-доску типичной команды в середине спринта. В колонке «In Progress» — 40 карточек. В «Review» — ещё 12. Ни одна из них не движется заметно к «Done». Все заняты, все работают. Но ничего не заканчивается.
Это пробка. Механика та же, что на шоссе: чем больше машин въезжает одновременно, тем медленнее едут все. Каждая новая задача, которую человек берёт в работу, не добавляет скорости — она увеличивает среднее время ожидания для всех остальных задач в очереди. Atlassian фиксирует это как базовый закон потока: чем больше незавершённой работы в системе, тем выше lead time и ниже пропускная способность.
Вспомните кейс KT-Team из начала статьи. 15 задач на человека выглядели как высокая загрузка, а по факту были постоянным контекст-свитчингом: разработчик бросал задачу A, переключался на задачу B по просьбе менеджера, затем возвращался к A, обнаруживал, что забыл контекст, тратил время на «разгон» — и так по кругу. Переработки были следствием потерь на переключение, а не объёма работы.
Здесь работает закон потока: система с высоким WIP предсказуемо производит долгий Cycle Time. Задачи копятся в статусе «В работе», создают ощущение прогресса — и почти не добираются до «Done». Управление потоком строится на ограничении одновременно открытых задач, а не на ускорении людей. О том, как при этом не создавать давления на команду, — в материале о дедлайнах без давления.
Что такое WIP-лимит и почему без него Kanban-доска — просто стикеры на стене
WIP-лимит — это максимальное количество задач, которое может одновременно находиться на определённом этапе работы. Если в колонке «Разработка» стоит лимит 6, а там уже 6 карточек — новую задачу туда не берут, пока одна из текущих не перейдёт дальше.
Kanban Guide 2025 фиксирует прямо: ограничение WIP является обязательным элементом Kanban. Без него доска остаётся визуализацией, но не системой управления потоком. Для руководителя это разграничение принципиально: доска без лимитов показывает, что происходит, но не управляет тем, как это происходит.
Разница в поведении команды ощутима. Доска без лимита: задачи берутся по мере поступления запросов, «In Progress» пухнет, узкие места невидимы, каждый занят, ничего не заканчивается. Доска с лимитом: новая задача не берётся, пока текущая не завершена. Если колонка заполнена — это сигнал, что где-то затор. Команда видит проблему и разбирается с ней, вместо того чтобы накапливать новые задачи поверх незакрытых.
Аналогия с конвейером здесь точна. Если на сборочной линии один стол завален деталями, которые ждут следующего этапа, — добавление новых деталей на предыдущий стол ничего не ускорит. Нужно разобраться с тем, что застряло. WIP-лимит заставляет команду разбираться с затором, а не прятать его под новыми задачами. Начатое должно завершаться раньше, чем берётся следующее.
Как рассчитать WIP-лимит: три подхода разной точности
Единственно правильной формулы не существует. Есть три подхода, и выбор зависит от того, насколько у команды уже собрана статистика по потоку. Перед любым расчётом — обязательное окно наблюдения: 2–3 недели ежедневного мониторинга фактического WIP. Формулы — стартовая точка, а не догма.
Подход 1 — «Среднее + 20%» (быстрый старт)
Формула: стартовый лимит = среднее количество задач в работе за 2–3 недели × 1,2.
Пример: если за три недели в колонке «In Progress» в среднем было 7 задач — лимит ставится 8–9. Логика: лимит немного выше среднего, чтобы не создавать немедленного шока для команды, но уже задаёт верхнюю границу.
Когда применять: команда только начинает работать с WIP-лимитами и статистики по Cycle Time нет или она ненадёжна.
Подход 2 — «Среднее минус 1–2» (мягкое давление)
Kanban Guide 2025 рекомендует ставить лимит на 1–2 единицы ниже среднего фактического WIP. Если в среднем в работе 9 задач — лимит 7–8.
Логика: лимит сразу убирает часть перегрузки, не дожидаясь «идеального» расчёта. Небольшое давление заставляет команду завершать задачи быстрее, прежде чем брать новые.
Когда применять: есть хотя бы 2–3 недели наблюдений, команда понимает принцип WIP-лимитов и готова к небольшому дискомфорту на старте.
Подход 3 — «1,5–2 задачи на человека» (ролевой расчёт)
Эмпирическое правило: WIP per person = 1,5–2. Для команды из 5 разработчиков лимит на колонку «In Progress» — 8–10 задач. Для узких колонок (Review, QA, согласование) лимит ставят ещё ниже — 3–5 задач — чтобы быстрее выявлять узкие места именно там.
Когда применять: команда работает с Kanban несколько месяцев, есть понимание ролей и типичной загрузки по этапам.
| Подход | Формула | Пример (средний WIP = 8) | Когда использовать |
|---|---|---|---|
| Среднее + 20% | Среднее × 1,2 | Лимит 9–10 | Старт, нет статистики |
| Среднее − 1–2 | Среднее − 1–2 | Лимит 6–7 | Есть наблюдения, нужно давление |
| 1,5–2 на человека | Кол-во людей × 1,5–2 | 5 чел. → лимит 8–10 | Зрелый процесс, ролевая настройка |
Кейс «Отдел согласований»: WIP со 156 до 40 — lead time с 19 дней до 5
Отдел из 8 сотрудников обрабатывал входящие заявки. Средний WIP на момент старта — 156 задач. Lead Time — 19 дней. Люди не простаивали: каждый вёл в работе почти 20 задач одновременно.
Установили WIP-лимит 40 — примерно 5 задач на человека. Через месяц Lead Time составил 5 дней, производительность выросла на 15%.
Механика здесь не в том, что люди стали работать быстрее. Лимит убрал из активной работы 116 задач — они ушли в очередь, а не висели одновременно на каждом сотруднике. Каждая оставшаяся в работе заявка стала получать внимание раньше, не дожидаясь, пока коллега разберётся с другими девятнадцатью своими задачами.
Главный вывод по итогам месяца: команду не ускорили — убрали очередь, которая мешала работе. Задачи перестали теряться в статусе «В работе», стало видно, какие заявки реально застряли и почему.
Это показательный пример для руководителя, который думает, что проблема в скорости команды. Чаще проблема в том, что система одновременно держит слишком много открытых задач, и каждая из них ждёт внимания, размазанного по всем остальным. WIP-лимит расчищает очередь.
Если задачи при этом слишком крупные и их сложно завершать в пределах одного цикла, помогает декомпозиция: разбивка на подзадачи позволяет точнее считать фактический WIP и видеть реальный прогресс.
Слишком жёсткий лимит убивает поток не хуже, чем его отсутствие
Руководители, которые впервые узнают про WIP-лимиты, нередко ставят их слишком низко. Логика понятна: если 15 задач — плохо, то 3 — хорошо. На практике это ломает работу.
Типичный сценарий: лимит на «In Progress» поставили 1 задача на человека. QA-инженер завершил тестирование и ждёт следующей задачи из «Review». Но разработчик не может положить туда новую задачу — его слот в «In Progress» занят задачей, которая застряла в ожидании ревью. Доска замерла. Люди сидят без работы — задачи есть, но лимит не оставляет пространства для манёвра.
Kaiten прямо предупреждает: WIP-лимиты не должны быть маленькими. Их размер зависит от целей оптимизации, и универсальной формулы нет — лимиты подбирают эмпирически по данным потока. Kanban Guide 2025 отказался от жёсткой рекомендации по числу и предлагает командам самим выбирать механизм ограничения.
Рабочий критерий: если команда регулярно простаивает из-за лимита, а не из-за реальных блокеров в задачах — лимит слишком низкий. Простой из-за ожидания освобождения слота — это паралич, а не управляемое напряжение.
Цель WIP-лимита — создать управляемое давление, при котором команда фокусируется на завершении, а не накапливает незакрытые задачи. Поток должен стать предсказуемым, а не остановиться.
Цветовые флаги и WIP-долг: как управлять лимитом, а не просто его установить
Поставить лимит — половина работы. Вторая половина — видеть сигналы перегрузки раньше, чем ситуация станет критической.
Практика цветовых флагов даёт руководителю простой триггер. Жёлтый флаг загорается, когда колонка заполнена на 80–99% от лимита. Красный — при 100% и выше. Жёлтый — это предупреждение, а не авария: QA становится узким местом, стоит перераспределить ресурсы или проверить, что именно застряло. Ждать красного не нужно.
WIP-долг считается просто: текущий WIP минус WIP-лимит. Если лимит колонки «Разработка» равен 4, а фактически там 7 задач — WIP-долг равен 3. Пока долг не обнулится, команда замораживает набор новой работы в эту колонку. Это механизм восстановления предсказуемости потока.
Пересматривать лимиты нужно каждые 2–4 недели, ориентируясь на два сигнала: Cycle Time и Throughput. Cycle Time вырос — лимит, вероятно, слишком высок. Throughput упал при нормальном Cycle Time — возможно, лимит слишком низкий или есть системный блокер.
В Shtab эта логика реализована на уровне колонок Kanban-доски. Допустим, в колонке «Тестирование» лимит — 4 задачи. Когда туда попадает пятая, система подсвечивает перегрузку, и руководитель видит затор до того, как он превратится в сорванный дедлайн. По сути, это те же цветовые флаги — только без ручного подсчёта карточек каждое утро. Если вы подбираете инструмент с поддержкой WIP-лимитов, посмотрите обзор приложений для планирования задач — там сравнение функциональности.
Один лимит на колонку больше не работает: что пришло на смену в 2025 году
Практика WIP-лимитов за последние два года заметно усложнилась. Один лимит на колонку — грубый инструмент, который работает на старте, но перестаёт справляться, когда в одной колонке конкурируют задачи разного типа.
Конкретный конфликт: срочная задача (expedite) и плановая задача занимают один слот в «In Progress». Команда вынуждена выбирать — взять срочное и нарушить лимит или соблюдать лимит и задержать критичную задачу. Ни то ни другое проблему не решает.
Kanban Guide 2025 фиксирует сдвиг к гибким WIP-лимитам, завязанным на контекст потока: класс обслуживания, стадию, возраст задачи (age of work item), наличие блокеров. Команды всё чаще используют лимиты на swimlane или class of service, на конкретного человека, token-kanban — несколько управляемых ограничителей вместо одного числа на доске.
Для руководителя это означает следующее: если процесс зрелый и один лимит на колонку уже создаёт конфликты — пора вводить разные ограничения для разных классов задач. Срочные задачи получают отдельный swimlane со своим лимитом, плановые — свой. Поток становится управляемым на уровне типов задач, а не только на уровне колонок.
Управление входящим потоком до того, как задачи попадают на доску, разобрано в материале о бэклоге проекта.
Чек-лист: пересмотр WIP-лимитов за 30 минут
WIP-лимиты нужно пересматривать каждые 2–4 недели. Вот конкретный алгоритм для одной встречи с командой или тимлидом.
- Собрать данные. Средний Cycle Time и Throughput за последние 2–4 недели. Если доска ведётся в Shtab, Cycle Time и загрузку по колонкам можно отслеживать без ручного подсчёта — данные уже в системе.
- Сравнить с предыдущим периодом. Cycle Time вырос — лимит, вероятно, слишком высок. Throughput упал — искать блокер или пересматривать лимит вниз.
- Проверить частоту превышений. Сколько раз за период WIP-долг был больше нуля? Если больше трёх раз за две недели — лимит систематически нарушается.
- Оценить простои. Были ли случаи, когда люди ждали освобождения слота, а не завершения задачи? Если да — лимит может быть слишком низким.
- Найти узкое место. Какая колонка чаще всего была в красной зоне (≥ 100%)? Это и есть bottleneck текущего цикла.
- Скорректировать лимит. Сдвиг на 1–2 единицы вверх или вниз. Не больше за один цикл — иначе непонятно, что именно повлияло на результат.
- Зафиксировать решение и дату следующего пересмотра. Без этого пересмотр не станет регулярной практикой.
Какие задачи оставить в лимите, а какие отложить в очередь — разобрано в материале о приоритизации задач.
Частые вопросы о WIP-лимитах
Нужно ли в Kanban устанавливать лимиты по задачам?
Да, и это требование методологии, а не рекомендация. Kanban Guide 2025 прямо фиксирует: ограничение WIP является обязательным элементом Kanban. Без него доска показывает статус задач, но не управляет потоком — команда не получает сигналов, когда нужно остановиться и разобраться с затором.
Как WIP-лимиты помогают снизить перегрузку команды?
Проще всего увидеть это на цифрах из кейса отдела согласований:
- WIP до лимита: 156 задач → lead time 19 дней
- WIP после лимита (40 задач) → lead time 5 дней
- Производительность: +15%
Лимит запрещает брать новую задачу, пока текущая не завершена или не перешла на следующий этап. Количество одновременных переключений контекста падает, а узкие места становятся видимыми: если колонка заполнена, значит, там затор — и его нужно разобрать.
Какой WIP-лимит поставить для начала?
Зависит от зрелости процесса. Среднее + 20% — если нет статистики. Среднее минус 1–2 — если есть 2–3 недели наблюдений. 1,5–2 задачи на человека — если процесс зрелый и роли понятны. Перед расчётом обязательны 2–3 недели ежедневного мониторинга фактического WIP. Любая формула — стартовая точка, которую нужно пересматривать через 2–4 недели по данным Cycle Time.
Что делать, если команда постоянно превышает WIP-лимит?
Рассчитать WIP-долг (текущий WIP минус лимит) и заморозить набор новой работы в эту колонку, пока долг не обнулится. Дальше — разобраться в причине. Если превышение системное, возможны два сценария. Первый: лимит занижен и его нужно поднять на 1–2 единицы. Второй, более частый: есть блокер в процессе, который не даёт задачам завершаться. Блокер нужно найти и устранить — поднимать лимит в этом случае бессмысленно.
WIP-лимиты работают только в IT-командах?
Нет. Кейс отдела согласований из этой статьи — 8 сотрудников, обработка заявок, никакой разработки. Продажи, HR, юридический отдел, операционные команды — принцип работает везде, где есть входящий поток задач и несколько этапов обработки. WIP-лимит расчищает очередь и сокращает время ожидания независимо от отрасли.
Что внедрить на этой неделе
WIP-лимит — про фокус: меньше одновременно открытых задач — быстрее каждая из них доходит до завершения.
Вот что можно сделать прямо сейчас:
- Зафиксировать базовый Cycle Time команды — он понадобится через две недели, чтобы оценить эффект от лимита.
- Посчитать карточки в колонке «In Progress» на доске сегодня и повторять замер ежедневно в течение двух недель. Фиксировать в таблице: дата — количество задач в работе.
- После двух недель поставить первый лимит по формуле «среднее + 20%» и назначить дату пересмотра.
- На первом пересмотре сравнить Cycle Time с базовым и скорректировать лимит по чек-листу выше.
Первый пересмотр покажет направление: Cycle Time пошёл вниз — лимит работает, можно аккуратно снижать. Cycle Time не изменился — ищите блокер в конкретной колонке, а не двигайте лимит вслепую.