Трудоустройство на новое место работы — стресс для сотрудника и хлопоты для команды, вовлеченной в процесс найма. При этом «мягкость» онбординга зависит лишь от того, какие меры приняла компания, чтобы новичок быстро вливался в коллектив и мог без проволочек приступать к рабочим задачам, а не тратить время на чтение инструкций.
Меня зовут Антон Гришин. Я продакт в медицинской компании СберЗдоровье. Когда-то я сам столкнулся с тяготами и лишениями трудоустройства на новую работу и после небольшого анализа понял, что эту проблему реально решить. Рассказываю, как медицинской компании СберЗдоровье удалось автоматизировать онбординг — с чего начинали, с чем столкнулись и что получили в итоге.
Признание проблемы через набитые шишки
Я устроился на работу в СберЗдоровье осенью 2022 года. Пришел на новый продукт, для которого только формировалась команда. Работа предстояла большая — на уровне построения космолета. Но сложность потенциальных задач пугала не меньше, чем вопросы, с которыми я начал сталкиваться с первых дней трудоустройства — СберЗдоровье динамично развивается, быстро «обрастает» новыми кадрами и имеет внушительную структуру с горизонталями по экспертизе и сотнями зависимостей, в которых надо разбираться. Это сделало мой онбординг и испытательный срок довольно насыщенным. Отчасти ситуацию усложнял тот факт, что в документации отдела не было ответов на некоторые возникающие вопросы.
После знакомства и общения с лидами команд и направлений стало понятно, что с появлением сложностей на этапе онбординга сталкиваются многие новички — например, им сложно понять, как работает команда, отдел, бизнес-стримы и другие направления.
Примечательно, что для каждой компетенции был свой набор документации по онбордингу — то есть артефакты были, но разбираться с ними в одиночку довольно сложно. Именно поэтому уже к тому времени в разработке у HR был проект Бадди — по сути, это специалист, который «ведет за руку» на всех этапах онбординга.
Поскольку я к тому моменту был менеджером проекта, я понимал, что в перспективе онбординг новых сотрудников ляжет на мои плечи. Допускать ситуаций, при которых новичок оставлен один на один с вопросами, недопустимо. Но и постоянно в ручном режиме решать возникающие ситуации — тоже не вариант, ведь основной пул задач направлен на построение нового продукта.
В итоге я с инициативной группой решил сделать фреймворк онбординга, с прицелом на автоматизацию и масштабирование на сотрудников всех департаментов.
От проблемы к исследованиям
На этапе формирования идеи нам надо было решить несколько ключевых задач:
создать единый процесс онбординга — от заведения заявки на найм до завершения испытательного срока;
понять, какие роли на каждом этапе выполняют полезные действия и оставляют после себя артефакты для следующих этапов;
раскатать этот процесс по статусной модели и закрепить за каждым статусом чек-лист для каждой роли;
желательно автоматизировать все процессы подручными способами.
Начали с определения этапов на пути от выявления потребности в новом специалисте до его окончательного трудоустройства. Таких получилось четыре: инициация найма, найм, выход на работу и испытательный срок.
Для детализации каждого этапа и выявления потенциальных сложностей, мы условно разделили всех будущих пользователей фреймворка на несколько групп.
Новые сотрудники — ключевые носители опыта, которые проходят через всю воронку онбординга.
Рекрутеры — отвечают за найм от инициации до оффера и передачи сотрудника в компанию.
HR — отвечают за встречу, презентацию компании, дальнейшую адаптацию и решение общих вопросов.
Лиды компетенций — отвечают за стек, знакомство с системами, поясняют специфику работы по конкретному направлению, готовят гайды и помогают профессионально прокачиваться.
Менеджеры команд — отвечают за адаптацию в команде и знакомство с продуктом, дают обратную связь по новым сотрудникам.
СТО — главные интересанты усиления команд и закрытия потребностей команд в найме.
Мы провели интервью с представителями каждой группы и постарались узнать:
какие есть специфические требования;
какие проблемы чаще возникают на разных этапах;
что должно стать результатом каждого этапа;
что хочется изменить, улучшить или добавить.
Результаты мы упаковали в огромную карту, в которой декомпозировали этапы и подсветили основные проблемы.
Подобное структурирование ответов и их аналитика позволили нам выделить общие потребности:
новый сотрудник хочет понятных шагов и спокойной интеграции в процессы;
лид компетенции и команда хотят, чтобы новый специалист максимально быстро начал выполнять поставленные задачи, а не париться организационными вопросами;
HR хочет, чтобы сотрудник чувствовал себя комфортно и, желательно, никуда не убежал.
На основе всей проделанной работы мы построили модель, в которой выделили четыре роли участников (сотрудник, менеджер команды, лид компетенцией и HR) и шесть этапов онбординга (от первого дня до завершения испытательного срока).
Для каждой роли и каждого этапа мы разработали индивидуальный чек-лист, в основу которого легли наработки по проекту Бадди.
Нам оставалось только решить вопрос автоматизации в условиях отсутствия ресурсов на разработку. В поисках вариантов мы решили сделать упор на использование общих инструментов — форм, трекера, вики.
Механику автоматизации на этапе MPV выбрали следующую:
На этапе найма рекрутер заполняет форму с необходимыми атрибутами для определения команды, специализации, ответственных по ролям.
Форма генерирует 4 задачи по новому сотруднику, которые попадают на отдельную доску и автоматически назначают исполнителей.
Задачи ходят по доске автоматически, пополняя чек-лист соответственно этапу испытательного срока.
Дополнительно трекер проверяет активность в задачах и напоминает о необходимости выполнения чек-листа, а также предупреждает о переходе задачи на следующий этап.
Наш прекрасный техсаппорт помог нам это все связать и автоматизировать, за что им низкий поклон. Надя, ты лучшая!
Пилотный запуск, доработки и первые факапы
После завершения подготовки мы решили протестировать реализованное решение на живых пользователях. Поскольку команда СберЗдоровья растет довольно динамично, найти несколько человек для теста новой системы онбординга не составило труда. Лиды, менеджеры команд и HR также приняли участие в тесте. В итоге мы заполнили форму для генерации задач на доску и стартанули.
Первые объективные и информативные результаты исследования мы смогли получить спустя месяц — за это время сотрудники успели пройти часть этапов онбординга и дать обратную связь. На их основании мы сделали некоторые доработки:
оптимизировали чек-листы — упростили формулировки и убрали лишние пункты, которые не несли никакой практической полезности;
доделали скрипты уведомлений-напоминалок, которые оказались слишком назойливыми;
откорректировали правила ведения онбординга со стороны лидов компетенции — некоторые лиды не успевали онбордить весь поток подопечных, поэтому мы придумали роль «Наставник», чтобы лид компетенции мог делегировать новичка опытному специалисту.
После пилотного запуска мы провели внутренние презентации на рекрутеров, лидов и HR… и случился Его Величество Факап — я сильно облажался.
Причина была довольно простой и очевидной — эгоистичный фокус на проблемах ИТ-команд и слепая вера в то, что ради общего блага можно закинуть дополнительный процесс рекрутерам, привели к непринятию нового процесса группой ключевых участников. В итоге рекрутеры, с которых все начинается и которые владеют нужными для старта данными, банально не успевали вручную заполнять формы — дополнительная нагрузка оказалась чрезмерной.
Как результат, нам понадобилась еще одна итерация доработок, в ходе которой мы закрыли возникшие боли.
Погрузились в инструменты рекрутеров, их чек-листы. Пришли к выводу, что рекрутеры используют общий трекер, у них есть своя доска и своя статусная модель. В итоге изменили механику, чтобы наша потребность в базовой информации для генерации задач онбординга ложилась в привычные для коллег действия.
Внедрили форму по новому сотруднику в процесс на доске рекрутмента. Теперь при переносе в статус «Оффер принят» появляется форма, которая генерирует задачи на доску онбординга.
Перенесли внутренний чек-лист рекрутеров в трекер и автоматизировали инициацию задач рекрутера из того же события, что и для онбординга.
Подобные доработки помогли нам исключить блокировку на отдельных этапах и вернуться к исходному сценарию работы с системой.
Завершив подготовку системы автоматизированного онбординга, мы подготовили подробную документацию и визуализацию процесса, а также представили систему на общей ИТ-синхронизации. После этого мы сделали релиз решения для всех ИТ-специалистов компании.
Первые результаты
К настоящему моменту автоматизированный процесс онбординга новых сотрудников работает уже более полугода. За это время решение было дополнено дашбордом в Superset для мониторинга активности и метрик прохождения испытательного срока.
Тест-драйв подхода показал положительные результаты.
основная цель была достигнута — процесс стал понятным и прозрачным для всех участников;
процесс стал управляемым — дашборд упрощает отслеживание команд и специалистов, которые халатно относятся к онбордингу новичков;
бонусом стало то, что за время подготовки внутреннего продукта мы упорядочили и систематизировали документацию по всем компетенциям.
При этом мы не смогли уйти от основного недостатка — онбординг по-прежнему зависит от человеческого фактора. Но мы сделали все, чтобы сотруднику в процессе не приходилось изобретать велосипед, а этапов, где можно совершить ошибки, было минимум.
Сейчас продукт передан под бережное покровительство HR-отдела, но наша команда помогает его поддерживать и развивать. Так, в перспективе мы планируем закастомить чек-листы под конкретные компетенции и продуктовые стримы, добавить типовые стартовые задачи для новичков, улучшить систему уведомлений внутри трекера и не только.
Главные выводы из нашего опыта
Онбординг — важный этап адаптации нового сотрудника в компании. Причем это обоюдный вопрос — от того, как выстроен онбординг, зависит как «порог входа» для новичка, так и количество хлопот, с которым приходится сталкиваться HR, лидам и менеджерам.
Наведение порядка в процессе онбординга — не обязательно быстрый и простой путь. Например, для построения системы, в том виде, в котором она сейчас существует, нам потребовалось полгода. Но подобные затраты времени и ресурсов с лихвой оправдывают себя — мы избавились от хаоса при найме, а нагрузка на HR, лидов и менеджеров снизилась.
В попытках автоматизировать онбординг лучше опираться на опыт команд и особенности их операционных процессов — внедрить нововведение будет проще, если всей команде не придется переучиваться с нуля. Чем нативнее вносятся изменения, тем быстрее можно получить результат.
Ошибки и факапы неизбежны. Но именно они помогают сделать продукт лучше и практичнее. Главное — найти решение, которое устроит всех вовлеченных в процесс участников.
Работа над автоматизацией онбординга не должна заканчиваться после внедрения. Доработки и планомерное расширение возможностей — именно то, что поможет создать «долгоиграющий» продукт, который будет полезен компании не один год.
