Многие руководители и тимлиды знакомы с мыслью: «ещё один разработчик — и всё заработает». Это естественная реакция на растущий бэклог и давление сроков. Но найм — это не универсальное решение. Это инструмент, который умножает то, что уже работает. Если система нестабильна, новые люди унаследуют и масштабируют проблемы.
В этой статье я даю практический алгоритм принятия решения, набор метрик и короткий эксперимент, который поможет понять — стоит ли открывать вакансию, или сначала надо поработать с процессом.
Почему найм часто не решает проблему
Найм даёт дополнительную пропускную способность, но одновременно увеличивает сложность координации. Новому человеку нужно время на адаптацию: доступы, настройка среды, знание кода и домена, знакомство с процессами и код-ревью. Пока идёт онбординг — команда тратит ресурсы на сопровождение новичка; это временно снижает общую эффективность.
Существуют типичные сценарии провала:
- Неясные роли. Новичок первые недели не понимает, чем заняться, потому что никто чётко не описал обязанности.
- Перегрузка наставников. Сильные инженеры вынуждены тратить значительное время на обучение — их собственные задачи тормозятся.
- Увеличение коммуникаций. Чем больше людей, тем больше встреч, больше ревью и больше синхронизаций. Если календарь и так перегружен, добавление сотрудников ухудшит ситуацию.
- Масштабирование плохих практик. Если в кодовой базе много технического долга, добавление рук приводит к росту конфликтов и регрессий.
Признаки, что пора нанимать
Найм оправдан, если большинство следующих пунктов верны:
- Постоянный рост входящего потока задач и backlog растёт несколько итераций подряд, при этом текущая команда стабильно закрывает работу на своих текущих максимумах.
- Качество под контролем. Падения качества не наблюдается: тесты стабильны, количество дефектов и откатов не растёт.
- Процессы ясны и повторяемы. Есть правила PR, SLA на ревью, WIP-лимиты, понятные Definition of Done.
- Онбординг подготовлен. Существует 30/60/90 план, есть назначенный наставник и первые задачи подготовлены.
- Документация и доступы готовы. Минимальный набор внутренних вики-страниц, архитектурных заметок и рабочих доступов — присутствует.
Если это так — найм имеет высокий шанс повысить throughput. Если нет — вы, вероятно, умножите проблемы.
Как проверить гипотезу быстрее: эксперимент на 1–2 спринта
Перед публикацией JD выполните целенаправленный эксперимент:
- Соберите метрики сейчас. Throughput (issues/stories merged per sprint), cycle time distribution, lead time, среднее время ревью, количество открытых PR и их средний размер.
- Определите узкие места. Где задача ждёт дольше всего: в ревью, в тестировании, в интеграции или на оценке?
- Поставьте короткий «чистящий» спринт. Фокус на уменьшении очередей: введите обязательное сокращение размера PR, выделите временной слот для ревью, уменьшите WIP.
- Измерьте эффект. Сравните метрики с базой. Если after-changes backlog уменьшился или lead time упал — возможно, нанимать уже можно. Если метрики не улучшились — причина за пределами нехватки рук.
Альтернативы найму (часто эффективнее)
- Переприоритизация: снизьте WIP, остановите нерелевантные задачи.
- Автоматизация: уменьшите ручной труд в CI/CD, автоматизируйте проверки и сборки.
- Кросс-тренинг: перераспределите знания, чтобы уменьшить Single Point of Failure.
- Временные эксперты: подключите консультанта на узкую задачу (технический долг, архитектура).
- Изменение формы работы: уменьшите размер задач, внедрите feature toggles, разделите крупные задачи на независимые части.
Модель расчёта влияния коммуникаций (простая)
Представьте, что объём взаимных синхронизаций примерно растёт с числом пар людей. Если у вас N разработчиков, количество пар ≈ N*(N-1)/2. Добавление M людей увеличит количество пар существенно. Если сейчас большая часть времени тратится на встречи и ревью, увеличение N приведёт к росту издержек. Потому сначала снизьте синхронизации.
Онбординг: минимальный набор
Перед наймом оформите:
- 30/60/90 план;
- чек-лист доступа и инструментов;
- первые три практических задачи (чистые, небольшие, с быстрым фидбеком);
- назначенного ментора;
- документ «как мы ревьюим» и «как мы релизим».
Критерии успеха найма (зафиксировать заранее)
Оценивать через 3 и 6 месяцев по метрикам:
- Изменение throughput команды (кол-во закрытых задач/спринт).
- Lead time и cycle time.
- Количество дефектов/откатов.
- Time-to-first-meaningful-contribution для новичка (цель: ≤ 8 недель для простых задач).
Если улучшений нет — вернуть фокус на процессы.
Риски преждевременного найма
- Выгорание наставников.
- Деградация практик и увеличение техдолга.
- Раcходы на рекрутинг и потерянное время при неудаче.
Пошаговая инструкция для решения «найм или процесс»
- Соберите метрики за последние 4–8 недель: throughput, cycle time, lead time, review latency.
- Проанализируйте: растёт ли backlog? стабильны ли quality metrics?
- Запустите 1–2 спринта на процессы (WIP, ревью, PR size).
- Сравните метрики. Если проблемы остаются — готовьте JD и онбординг.
- Определите success criteria до публикации вакансии.
- Оцените альтернативы (автоматизация, контракт, приоритеты).
- Нанимайте только при зелёном чек-листе.
Итог
Найм усиливает то, что уже работает, и масштабирует то, что ломается. Прежде чем публиковать вакансию, честно ответьте на вопрос: «Добавляем людей в сильную систему или просто затыкаем дырку ресурсами?» Если первое — нанимайте. Если второе — сначала исправляйте процессы.
Если хотите — могу подготовить чек-лист для вашей конкретной команды (онбординг, 30/60/90, метрики), либо шаблон JD и success criteria под роль. А ещё — подписывайтесь на мой Telegram-канал: https://t.me/pavelsengineeringstuff.