Онбординг разработчика: как ввести в проект за неделю

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

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

Почему онбординг затягивается?

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

Типичные причины:

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

Что подготовить до первого дня?

До первого дня нужно подготовить доступы, рабочее окружение и план недели — так, чтобы новичок в первый же день запустил проект и увидел его работу. Всё это одинаково для каждого нового человека, поэтому оформляется в чек-лист один раз.

Чек-лист подготовки:

1. Учётные записи: почта, мессенджер, трекер задач, репозиторий, документация.
2. Доступы к тестовому окружению; к продакшену — только если нужен для работы и по принципу минимальных прав.
3. Рабочий ноутбук с нужным ПО, если его выдаёт компания.
4. Назначенный наставник из команды, у которого в первую неделю заложено время на помощь.
5. Подобранная первая задача и план на неделю.

Как сделать, чтобы проект запускался за час?

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

git clone git@github.com:company/project.git && cd project
cp .env.example .env
docker compose up -d
docker compose exec app php artisan migrate --seed
# Открыть http://localhost:8000 — тестовый пользователь указан в README

Что должно быть в README для нового разработчика:

• требования к системе и одна команда запуска;
• как запустить тесты и проверки стиля кода;
• тестовые данные и учётные записи для входа;
• ссылки на описание архитектуры, соглашения команды и процесс выкладки.

Фото: Unsplash

Как выглядит первая неделя?

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

День	Что происходит	Результат
1	Доступы, запуск проекта, знакомство с командой и продуктом	Проект работает локально
2	Обзор архитектуры с наставником, чтение ключевых модулей	Понятно, где что лежит
3	Первая задача: небольшое реальное изменение	Черновик решения
4	Код-ревью, исправления, тесты	Задача принята на ревью
5	Выкладка, демо команде, ретроспектива онбординга	Изменение в продакшене, список улучшений онбординга

Какой должна быть первая задача

Хорошая первая задача касается реального продукта, затрагивает несколько слоёв — например, API и интерфейс, — но укладывается в один-два дня. Исправление небольшой ошибки или маленькое улучшение подходят лучше, чем изолированная «учебная» задача или крупная новая функция.

Какая документация ускоряет онбординг?

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

Минимальный набор:

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

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

Как понять, что онбординг прошёл успешно?

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

Что спросить у новичка:

1. Где пришлось ждать или искать информацию дольше всего?
2. Какие шаги README не сработали?
3. Что было непонятно в архитектуре и чего не хватило в документации?

Ответы превращаются в задачи на улучшение — и следующий онбординг проходит быстрее.

Коротко

• Готовьте доступы, окружение и наставника до первого дня.
• Проект должен запускаться одной командой, README проверяет сам новичок.
• К концу первой недели — первое изменение в продакшене.
• Первая задача — реальная, небольшая, затрагивает несколько слоёв системы.
• Короткая документация об архитектуре и решениях ускоряет онбординг сильнее подробной.