Самый эффективный способ ввести нового разработчика в вашу команду

Введение

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

В этой статье я покажу вам, как сделать процесс погружения нового разработчика в команду более плавным. Также я подскажу, на что следует обращать внимание, а чего делать не следует.

В первую очередь эта статья подойдет для объединения в команду опытных специалистов, но будет полезна и новичкам. Вам нужно добавить больше времени для обучения. Опять же, эта инструкция будет более полезна для компаний, где в команду интегрирован человек, а не вся компания, как Google.< /p>

План адаптации

Перед выходом нового сотрудника на работу

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

Итак, еще до того, как будет определена вера нового сотрудника, мы должны понять, что он будет делать. Это может быть не конкретная задача, а хотя бы услуга или товар.

Также еще до прихода работника должно быть определено оборудование, на котором он будет работать, а также все необходимые счета. Их необязательно создавать заранее, но если они еще не созданы, убедитесь, что все готовы создать их при необходимости.

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

Первый день

Было бы идеально, если бы вы приветствовали нового сотрудника в компании или были бы одним из его первых контактов. Для этого убедитесь, что вы участвуете в приветственной встрече. Если вас не будет в день релиза - не могли бы вы убедиться, что делегировали все необходимое коллеге и описали, что нужно сделать и сказали новичку?

Итак, человек получил техническую информацию, а вы убедились, что у него есть необходимые аккаунты в корпоративных системах и, самое главное, электронная почта и корпоративный мессенджер. Далее встречаемся лично или звоним - в случае удаленной работы. Дайте основную информацию о проекте, которым предстоит заниматься, и с кем. Поделитесь заранее созданным планом и запланируйте периодические встречи с кандидатом. Рекомендуемая частота встреч — несколько встреч в первые две недели и еженедельные встречи после этого. Запланируйте встречи во время и в конце адаптации, включая HR. Это будет полезно, потому что вам потребуется предоставить кандидату четкую и понятную обратную связь, о которой будут знать все заинтересованные стороны.

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

Часто у HR есть активности для новичков — пусть так и будет. Это будет полезно.

После этого вы могли бы позволить сотруднику переварить полученную информацию?

Что должно быть в плане на первые несколько месяцев?

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

Кто должен быть в этом списке?

Все члены команды, в которой будет работать сотрудник, должны присутствовать.

О чем с ними поговорить помимо общих тем?

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

* Разработчики должны говорить о том, как они пишут код, и о службах, за которые они несут ответственность. * QA инженеры расскажут о том, как определяется качество продукта. * Менеджеры проектов расскажут о процессах и артефактах в календаре/баг-трекере внутри команды. * Менеджеры по продукту могут говорить о бизнес-ценности продукта и планах внутри компании. * Тимлид, то есть вы должны рассказать о культуре команды и компании и ваших ожиданиях. * Архитекторы могут говорить на высоком уровне об ИТ-архитектуре компании и технических планах. * Дизайнеры могут говорить о дизайн-системе. * Аналитики могут рассказать о потоке данных в системе. * DevOps поделится знаниями об инфраструктуре. * Если вы считаете, что в списке должен быть кто-то еще, добавьте его.

Полезно, если вы не будете назначать эти встречи, а позволите сотруднику организовать их самостоятельно.

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

Чтобы показать, как работает весь процесс, попросите их выполнить первое развертывание функциональности в рабочей среде в течение первой недели. Пусть это будет самый минимум — изменить Readme, исправить опечатку или конкретную ошибку, но пусть новичок пройдет весь процесс создания ценности.

Пусть он пишет тесты, пусть его коллеги проверяют его код, пусть работает система непрерывной доставки, и пусть его код попадает в производство, где он увидит сообщение об этом в логах.

Наличие задач в плане помогает сотруднику ознакомиться с системами прав доступа/инцидентов и инструментами эскалации. Часто это сложно, и будет лучше, если у него будет опыт работы в спокойной обстановке.

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

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

В первые недели сотрудник невероятно наблюдателен к различным багам и недоработкам существующей системы — не могли бы вы попросить его подправить описание в системе хранения данных или описание сервисов, если это необходимо?

Несмотря на то, что первые недели адаптации у разных сотрудников одинаковы, оставьте запас в плане на вторую половину адаптации. Это делается для того, чтобы сотрудник мог приступить к выполнению явно подготовленных для него задач. Хотя они общеизвестны, подробности о них становятся известны лишь спустя некоторое время.

Кто отвечает за адаптацию?

За адаптацию нового сотрудника отвечает руководитель, но стоит задействовать всю команду. Ведь именно с командой у него будет наибольшее взаимодействие, поэтому было бы здорово, если бы каждый член команды принимал активное участие в адаптации. Делегируйте им как можно больше.

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

Привлеките HR к адаптации. У них большой опыт в этом, и они могут подсказать, как сделать это лучше.

Ошибки в процессе адаптации

Распространенной ошибкой является неуправляемая регистрация. Многие компании дают человеку задание, и ему приходится выполнять его самостоятельно. Ему не говорят об ожиданиях, дают обратную связь, а иногда и забывают о новом сотруднике. Это большая ошибка, потому что после длительного процесса найма прекращение заботы о сотруднике приводит к пустой трате ресурсов.

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

Заключение

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

Это поможет руководителю команды быть более объективным в оценке результатов испытательного срока, если он есть.

Пример 90-дневного плана показан ниже:

## Main outcomes
1. Implement specific features (list of features) for leading service of the company
2. Fix bugs in the authorization service
3. Become a tech owner of necessary processes (list of processes) in the company

## First day
1. Get equipment (laptop/desired licenses)
2. Conduct meetings with the manager and HR. Agreed about the 90-day plan. 3. Perform basic setup (email/slack)
4. Set up meetings with the manager and HR.

## First two weeks
1. Intro with every team member (developers/QA engineers)
2. Introduction with necessary colleagues (PM/PMO/Data Scientists/DevOps/Designers/Architects)
3. First deploy to production (Fix README in notification service)
4. Receive all necessary accesses from list <link_to_list>
5. Onboarding with HR (the day offs, vacations, sick days)
6. Get familiar with the team's services. 7. Get familiar with the team's slack channels (list of channels)
8. Read the <For Newcomers> page in Confluence. ## First month
1. Get familiar with the duty routine
2. Conduct two shifts on duty in shadow mode
3. Fix linter errors and README in owned payment service. 4. Add Facebook authorization to the authorization service

## Second month
1. Conduct two shifts on duty
2. Fix bugs in the authorization service (list of bugs)
3. Add remaining authorization ways to the authorization service
4. Intermediate performance check

## Third month
1. Become the owner of the process of monthly client notifications (know it, document it, lead it)
2. Leftovers from previous periods.