{"id":14256,"url":"\/distributions\/14256\/click?bit=1&hash=b2f03b73766e298ad5a0f21b9f00bd3946a42f407f2db39dff35e9cc6d09b682","title":"\u041f\u043e\u0443\u0447\u0430\u0441\u0442\u0432\u043e\u0432\u0430\u0442\u044c \u0432 \u0445\u0430\u043a\u0430\u0442\u043e\u043d\u0435 \u0438 \u0432\u044b\u0438\u0433\u0440\u0430\u0442\u044c \u0434\u043e 700 \u0442\u044b\u0441\u044f\u0447 \u0440\u0443\u0431\u043b\u0435\u0439","buttonText":"","imageUuid":""}

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

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

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

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

Что такое онбординг и зачем он нужен

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

Цели онбординга

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

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

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

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

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

Эволюция онбординга в СберЗдоровье

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

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

Подход 1: Гордей и руководитель

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

Плюсы:

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

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

Минусы:

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

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

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

Подход 2: Гордей и тимлид

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

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

Плюсы:

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

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

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

Минусы:

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

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

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

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

Подход 3: Гордей делает все сам

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

Что входит в Wiki Quick Start?

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

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

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

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

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

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

- Процессы.

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

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

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

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

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

Плюсы такого подхода:

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

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

Минусы:

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

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

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

И что дальше?

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

0
2 комментария
Кирилл Чиркин

Лучший онбоардинг - это у ЕРАМ. Для каждого нового сотрудника сделана целая игра, как ознакомиться с внутренними регламентами и процессами.

Нужно пройти несколько курсов по различным тематикам.

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

Рекомендую подсмотреть у них.

Ответить
Развернуть ветку
Дмитрий Каратаев

А еще вот мне интересно:
Прием сотрудника начинается задолго до выхода сотрудника на работу
Ну или (если найм "пакетный") мы знаем сколько человек нам нужно
Тогда вот эти все истории с доступами в Jira/Git/Confluence/etc. могут ведь быть сделаны заранее?

Например, пусть нам нужно нанять 5 человек. Мы знаем их должности, круг обязанностей, полномочия и все такое ДО того, как они придут. Соответственно, мы можем подготовить 5 учетных записей под них в деактивированном состоянии, а также все необходимое на виртуалках и прочем (например, снэпшоты). А затем, когда они уже выйдут на работу мы просто переименовываем учетку на ФИО@mycompany.com и активируем ее, нет?

Ответить
Развернуть ветку
-1 комментариев
Раскрывать всегда