Внедрить нового человека в IT-команду — звучит как текст из фильма про шпионов, но процесс онбординга как раз об этом. На первых порах даже небольшая ошибка может серьезно навредить команде и продукту. Подробней о том, как избежать проблемы во время онбординга IT-специалиста, расскажет Алексей Голубев, Lead Software Engineer at SoftServe с опытом работы более 8 лет.
Это вторая статья цикла «Шпаргалка для проектного менеджера», продолжение первой части, в которой говорили о том, как правильно провести интервью с новичком в IT.
Как упростить и ускорить онбординг новичка
Представьте, что вы привели в команду новенького участника, всем его представили и дали задание. Через какое-то время спрашиваете у него, как обстоят дела с поставленной задачей. В ответ слышите, что часть не удается выполнить, так как нет доступа к определенному документу. На ваш вопрос, почему вы об этом узнаете только сейчас, новый разработчик или разработчица отвечает, что было неясно, к кому нужно обратиться по этому поводу, а вы все время были заняты.
Дальше ситуация может развиваться по разным сценариям, но суть в том, что у каждого специалиста в команде всегда должны быть доступы ко всем нужным документам, ПО и «железу». За это отвечает проектный менеджер. Поэтому, когда онбордите новичка, обязательно проследите за тем, чтобы он мог спокойно приступить к выполнению своих обязанностей.
Еще одна из трудностей, с которой сталкиваются разработчики на этапе онбординга, но о чем часто молчат, — документация, в которой сложно самостоятельно разобраться. На проектах не всегда все очевидно: иногда нужно VPN специальным способом подключить, аккаунт запустить в нескольких местах и т. п. Об этом PM-ы тоже порой забывают.
В итоге новичок вместо того, чтобы быстро влиться в проект, тратит много времени на изучение документации и технических моментов. Чтобы такого не происходило, назначьте опытного ментора, который поможет быстро во всем разобраться. На практике час работы в связке «ментор-новичок» экономит около недели времени нового участника команды в сравнении с его самостоятельным «копанием» в информации.
После того как специалист изучил документацию и ознакомился с базовой технической информацией (что и как запускать, какие есть доступы и к чему), начинайте его «погружение» в детали проекта — дайте так называемый контекст. По сути, расскажите о специфике задач. Например, на медицинских проектах разработчикам часто приходится писать много технической документации и тестов. Об этом обязательно нужно говорить в самом начале работы и показывать примеры. Такая информация позволит быстрее адаптироваться к проекту.
Немного о workflow
После погружения в контекст самое время познакомить нового члена вашей IT-команды с workflow. Если предыдущий этап можно переложить на плечи ментора, то этот уж точно задача проектного менеджера. Расскажите: у кого какие роли, с кем и как нужно взаимодействовать, основные задачи девелопера и особенности процессов. Например, в работе команда практикует деление тасков на какое-то количество сабтасков с обязательными промежуточными отчетами. Вы, как PM, должны пояснить новому сотруднику, как правильно проходить все этапы по принятому в компании алгоритму.
Обязательно расскажите про некоторые общепринятые правила (особенно, если проект на аутсорс):
- нельзя брать в работу таски, которые непонятны;
- не берем в спринт стори, которые больше 60% от общего капасити;
- объемные таски нужно разбивать на сабтаски с уточнениями и разъяснениями.
Это примерный список того, что и как можно или нельзя делать IT-специалисту. Пункты всегда можно дополнить или изменить. Задача проектного менеджера в данном случае — максимально документальным путем «подстелить себе соломку» и обезопасить новичка и команду от возможных претензий со стороны заказчика.
Онбординг разработчиков, в идеале, заканчивается на workflow. Дальше идет эстимейт и непосредственно реализация проекта, но об этом в следующих статьях цикла «Шпаргалка для проектного менеджера».