Онбординг junior-разработчиков: как сделать так, чтобы онбординг завершался словами «и жили они долго и счастливо»
Приветствую, Хабр! Я, Полина, HR-менеджер Digital HR компании «Улей». В прошлый раз я рассказывала о том, как в Улье устроен процесс онбординга. Среди комментариев был один, на который мне захотелось ответить подробно. Пользователь спрашивал, как устроен в нашей компании процесс адаптации разработчиков, как структурно выглядит погружение нового разработчика в продукт, ведут ли у нас новеньких наши текущие сотрудники и сколько они на это тратят времени? Сегодня постараюсь ответить на запрос и подробно расскажу, как мы онбордим разработчиков. И не просто разработчиков, а junior-разработчиков.
Для начала определимся с терминологией. Мы понимаем под адаптацией – процесс, в ходе которого новичок осваивается на рабочем месте, а под онбордингом – целенаправленные действия, которые ускоряют и облегчают адаптацию, то есть онбординг – это часть адаптации.
Итак, онбординг разработчика условно можно разделить на две части: общий и специальный. Для наглядности мы разработали таймлайн онбординг разработчика:
Почему так? Потому что в любой компании работают не только программисты. В Улье выделено три направления: административное, коммерческое и техническое. У каждого направления есть специфичный онбординг, ориентированный на знакомство с конкретными инструментами и проектами. Но при этом сначала важно дать одинаковые вводные для всех сотрудников – познакомить новеньких со структурой и культурой компании, командой, рассказать, какие существуют каналы коммуникации и инструменты для работы. Поэтому любой разработчик в Улье проходит через общий онбординг.
Общий онбординг. Пребординг
Онбординг начинается с пребординга, цель которого минимизировать отвал кандидатов. С момента принятия оффера и до первого рабочего дня мы стараемся установить связь между кандидатом и компанией, чтобы снизить показатель отвала. По статистике 25% кандидатов, принявших оффер, отказываются от него. Мы не исключение, статистика Улья по найму за полгода:
288 первичных интервью,
56 интервью с экспертом,
20 офферов,
16 принятых оффера.
В среднем у нас 1–3 отвала за полгода, это, конечно, лучше, чем 25%, но с учётом воронки рекрутинга – это всё равно много. Если говорить о воронке по разработчикам, за полгода мы провели 24 первичных интервью и 18 интервью с экспертом; сделали 7 офферов из которых 4 были приняты. Отвалов по разработчикам у нас нет.
Пребординг особенно важен, когда до первого рабочего дня больше недели. Реалии таковы: как только кандидат получает предложение, соглашается и сообщает текущему работодателю о своём намерении сменить место работы – начинается… Уговоры, манипуляции, шантаж: от «мы повысим тебе ЗП» до «погасим ипотеку, переведём на новый проект с интересными задачами, откроем офис на Бали и перевезём тебя, семью и твою капибару». И уже согласившийся на оффер кандидат сдаётся и остаётся на своём месте, пакует чемодан и уезжает на Бали, а рекрутёр начинает поиск заново.
Что мы делаем, чтобы этого не случилось:
До даты выхода на работу обеспечиваем сотрудника всем необходимым:
Электронная почта, доступ к системам, подключение почты к CRM (для аккаунт-менеджеров и руководителей проектов). Ответственный – специалист службы HelpDesk.
Задача на onboarding в портале. Ответственный – HR, руководитель нового сотрудника.
Поддерживаем контакт:
Когда до выхода кандидата меньше недели, и времени передумать почти не остаётся, то цель меняется: необходима корректная подготовка к выходу нового сотрудника, минимизация потери информации из-за разделения ролей и зон ответственности. Как это бывает: кандидат после блестящего собеседования, очарованный харизмой руководителя и перспективой карьерного роста, выходит в свой первый рабочий день и… не находит стула у своего рабочего места, не принёс оригиналы документов, до кучи ещё и не настроены доступы… и каким бы классным не было интервью – новенький серьёзно задумается, а правильный ли он сделал выбор.
Что мы делаем, чтобы этого не случилось?
Анкета нового сотрудника.
Чек-лист на выход нового сотрудника.
Список документов для трудоустройства.
Общий онбординг. Активная стадия
На этом заканчивается пребординг и начинается активный онбординг, цель которого дать общую информацию о компании, снизив эмоциональную нагрузку в первые рабочие дни.
Что включает в себя активная стадия общего онбординга?
Сопровождение процесса трудоустройства. Артефакты: памятка сотруднику перед выходом на работу со списком документов.
Правила коммуникации в компании. Артефакты: База знаний, курс по коммуникациям).
Знакомство с ценностями компании и её традициями. Артефакты: интерактивный обучающий курс.
Изучение корпоративного портала и его возможностей. Артефакты: обучающие ролики, практические задания.
Базовое изучение продуктов Улья. Артефакты: интерактивный обучающий курс.
На всё про всё – один, максимум три дня.
На протяжении всего онбординга с новым сотрудником проводятся регулярные встречи с целью скорректировать процесс для успешного прохождения испытательного срока. Всего в нашей практике четыре встречи с HR: в первый день, по итогам первой недели, по итогам первого месяца и встреча, завершающая испытательный срок с фидбэком от сотрудника.
Помимо HR, с новым сотрудником встречается его непосредственный руководитель. Основная цель этих встреч – наладить эмоциональное состояние и ответить на возникающие вопросы. На протяжении первого месяца встречи проводятся раз в неделю, а во втором и третьем – один раз в месяц или по просьбе сотрудника.
При оценке эффективности общего онбординга мы проводим анкетирование как сотрудников, так и их коллег, включающее широкий спектр вопросов.
В анкете для сотрудников, проходящих онбординг, акцент делается на их восприятие компании и адекватность ожидаемых условий. Вопросы охватывают различные аспекты, такие как уровень комфорта в первые недели работы, получение обратной связи от руководителя и понимание организационной структуры. Например, сотрудника спрашивают, насколько оправдались его ожидания, и хватает ли ему взаимодействия с непосредственным руководителем. Также важно выяснить, удалось ли ему наладить контакт с коллегами и насколько ему понятны его обязанности.
Параллельно проводится опрос для коллег, в котором внимание уделяется оценке работы нового сотрудника и его интеграции в команду. Коллегам задаются вопросы о качестве выполнения задач новым сотрудником и его способности соблюдать сроки. Они также оценивают коммуникативные навыки нового коллеги и его реакцию на критику. В анкете предусмотрена возможность оставить развёрнутый фидбек.
А теперь к специфике онбординга разработчика.
Специальный онбординг для джуниор-разработчика
«Процесс адаптации должен быть структурированным, но при этом гибким. Важно обеспечить новичку чёткий план на первые недели, который включает как знакомство с проектами, так и постепенное погружение в задачи. Сложнее всего для джуниора – разобраться с "правильной" кастомизацией корпоративного портала и погрузиться в архитектуру наших решений. Преодолеть эти трудности помогает чёткое руководство, поддержка наставника и регулярная обратная связь», – Павел Квашин, руководитель отдела разработки компании Улей.
Специальный онбординг идёт параллельно общему и начинается в первый рабочий день. Цель специального онбординга – передать новичку знания, необходимые для быстрой адаптации и начала работы.
Что включает в себя активная фаза онбординга разработчика?
Получение необходимых для работы доступов и регистрация на специализированных платформах, администраторами которых являются сотрудники отдела разработки.
Личная коммуникация с руководителем отдела разработки и тимлидом.
Самостоятельное изучением регламентов работы.
Изучение кодовой базы продуктов компании.
На всё про всё от семи до десяти дней.
Специальный онбординг. Наставник
В начале онбординга новому сотруднику определяют наставника. Это обязательно тимлид. Тимлид понимает стратегические цели проекта и может направить джуниора в соответствии с общими задачами команды. Кроме того, наставничество со стороны тимлида способствует созданию доверительной атмосферы, где новичок может открыто задавать вопросы и получать конструктивную обратную связь.
Специальный онбординг. Самостоятельная работа над задачами
После знакомства со всеми регламентами, командой, кодовой базой, обсуждения процесса разработки и правил работы с задачами наступает третий этап онбординга – самостоятельная работа над задачами по принципу от более лёгкой к более сложной в соответствии с уровнем подготовки. Джуниор-разработчику подбираются совсем простые задачи. Их цель просто показать весь путь от получения задачи исполнителем до её релиза. На этом этапе оттачиваются следование корпоративным требованиям в части кода и его оформления, ведение задачи.
Как правило, первая задача для джуниор-разработчика связана с устранением небольшой ошибки в настройках. Пример первой задачи:
Сейчас встречаются случаи, когда руководитель подразделения, который не является руководителем другого вложенного подразделения, отображается у себя в подчиненных. Необходимо убрать руководителя у себя из Подчинённых в блоке Доп. информация в карточке пользователя.
Пример задачи посложнее:
Создать свой новый компонент (ipr.staff, например, или ipr.user.list)
Реализовать в файле class.php получение данных о сотрудниках, а в template.php вызов main.ui.filter и main.ui.grid для вывода стандартного фильтра и грида соответственно.
Чтобы было проще, за основу можно взять стандартный компонент intranet.user.list, структура схожа, будет отличаться только выборка данных (фильтруем дополнительно) и групповые действия.
Дополнительный пример грида с фильтром уже из наших решений - assessment.360.templates.list из Оценки 360, там в том числе и несложное групповое действие есть (удаление записи)
На примеры посмотреть будет полезно, если с подобным еще не работал
Какую общую задачу решаем:
В КУ сейчас нет общего места для массовых операций над сотрудниками, а массовых операций потребуется много, первые, самые востребованные на текущий момент:
A) Массовая привязка сотрудников к схеме карьерных траекторий. Сейчас единственный способ это сделать - это через админку заходить в каждый профиль и привязывать их по очереди.
B) Массовый запуск развития. Сейчас просто это не возможно.
C) Явно позже потребуются различные массовые изменения: возможно установка имеющихся компетенций, возможно установка/смена текстовой должности, возможно каких-то других полей в профиле сотрудника.
Что делаем по этой задаче - только п.A., для чего нужно создать пункт "Сотрудники" в верхнем меню раздела, вывести его по умолчанию вторым, после личного кабинета. И по этому пункту меню должна размещаться страница по адресу /university/staff/ , доступная всем сотрудникам, и на которой должно выводиться:
В задаче велось активное обсуждения с вопросами и срачем полезным спором в комментариях:
И уже совсем сложная задача для джуниора:
ТЗ приложила
Макеты по ссылке (мы её удалили из статьи, да)
Пункт 3.5
В этой задаче исключительно создаем и добавляем перечисленные поля, прочий функционал из пункта будет в другой задач ,на прочие пункты ТЗ не смотрим, там много всякого.
а) Прогнозируемый % выполнения. Для промежуточной можно менять. Для итоговой нет
б) Комментарий к прогнозируемому % выполнения. Для промежуточной можно менять. Для итоговой нет. Пока сделать по аналогии с другими полями текстовым полем. (на макетах просто текст уже, но это к другой доработке)
Утвержденная - свойство Статус USER_GOAL_STATUS = Утверждена
Промежуточная - новый признак USER_GOAL_RATING_TYPE. Само свойство создано, но еще не заполняется, для тестов руками можно проставить у каких-то карт. Там либо Промежуточная, либо Итоговая
Контроль онбординга
Для контроля хода онбординга в нашей команде используются ежедневные пятнадцатиминутки со всеми членами команды. После которых идут one-to-one по выявленным на пятнадцатминутках необходимостям. Также со всеми новыми сотрудниками есть обязательный one-to-one раз в неделю.
Рядом будут: тимлид и руководитель отдела разработки. Вот что они думают об онбординге джуниоров и свой роли в этом процессе:
«Джуниор-разработчик в команде – это не только риски, затраты времени на обучение и снижение производительности. При правильном подходе через несколько месяцев команда усилится и производительность вырастет», – Александр Змеевский, тимлид компании Улей.
Что можно улучшить?
В своих анкетах обратной связи по онбордингу наши начинающие разработчики отмечают, что улучшить онбординг можно, если:
Добавить одну встречу с тимлидом или руководителем отдела для того, чтобы пройтись по всем регламентам – done.
Добавить в чек-лист несколько пунктов с первичной настройке рабочего места с ссылками на базу знаний – done.
Сделать более обширным мануал на тему виртуальных машин – в работе.
Переработать информацию о решениях в более удобоваримую форму, в таком виде она вся в короткий срок в голову не помещается – в работе, скоро done.
Вывод
Разработчик такой же сотрудник, как и все в компании, и ему не избежать общего онбординга: знакомства с компанией, её продуктами, ценностями, командой и локальными нормативными актами. Также ему не избежать и специального онбординга: знакомства с регламентами, кодовой базой и документацией.
Джуниор-разработчик – молодой и неопытный специалист, которому необходимо пристальное внимание со стороны тимлида и наставника.
Поэтому онбординг джуниор-разработчика должен быть комплексный, сочетающий в себе элементы общего и специального онбординга, а также включать в себя индивидуальную поддержку со стороны опытных коллег. Важно обеспечить плавный вход в команду, уверенность в своих силах и возможность быстрого овладения необходимыми навыками. Только так можно сделать онбординг действительно эффективным и позволить джуниору быстро и успешно интегрироваться в рабочий процесс.