Рост команды на порядок

В начале весь публичный frontend жил в общем монорепозитории, на общей инфраструктуре и с общим релизом. Маленькая команда справлялась, но её тимлид становился узким местом: общался с заказчиками, оценивал задачи, делал ревью, собирал релиз и разбирал дефекты после общего регресса. Первым изменением стал project manager, который взял на себя поток требований и базовую организацию работы. Команда получила собственную релизную ветку и инфраструктуру, поэтому могла выпускать изменения независимо.

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

Когда команд стало много, они начали независимо решать похожие задачи. Общие части приложений вынесли в отдельные пакеты и репозитории. Появились продуктовые и релиз-менеджеры: первые отвечали за бизнес-результат, вторые помогали настраивать процесс, содержание и сроки релизов. Чтобы улучшения не превратились в набор ритуалов, команда стала измерять объём поставляемого функционала, скорость релизов и пропущенные дефекты. Метрики показали пользу небольших команд и маленьких частых релизов, а также помогли замечать деградацию при новых волнах роста.

Последним описанным шагом стал уход от общего монорепозитория к отдельным приложениям с собственными репозиториями. Переиспользуемый инструментарий подключался как зависимость и развивался по модели внутреннего open source. Core-команда и архитектор отвечали за общие движки, а каждый продуктовый тимлид — за своё приложение и технический роадмап. Граница репозитория наконец совпала с границей ответственности: команда могла выбирать решения и полностью отвечала за их последствия.

Роль лида взрослеет вместе с системой. Сначала он лично контролирует почти каждую операцию. Затем учится делегировать коммуникации и процессы, растить новых лидов, согласовывать технические планы между командами и управлять не отдельными задачами, а условиями, в которых команды принимают решения. При этом переход в менеджмент не обязан быть необратимым: сильному senior-разработчику полезно дать пробный период и безопасную возможность вернуться в технический трек. В рассказанной истории один из новых тимлидов через год именно так перешёл в tech lead.

Главная защита от управленческого хаоса — понимать бизнес-цель, текущий этап жизни команды и свои обязанности на этом этапе. Архитектуру и оргструктуру нельзя развивать отдельно: изменение одной почти неизбежно требует изменения другой. И ещё важно честно ответить себе, хочется ли отвечать за людей и систему целиком или больше удовольствия по-прежнему приносит работа с кодом.