Наставник не делает работу за подопечного
Наставничество — это задача на грани возможностей человека и страховка, а не готовое решение. Что работает:
- план — с какого уровня начинаем и куда идём;
- постепенное усложнение задач;
- разбор сделанного и ревью с объяснениями;
- регулярность — короткие встречи раз в неделю лучше редких длинных.
На собеседовании историю рассказывают с измеримым результатом: «через полгода он сам вёл задачи по интеграциям и прошёл повышение», «онбординг сократился с месяца до двух недель». Сильный штрих — что вы сами узнали от подопечного: его вопросы вскрывают пробелы в документации и процессах.
Онбординг новичка
- До первого дня — доступы и рабочее окружение.
- Первая неделя — запустить проект локально по инструкции (заодно проверить её), обзор архитектуры и процессов, первая маленькая задача до продакшена: новичок проходит весь путь от ветки до выкатки.
- Дальше — задачи с постепенным усложнением, короткие регулярные встречи, ревью с объяснениями.
Цели на первый месяц формулируют явно: «самостоятельно закрывает задачи в модуле заказов». У новичка есть назначенный наставник, к которому не стыдно идти с вопросом. Каждый его вопрос — сигнал дыры в документации, её закрывают сразу. Метрика онбординга — время до первого самостоятельного релиза.
Ревью, после которого растут
- Объяснять почему, а не только что: «здесь будет гонка, если два запроса придут одновременно — вот как это проявится».
- Задавать наводящие вопросы, чтобы человек нашёл проблему сам.
- Разделять обязательное и пожелания, не заваливать мелочами.
- Отмечать хорошие решения.
- Сложное обсуждать голосом, а не в двадцати комментариях.
- Не переписывать код за автора в своём коммите — так он не научится.
Повторяющееся замечание — повод для гайда или правила линтера. Хорошее ревью — то, после которого следующий PR этого человека лучше.
Документация, которая окупается
Минимум:
- README — как запустить проект;
- схема архитектуры и потоков данных;
- runbook — что делать дежурному при типовых сбоях;
- ADR — решения с причинами;
- описание API.
Документация живёт рядом с кодом и обновляется в том же PR, что и код — пункт «обновлена документация» в шаблоне PR помогает. То, что можно сгенерировать, генерируют. Устаревшее хуже отсутствующего — его удаляют. Проверка качества: новый человек запускает проект только по README. Ответили на вопрос в чате второй раз — пора записать.
Не быть единственным экспертом
Bus factor — сколько людей должно выпасть, чтобы работа встала. Если это вы один — риск для команды и потолок для вас: вас не отпустят ни в отпуск, ни на новый проект. Снижают так:
- отдавать интересные задачи в «своей» части системы другим и ревьюить их;
- парная работа и разбор сложных мест;
- внутренние доклады и разборы инцидентов для всей команды;
- дежурства по очереди и ревью от разных людей.
Цель — чтобы любой критичный компонент знали минимум двое. Признак успеха — вы уходите в отпуск, и ничего не ломается.
Что запомнить
- Наставник даёт задачу на грани возможностей и страхует.
- Первая задача новичка — маленькая, но до продакшена.
- В ревью — «почему» и наводящие вопросы.
- Документация обновляется в том же PR, что и код.
- Каждый критичный компонент знают минимум двое.