Handbook / Приветственное письмо

В момент выхода на работу сотруднику выдаётся handbook или высылается приветственное письмо. В этом артефакте концентрируется вся информация, которую нужно знать в первые месяцы работы, и инструкции о том, что нужно сделать в первые дни.

Вероятно, составление полноценного handbook-а лишено смысла для компаний меньше 30 человек, в которых всё на виду и проще ответить на вопросы на словах (но это не точно).

Какие проблемы решает Handbook

Такие же, как и онбординг в целом

У руководителей подразделений:
- Новые сотрудники долго выходят на "производственную мощность"
- Онбординг новых сотрудников забирает много сил
- Разобщенность подразделений
У knowledge-менеджера:
- Нужно привить культуру обмена знаниями
- Нужно исправить ошибки в базе знаний

== Инструменты онбординга и примеры их реализации:

Доклад Александра Афенова "Теория и практика knowledge sharing в Lamoda" об опыте использования различных инструментов knowledge management для повышения качества адаптации новых сотрудников.
Доклад Глеба Дейкало "Добро пожаловать на борт: вводим новых разработчиков в команду" с очень четким описанием такого инструмента, как адаптационный чек-лист (есть пример документа).

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

Определить "полную мощность" может, как правило, руководитель эмпирически, а также он может сформулировать формальные критерии (например: сотрудник самостоятельно решает какой-то класс задач, или какая-то частая задача начинает занимать меньше N времени, или какой-то формальный показатель достигает определённого значения).

С чего начать разработку и внедрение Handbook-а

Классические примеры handbook-ов:

Valve New Emoloyee Handbook — один из самых известных примеров.
GitLab Handbook. Обратите внимание, что GitLab — распределенная компания, они работают на удалёнке.
Tesla Anti-Handbook. Это нетипичный хэндбук. Он описывает разные ценностные и культурные вещи, вроде того, что каждый себя должен дисциплинировать сам, не делать глупых вещей, брать инициативу, просить фидбека, если хочешь фидбека, предупреждать об отсутствии, задавать вопросы. В целом, все это здравый смысл, но, вероятно, не всем очевидный.

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

Запуск пилотного проекта

Внедрение Handbook подразумевает:

Написание документа — скорее всего потребуется выяснять подробности у представителей разных специализаций (руководители производственных подразделений, HR, маркетинг, бухгалтерия, руководство компании).
Тестирование документа вместе с новичками — в самом простом случае это можно сделать либо путём опроса новичков и их руководителей, а в идеале — можно ежедневно сопровождать новичков, чтобы выявлять возникающие у них трудности.
Оценку отдачи — также, как и для прочих методов онбординга.
Обеспечение обновляемости — требует вовлечение в работу с Handbook всех руководителей, чтобы при изменении в критичных бизнес-процессах эти изменения отражались в handbook. Но на первых порах обновление может производиться силами и за счет инициативы knowledge manager-а.

Как обеспечить действительно полезное наполнение handbook-а и избежать карго-культа и бессмысленной писанины?

Масштабирование успеха

Со временем имеет смысл развивать несколько подходов

В процессе развития онбординга он может объединять несколько подходов.

В докладе "Добро пожаловать на борт: вводим новых разработчиков в команду" (статья) описана целостная система онбординга, включающая в себя: менторство в онбординге, экскурсию по офису, автоматизацию и трекинг процесса онбординга, правила составления Quick Start документа, практические задания, тестирование онбордящихся и идеи упражнений по проектированию.

Также стоит обратить внимание на доклад Александра Афёнова "Сверстать всех наверх: Онбординг новых сотрудников", он сменил несколько лидерских позиций в Lamoda и наблюдал масштабирование и изменение практик онбординга в компании, он считает, что в компании сложился фреймворк и делится им в докладе. В этот фреймворк входят следующие практики:

Buddy внутри команды, кому можно задавать вопросы, регулярно встречаться и передавать знания (это время учтено в спринт-планинге и поощряется на перфоманс-ревью);
Погружение в бизнес компании, в задачи и проблемы, что именно придётся автоматизировать: induction лекция на несколько часов о работе каждого департамента, о решении задач бизнеса, об успехах и провалах;
IT-онбординг: рассказ о процессах разработки, инфраструктуре, к кому с чем идти, история технических решений;
IT Gathering: сбор всего ИТ раз в квартал, куда мы идем и куда пришли, что нового, какие планы. С новичками говорят на равных.
Экскурсия на склад, рассказ обо всех производственных процессах, где новички видят, что они будут автоматизировать (опционально: экскурсия на фотостудию, создание контента для сайта и возможность побыть курьером-водителем, поразвозить заказы, подождать примерку и т.д.);
Q&A каждый день, выделенное время на задавание вопросов. Не замена 1-1 встречам.
Чек-лист: все, что человеку нужно освоить за определённый период, куда получить доступы и в чём поучаствовать, например, понять, что показывается на борде в Grafana.

Ещё один доклад от Руслана Остропольского из Сберздоровья про онбординг в распределенной команде (статья-выжимка на VC и слайды), он рассказывает о трёх подходах к онбордингу (лекция тимлида, наставничество и онбординг по плану из вики-системы) и их плюсах / минусах для разных ситуаций.

Докладчик поделился, что входит в их онбординг "квик старт":

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

Из интересных идей:

Структурируйте путь новичка в виде roadmap, чтобы он видел следующие шаги и последовательность действий;
Использовать вложенность страниц, делайте кросс-ссылки между разделами, например, про разработку и тестирование, так разные отделы могут поддерживать свои куски;
Используйте скриншоты и видео;
Добавляйте контакты в помощь;
Присваивайте каждому пункту Definition of done, что является результатом каждого шага или как проверить его выполнение.