Речь пойдёт именно о переходе программиста на другой проект в рамках той же компании. Если говорить о новом принятом сотруднике, то у него кроме онбординга на проекте есть ещё и онбординг уровня компании; если вести речь за джуна-новичка, то в такой ситуации нужен полноценный наставник – эти вопросы в рамках данного текста не затрагиваются.
Итак, какие шаги нужны для того, чтобы разработчик максимально быстро и безболезненно въехал в новый проект?
Это тот, к кому новичок может в любой момент обратиться с вопросами (а вопросов будет ну оооочень много). Он не обязан обстоятельно разъяснять различные аспекты проекта, но он всегда указывает, куда двигаться дальше – к кому обратиться, какую страницу документации прочитать и т.д.
Чаще всего эту роль называют “наставник”, хотя на мой взгляд это название не очень подходит – в его обязанности не входит возиться и опекать, он может быть просто “маршрутизатором” 😀.
Только выделяя человека, имейте в виду, что дёргать его новичок будет не переставая – так что загруженных в данный момент на проекте членов команды лучше на эту роль не назначать.
Это страничка – хранилище ссылок на все материалы, которые могут понадобиться новичку – инструкции, страницы документации, контакты, записи видео и т.д. Меньше будет дёргать наставника, да и ему проще хранить у себя одну ссылку, чем создавать коллекцию.
Не, ну серьёзно – прочитайте.
Очень часто после прихода разработчика на проект его просто начинают сразу грузить задачами, а он не может эффективно их выполнять, т.к. не знает ни предметной области, ни функциональности системы. Это ну очень сильно мешает.
Конечно, со временем, постепенно он предметную область освоит. Но на это уйдут месяцы. Так что лекция по предметной области – тот самый случай, когда полчаса-час экономят недели.
Я тут написал “лекция”, хотя это зависит от размера системы – может быть и ряд лекций. Однажды мы онбордили нового сотрудника, лекций было две: одна по всей предметной области проекта, вторая – по статусной модели (очень уж развесистая она была).
Примечание: в тексте дальше так же вместо “лекция” может быть “лекции”.
Лайфхак, как ресурсно сэкономить: читая такую лекцию первый раз, запишите её на видео. Всем последующим можно просто давать смотреть это кино.
Т.е. как работать с системой с точки зрения пользователей. И да, тоже запишите её на видео, чтобы не читать каждый раз заново.
Понятно, что первую и вторую лекцию должны читать аналитики. В треугольнике разработки (аналитики – програмисты – тестировщики) они лучше всех знают предметную область. (А программисты – хуже всех 😀.)
Вот здесь уже разработчики должны расказать разработчику про разработку (сказанул, однако 😀). Какова архитектура системы (слои, фреймворки, СУБД, …), какие подходы используются, какие есть процессы, связанные с разработкой (код-ревью, CI, тестирование, …), какая стратегия бранчевания используется и т.д. Обязательно про архитектурные костыли, если такие есть, т.к. самостоятельно такое осознать практически невозможно (Саша, помнишь про версионность? 😆😆😆😆).
Вообще, конечно же, на все эти вопросы должна быть документация 😀 – просто выдайте ему список ссылок. Если документации нет, то идём стандартным путём: лекция или лекции → запись видео.
Далее –
Давайте поначалу много мелких и разнообразных задач. Так сказать, ознакомительный тур по кодовой базе.
Т.к. желательно охватить как можно больше аспектов системы, то задач должно быть много. А значит, они должны быть мелкими – например, неплохо на эту роль подходят баги.
Опять же, с решением каждой задачи постепенно будет заполняться шкала уверенности разработчика, которая при появлении на новом проекте находится на нулевом уровне. Так что размер задач имеет ещё и психологическое измерение 😀.
Со временем, в процессе погружения разработчика в предметную область, разрабатываемую систему, кодовую базу и процессы на проекте, задачи могут становиться всё более крупными и сложными. Какое время на это понадобится, сказать невозможно – зависит в первую очередь от размера и сложности проекта, во вторую – от самого разработчика. Думается, что средний срок онбординга – от двух до шести месяцев.
Напоследок, небольшой лайфхак: используйте новичков как тестировщиков вашей документации. Известно, что документация быстро теряет свою актуальность, и следить за этим очень хлопотно.
Так вот, давая задание новичку прочитать тот или иной документ, поручите ему сообщать обо всех найденных “косяках” овнеру (владельцу) документа, чтобы тот сразу проводил актуализацию. Как говориться, и овцы сыты, и волки целы 😆.
Дедушка Волшебник, 2021-07-05