Команда выросла в размере, но не в скиллах
Ситуация
Продуктовая команда клиента росла быстро — за год штат разработки увеличился втрое. Найм шёл в спешке: сроки поджимали, а собеседования всё больше превращались в формальность — «умеет писать код, свободен по деньгам, стартует завтра». Никто не измерял уровень системно, никто не смотрел на архитектурное мышление.
Дальше — контракт мечты. Крупный заказчик, серьёзный бюджет, жёсткий дедлайн. Задача была понятной на словах: реализовать интеграцию с внешним биллингом и переработать основной модуль под возросшую нагрузку. Но когда дело дошло до декомпозиции, стало видно: в команде из пятнадцати человек некому спроектировать это решение. Разработчики умели закрывать тикеты, но не умели проектировать систему, которая выдержит нагрузку и не развалится через полгода.
Диагноз
Пришёл на экспресс-аудит, а задержался на два месяца в роли играющего тренера. Первое, что бросилось в глаза при код-ревью — отсутствие единого архитектурного видения. Каждый писал «как удобно», модули не были декомпозированы, зависимости шли по кругу. Ошибка, знакомая по десяткам похожих кейсов: рост штата подменили ростом компетенций. Это тот самый риск, о котором нужно было говорить на этапе найма, а не после подписания контракта.
Провёл серию 1:1 с ключевыми разработчиками — не чтобы «проверить», а чтобы понять, кто способен расти в тимлида, а кто уже перегорел на рутине. Из пятнадцати человек нашлось трое с потенциалом взять на себя техническое лидерство отдельных вертикалей.
Что сделали
- Спроектировал архитектуру интеграции с биллингом: очереди, идемпотентность операций, отдельный сервис для сверки данных — без революции в стеке, монолит остался монолитом там, где это было оправдано.
- Декомпозировал крупный заказ на вертикали, каждую отдал под ответственность одного из трёх потенциальных лидеров, а сам взял на себя код-ревью и парное программирование на самых рискованных участках.
- Ввёл регулярные ретро и понятную оценку трудозатрат — раньше сроки называли «на глаз», теперь опирались на декомпозицию.
- Организовал менторскую программу: не разовые лекции, а разбор реальных PR с объяснением, почему решение хрупкое и как его укрепить.
Результат
Заказ был закрыт в срок, без ночных «пожаротушений» и без раздувания штата — то есть без той самой ошибки, которая обычно и убивает бюджет проекта. Что важнее для бизнеса — команда получила внутреннюю техническую вертикаль: теперь у неё есть три человека, способных самостоятельно вести архитектурные решения, а не только писать код по спецификации.
Показательный момент: клиент изначально хотел «нанять ещё пятерых сеньоров под дедлайн». Экспресс-аудит на старте показал, что проблема не в руках, а в мышлении — и обошёлся кратно дешевле, чем срочный найм под давлением сроков.
У вас такая же ситуация?
Давай решим...