Быстрый набор команды в IT: риски и плюсы

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

Почему вообще возникает спешка

Быстрый набор — это редко про «захотелось». Обычно это про окно, которое вот-вот закроется. Проект стартует, бюджет утверждён, заказчик хочет первые результаты «ещё вчера», а у тебя на руках пустой Jira-борд и техлид, который в одиночку тянет весь бэклог. В такой ситуации выбор простой: либо ты набираешь людей быстро, либо проект начинает опаздывать ещё до первого спринта.

Я сознательно пошёл по первому пути. Мне были очень нужны спецы, и по всем формальным факторам — от хардов до софтов — кандидаты подходили. Собеседования они прошли честно, я их поджимал по времени, но не халтурил на самом интервью. И всё равно двое оказались не тем, что показалось на входе. Почему так — к этому и вернёмся.

Главная мысль: часть проблем с человеком на собесе не увидеть в принципе. Они всплывают только на реальных задачах. Дай кандидату индивидуальный кусок работы, посмотри на результат — и через пару недель ты узнаешь о нём больше, чем за пять раундов интервью. Проблема в том, что при быстром найме этих двух недель у тебя нет.

Риски быстрого набора

Спешка не бесплатна. Вот за что конкретно приходится платить.

Неподходящие кандидаты. Когда времени в обрез, ты невольно снижаешь планку. Не по хардам — по совпадению с проектом и командой. Человек может уметь ровно то, что нужно, но не тянуть контекст, в котором это «то» приходится применять. На собесе он решает алгоритмическую задачку, а в проекте ему надо разбираться в легаси без документации и договариваться с тремя смежными командами. Это разные навыки, и второй на интервью почти не проверяется.

Недостаточная оценка компетенций. Любой собес — это модель, а не реальность. И модель эту можно взломать: подготовиться к типовым вопросам, красиво рассказать про прошлые проекты, где твоя роль была, скажем так, творчески преувеличена. Я к таким кейсам отношусь спокойно — сам знаю, как устроен рынок. Но факт остаётся: чем короче воронка, тем выше шанс, что ты купишь упаковку, а не содержимое. Единственное честное лекарство — испытательный период с реальными задачами, а его при спешке хочется проскочить.

Нарушение культуры команды. Это самый недооценённый риск. Хард-скиллы видно сразу, а вот как человек ведёт себя в конфликте, как реагирует на критику на код-ревью, готов ли он подхватить чужую задачу в пятницу вечером — это про ценности, и на срочном найме их оценить некогда. Один неудачно вписанный человек в команде из десяти способен просадить атмосферу так, что заметишь ты это, только когда двое сильных ребят придут с заявлениями. Культура — штука хрупкая, и починить её сложнее, чем нанять.

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

Плюсы быстрого набора

Если бы одни риски — я бы так не делал. Но у скорости есть вполне осязаемые плюсы, ради которых эти риски и терпишь.

Ты стартуешь раньше. Самый очевидный выигрыш. Пока другие полгода перебирают резюме в поисках идеального кандидата, у тебя команда уже в бою и катает первые релизы. В IT это часто решает: рынок, окно возможности, приоритеты заказчика меняются быстрее, чем закрывается вдумчивая воронка на одного мидла. Иногда «достаточно хорошая» команда сегодня приносит больше, чем «идеальная» через полгода.

Пространство для экспериментов. Быстро собранная команда — это команда, которую ты собирал под конкретную задачу здесь и сейчас, а не под абстрактный «идеальный профиль». Такие люди обычно легче на подъём, охотнее пробуют новое и меньше цепляются за «как принято». Гибкость на старте дорогого стоит: проще менять подходы, пока процессы ещё не забетонированы.

Ты ловишь тех, кому важен темп. Есть отдельная порода специалистов, которых медленный найм отпугивает. Им скучно ждать три недели фидбэка после финального этапа. Быстрый, честный, решительный процесс сам по себе притягивает тех, кому этот темп в кайф. А именно такие люди и нужны на старте динамичного проекта.

Как я снижаю риски, не тормозя

Компромисс между скоростью и качеством не в том, чтобы выбрать одно. Он в том, чтобы отдать скорости то, что можно отдать без потерь, и защитить критичное.

Первое — реальная задача вместо ещё одного раунда интервью. Не абстрактная головоломка, а маленький кусок настоящей работы с настоящим контекстом. Пара дней такой проверки говорит о человеке больше, чем час разговоров про его прошлые заслуги.

Второе — не проскакивать испытательный срок формально. Если ты нанимаешь быстро, то самая честная страховка — внимательно смотреть на первые недели и дать себе право на быстрый откат. Ошибку в найме дешевле признать на второй неделе, чем тащить полгода из жалости к себе и человеку.

Третье — держать в голове культуру, а не только стек. Хотя бы один вопрос на собесе должен быть не про технологии, а про то, как человек работает в команде и что его драйвит. Это не гарантия, но это лучше, чем ноль внимания к софтам.

И да, свой промах с двумя спецами я не считаю провалом всей затеи. Результат найма в целом я признаю успешным: костяк за месяц, полная команда за два, проект поехал вовремя. Двое из десяти не подошли — это цена, которую я заплатил за скорость, и я знал, на что иду.

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

---

Впервые опубликовано в моём Telegram-канале @it_underside.

Ваш ДПУПП