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

Мы столкнулись с этим в ИТ-подразделении из 42 специалистов: 24 бизнес-аналитика и 18 разработчиков. Подразделение обслуживало шесть бизнес-направлений и одновременно вело около 6–8 проектов. Мы перешли от Scrum к вытягивающей системе на основе Kanban. Но новая доска не была главным изменением. Поток стал управляемым после того, как мы ограничили незавершённую работу и связали планы бизнеса с реальной ёмкостью команды.

Почему бизнес стремится занять место в спринте?

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

Чем больше задач начали, тем меньше задач заканчиваем

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

Как мы определили ограничения

Сначала разделили работы на три категории по трудозатратам и срокам и выделили три зоны потока: сбор требований и подготовка технического задания; разработка после согласования требований; тестирование, документирование и выпуск.

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

Эти значения нельзя просто перенести в другую компанию. Лимит зависит от устройства команды, видов работ и фактической пропускной способности этапов.

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

WIP-лимит — не запрет для бизнеса

Если внедрить ограничение только внутри ИТ, бизнес увидит в нём ещё одну причину отказать в новой задаче. Поэтому вместе с WIP-лимитами мы изменили подход к планированию.

Три категории задач получили веса 1, 3 и 5 SP. С учётом исторической скорости, доступных специалистов, отпусков и операционной нагрузки мы рассчитывали объём SP, который могли выделить каждому бизнес-направлению на месяц. Внутри этой границы направление само выбирало наиболее важные работы.

План формировали на месяц. Каждые две недели пересматривали приоритеты. Раз в месяц анализировали показатели процесса. Разговор менялся с «возьмите ещё одну задачу» на «какая задача важнее в пределах доступного объёма». Ограничение делает цену выбора видимой.

Для чего нам были нужны Story Points

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

Результат появился не сразу

Переход проходил в 2023–2024 годах и занял около 12 месяцев: около трёх месяцев на смену системы работы, трёх на запуск и данные, шести на наблюдение и дополнительные правила.

По данным внутреннего учёта стоимость разработки одной задачи, рассчитанная через трудозатраты, снизилась на 20% при прежней численности команды. Средний срок выполнения задачи от взятия в работу до завершения сократился на 30% по сравнению с предыдущим годом. Источник — внутренний учёт задач, трудозатрат и сроков и управленческая отчётность. Независимый аудит не проводился.

Главный вывод

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

Если просто заменить Scrum-доску на Kanban-доску и продолжить брать в работу всё приоритетное, система останется прежней.

Полная версия статьи на сайте: https://koldomov.ru/articles/wip-limits-before-kanban