Сроки по релизу согласованы, бюджет утвержден, роадмап расписан на три квартала вперед. Не хватает только людей — четырнадцати человек, которых надо найти, проверить и включить в работу за то время, пока конкурент делает то же самое. Классический найм в такой рамке не помогает: он рассчитан на другую скорость.
Почему найм всегда отстает от плана роста
Средний цикл закрытия сильной позиции в разработке — от полутора до трех месяцев: описание роли, поиск, техническое интервью, оффер, отработка на прежнем месте. Умножьте на четырнадцать позиций, и квартал закончится раньше, чем соберется команда. При этом рекрутер не виноват: рынок кандидатов на редкие стеки просто уже занят.
Вторая проблема — неравномерность. Пик потребности приходится на активную фазу проекта, а после релиза половина набранных людей окажется без загрузки. Держать их в штате дорого, сокращать — потеря репутации и денег на повторный набор.
Здесь и работает подход, который devcom.ru формулирует прямо в своем позиционировании: масштабируем IT-команды — то есть добираем нужные роли под конкретную фазу проекта и снимаем усиление, когда потребность падает. Внутренняя команда при этом остается ядром, а не размывается.
Что ломается, когда людей становится в четыре раза больше
Первое — код-ревью. Пятерым разработчикам достаточно неформального обсуждения, двадцати нужны явные правила: кто ревьюер, какой SLA на проверку, что блокирует мердж. Без этого пул-реквесты копятся неделями, и рост команды не дает роста скорости.
Второе — онбординг. Когда каждый новый человек отвлекает тимлида на два дня, четырнадцать новичков съедают месяц его времени. Нужны актуальная документация по архитектуре, поднимаемое одной командой локальное окружение и стартовые задачи с понятным критерием приемки.
Третье — управление коммуникацией. Если каждый внешний специалист приходит от отдельного подрядчика со своим менеджером, техдиректор превращается в диспетчера. Модель с одним ответственным лицом на всё усиление снимает эту нагрузку: постановка задач и вопросы по составу идут в одну точку.
Гибридная модель: ядро в штате, усиление снаружи
В штате имеет смысл держать тех, кто носит в голове предметную логику и архитектурные решения: тимлидов, ведущих разработчиков, системных аналитиков по критичным доменам. Их уход стоит дороже всего, и на них строится преемственность.
Через аутстафф закрывают объемные и хорошо декомпозируемые участки: доработки по 1С, мобильные приложения под Android и iOS, бэкенд на Java и Python, интеграции, портал на Битрикс24. Отдельная история — редкая экспертиза, которую нет смысла держать постоянно: специалист под задачу вроде интеграции с «Честным знаком» нужен несколько недель, а не годами.
Проверять квалификацию до выхода на проект дешевле, чем выяснять ее в бою. Внутренняя техническая сертификация у поставщика, особенно в 1С, где формальный опыт в резюме почти ничего не говорит, снимает с вашей команды часть интервью и экономит недели.
Что проверить перед стартом
Начните с пилота на одной вакансии вместо рамочного договора на пятнадцать. Одна позиция, две-три недели, измеримый результат — этого достаточно, чтобы понять и скорость подбора, и уровень людей, и то, как поставщик реагирует на замену.
Запросите обзор рынка по вашим ролям до старта. Если по нужному стеку кандидатов в регионе физически мало, лучше узнать это в начале планирования, чем на третьем месяце. Заодно проверите, работает ли поставщик с международным рынком — это расширяет пул.
Уточните схему замены и передачи знаний: как быстро выводится специалист, если он не подошел, и что остается вам после окончания работ. Документация, тесты и разобранная задача — это то, что отличает усиление команды от разового закрытия дырки в графике.
