Когда lead time фичи проседает на 40%, инциденты в проде растут втрое, а инженеры формально работают по 50–60 часов в неделю, проблема уже не в «низкой скорости команды». Это перегрузка IT-команды в чистом виде: задач больше, чем система способна переварить без брака, авралов и выгорания. Для российских команд с замороженным наймом история болезненно узнаваемая: ресурсов не добавят, а сроки никто не сдвинет.
Об этом пишет Habr / Менеджмент в колонке независимого эксперта по IT и ИБ Андрея Бирюкова. На примере условной компании «ФинТех» он разбирает типичный сценарий: три продуктовые команды по 6–8 разработчиков, годовой план на 120 крупных фич, мелкие доработки сверху и увесистый техдолг внизу. Первые полгода система еще держится, а к девятому месяцу начинает разваливаться: скорость выпуска падает, горячих инцидентов становится больше, два ключевых разработчика увольняются из-за выгорания, а финансовый блок отвечает IT-директору предсказуемо: бюджет на найм заморожен до следующего финансового года.
Главная мысль здесь неприятная, но полезная для менеджмента: команда тонет не потому, что «разработчики стали хуже», «процессы недокручены» или «мешает техдолг». Все это, по версии автора, уже последствия. Корень проблемы в другом: входящий поток задач стабильно превышает реальную пропускную способность разработки. В его примере команда способна обрабатывать 10 условных юнитов работы за спринт, а на вход получает 18–20 юнитов плюс еще семь «пожаров». Разрыв закрывается привычным русским способом: бесплатными переработками, ростом незавершенной работы и деградацией качества. На короткой дистанции это выглядит как самоотверженность. На длинной превращается в управленческий саботаж собственными руками.
Интуитивная реакция руководства в такой момент почти всегда одинакова: давайте еще сильнее ускоримся. Докрутим CI/CD, автоматизируем ревью, перепишем мониторинг, построим идеальный процесс. Но именно здесь перегрузка IT-команды и становится ловушкой. У людей, которые уже работают на износ и живут в постоянных переключениях, нет запаса на «ускорение через улучшения». В результате даже правильные инженерные инициативы превращаются в дополнительную нагрузку. Автор предлагает неприятное, но логичное лекарство: не ускорять поток, а на 10 рабочих дней остановить поступление новых задач. Формула жесткая: никакие новые фичи, доработки и запросы бизнеса не принимаются; исключение только для блокирующих багов в основном пользовательском сценарии. Все остальное уходит в бэклог с пометкой о заморозке до конца моратория.
Такой Stop the Line автор предлагает продавать не как «команде нужен отдых», а как разговор о рисках и деньгах. Аргумент звучит просто: за две недели бизнес не получит новых фич, зато избежит сценария, в котором через три-четыре месяца не получит вообще ничего, потому что команда окончательно выгорит, а ключевые инженеры уйдут. Для IT-директора это важный сдвиг роли. В этот момент он нужен не как человек, который лучше всех понимает в пайплайнах и логах, а как переговорщик, способный связать техническую перегрузку с прямыми последствиями для бизнеса. И это, пожалуй, самая трезвая часть всей конструкции: если поток работы не контролируется на входе, никакая героика внутри команды уже не спасает.
При этом двухнедельный мораторий у Бирюкова — не отпуск под видом ретроспективы. Он предлагает четыре конкретных направления работ. Первое: добить незавершенку и закрыть до 80% уже начатых задач, не открывая новых. Второе: выбрать три самые болезненные рутины и автоматизировать только их, без рефакторинга «всего подряд». Третье: взять три самых частых инцидента за последний месяц и для каждого написать автоматический тест, чтобы проблема не возвращалась молча. Четвертое: привести в порядок документацию по онбордингу и деплою, но без попытки за эти же две недели построить «идеальный процесс». Логика здесь взрослая: не лечить все, что болит в системе годами, а снять именно те узкие места, которые каждый день съедают часы и нервы.
В качестве примера автор приводит команду, которая тратила по четыре часа в неделю на обновление тестовых данных в dev-среде. За два дня ей удалось написать скрипт и сократить операцию до 10 минут. Экономия составила 3,5 часа в неделю уже со следующего спринта. Масштаб будто бы скромный, но в этом и ценность кейса: речь не о волшебной платформе и не о многомиллионной трансформации, а о рутине, которую можно убрать здесь и сейчас. Отсюда и еще одна практичная идея — публичный «зал славы автоматизаций», где команда фиксирует, какие рутинные операции убраны и сколько часов это вернуло в работу. В условиях, когда люди привыкли видеть только нескончаемый список задач, такой список становится редким доказательством, что усилия действительно уменьшают хаос, а не просто красиво оформлены в Jira.
Но самый важный блок начинается после моратория. Автор честно предупреждает: если не поменять правила игры, перегрузка IT-команды вернется через пару месяцев. Для профилактики он предлагает три жестких механизма. Первый — лимит WIP: не больше 3–5 задач в статусе In Progress на команду, то есть примерно по одной на разработчика, но не больше пяти одновременно. Смысл не в аскезе ради аскезы, а в снижении переключений и росте фокуса. Второй — еженедельный 15-минутный ритуал Stop the Line: если бы мораторий начинался завтра, какие три автоматизации команда сделала бы первыми. Если за месяц не реализована ни одна, это уже сигнал руководству, что система снова задыхается. Третий — правило «один входящий, один исходящий»: чтобы протащить в спринт новую крупную задачу, продакт должен убрать одну текущую в дальний бэклог. Это болезненно для бизнеса, зато быстро показывает, какие фичи действительно важны, а какие жили только потому, что никто не хотел выбирать.
Отдельно Бирюков бьет по популярной иллюзии, что новый найм всегда лечит перегрузку. Его критерий звучит почти как холодный душ: если команда уже тратит более 20% времени на переработки в среднем за месяц, новый человек не спасет, а добавит хаоса. Сначала нужно отрегулировать поток, потом думать о расширении штата, если оно вообще останется нужно. Для разработчиков это хороший аргумент против вечной корпоративной мантры «надо просто поднажать». Для продактов и IT-директоров — напоминание, что производительность падает не только от слабой дисциплины, но и от избыточного аппетита на входе. Пожалуй, главный вопрос здесь не в том, готовы ли команды к очередной автоматизации, а в том, готовы ли бизнес и менеджмент наконец признать простую вещь: у любой разработки есть предел пропускной способности, и игнорировать его дороже, чем на две недели перестать делать вид, будто конвейер бесконечный.