Ловушка масштаба: почему с ростом компании падает скорость обновлений
В стартапе обновления продукта не занимают много времени: для релиза часто достаточно нескольких дней. В небольшой команде все понимают общую задачу, знают продукт целиком и быстро договариваются, а разработчик способен почти в одиночку провести изменение от идеи до продакшена.
Но если дела у стартапа идут хорошо и продукт развивается, вместе с ним увеличивается количество процессов, а следом — штат. Появляются отдельные команды и специалисты по разработке, аналитике, тестированию и безопасности. Кажется, что это должно ускорить релизы, но нередко все происходит наоборот, и даже небольшая функция вдруг начинает занимать несколько недель. Centicore Group о том, почему с ростом компании процессы парадоксально начинают занимать больше времени.
Сложности взаимодействия
Для пользователя новая функция может выглядеть как одна кнопка, но за ней скрываются изменения в интерфейсе, бэкенде, базе данных, аналитике и мобильном приложении. И за каждую составляющую отвечает своя команда со своими приоритетами.
Допустим, фронтенд-разработчик готов начать сегодня, но ему нужен новый метод от бэкенда. У бэкенда задача попадет только в следующий спринт. Затем требуется согласование с владельцем другого сервиса, а готовое обновление будет ждать тестирования и проверки безопасности.
В результате каждый участник может выполнить свою часть быстро и качественно, но на стыках возникает задержка: один специалист ждет, пока освободится другой, задача передается из рук в руки, а контекст приходится объяснять заново. В итоге изменение добирается до пользователя за месяц — хотя непосредственно работа над ним суммарно заняла три дня.
Так компания попадает в ловушку масштаба: она оценивает скорость по времени разработки, а основной подвох скрывается в ожидании и координации сотрудников и команд.
Больше людей — больше проблем
Кажется, что самый очевидный способ справиться с длинной очередью задач — нанять еще специалистов. Но расширение штата далеко не всегда решает проблему — и даже наоборот, где-то может ее усугубить.
Представьте, что десять разработчиков передают изменения двум ревьюерам или одной QA-команде. Объема кода и pull request станет больше, но пропускная способность следующего этапа не изменится: то есть вместо того, чтобы сократить очередь, компания станет лишь быстрее ее пополнять.
Кроме того, любое подключение к проекту нового человека требует времени на онбординг. Специалиста нужно познакомить с продуктом, архитектурой и внутренними правилами, а заниматься этим приходится его коллегам, которые тратят на эту задачу свои рабочие часы. Поэтому в первое время расширение штата может даже замедлить работу.
Наконец, увеличение команды автоматически усложняет синхронизацию. В компании появляются дополнительные созвоны, переписки, доски с задачами, регламенты и менеджеры. Обсудить все в одном чате уже не получится — иначе вы превратите его в хаос. А чем больше встреч и уровней согласований, тем больше команда тратит на координацию и меньше — на сам продукт.
Рассинхронизация команд
По мере роста продукта компания начинает делить его составляющие между несколькими проектными командами, в каждой из которых есть свои разработчики, аналитики и тестировщики. Это помогает оптимизировать работу внутри команды, но переводит проблему на новый уровень — межкомандного взаимодействия.
Допустим, команда, которая работает над личным кабинетом, хочет добавить в него настройку уведомлений. Все необходимые специалисты у нее есть, но само изменение затрагивает общую систему авторизации, сервис хранения пользовательских соглашений и платформу рассылок. За эти компоненты отвечают другие команды, у которых свои планы и приоритеты. В итоге задача формально готова, но уходит в ожидание изменений или согласований со стороны владельцев смежных сервисов. Чем сильнее разрастается продукт, тем чаще небольшая функция пересекает границы нескольких зон ответственности, и в итоге срок выполнения зависит от того, когда все участники смогут синхронизировать работу.
Если такие внешние зависимости возникают почти в каждой задаче, это может быть сигналом, что архитектура продукта и границы ответственности команд больше не соответствуют специфике развития бизнеса. Тогда есть смысл пересмотреть взаимодействие между компонентами: создать стабильные API и инструменты самообслуживания, уменьшить число обязательных согласований или передать одной команде ответственность за пользовательский сценарий целиком.
Как выйти из ловушки масштаба
Универсального способа вернуть прежнюю скорость нет: сначала нужно понять, на каком этапе и по какой причине компания начала ее терять. В первую очередь — перестать измерять только время непосредственной работы над задачей и посмотреть на весь путь до продакшена. Сколько дней изменение действительно находится в разработке, а сколько ждет ревью, тестирования, согласования или действий смежной команды? Такой анализ покажет реальное узкое место. Если задачи скапливаются перед QA, возможно, стоит усилить тестирование или автоматизировать часть проверок. Если время уходит на синхронизацию — сократить количество встреч, закрепить владельцев решений и документировать договоренности, чтобы не восстанавливать контекст при каждой передаче задачи. И расширять команду можно, только если вы выяснили, что на каком-то этапе действительно не хватает рабочих рук.
Отдельно нужно настраивать зависимости между командами. Отделам, которые регулярно взаимодействуют друг с другом, важно заранее синхронизировать планы, а типовые операции по возможности переводить в режим самообслуживания с помощью стабильных API и готовых инструментов. Согласования при этом лучше привязывать к риску: небольшое обратимое обновление не должно проходить тот же путь, что и изменение критичной системы.
