Три месяца назад у меня появилась задача, от которой до сих пор немного сводит плечи: собрать backend-команду с нуля и вывести первый рабочий релиз в продакшен. Контекст был максимально недружелюбным. Продукт новый, требования менялись на ходу, бюджет ограниченный, а сроки, как обычно, уже вчера. Я честно сел и подумал: нанимать готовых специалистов на рынке или вкладываться в людей и учить их самому. Спойлер: в итоге я сделал и то, и другое, и именно эта комбинация спасла проект.
Сначала я пошёл классическим путём и открыл вакансии на сильного мидла и сеньора. И быстро понял неприятную правду: хорошие backend-разработчики не лежат на рынке и не ждут меня. На один нормальный отклик приходилось двадцать резюме с восемью годами опыта в трёх компаниях одновременно. Собеседования растянулись на пять недель, офферы улетали за границы моего бюджета, а один кандидат на финальном этапе просто перестал отвечать. При этом даже идеально нанятый сеньор не закрывает всё: нужен ещё кто-то, кто будет писать тесты, чинить мелочи и разгребать тикеты.
Поэтому я перестал искать серебряную пулю и собрал гибридный план. За первые три недели взял двух крепких мидлов, которым доверял архитектурные решения, и параллельно открыл две позиции для джунов без коммерческого опыта. Итого пять человек в команде: двое задают технический уровень, трое растут и берут на себя рутину. Это не компромисс ради экономии, это осознанная ставка: сильные люди вокруг слабых растут быстрее, чем слабые люди вокруг слабых.
Учить оказалось тяжелее, чем нанимать, но результат того стоил. Мы завели простое правило: у каждого задания есть наставник, а код джуна не попадает в основную ветку без ревью. Первый месяц я лично разбирал с новичками каждую задачу и объяснял, почему именно так, а не иначе. Потом появился внутренний учебный проект, который имитировал наш реальный сервис: там можно было спокойно ломать, ошибаться и переделывать. Через шесть недель ребята уже закрывали задачи по нашему бэклогу, а через десять я перестал проверять каждую строчку.
Отдельно скажу про процессы, потому что без них ни найм, ни обучение не работают. Мы завели короткий ежедневный созвон на пятнадцать минут, демо раз в неделю и честное определение готовности задачи: код плюс тесты плюс документация плюс ревью. Ещё одна вещь, которая нас спасла, это парное программирование в первый месяц работы любого новичка, и наёмного, и обученного. Это медленнее в моменте и заметно быстрее в перспективе, потому что человек вливается в контекст за две недели, а не за два месяца.
Ошибки тоже были, и не одна. Я слишком долго тянул с закрытием одной вакансии, из-за чего потерял три недели. Один раз взял человека по красивым словам на собеседовании и расстался с ним через месяц. Ещё недооценил скорость джунов: то, что мне казалось задачей на день, у них занимало три, и я поначалу злился, пока не понял, что причина в моих расплывчатых формулировках, а не в их способностях. И главное: я почти выгорел, потому что пытался одновременно быть тимлидом, наставником и рекрутером.
Что бы я посоветовал тому, кто сейчас стоит перед таким же выбором. Не делите мир на нанимать или учить, делите задачи на те, где нужен готовый опыт, и те, где нужен рост. Под самые критичные участки берите людей, которые уже проходили это в проде, остальное закрывайте обучением. Закладывайте на наставничество отдельное время в спринте, а не остаточный ресурс, иначе обучение тихо умрёт. Проверяйте не только знания, но и то, как человек реагирует на критику кода. И пишите документацию с первого дня, потому что это единственный способ масштабировать себя.
В итоге через три месяца у нас был работающий сервис, покрывший основной сценарий, и команда, которая умеет обсуждать решения, а не просто ждать указаний. Ни один из обученных джунов не ушёл, а один мидл дорос до того, что сам ведёт фичу. Я не считаю этот путь универсальным, но он оказался честнее и дешевле, чем гонка за редкими сеньорами. А теперь вопрос к вам, коллеги: расскажите, что сработало у вас, вы чаще берёте готовых специалистов или всё-таки инвестируете в рост своих? Буду рад разобрать ваши истории и, возможно, заберу пару приёмов в свою следующую команду.
Сначала я пошёл классическим путём и открыл вакансии на сильного мидла и сеньора. И быстро понял неприятную правду: хорошие backend-разработчики не лежат на рынке и не ждут меня. На один нормальный отклик приходилось двадцать резюме с восемью годами опыта в трёх компаниях одновременно. Собеседования растянулись на пять недель, офферы улетали за границы моего бюджета, а один кандидат на финальном этапе просто перестал отвечать. При этом даже идеально нанятый сеньор не закрывает всё: нужен ещё кто-то, кто будет писать тесты, чинить мелочи и разгребать тикеты.
Поэтому я перестал искать серебряную пулю и собрал гибридный план. За первые три недели взял двух крепких мидлов, которым доверял архитектурные решения, и параллельно открыл две позиции для джунов без коммерческого опыта. Итого пять человек в команде: двое задают технический уровень, трое растут и берут на себя рутину. Это не компромисс ради экономии, это осознанная ставка: сильные люди вокруг слабых растут быстрее, чем слабые люди вокруг слабых.
Учить оказалось тяжелее, чем нанимать, но результат того стоил. Мы завели простое правило: у каждого задания есть наставник, а код джуна не попадает в основную ветку без ревью. Первый месяц я лично разбирал с новичками каждую задачу и объяснял, почему именно так, а не иначе. Потом появился внутренний учебный проект, который имитировал наш реальный сервис: там можно было спокойно ломать, ошибаться и переделывать. Через шесть недель ребята уже закрывали задачи по нашему бэклогу, а через десять я перестал проверять каждую строчку.
Отдельно скажу про процессы, потому что без них ни найм, ни обучение не работают. Мы завели короткий ежедневный созвон на пятнадцать минут, демо раз в неделю и честное определение готовности задачи: код плюс тесты плюс документация плюс ревью. Ещё одна вещь, которая нас спасла, это парное программирование в первый месяц работы любого новичка, и наёмного, и обученного. Это медленнее в моменте и заметно быстрее в перспективе, потому что человек вливается в контекст за две недели, а не за два месяца.
Ошибки тоже были, и не одна. Я слишком долго тянул с закрытием одной вакансии, из-за чего потерял три недели. Один раз взял человека по красивым словам на собеседовании и расстался с ним через месяц. Ещё недооценил скорость джунов: то, что мне казалось задачей на день, у них занимало три, и я поначалу злился, пока не понял, что причина в моих расплывчатых формулировках, а не в их способностях. И главное: я почти выгорел, потому что пытался одновременно быть тимлидом, наставником и рекрутером.
Что бы я посоветовал тому, кто сейчас стоит перед таким же выбором. Не делите мир на нанимать или учить, делите задачи на те, где нужен готовый опыт, и те, где нужен рост. Под самые критичные участки берите людей, которые уже проходили это в проде, остальное закрывайте обучением. Закладывайте на наставничество отдельное время в спринте, а не остаточный ресурс, иначе обучение тихо умрёт. Проверяйте не только знания, но и то, как человек реагирует на критику кода. И пишите документацию с первого дня, потому что это единственный способ масштабировать себя.
В итоге через три месяца у нас был работающий сервис, покрывший основной сценарий, и команда, которая умеет обсуждать решения, а не просто ждать указаний. Ни один из обученных джунов не ушёл, а один мидл дорос до того, что сам ведёт фичу. Я не считаю этот путь универсальным, но он оказался честнее и дешевле, чем гонка за редкими сеньорами. А теперь вопрос к вам, коллеги: расскажите, что сработало у вас, вы чаще берёте готовых специалистов или всё-таки инвестируете в рост своих? Буду рад разобрать ваши истории и, возможно, заберу пару приёмов в свою следующую команду.