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

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

Зачем вообще «собрать и передать»

Частая ситуация: у бизнеса есть идея и бюджет, но нет инженерной функции. Нанимать вслепую долго и рискованно. Решение — внешний человек (тимлид/архитектор) собирает ядро команды, ставит процессы и доводит продукт до стадии, когда им можно управлять изнутри. После этого команда переходит в штат заказчика, а внешний человек выходит. Главная ценность здесь — не код, а работающая, самостоятельная команда на выходе.

Шаг 1. Сначала роли, потом люди

Я не начинаю с вопроса «кого нанять», а с вопроса «какие роли закрывают риски проекта». Минимальный жизнеспособный состав обычно такой:

  • Аналитик — переводит бизнес-задачи в понятные требования и ТЗ; без него команда быстро и качественно делает не то, что нужно бизнесу. Часто самая недооценённая роль.
  • Бэкенд — ядро системы и данные.
  • Фронтенд — там, где есть веб-интерфейс.
  • DevOps / инфраструктура — хотя бы частично, иначе деплой превращается в шаманство.
  • QA — даже один человек резко поднимает предсказуемость релизов.

На старте часть ролей совмещается; важно явно назвать их, чтобы потом понимать, какие позиции открывать в штат.

Шаг 2. Нанимать на задачу, а не на резюме

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

Шаг 3. Процессы с первого дня

Команду делает командой не чат, а воркфлоу. С самого начала я ставлю:

  • трекер задач с понятными статусами и Definition of Done;
  • код-ревью как обязательный шаг (не «по желанию»);
  • CI: автотесты на каждый пулл-реквест;
  • предсказуемый цикл релизов и ведение изменений.

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

Шаг 4. Документация как актив передачи

Передать команду — значит передать знания. Я с самого начала требую, чтобы решения фиксировались: схема архитектуры, описание окружений, runbook по инцидентам, onboarding-гайд для новичка. Это скучная работа, которую все откладывают, но именно она определяет, сможет ли заказчик жить самостоятельно.

Шаг 5. Планомерный выход

Самая частая ошибка — оставаться единственным, кто «знает, как всё устроено». Я сознательно вывожу себя из критического пути: делегирую ревью, передаю владение модулями, назначаю внутреннего тимлида и постепенно ухожу в роль консультанта. Критерий готовности к передаче простой: команда проходит релиз и чинит инцидент без меня.

Где обычно ломается

  • «Соберём процессы потом». Потом не наступает; хаос костенеет.
  • Завязка всех знаний на одного человека. Bus-factor = 1 — это бомба замедленного действия.
  • Передача «по факту ухода». Передачу нужно планировать с первого дня, а не объявлять в последнюю неделю.

Итог

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

Если вам нужно собрать команду под проект и довести её до передачи в штат — помогу выстроить это на консультации.