Онбординг в распределенной команде: как эффективно и быстро ввести новых сотрудников в работу

Привет! С вами снова Руслан Остропольский, Head of PMO В СберЗдоровье.

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

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

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

- Быстрый и более управляемый вход в работу.

- Долгосрочные отношения. Мы хотим, чтобы наши сотрудники были с нами 3, 5, а может быть и 10 лет. Нам неинтересно набирать людей, которые через пол года уйдут. Онбординг помогает понять насколько мы друг другу подходим.

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

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

- Снижение нагрузки на руководителя. Никому не хочется вводить людей в работу самостоятельно, особенно во время быстрого роста. Если за квартал нужно нанять 30 новых сотрудников, то руководитель вообще ничем кроме найма и ввода в работу заниматься не будет.

Предположим, к вам приходит новый сотрудник. Предположим, его зовут Гордей. Гордей — новенький и очень хочет как можно скорее влиться в команду. В первые часы работы рядом с ним есть несколько человек: руководитель отдела, тимлид и HR. Кто из них должен вводить Гордея в процессы?

Правильного ответа здесь нет, есть только разные подходы. Мы проходили буквально через каждый из них — они менялись вместе с нашим ростом: от самых простых (для небольших команд) к тому формату онбординга, где мы сейчас.

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

Можно позволить себе, если у вас маленькая команда.

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

Тратится много времени руководителя.

Очень долгий вход в работу.

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

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

С этим подходом есть одна проблема. Представим, что в отделе есть 3 старших сотрудника, каждый из которых работает на свои 100%. Когда приходит наш Гордей, его эффективность вряд ли превышает 50%, а скорее всего она еще ниже. Гордей начинает работать с наставником, и производительность этого наставника неизбежно падает. При этом, нагрузка и задачи компании никуда не уходят — они ложатся на остальных сотрудников. В скором времени либо кто-то начнет подгорать, либо ваш отдел будет просто выполнять меньше задач.

Одна точка входа.

Управляемый ввод.

Свобода рук руководителя.

У наставника падает эффективность работы.

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

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

Долгий вход в работу.

Такой подход лучше всего подходит для больших команд, особенно если сотрудники работают удаленно. Все достаточно просто: Гордей выходит на работу, проходит максимум одну вводную встречу и затем погружается в Wiki Quick Start — подробное и пошаговое описание того, что ему нужно делать. Какое-то время Гордей идет по Wiki, делает все, что там написано, и один раз в день синхронизируется со своим тимлидом.

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

- Культура и ценности команды

- Административные моменты

- Организационные моменты

- Инструменты и доступы

- Проекты и команды

- Процессы.

Мы используем Wiki уже достаточно давно и за это время у нас накопилось несколько не самых очевидных, но крайне полезных советов и лайфхаков:

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

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

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

Прописывайте DoD — Definition of Done. В свое время к каждому пункту мы добавили четкое и понятное описание того, что мы вообще ожидаем от человека после того, как он пройдет онбординг. Добавляйте контакты в помощь. Здесь все просто — я советую добавить в Wiki контакты людей, которые лучшего всего знают тот или иной функционал или систему, чтобы Гордей в случае чего мог обратиться к ним напрямую.

Не тратим время руководителя и сотрудников на ввод.

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

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

Это подходит только для исключительно самостоятельных людей. В первые два раза этот подход у нас сработал на отлично. После этого все почему-то сломалось: люди все равно приходили с вопросами и что-то уточняли.

Долгий вход тоже никуда не делся.

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

#разработка #онбординг #адаптация #менеджмент