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

Этот кейс относится к отдельной команде, сформированной до моего перехода в новый Decision Engine в конце сентября 2024 года.

Костяк команды удалось собрать примерно за месяц, основной состав — за два. Такой темп помог проекту стартовать вовремя, но несколько решений по найму пришлось пересмотреть. Быстрый подбор — не достижение сам по себе, а обмен скорости на дополнительный риск.

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

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

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

Где скорость особенно опасна

Совпадение с контекстом. Технических знаний недостаточно, если человек не умеет работать с зависимостями и ограничениями конкретного проекта.

Командное поведение. Реакция на обратную связь, готовность объяснять решения и способность договариваться влияют на результат не меньше кода.

Поспешный оффер. Давление сроков легко превращается в завышенные ожидания с обеих сторон. Их лучше проговорить до выхода, а не исправлять через несколько месяцев.

Что помогает не потерять качество

Первое — обсуждать не абстрактные задачи, а ситуации, похожие на будущую работу. Как кандидат разбирается в неизвестном сервисе? Что делает при конфликте приоритетов? Как сообщает о риске для срока?

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

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

Я по-прежнему предпочитаю оперативный найм многомесячному ожиданию идеального кандидата. Но скорость работает только вместе с ясными критериями, внимательным онбордингом и готовностью честно пересмотреть ошибку.

Сначала план запуска, затем вакансии

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

Я бы описал для каждой роли три вещи: результат первых недель, необходимую самостоятельность и зависимости от остальных. Такая карта помогает выбирать между постоянным наймом, временным усилением и консультацией эксперта. Эти варианты закрывают разные потребности и не должны маскировать друг друга.

На интервью полезен один общий контекст. Например, команда получает недокументированный API соседней системы и обещанный срок запуска. Я смотрю, какие вопросы кандидат задаст, что проверит первым и когда сообщит о риске. Это предметнее, чем длинная викторина по технологиям, которые могут вообще не встретиться в проекте.

Первые недели — часть управленческой работы

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

Обратную связь я связываю с наблюдаемой работой: удалось ли разобраться в контракте, показать результат, запросить недостающий контекст и договориться с коллегами. Раннюю ошибку нельзя автоматически считать доказательством плохого найма. Сначала стоит проверить, были ли ясны ожидания и предоставлена ли необходимая поддержка.

Для руководителя полезны время до первой самостоятельной поставки, объём помощи и повторяющиеся препятствия. Количество закрытых вакансий показывает активность подбора; эти наблюдения показывают, появилась ли у команды способность делать продукт.

---

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

Ваш ДПУПП