Приветствую, Хабр! Я, Полина, HR‑менеджер Digital HR компании «Улей». В прошлый раз я рассказывала о том, как в Улье устроен процесс онбординга. Среди комментариев был один, на который мне захотелось ответить подробно. Пользователь спрашивал, как устроен в нашей компании процесс адаптации разработчиков, как структурно выглядит погружение нового разработчика в продукт, ведут ли у нас новеньких наши текущие сотрудники и сколько они на это тратят времени? Сегодня постараюсь ответить на запрос и подробно расскажу, как мы онбордим разработчиков. И не просто разработчиков, а junior‑разработчиков.

Для начала определимся с терминологией. Мы понимаем под адаптацией — процесс, в ходе которого новичок осваивается на рабочем месте, а под онбордингом — целенаправленные действия, которые ускоряют и облегчают адаптацию, то есть онбординг — это часть адаптации.

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

Почему так? Потому что в любой компании работают не только программисты. В Улье выделено три направления: административное, коммерческое и техническое. У каждого направления есть специфичный онбординг, ориентированный на знакомство с конкретными инструментами и проектами. Но при этом сначала важно дать одинаковые вводные для всех сотрудников — познакомить новеньких со структурой и культурой компании, командой, рассказать, какие существуют каналы коммуникации и инструменты для работы. Поэтому любой разработчик в Улье проходит через общий онбординг.

Общий онбординг. Пребординг

Онбординг начинается с пребординга, цель которого минимизировать отвал кандидатов. С момента принятия оффера и до первого рабочего дня мы стараемся установить связь между кандидатом и компанией, чтобы снизить показатель отвала. По статистике 25% кандидатов, принявших оффер, отказываются от него. Мы не исключение, статистика Улья по найму за полгода:

• 288 первичных интервью,

• 56 интервью с экспертом,

• 20 офферов,

• 16 принятых оффера.

В среднем у нас 1–3 отвала за полгода, это, конечно, лучше, чем 25%, но с учётом воронки рекрутинга — это всё равно много. Если говорить о воронке по разработчикам, за полгода мы провели 24 первичных интервью и 18 интервью с экспертом; сделали 7 офферов из которых 4 были приняты. Отвалов по разработчикам у нас нет.

Пребординг особенно важен, когда до первого рабочего дня больше недели. Реалии таковы: как только кандидат получает предложение, соглашается и сообщает текущему работодателю о своём намерении сменить место работы — начинается… Уговоры, манипуляции, шантаж: от «мы повысим тебе ЗП» до «погасим ипотеку, переведём на новый проект с интересными задачами, откроем офис на Бали и перевезём тебя, семью и твою капибару». И уже согласившийся на оффер кандидат сдаётся и остаётся на своём месте, пакует чемодан и уезжает на Бали, а рекрутёр начинает поиск заново.

Что мы делаем, чтобы этого не случилось:

1. До даты выхода на работу обеспечиваем сотрудника всем необходимым:

1. Электронная почта, доступ к системам, подключение почты к CRM (для аккаунт‑менеджеров и руководителей проектов). Ответственный — специалист службы HelpDesk.

2. Задача на onboarding в портале. Ответственный — HR, руководитель нового сотрудника.

2. Поддерживаем контакт:

Когда до выхода кандидата меньше недели, и времени передумать почти не остаётся, то цель меняется: необходима корректная подготовка к выходу нового сотрудника, минимизация потери информации из‑за разделения ролей и зон ответственности. Как это бывает: кандидат после блестящего собеседования, очарованный харизмой руководителя и перспективой карьерного роста, выходит в свой первый рабочий день и… не находит стула у своего рабочего места, не принёс оригиналы документов, до кучи ещё и не настроены доступы… и каким бы классным не было интервью — новенький серьёзно задумается, а правильный ли он сделал выбор.

Что мы делаем, чтобы этого не случилось?

1. Анкета нового сотрудника.

2. Чек‑лист на выход нового сотрудника.

3. Список документов для трудоустройства.

Общий онбординг. Активная стадия

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

Что включает в себя активная стадия общего онбординга?

• Сопровождение процесса трудоустройства. Артефакты: памятка сотруднику перед выходом на работу со списком документов.

• Правила коммуникации в компании. Артефакты: База знаний, курс по коммуникациям).

• Знакомство с ценностями компании и её традициями. Артефакты: интерактивный обучающий курс.

• Изучение корпоративного портала и его возможностей. Артефакты: обучающие ролики, практические задания.

• Базовое изучение продуктов Улья. Артефакты: интерактивный обучающий курс.

На всё про всё — один, максимум три дня.

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

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

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

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

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

А теперь к специфике онбординга разработчика.

Специальный онбординг для джуниор-разработчика

«Процесс адаптации должен быть структурированным, но при этом гибким. Важно обеспечить новичку чёткий план на первые недели, который включает как знакомство с проектами, так и постепенное погружение в задачи. Сложнее всего для джуниора — разобраться с „правильной“ кастомизацией корпоративного портала и погрузиться в архитектуру наших решений. Преодолеть эти трудности помогает чёткое руководство, поддержка наставника и регулярная обратная связь», — Павел Квашин, руководитель отдела разработки компании Улей.

Специальный онбординг идёт параллельно общему и начинается в первый рабочий день. Цель специального онбординга — передать новичку знания, необходимые для быстрой адаптации и начала работы.

Что включает в себя активная фаза онбординга разработчика?

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

2. Личная коммуникация с руководителем отдела разработки и тимлидом.

3. Самостоятельное изучением регламентов работы.

4. Изучение кодовой базы продуктов компании.

На всё про всё от семи до десяти дней.

Специальный онбординг. Наставник

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

Специальный онбординг. Самостоятельная работа над задачами

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

Как правило, первая задача для джуниор‑разработчика связана с устранением небольшой ошибки в настройках. Пример первой задачи:

Сейчас встречаются случаи, когда руководитель подразделения, который не является руководителем другого вложенного подразделения, отображается у себя в подчиненных. Необходимо убрать руководителя у себя из Подчинённых в блоке Доп. информация в карточке пользователя.

Пример задачи посложнее:

Создать свой новый компонент (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 раз в неделю.

Рядом будут: тимлид и руководитель отдела разработки. Вот что они думают об онбординге джуниоров и свой роли в этом процессе:

«Джуниор‑разработчик в команде — это не только риски, затраты времени на обучение и снижение производительности. При правильном подходе через несколько месяцев команда усилится и производительность вырастет», — Александр Змеевский, тимлид компании Улей.

Что можно улучшить?

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

1. Добавить одну встречу с тимлидом или руководителем отдела для того, чтобы пройтись по всем регламентам — done.

2. Добавить в чек‑лист несколько пунктов с первичной настройке рабочего места с ссылками на базу знаний — done.

3. Сделать более обширным мануал на тему виртуальных машин — в работе.

4. Переработать информацию о решениях в более удобоваримую форму, в таком виде она вся в короткий срок в голову не помещается — в работе, скоро done.

Вывод

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

Джуниор‑разработчик — молодой и неопытный специалист, которому необходимо пристальное внимание со стороны тимлида и наставника.

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