Ловушка масштаба: почему команда растёт, а обновления выходят медленнее

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

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

Посмотрите, где задача останавливается

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

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

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

Допустим, вы добавляете кнопку в личном кабинете. Интерфейс можно подготовить сразу, но для него нужен новый метод серверного API. Бэкенд-команда сможет взяться за него в следующем спринте. После этого обновление попадёт в очередь на тестирование. Каждый участник укладывается в свою оценку, а общий срок растягивается из-за пауз между этапами.

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

Усиливайте этап, который задерживает выпуск

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

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

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

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

Сокращайте обязательные передачи между командами

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

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

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

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

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

Соотносите согласования с риском изменения

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

Определите, какие решения команда может принимать самостоятельно, а для каких нужна дополнительная экспертиза. Проверку безопасности или архитектуры привязывайте к характеру изменения и возможным последствиям ошибки. Это один из вариантов подхода к согласованию изменений.

После изменения процесса снова проследите путь нескольких задач. Сократилось ли ожидание? Стало ли меньше возвратов на уточнение? Доходят ли обновления до пользователей раньше? Это покажет, помогли ли новый специалист, автоматизация или другие правила взаимодействия. Сам по себе рост числа закрытых задач внутри одного отдела ещё не объясняет, что произошло со сроком релиза.

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