Онбординг в IT
Sergei Ermolaev
После того как мы наняли новых сотрудников к нам в команду их необходимо ввести в курс дела. Думаю, что все примерно понимают что такое онбординг и как его готовить, в этой статье будет несколько вещей о том как его систематизировать и сделать немного эффективнее
Прежде всего давайте начнем с того какие проблемы мы решаем?
1. Ускорить адаптацию нового сотрудника
2. Снизить стресс у человека
3. Снижение издержек остальных участников команды на обучение
Как ускорить адаптацию?
1. Сейчас будет капитанство, но, чтобы человек быстрее адаптировался надо на старте явно проговорить критерии успешности его работы. Я обычно при найме нового человека проговариваю с ним 3 критерия его успешности: идеальный вариант, достаточный и тот, при котором мы не будем продолжать сотрудничество
2. Дальше вы должны обеспечить как можно быструю возможность инженера приступить к обучению и решению задач. Это очень часто является проблемой в больших компаниях. В одной из которых я работал, время от устройства до доступа к проекту могло занимать до месяца. Просто представьте, что человек первый месяц мог получить зарплату просто так. Соответственно дальше у него остаётся только 2 месяца, чтобы влиться а у вас чтобы его оценить.
Большую часть активностей по настройке доступов, скачивания ide можно автоматизировать и переложить на кого-то более низкооплачиваемого. В идеале мы должны сделать так, что сотрудник в день устройства в компанию уже мог начать писать код
3. После того как человек может начать решать ваши задачи для него необходимо составить план действий, которые ему необходимо выполнить. Эта штука, которая аналогична для всех сотрудников, ее следует задокументировать и просто выдавать на входе. Обычна она включает в себя набор необходимых курсов о том как мы работаем, какие у нас есть особенности, описание наших процессов и тд. Вообще общий совет, который я долго игнорировал и считал бесполезным — документируйте все что у вас есть, финально это тратит время в моменте, но экономит в будущем и позволяет вам проще масштабироваться.
4. Подготовьте тестовую задачу, которая включает в себя основные проблемы, которые придется решать инженеру в работе. Первую неделю/спринт инженер все равно не сможет полноценно работать и планировать его нагрузку может быть не очень предзаказуемо. Поэтому лучше дать тестовую задачу, в которой он разберется с основным сложностями, а потом уже сможет решить на боевой задаче
5. Проговорить с сотрудником способ решения вопросов и поставить регулярные встречи для их обсуждения. Обычно я прошу человека создавать документ, копить там вопросы, чтобы потом обсудить все вместе. Одновременно с этим ставятся регулярные встречи, сначала раз в пару дней, потом периодичность снижается до созвона в пару недель
6. Назначить новичку бадди-помощника. Как бы вы не хотели, но вы руководитель и часто ваши знания могут быть ниже, чем у кого-то из ваших инженеров, а в случае с разными платформами, вы можете быть вообще практически не компетентны в решении вопросов. Поэтому лучше делегировать это кому-то из ваших коллег. Это лучше потому что, время руководителя дороже времени инженера, инженер получит новый опыт обучения другого человека, прокачается и станет круче
Снижение стресса у сотрудника
Очень часто руководители об этом не задумываются, но новичок дико стрессует от всего нового. Надо явно с ним проговаривать, что является проблемой, а что нормой и во время корректировать его
Снижение издержек на онбординг
Так же важно стараться снижать затраты на обучение новичка. Если у вас для обучения новчика нужно фул-тайм привлекать лида или синьор разработчика, очевидно, что онбординг не очень эффективен и приносит больше вреда, чем пользы. Давайте резюмируем, для того чтобы снизить расходы, необходимо
- Автоматизировать настройку оборудования
- Описать правила работы в вашей команде
- Подготовить чеклист с материалами необходимым для прохождения
- Делегировать технические вопросы на бадди