Команда из 12 разработчиков в KT-Team закрывала 8 задач за спринт при среднем Cycle Time больше 20 дней. После введения WIP-лимитов — 11 задач за спринт, Cycle Time 10 дней. Люди стали работать меньше сверхурочно, а выпускать больше. Парадокс? Нет — математика потока.
В большинстве IT-команд России и СНГ Flow Efficiency не превышает 15%. Из 10 рабочих дней задача находится в активной работе меньше полутора. Остальное время она стоит — ждёт ревью, ждёт следующего разработчика, ждёт ответа от заказчика. Согласно исследованию 150+ команд РФ/СНГ 2025 года, команды с WIP-лимитами повышают этот показатель до 45–70%.
Причина низкой эффективности потока — не ленивые разработчики и не плохие менеджеры. Слишком много задач в работе одновременно. Каждая конкурирует за внимание, каждая создаёт очередь ожидания. Дальше — как это лечится и почему лечение требует точной дозировки.
Flow Efficiency 15%: что это говорит о вашей системе, а не о людях
Flow Efficiency — отношение времени активной работы над задачей к общему времени её нахождения в системе, умноженное на 100%. Задача взята в работу 10 дней назад, но реально над ней работали 1,5 дня? Flow Efficiency = 15%.
Низкий показатель — диагностика системы, не оценка людей. Если задача 85% времени стоит в очереди, значит, в системе слишком много параллельной работы, и каждая задача ждёт, пока освободится нужный человек или колонка. Delivery Flow Efficiency — процент времени в активных статусах работы (за вычетом блокеров) к общему Delivery Cycle Time. Чем выше WIP — тем длиннее очереди, тем ниже показатель.
Типичный диапазон без лимитов: 15–25%. С лимитами — 45–70%.
Разница не в том, что люди начинают работать усерднее. Задачи перестают простаивать. Цифра 15% — отправная точка и сигнал: система перегружена WIP, и есть конкретный рычаг для улучшения. Следующий вопрос логичный: почему именно параллельные задачи убивают эффективность потока?
Пять задач одновременно — это не пятикратная скорость, а работа вхолостую
Есть распространённое управленческое заблуждение: чем больше задач в работе — тем больше шансов, что хоть что-то завершится быстро. На практике всё наоборот.
Когда разработчик переключается между пятью задачами, он не работает над пятью задачами одновременно. Он работает над одной, тратя время на вход в контекст четырёх остальных. Gerald Weinberg в книге Quality Software Management показал, что при пяти параллельных проектах потери на переключение контекста достигают 75% рабочего времени. При двух параллельных задачах потери относительно небольшие — около 20%. При пяти — Kanban.club описывает это как работу «вхолостую»: человек занят, устаёт, но реальный прогресс минимален.
Потери нелинейны. Это важно.
Здесь же стоит упомянуть концепцию Slack Time — осознанного буфера в загрузке команды. Команда, загруженная на 100%, не имеет возможности реагировать на блокеры, срочные задачи или технический долг. Любой неожиданный запрос ломает весь план. Полная загрузка выглядит эффективно на бумаге, но убивает гибкость: когда каждый слот занят, даже пятиминутный блокер создаёт каскад задержек по всему потоку.
WIP-лимит защищает продуктивность, а не ограничивает её. Он не заставляет людей работать меньше. Он заставляет систему работать так, чтобы каждая задача двигалась быстрее от старта до финиша.
Это напрямую связано со статьёй о перфекционизме и выгорании в команде: постоянное переключение между задачами — один из главных триггеров выгорания, причём незаметный. Человек «занят», но не чувствует прогресса.
Формула расчёта WIP-лимита: от «среднее +20%» до лимитов по ролям
Универсальной формулы не существует. Kaiten прямо указывает: копирование лимитов из другой команды малоэффективно — у вас другая структура, другие задачи, другая скорость. Есть проверенный алгоритм старта, который работает как итерация, а не как разовая настройка.
Шаг первый — замерить текущую реальность
В течение 2–3 недель фиксируйте, сколько задач одновременно находится в колонке «В работе» на каждый день. Считайте среднее. Многие команды думают, что у них 3–4 задачи на человека, а по факту оказывается 8–10.
Шаг второй — установить стартовый лимит с запасом
Стартовый лимит = среднее количество задач в работе +20%. Если за три недели наблюдений в колонке «В работе» в среднем было 7 тикетов — ставьте лимит 8–9.
Почему не сразу жёстко? Потому что резкое снижение WIP создаёт стресс и сопротивление. Команда видит, что задачи «не помещаются», начинает обходить лимиты или теряет доверие к инструменту. Мягкий старт даёт время адаптироваться и начать видеть узкие места, не создавая ощущения принуждения. Это критически важно: лимит, который команда саботирует, хуже, чем отсутствие лимита.
Шаг третий — снижать на 1 каждые 1–2 недели
Команда привыкла к лимиту, Cycle Time начал снижаться — можно «затянуть» на одну задачу. Снизили с 9 до 8 — смотрите на Cycle Time через две недели. Снижается — хорошо. Растёт или стабилизировалось — это и есть ваш оптимум.
Лимиты по ролям — не по колонкам
Устанавливать единый лимит на всю колонку — грубый инструмент. Точнее работать по ролям. KT-Team в своём кейсе использовали следующие ориентиры: разработчик — 2–3 задачи, QA — 1–2.
Почему QA нужен более жёсткий лимит? Тестирование по природе последовательно: нельзя нормально тестировать шесть фич одновременно, переключаясь между ними. Один баг в одной фиче требует полного контекста. QA с лимитом 1–2 завершает проверку быстрее и с меньшим количеством пропущенных дефектов, чем QA с лимитом 5–6, который «держит в голове» несколько продуктовых веток. Для дизайнеров и аналитиков ориентир похожий: 2–3 задачи.
Расчёт лимитов по ролям — первичная форма планирования пропускной способности. Прежде чем нанимать нового QA или разработчика, стоит проверить, не решается ли проблема снижением WIP на существующих ролях. Нередко команда из 12 человек с лимитом 2–3 на разработчика закрывает столько же задач, сколько команда из 15 без лимитов — просто за счёт устранения потерь на переключение контекста.
Кейс KT-Team: как 12 разработчиков сократили Cycle Time вдвое
До внедрения WIP-лимитов команда из 12 разработчиков (продуктовая разработка, B2B-сегмент) работала в режиме, знакомом многим: средний WIP около 15 задач на человека, Cycle Time больше 20 дней, постоянные переработки и нарастающее выгорание. Задачи технически «делались», но закрывались медленно — слишком много всего было в работе одновременно.
Решение было прямолинейным: ввели лимиты по ролям — 2–3 задачи на разработчика, 1 на QA. Блокеры вынесли в отдельную колонку, чтобы они не засоряли «В работе» и были видны сразу. Начали отслеживать Lead Time и Throughput как основные метрики здоровья потока.
Результаты, зафиксированные в кейсе KT-Team, оказались контр-интуитивными для тех, кто ещё не работал с лимитами:
- Throughput вырос с 8 до 11 задач за спринт — плюс 35%
- Cycle Time сократился вдвое: с 20+ дней до 10
- Flow Efficiency поднялась с 25% до 53%
- Переработки снизились на 60%
Рост пропускной способности произошёл при снижении нагрузки на людей. Команда стала закрывать больше задач, работая меньше параллельно. «Делать меньше одновременно = завершать больше» — это измеримый эффект, а не управленческая метафора.
Снижение overtime на 60% — индикатор того, что система перестала работать за счёт людей. Раньше переработки компенсировали неэффективность потока. После внедрения лимитов компенсировать стало нечего.
Контр-интуитивный вывод: слишком низкий WIP-лимит вреднее, чем его отсутствие
Большинство статей о WIP-лимитах заканчиваются на «внедряйте, и будет хорошо». Есть сторона, о которой говорят редко.
Представьте: команда из пяти разработчиков ставит лимит 2 на колонку «В работе». Двое работают. Трое ждут, пока освободится слот. Задачи не двигаются — не потому что их не делают, а потому что система искусственно простаивает. Через неделю команда раздражена, лимиты отменяют, и к ним больше не возвращаются.
ScrumTrek формулирует это точно: для каждой системы существует оптимальное значение WIP вблизи «границы насыщения». Выше — система перегружена. Ниже — система недогружена и простаивает. Без мониторинга инструмент дискредитирует себя быстрее, чем успевает принести пользу.
Kanban Guide 2025 вводит для этого понятие WIP-долга: разница между текущим WIP и установленным лимитом. Если лимит превышен, команда осознанно фиксирует «долг» и не берёт новые задачи, пока он не погашен. Это гибче, чем жёсткая блокировка: система сигнализирует, но не останавливается принудительно. Именно такую философию описывает Kanban Guide 2025 — «свобода выбора механизма» ограничения, а не единственно верный способ его реализации.
Лимит превышен — это данные, а не нарушение. Вопрос в том, что команда делает с этими данными дальше.
Как диагностировать узкие места до того, как сорвётся дедлайн
Четыре инструмента в связке дают раннее предупреждение о перегрузке за 1–2 недели до реального срыва.
Cycle Time — время от начала работы над задачей до её завершения. Если этот показатель начинает расти, значит, WIP слишком высок: задачи берутся быстрее, чем завершаются, и очереди удлиняются. Cycle Time растёт постепенно, и именно это делает его хорошим ранним индикатором.
Throughput — количество задач, завершённых за единицу времени (обычно за спринт или неделю). Если WIP растёт, а Throughput падает или стагнирует — система перегружена. Парадокс: больше задач в работе = меньше задач завершается.
Flow Efficiency ниже 20% — сигнал, что задачи проводят большую часть времени в ожидании, а не в работе. Это прямое следствие избыточного WIP.
Cumulative Flow Diagram (CFD) — визуализация, которая показывает накопление задач на каждом этапе. Если полоса одной колонки расширяется — там формируется затор. CFD делает узкое место видимым за несколько дней до того, как оно отразится на Cycle Time.
Это стартовый диагностический набор, не исчерпывающий. Monte Carlo симуляции, контрольные карты и другие инструменты добавляются по мере зрелости процесса.
Практика мониторинга: жёлтый флаг, когда колонка заполнена на 80–99% от лимита, красный — при 100% и выше. Пересматривайте лимиты каждые 2–4 недели на основе этих сигналов.
В Shtab эти сигналы встроены в интерфейс: при превышении лимита цифра на колонке подсвечивается красным — мягкая сигнализация, которая не блокирует перемещение карточек, а информирует менеджера в момент принятия решения. Лимит устанавливается нажатием на число возле названия столбца. Философия та же, что в Kanban Guide 2025: как использовать лимит — решает команда, исходя из своих процессов. Подробнее о настройке WIP-лимитов в Shtab.
Если вы ещё выбираете между Kanban и другими подходами к визуализации работы, статья «Диаграмма Ганта vs Kanban» поможет разобраться, когда какой инструмент уместен.
Почему пересмотр лимитов каждые две недели важнее их первоначальной установки
Команды, которые один раз настраивают WIP-лимиты и забывают о них, теряют значительную часть эффекта. Лимит — живой параметр, который должен следовать за изменениями в команде и потоке работы.
Ритуал пересмотра выглядит просто. На ретроспективе или отдельной короткой встрече раз в две недели команда смотрит на два числа: Cycle Time и Throughput. Если Cycle Time снижается — можно попробовать уменьшить лимит ещё на одну задачу. Если растёт — ослабить. Если стабилен — оставить как есть и наблюдать ещё цикл.
Кейс Directum иллюстрирует итеративный подход. Стартовый лимит установили как среднее +20% (8–9 задач), затем снижали на одну каждые 1–2 недели. Итог через несколько месяцев: завершённость задач выросла на 45%, Cycle Time сократился на 35%, перегрузки снизились на 55%. Эффект накапливался постепенно — не за счёт одного правильного числа, а за счёт регулярной калибровки.
Kanban Guide 2025 дополняет этот ритуал практическим инструментом: если лимит превышен, команда фиксирует WIP-долг и не берёт новые задачи, пока он не погашен. Это превращает превышение лимита из нарушения в управляемое решение с явными последствиями — и именно это стоит обсуждать на встрече по пересмотру, а не только сухие цифры метрик.
В Shtab ритуал пересмотра можно организовать без переключения между инструментами: одна вкладка показывает текущий WIP по исполнителям с группировкой, другая — просроченные задачи и динамику колонок. Команда Directum сократила время подготовки к ретро с 40 минут до 10 — за счёт единого дашборда с метриками в одном месте.
FAQ
Что такое WIP-лимиты в Канбан?
WIP-лимит (Work In Progress Limit) — ограничение на количество задач, которые одновременно находятся на определённом этапе процесса. Цель — не допустить накопления незавершённой работы, сделать узкие места видимыми и сохранить предсказуемый поток. Задача не берётся в работу, пока не освободится слот — это и есть вытягивающая система.
Нужно ли в Kanban устанавливать лимиты по задачам?
Kanban Guide 2025 делает ограничение WIP обязательным — без него это просто визуализация на доске, а не Kanban. При этом документ оставляет свободу выбора механизма: ограничивать можно по количеству задач, по часам или по другому критерию, который соответствует контексту команды.
Что делать менеджеру, если лимит постоянно нарушается?
Постоянное превышение — сигнал, что лимит установлен слишком жёстко, либо в системе есть блокеры, которые не позволяют завершать задачи. Первый шаг — вынести блокеры в отдельную колонку и посмотреть, что именно мешает. Второй — временно поднять лимит на 1–2 задачи и снижать снова, когда причина устранена.
Как часто нужно пересматривать WIP-лимиты?
Каждые 2–4 недели, ориентируясь на Cycle Time и Throughput. Если Cycle Time стабильно снижается — можно уменьшить лимит на одну задачу. Если растёт — ослабить. Лимит, установленный однажды и никогда не пересматриваемый, перестаёт быть инструментом управления и становится просто числом на доске.
Попробуйте прямо сейчас: посчитайте средний WIP по самой загруженной колонке за последние две недели, установите лимит «среднее +20%» и сравните Cycle Time через два спринта. Итеративный подход здесь работает лучше, чем поиск идеального числа с первого раза.