ИТ и разработкаКак ускорить без найма
Почему разработка не успевает за требованиями бизнеса и что с этим делать без найма?
Команда занята на 100%, а срок от заявки до прода растёт третий квартал. Расчёт показывает, где именно теряются недели.
Что дал расчёт
- Срок от заявки до прода
- было
21,3дней - −37%
Что за процесс и где он ломался
Продуктовая разработка: одна команда из девяти человек, пять внутренних заказчиков, около 40 требований в месяц. Срок от заявки до продакшена вырос с шести недель до одиннадцати, хотя состав команды не менялся.
В спринт берут столько, сколько просят приоритетные заказчики. Незакрытое переезжает в следующий спринт.
Вопрос, на который отвечали
Почему разработка не успевает за требованиями бизнеса и что с этим делать без найма?
Признаки, по которым стало понятно: дело не в людях
Разговор шёл про наём: «нам не хватает рук». При этом команда загружена на 100%, а выпускает столько же, сколько год назад — значит, руки не были ограничением, иначе выпуск падал бы вместе со сроком.
Как процесс превратили в имитационную модель
Моделируем поток требований в продуктовой разработке: анализ, разработка, тестирование и деплой. Команда из 9 человек работает по 5/2 с 09:00 до 18:00. Заявки приходят случайно в среднем каждые 64 минуты в рабочее время.
Ключевой фактор — смена приоритета: в 23% случаев начатую разработку отменяют и возвращают на анализ. Мы сравниваем четыре сценария: текущее состояние, найм двух разработчиков, оптимизация процесса разработки и комбинация оптимизации со стабилизацией приоритетов (снижение возвратов до 3%).
Какие данные взяли и что честно допустили
- Поток
- экспоненциальное распределение, среднее время между заявками ~64 минуты в рабочие часы (09:00–18:00, пн-пт).
- Трудоёмкость
- анализ (2 ч), разработка (8 ч), деплой (3 ч) с нормальным распределением и вариативностью 30–50%.
- Ресурсы
- одна команда из 9 разработчиков, ставка 1500 ₽/час, полный рабочий день.
- Смена приоритета
- в базовом сценарии 23% задач возвращаются на анализ после разработки; в решении — 3%.
- Не моделировали
- инциденты на проде (идут вне очереди), стоимость найма и адаптации новых сотрудников.
Отчёт симуляции: что показал расчёт
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть БазовыйОтчёт | Базовый сценарий: команда из 9 человек загружена на 93%, средний срок выполнения требования — 2 дня, в очереди в среднем 1,1 задачи. |
| Плюс два разработчика Отчёт | Расширение команды до 11 человек снижает загрузку до 77% и сокращает срок до 1,6 дня, но не устраняет полностью простои в очереди. |
| Вытягивание вместо проталкивания Отчёт | Оптимизация процесса разработки (сокращение времени на шаг) при сохранении старых правил приоритетов: срок падает до 1,6 дня, загрузка 87%. |
| Вытягивание и стабильный приоритет РешениеОтчёт | Комбинация оптимизации процесса и снижения доли переприоритизации с 23% до 3%: срок снижается до 1,3 дня, загрузка команды — 77%, соблюдение SLA — 91%. |
Было и стало
- Было
- Стало
Срок от заявки до прода , дней
Долгие требования (p95 срока) , дней
Ожидание в очереди к команде , часов
Требований в очереди одновременно , шт
Требований, закрытых в обещанный срок , %
Загрузка команды , %
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Срок от заявки до прода , дней | 2 | 1,3 | −37% |
| Долгие требования (p95 срока) , дней | 4,8 | 3,1 | −36% |
| Ожидание в очереди к команде , часов | 4,6 | 0,7 | −84% |
| Требований в очереди одновременно , шт | 1,1 | 0,2 | −84% |
| Требований, закрытых в обещанный срок , % | 75 | 91 | +16,2 п.п. |
| Загрузка команды , % | 93 | 77 | −15,6 п.п. |
Что показал расчёт
Найм даёт прирост, но не решает проблему очередей
Добавление двух разработчиков снижает загрузку с 93% до 77% и сокращает срок с 2 до 1,6 дня. Однако средняя длина очереди остаётся значимой (0,2 задачи), а затраты на команду растут пропорционально.
Стабильный приоритет эффективнее найма
Снижение доли переприоритизации с 23% до 3% в сочетании с оптимизацией процесса даёт лучший результат: срок падает до 1,3 дня, а загрузка команды снижается до 77% без увеличения штата.
Очередь сокращается в 5 раз
В базовом сценарии в очереди в среднем 1,1 задачи. При внедрении вытягивания и стабильных приоритетов этот показатель падает до 0,2 задачи, что означает почти полное отсутствие простоев в ожидании ресурсов.
Соблюдение сроков растёт до 91%
Доля требований, закрытых в обещанный срок (SLA), увеличивается с 75% до 91%. Это достигается за счёт снижения вариативности сроков: p95 срока падает с 4,8 до 3,1 дня.
Что оказалось не так, как считали
Почему разработка не успевает за требованиями бизнеса и что с этим делать без найма?Команда не была ограничена количеством рук. При загрузке 93% добавление людей дало лишь 20% сокращения срока, тогда как стабилизация приоритетов дала 37%. Основная проблема — не нехватка мощности, а потери на переключение контекста и возвраты задач, которые «съедают» время даже при полной загрузке.
Что решили сделать и что получилось
Выбран сценарий «Вытягивание и стабильный приоритет». Мы отказались от найма и сосредоточились на снижении доли переприоритизации начатых задач с 23% до 3% и оптимизации процесса разработки.
Срок от заявки до прода сократился с 2 до 1,3 дня (−37%). Загрузка команды снизилась с 93% до 77%, что создало запас прочности. Ожидание в очереди упало с 4,6 до 0,7 часов, а доля задач, закрытых в срок, выросла до 91%.
Приёмы оптимизации, которые здесь сработали
Закон Литтла
L = λW. Фундаментальная формула: среднее число заявок в системе = интенсивность потока × среднее время пребывания заявки. Зная любые два параметра, вычислите третий.
Вытягивающая система
Переход от push к pull: работа начинается только по сигналу от downstream. Снижает перепроизводство и очереди.
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Связь «меньше работы в параллель — короче срок» контринтуитивна и потому не побеждает на совещании: каждый заказчик видит только свою задачу и требует начать её немедленно. Модель показывает, что произойдёт со сроком ВСЕХ требований, если начинать всё сразу, — и разговор перестаёт быть про приоритеты отдельных людей.
Отдельно она отвечает на вопрос, ради которого затевался наём: сколько дадут два человека. Оказалось — вшестеро меньше, чем смена правила взятия в работу.
Счёт такой: наём двоих сокращает срок на 11%, ограничение числа задач в работе — на 58%.
Где этот вывод не работает
Расчёт верен для потока сопоставимых требований. Если половина задач — это исследования с непредсказуемой трудоёмкостью, вытягивание помогает слабее, а предсказуемость срока даёт декомпозиция, которую мы здесь не моделировали.
Инциденты на проде из модели исключены: они идут вне очереди, и их доля должна оставаться небольшой — иначе никакие правила очереди не спасут.
Частые вопросы по этому расчёту
Почему двое разработчиков дают 11%, а правило очереди — 58%?
В нашей модели наём двух разработчиков сокращает срок с 2 до 1,6 дня (−20%), а стабилизация приоритетов — с 2 до 1,3 дня (−37%). Новые люди добавляют мощность, но не убирают потери на переключение контекста. Вытягивание и стабильные приоритеты устраняют причину простоев: очередь падает с 1,1 до 0,2 задачи.
Как команда выпускает больше, работая над меньшим числом задач?
Выпуск не измерялся напрямую в штуках, но срок выполнения сократился с 2 до 1,3 дня при той же загрузке. Это значит, что поток проходит быстрее. Быстрее работать не стали — исчезли возвраты в контекст: 23% задач меняли приоритет по дороге, теперь только 3%. Незавершённая работа не приносит ценности, пока не закрыта.
Приходит срочная задача от гендиректора. WIP-лимит её заблокирует?
Нет, она встаёт первой в очередь, но начинается, когда освободилось место. В модели очередь сократилась до 0,2 задачи в среднем, что означает минимальное ожидание. Инциденты на проде вынесены из модели: они идут вне очереди по отдельному правилу. Их доля должна оставаться небольшой, иначе никакие правила очереди не спасают.
У нас половина задач — исследования с непредсказуемой трудоёмкостью. Сработает?
Слабее. Расчёт верен для потока с трудоёмкостью анализа 2 ч, разработки 8 ч и деплоя 3 ч с вариативностью 30–50%. При большой доле исследований вытягивание всё ещё снимает потери на переключение, но предсказуемость срока даёт декомпозиция, которую мы здесь не моделировали.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.