Когда у бизнеса есть жесткий срок, найм начинает жить в конфликте с проектом. HR ищет кандидатов, проводит собеседования, согласует тестовые, ждет обратную связь от технической команды. Все идет по процессу, но дедлайн не двигается. Бэклог растет, бизнес спрашивает дату релиза, а ИТ-директор все чаще понимает, что проблема уже не только в количестве задач, а в том, что их просто некому делать.
Так произошло у Андрея* - ИТ-директора федеральной аптечной сети с сотнями точек по стране и растущей долей онлайн-заказов. Мобильное приложение для компании давно перестало быть дополнительным каналом. Через него клиенты оформляли доставку, бронировали товары в ближайшей аптеке, пользовались картой лояльности и возвращались за повторными покупками. От стабильной работы приложения зависели выручка, нагрузка на аптеки и впечатление клиентов от всей сети.
К сезонному пику приложение должно было быть готово, но задач накопилось на три месяца
В начале года в бэклоге накопилось задач примерно на три месяца работы. Нужно было обновить API, переработать схему базы данных, доработать интеграции с внешними сервисами и расширить функционал админ-панели. При этом у бизнеса был жесткий срок: обновление должно выйти к сезонному пику спроса на лекарства.
Если приложение не успеет к этому периоду, компания рискует потерять часть заказов в самый денежный момент. Для ИТ-директора это уже не просто техническая задача, а зона прямой ответственности перед бизнесом.
Штатный найм оказался слишком медленным для горящего проекта
Андрей пошел по понятному пути и решил усилить команду штатными backend-разработчиками. HR-отдел запустил подбор под стек Node.js и PostgreSQL. На бумаге все выглядело управляемо: найти специалистов, провести отбор, вывести их на проект и закрыть бэклог до сезона.
На практике один найм занимал до 140-150 часов. Сначала скрининг резюме, потом тестовое, техническое интервью, финальное собеседование, согласование оффера. Пока шел процесс, задачи никуда не исчезали. Бизнес ждал результат, команда продолжала работать в перегрузе, а сроки постепенно становились все жестче.
Когда этапы отбора сократили, слабые места кандидатов всплыли уже на проекте
Чтобы уложиться в сроки, этапы найма начали сокращать. Тестовые задания урезали, финальные собеседования в отдельных случаях убрали, часть решений принимали быстрее обычного. Казалось, так получится быстрее вывести людей на проект.
Но проблема просто переехала внутрь команды. После выхода на проект выяснялось, что у некоторых разработчиков есть пробелы в базовых компетенциях, хотя в резюме был указан уверенный уровень. Команда тратила время на объяснения, дообучение и переделки. Вместо ускорения проект начинал буксовать еще сильнее.
В какой-то момент стало понятно: экономия времени на отборе не исчезла, а превратилась в потери времени на проекте.
Опытных разработчиков было мало, а офферы срывались в последний момент
Следующим шагом стала ставка на более опытных кандидатов. Но здесь компания быстро уперлась в дефицит. На одну вакансию приходило всего 3-4 релевантных отклика. Кандидаты, дошедшие до оффера, в последний момент выбирали другую компанию или просто не выходили.
Один разработчик вообще не вернулся с обеда.
Для бизнеса это звучит странно, но для ИТ-рынка ситуация узнаваемая: формально человек найден, процесс вроде бы идет, но по факту проект снова остается без рук. А время продолжает уходить.
Дешевый аутстаффинг снова превратился в бесконечный подбор
Когда стало понятно, что штатным наймом задачу быстро не закрыть, Андрей вместе с HR обратился к нескольким бюджетным аутстафф-провайдерам. Ожидание было простым: вместо длинного рекрутинга быстро получить backend-разработчиков под проект.
Но на практике все снова превратилось в тот же подбор. Провайдеры присылали CV, команда проводила собеседования, кандидаты не подходили по уровню, стеку или опыту работы с мобильными продуктами. Прошел месяц, а ни одного разработчика с нужным уровнем вовлечь в проект не удалось.
Бэклог почти не сдвинулся, дедлайн приблизился, а у Андрея становилось все меньше вариантов.
Когда CEO лично спросил про сроки, стало ясно: нужен другой способ усилить команду
На этом фоне CEO лично вернулся к теме релиза. До сезонного пика оставалось три месяца, и к этому моменту приложение должно было быть обновлено и готово к повышенной нагрузке.
Для Андрея это был уже не просто спор о ресурсах. Если проект не удастся удержать в сроках и бюджете, компании придется пересматривать все направление. И вместе с ним - роль ИТ-директора.
После этого стало понятно: нужен не очередной канал поиска кандидатов, а другой подход к усилению команды.
Подрядчик должен был дать не пачку резюме, а готовых к проекту специалистов
Андрей пересобрал критерии выбора подрядчика. Нужна была команда, которая понимает мобильные продукты, backend-разработку, интеграции и умеет быстро выводить специалистов в существующие процессы заказчика.
Важно было не получить еще одну пачку резюме, а сократить путь от запроса до работающего разработчика на проекте. Потому что в ситуации, когда релиз уже горит, заказчику нужен не процесс ради процесса, а специалисты, которые подходят под стек, проходят техническую проверку и могут включиться без долгой раскачки.
По этим критериям в шорт-лист попал Синаптик.
Для проекта искали не просто Node.js-разработчиков, а людей с опытом мобильных API
Команда заказчика запросила у нас примеры проектов, стек backend-разработки и типовой процесс подключения специалистов. После обсуждений сформулировали конкретный запрос: два backend-разработчика с опытом Node.js, PostgreSQL, мобильных API и интеграций с внешними сервисами.
Это был важный момент. Компании был нужен не просто backend на Node.js. Нужны были люди, которые понимают, как работает мобильный продукт: авторизация, обмен с внешними сервисами, нагрузка, админ-панель, стабильность API и ответственность за работу приложения в сезонный пик.
В течение 1-2 недель мы предложили пул кандидатов, прошедших внутреннюю техническую оценку. Андрей провел финальные интервью и выбрал двух специалистов.
Два внешних разработчика закрыли задачи, под которые планировали нанимать 2-3 человека в штат
После отбора разработчиков вывели на проект. Они вошли в процессы заказчика и сразу сфокусировались на задачах, которые тормозили релиз.
Без долгой раскачки. Без ожидания выхода кандидата через месяц. Без нового круга собеседований с непредсказуемым результатом.
За три месяца совместной работы команда закрыла накопленный бэклог. Обновленное приложение вышло к сезонному пику спроса и выдержало повышенную нагрузку. Задачи, под которые изначально планировали нанимать 2-3 человек в штат, удалось решить силами двух внешних разработчиков без расширения FTE.
Бизнес сохранил релиз к сезону и снизил затраты на команду до 25-30%
По оценке финансовой службы, аутстаффинг вместо найма в штат дал до 25-30% экономии совокупных затрат на ФОТ с учетом налогов, соцпакета и HR-процессов.
Для бизнеса это означало сохраненный релиз, готовность приложения к сезону и отсутствие необходимости срочно раздувать штат. Для Андрея - рабочий инструмент на случай кадровых кризисов и квартальная премия за проект.
Главное, компания получила способ усиливать команду тогда, когда классический найм слишком медленный, а проект уже требует результата.
Когда проект горит, важна не скорость найма, а скорость появления результата
Штатный найм нужен, когда компания планомерно растит команду. Но если проект уже горит, бэклог давит, а бизнес ждет релиз к конкретному сезону, классический найм может оказаться слишком медленным инструментом.
В такой ситуации нужны не резюме пачками и не бесконечные собеседования, а разработчики, которые подходят под стек, понимают продуктовую задачу и могут быстро войти в проект.
Мы строим ИТ-системы и усиливаем команды так, чтобы руководитель занимался стратегией и ростом, а не проверял, вернулся ли новый сотрудник с обеда.