Привет, Хабр! Меня зовут Андрей Бирюков. Я являюсь независимым экспертом в области ИТ и ИБ, преподаю в учебных центрах и пишу книги.

В нынешней экономической ситуации запрет найма — это норма. Но при этом поток задач никто снижать не собирается. В результате возникает перегрузка команды, и в этой статье мы поговорим о том, что нужно делать в подобной ситуации.

Но для начала небольшой типовой пример.

Давайте представим, что у нас имеется условная компания «ФинТех», в которой есть три продуктовые команды по 6–8 разработчиков. При этом их годовой план содержит 120 крупных фич, множество мелких доработок и «килобайты» технического долга.

Первые 6 месяцев — обычный ритм: иногда переработки, иногда спокойно. К 9-му месяцу наступает полный коллапс:

• Скорость выхода фич (через lead time) упала на 40% относительно начала года.

• Инженеры работают по 50–60 часов в неделю формально, но эффективно — 30 (бесконечные переключения, авральные изменения, синхронизации).

• Количество горячих инцидентов в проде выросло в 3 раза.

• За месяц по причине выгорания уволились два ключевых разработчика.

В такой ситуации ИТ‑директор идёт к финансовому за разрешением на наём и получает ответ:

«Бюджет заморожен до следующего финансового года. Живите с тем, что есть, но дедлайны не меняются.»

Вполне логично, что в такой ситуации ИТ‑директор первым делом попытается автоматизировать и ускорить всё, что только можно: CI/CD, мониторинг, ревью кода и так далее. Результатом такого подхода становится то, что команды закапываются ещё глубже, потому что у них нет времени на автоматизацию.

Для начала давайте выделим главный дефект, который обычно игнорируют. В данной ситуации входящий поток задач превышает пропускную способность системы. То есть не «разработчики плохие», не «процессы слабые», не «техдолг мешает». Всё это — следствие проблемы, а корень кроется в том, что бизнес и продакт‑менеджмент продолжают лить задачи в переполненную систему, ожидая, что она чудесным образом начнёт переваривать больше.

Вот некоторые количественные характеристики для такой ситуации: пропускная способность команды — это 10 условных «юнитов работы» в спринт, при этом входящий поток — 18–20 юнитов + 7 пожаров. В результате разрыв компенсируется выгоранием (скрытые часы, бесплатные переработки), ростом незавершёнки (WIP — work in progress) и падением качества (фикс‑фиксов‑фиксов).

Когда найм запрещён, стандартный рычаг («добавим людей») недоступен. Значит, нужно управлять входом.

“Stop the Line”

Теперь давайте поговорим о том, что же можно сделать в подобной ситуации. Общая идея у нас будет следующая: если система перегружена, любой разработчик имеет право остановить поступление новых задач до устранения перегрузки.

Главный шаг со стороны ИТ‑руководства: «красная зона» на 10 рабочих дней.

Формулировка объявления должна быть жёсткой:

«С завтрашнего дня никакие новые фичи, доработки, запросы бизнеса не принимаются. Исключение — только блокирующие баги в основном пользовательском сценарии. Всё остальное — в бэклог с пометкой „заморожено до окончания моратория“„.“»

При этом очень важно, как все это продается бизнесу. Здесь важен переход от языка «мы хотим отдохнуть» к языку рисков и денег.

«Уважаемый бизнес, текущая модель приводит к падению продуктивности на 40%, росту аварий и увольнениям. За следующие две недели мы не выпустим ни одной новой фичи — это наш вынужденный „капитальный ремонт“ конвейера. Если мы этого не сделаем, через три месяца мы не выпустим фичи вообще — команда окончательно выгорит. Выбор: потерять 2 недели сейчас или потерять 3–4 месяца позже с увольнением ключевых инженеров».

В такой ситуации ИТ‑директор выступает не как технарь, а как переговорщик, который умеет увязать техническую перегрузку с бизнес‑последствиями.

Две недели на все

Важно понимать, что мораторий — это не отпуск. Это целенаправленная инженерная работа по сокращению технического долга и автоматизации. Данная деятельность делится на четыре направления.

• Первое — работа с долгом. Команда завершает до 80% начатых, но незавершённых задач. «Добить висяки» — ключевая задача. При этом категорически запрещается открывать новые задачи.

• Второе — автоматизация технического долга. Выбираются топ-3 самых частых рутинных операции (например, деплой, проверка логов, обновление тестовых данных) и автоматизируются. Важно: не рефакторить всё подряд, а брать только самое больное место.

• Третье — устранение корневых причин инцидентов. По данным за последний месяц выбираются три самых частых инцидента. Для каждого пишется автоматический тест, который будет отлавливать повторение. Исключение — сиюминутные пожары, кроме наиболее критичного уровня, их тушить не нужно.

• Четвёртое — точечная доработка процессов. Пишется или исправляется документация по онбордингу и деплой‑инструкции. Но без внедрения новых фреймворков и без «расписывания идеального процесса».

Давайте посмотрим пример автоматизации из реального кейса. Одна команда тратила 4 часа в неделю на обновление тестовых данных в dev‑среде. За два дня написали скрипт, который делает это за 10 минут. Сэкономленное время — 3,5 часа в неделю со следующего спринта. Без найма, без новых фич.

Получаем главный артефакт моратория: «Зал славы автоматизаций» — публичный список того, что убрали из рутины, с указанием сэкономленных часов. Он вешается на видном месте в доске задач (физической или в Trello/Jira). Это важный психологический якорь: люди видят, что их усилия не прошли даром.

А что после моратория

Итак, мы потушили наш пожар, сняв острую фазу кризиса. Но без постоянного механизма перегрузка вернётся через пару месяцев. Для того чтобы проблемы не повторялись, мы предлагаем внедрить простой, но жёсткий протокол из трёх элементов.

Элемент первый — лимит WIP (работы в процессе) на команду. Правило звучит так: не более 3–5 задач в статусе «In Progress» на команду. Конкретное число выводится просто — одна задача на разработчика, но не больше пяти на команду. Зачем это нужно? Низкий WIP уменьшает переключения между задачами, увеличивает фокус и может увеличить выпуск на 30–50% без единого нового найма.

Элемент второй — еженедельный «Stop the Line»‑ритуал. Каждую пятницу в 11:00 команда собирается на 15 минут и отвечает на один вопрос: «Если бы завтра наступил мораторий, какие три автоматизации мы бы сделали в первую очередь?» Лидеры записывают эти три идеи в отдельный список. Правило: если через месяц ни одна из трёх идей не реализована — это красный флаг для руководства. Значит, система снова перегружена.

Элемент третий — формула приоритизации для бизнес‑задач. Когда бизнес приносит новую фичу, она не идёт в бэклог автоматом. Вместо этого применяется правило «один входящий — один исходящий». Чтобы добавить новую крупную задачу в текущий спринт, продакт‑менеджер обязан убрать одну существующую — в долгий бэклог или на потом. Это простой, но безжалостный механизм, который заставляет бизнес ранжировать по‑настоящему важное.

Давайте рассмотрим калькулятор найма, а точнее, критерий, когда нанимать НЕ нужно. Если текущая команда тратит более 20% времени на переработки в среднем за месяц — любой новый человек не только не поможет, а лишь усугубит хаос. Перегрузка в такой ситуации системная, проблема не в количестве рук, а в устройстве потока. Сначала — Stop the Line, потом — найм (если он вообще понадобится).

Наш «ФинТех» через полтора месяца

Вернемся к нашему примеру с компанией «ФинТех», в которой внедрили описанное решение. До моратория картина была действительно удручающей: lead time фичи (время от старта до релиза) составляло 28 дней, WIP на команду прыгал от 8 до 12 задач, при этом каждый инженер перерабатывал по 15–20 часов в неделю, а инцидентов в месяц фиксировалось 12, из них три серьёзных, с потерей данных или длительным простоем.

Через 30 дней после моратория цифры радикально изменились. Lead time упал до 16 дней — снижение на 43%. WIP стабилизировался на уровне 3–5 задач. Переработки сократились до 3–5 часов в неделю, причём только по желанию, не по принуждению. Инцидентов осталось пять, и все мелкие, не требующие ночных подъёмов.

Через 90 дней случилось самое интересное. Команда вернула доверие бизнеса: дедлайны стали выполняться предсказуемо. Финансовый директор, который раньше запрещал найм, сам предложил «добавить пару инженеров для роста». И, что важнее всего, ни один из ключевых разработчиков не уволился. Те, кто собирался писать заявление, отложили его.

Выводы

В заключение мы предлагаем некоторые рекомендации по тому, когда в компании требуется вводить мораторий. Первым делом следует обратить внимание на число незавершённых задач. Если их больше, чем число разработчиков, умноженное на 1,5, то это уже проблема. Например, для команды из 6 человек WIP > 9 — уже опасно.

Также, если время от возникновения критического инцидента до его устранения выросло в два и более раза за последний квартал. И если хотя бы один ключевой сотрудник уволился за последний месяц, назвав причиной перегрузку и выгорание.

При этом бизнес говорит «давайте ускоримся» в ответ на просьбы об автоматизации или снижении количества параллельных задач, не предлагая при этом никаких инвестиций (ни деньгами, ни временем, ни снижением требований).

При совпадении трёх из пяти двухнедельный мораторий не опционален, он обязателен. Причём инициировать его должен руководитель ИТ, не дожидаясь разрешения сверху. Как в авиации: если загорелся двигатель, вы не спрашиваете пассажиров, можно ли включить противопожарную систему. Вы включаете её и потом объясняете.

Таким образом, перегрузка команд без найма — это управленческая задача, а не инженерная. Техника «Stop the line» решает её через временную остановку потока задач, снижение WIP и принудительную автоматизацию самой частой рутины. Двухнедельный мораторий — не признак слабости, а признак зрелого менеджмента, который смотрит на полгода вперёд, а не на следующую пятницу.

Многие ИТ‑руководители боятся останавливать конвейер, потому что бизнес «не поймёт». Опыт показывает обратное: бизнес понимает язык потери денег и срывов сроков. Когда вы приходите с цифрами (рост инцидентов на 300%, падение скорости на 40%, увольнение ключевых специалистов) и чётким планом действий на две недели, а не с жалобами на усталость — вас слышат.

Если команда уже работает на пределе, а новые задачи продолжают лететь без остановки — присмотритесь к этим открытым урокам OTUS:

• 4 июня, 20:00 — «Операционная эффективность в IT: как находить скрытую прибыль в процессах разработки». Записаться
  _{Поможет увидеть, где команда теряет время, почему процессы начинают съедать ресурс и как искать точки роста без расширения штата.}

• 16 июня, 20:00 — «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться
  _{Будет полезен тем, кто устал от постоянного firefighting и хочет уменьшить количество повторяющихся инцидентов.}

• 18 июня, 20:00 — «Операционный директор в IT: компетенции, которые превращают хаос в систему». Записаться
  _{Подойдёт руководителям, которым нужно выстраивать устойчивые процессы, управлять перегрузкой команд и удерживать скорость разработки без постоянных переработок.}

Все уроки бесплатные, проходят онлайн и позволяют познакомиться с преподавателями‑практиками и подходами OTUS.

Больше материалов про управление IT‑командами, процессы разработки, DevOps, архитектуру и инженерные практики — на канале OTUS в MAX. Подписывайтесь, чтобы не пропускать новые открытые уроки и полезные разборы.