ИТ и разработкаКак ускорить без найма
Почему разработка не успевает за требованиями бизнеса и что с этим делать без найма?
Команда занята на 100%, а срок от заявки до прода растёт третий квартал. Расчёт показывает, где именно теряются недели.
Что дал расчёт
- Срок от заявки до прода
- было
11,04,6недель−58% - Требований в работе одновременно
- было
7945шт−43% - Выпуск за месяц
- было
3142требований+35%
На потоке 504 требований в год это12,6 млн ₽в год
Что за процесс и где он ломался
Продуктовая разработка: одна команда из девяти человек, пять внутренних заказчиков, около 40 требований в месяц. Срок от заявки до продакшена вырос с шести недель до одиннадцати, хотя состав команды не менялся.
В спринт берут столько, сколько просят приоритетные заказчики. Незакрытое переезжает в следующий спринт.
Вопрос, на который отвечали
Почему разработка не успевает за требованиями бизнеса и что с этим делать без найма?
Признаки, по которым стало понятно: дело не в людях
Разговор шёл про наём: «нам не хватает рук». При этом команда загружена на 100%, а выпускает столько же, сколько год назад — значит, руки не были ограничением, иначе выпуск падал бы вместе со сроком.
Как процесс превратили в имитационную модель
В модель заложили поток требований по неделям, их разброс по трудоёмкости, состав команды, потери на переключение между задачами и вероятность смены приоритета уже начатой работы.
Ключевое, чего нет в доске задач: сколько стоит переключение. Разработчик, ведущий три задачи, не работает над ними втрое медленнее — он теряет контекст при каждом возврате.
Какие данные взяли и что честно допустили
- Поток
- 40 требований в месяц, распределение по неделям — фактическое из трекера
- Трудоёмкость
- от 8 до 90 человеко-часов, распределение восстановлено по закрытым задачам
- Потеря на переключение
- 40 минут на возврат к отложенной задаче
- Смена приоритета начатой задачи
- 23% случаев
- Не моделировали
- инциденты на проде — они идут вне очереди по отдельному правилу
Отчёт симуляции: что показал расчёт
Здесь будет живой отчёт симуляции
Расчёт по этому кейсу ещё не прогнан. После прогона сюда встанет тот же отчёт, что видит пользователь Storm: очереди, загрузка ресурсов, время цикла и стоимость одной заявки по каждому сценарию.
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть Базовый | Берём в спринт всё, что просят приоритетные заказчики |
| Плюс два разработчика | Состав команды растёт, правила прежние |
| Вытягивание вместо проталкивания | Новое требование берётся, только когда освободилось место |
| Вытягивание и стабильный приоритет | Плюс запрет менять приоритет начатой задачи |
Было и стало
- Было
- Стало
Срок от заявки до прода , недель
Требований в работе одновременно , шт
Выпуск за месяц , требований
Потери на переключение , % времени
Требований, закрытых в обещанный срок , %
Стоимость одного требования , ₽ тыс
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Срок от заявки до прода , недель | 11,0 | 4,6 | −58% |
| Требований в работе одновременно , шт | 79 | 45 | −43% |
| Выпуск за месяц , требований | 31 | 42 | +35% |
| Потери на переключение , % времени | 22 | 7 | −15 п.п. |
| Требований, закрытых в обещанный срок , % | 54 | 89 | +35 п.п. |
| Стоимость одного требования , ₽ тыс | 100 | 75 | −25% |
Что показал расчёт
Наём двух разработчиков сокращает срок на 11%, вытягивание — на 58%
Люди добавляют мощность, но не убирают очередь: новые руки так же берут в работу всё сразу и так же переключаются.
Выпуск вырос на 35% при том же составе
Не потому, что стали работать быстрее, а потому, что перестали работать над всем одновременно: исчезли потери на возврат в контекст.
Смена приоритета начатой задачи стоит дороже самой задачи
Каждая переприоритизация обнуляет накопленный контекст и отправляет работу в очередь заново — по расчёту это 23% случаев и 15 процентных пунктов потерь.
Что оказалось не так, как считали
Почему разработка не успевает за требованиями бизнеса и что с этим делать без найма?Команда не была медленной. Она была перегружена незавершённой работой: 27 требований в работе на девять человек. Срок вырос ровно во столько раз, во сколько выросла очередь, — это прямое следствие закона Литтла, и наём его не отменяет.
Что решили сделать и что получилось
Перешли на вытягивание: новое требование берётся в работу, только когда освободилось место. Порог рассчитали через Закон Литтла, механику взяли из приёма «Вытягивающая система».
Найм двух разработчиков отложили. Через квартал вернулись к вопросу уже с другой цифрой: при вытягивании та же команда закрывает 38 требований в месяц вместо 31.
Приёмы оптимизации, которые здесь сработали
Закон Литтла
L = λW. Фундаментальная формула: среднее число заявок в системе = интенсивность потока × среднее время пребывания заявки. Зная любые два параметра, вычислите третий.
Вытягивающая система
Переход от push к pull: работа начинается только по сигналу от downstream. Снижает перепроизводство и очереди.
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Связь «меньше работы в параллель — короче срок» контринтуитивна и потому не побеждает на совещании: каждый заказчик видит только свою задачу и требует начать её немедленно. Модель показывает, что произойдёт со сроком ВСЕХ требований, если начинать всё сразу, — и разговор перестаёт быть про приоритеты отдельных людей.
Отдельно она отвечает на вопрос, ради которого затевался наём: сколько дадут два человека. Оказалось — вшестеро меньше, чем смена правила взятия в работу.
Счёт такой: наём двоих сокращает срок на 11%, ограничение числа задач в работе — на 58%.
Где этот вывод не работает
Расчёт верен для потока сопоставимых требований. Если половина задач — это исследования с непредсказуемой трудоёмкостью, вытягивание помогает слабее, а предсказуемость срока даёт декомпозиция, которую мы здесь не моделировали.
Инциденты на проде из модели исключены: они идут вне очереди, и их доля должна оставаться небольшой — иначе никакие правила очереди не спасут.
Частые вопросы по этому расчёту
question
question
question
question
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.