Привет! Я Евгений Антонов, ведущий технический менеджер проектов в Yandex Infrastructure. В ИТ‑индустрии за 17 лет успел поадминистрировать, поразрабатывать и поруководить. Работал на многих позициях в разных компаниях — аутсорсных и продуктовых.

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

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

Компании разные, проблемы одинаковые

Вообще, в онбординге часто распространены одни и те же проблемы. Многие коллеги по индустрии сталкивались с ситуацией, когда онбординга в компании совсем нет или он минимальный: руководитель просто отдаёт ноутбук с преднастроенным ПО, а дальше делай что хочешь.

Я знаю типичные истории из крупных и скрипучих энтерпрайзов: человек устроился на работу и несколько недель просто ждёт, когда ему наконец дадут доступы. Такое ожидание может длиться 1–2 месяца. Программист спит, а оклад идёт.

Или встречал совсем гротескный пример: руководитель забыл, что к нему выходит новый сотрудник. Никого не предупредил, место не подготовил, рабочий компьютер не запросил, пропуск не сделал и уехал в отпуск. Человек пришёл, а его охранник не пускает в офис.

В итоге человек сидел в коридоре перед дверьми офиса на диване и два дня работал с личного ноутбука. Хорошо, что не с телефона.

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

• Первая проблема — репутационные риски. Думаю, многие читали статьи на Хабре или VC, где разгневанные, униженные, оскорблённые разработчики, менеджеры или другие сотрудники изливают свой гнев и рассказывают, как ими не занимались, как им ничего не объяснили, не показали, не дали. В нашем маленьком, уютном мире IT такие неприятные слухи быстро расходятся из уст в уста, и в дальнейшем будет сложно «отмываться» и нанимать новых людей в команду, так как испортится HR‑бренд.

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

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

Так что ответ на вопрос «Кому выгоден хороший онбординг?», на мой взгляд, очевиден — он выгоден всем. В первую очередь — работодателю. Чем лучше будет онбординг, тем быстрее люди начнут приносить пользу, меньше будет бестолковых трат времени и денег, а шанс построить долгосрочные трудовые отношения с человеком вырастет.

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

Общий и локальный онбординг

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

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

Но суть предлагаемого мной процесса от этого никак не меняется.

Общий онбординг — вовлечение в дела компании. Обычно за это отвечает HR‑отдел, а если компания небольшая, то специалисты по кадровому документообороту, делопроизводители или другие люди, которые ориентируются во внутренних документах и готовы рассказать новичку, когда и как выдают зарплату, как оформить ДМС, как написать заявление на командировку, как использовать корпоративное такси, оформить отгул и т. д.

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

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

Чтобы новичок попал во все эти нужные документы, существует самый простой вариант такого общего онбординга — обычное приветственное welcome‑письмо.

Наверное, многие с этим сталкивались — при трудоустройстве в компанию вам приходит письмо, в котором написано: «Здравствуй, дорогой Вася / Петя / Маша! Ты у нас работаешь, мы все тебе рады. Хочешь узнать про отпуск — сходи по этой ссылке, вот документация; хочешь узнать про ДМС — сходи по этой ссылке, вот документация».

Я такие письма получал и очень им радовался. Они действительно помогали, и я надолго погружался в эту документацию. У меня всегда очень много вопросов, как мне в дальнейшем жить и работать в компании, мне всегда это было интересно. И я искренне благодарен тем людям, которые такие письма составляют.

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

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

В общем, если у вас этой документации нет, не поленитесь и напишите. Тогда и онбординг настроите, и доброе дело всей компании сделаете, потому что без этого никак.

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

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

Локальный онбординг тоже хочу разделить на две части. Первая — официальная часть, где вы погружаете человека в процессы, которые у вас есть в команде: все Scrum-Agile, митапы и ретро-груминги, как у вас делается код-ревью и делается ли вообще, какие у вас код-стайлы и средства для коммуникации, какие доступы, проекты и архитектура в проектах, какие бизнес-процессы в этих проектах заложены, кто с кем как общается из смежников. Это всё, что нужно знать для выполнения работы.

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

Инструкции в онбординге: пишите сами, просите новичков

Как фиксировать инструкции. Роковая ошибка многих заключается в том, что они предпочитают не заморачиваться. Тимлиду говорят: «К тебе завтра / послезавтра / через неделю придёт новый сотрудник. Готовься». А он думает: «Зачем готовиться? Я и так всё знаю. Там приключение на 20 минут, зашли и вышли. Ничего не надо».

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

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

Первоначальное написание такой инструкции — это задача тимлидов. Но если мы годами в проекте — мы всё знаем, нам всё и так понятно, то мы думаем: «Зачем какие‑то мелочи описывать? И так всё ясно, две строчки только накидаем». Глаз тимлида замылен его опытом. У новичка нет такого контекста, он многое тут видит впервые.

Я рекомендую произвести мысленное упражнение:

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

• Представили? А теперь по горячим следам попробуйте написать какой‑то регламент, инструкцию: что нужно сделать этому новому человеку. Может быть, какой‑то софт поставить, где‑то зарегистрироваться, какие‑нибудь календарики завести, встречи в расписание добавить, заявки на доступы отправить, какую‑то доку по проекту прочитать.

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

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

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

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

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

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

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

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

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

Ожидания и дорожные карты

Отдельная боль и отдельная тема, на которой хотел бы остановиться, — это ожидания от работника. К сожалению, некоторые работодатели сами не очень понимают, чего хотят получить от человека. «В компании медленно релизится продукт — давайте наймём трёх разработчиков, закинем их в команду». А почему 3? А почему не 1 или не 5? А что они будут делать вместе? Что будет делать каждый из них? Как потом разбираться, прошёл ли каждый из нанятых испытательный срок? Непонятно.

Работодателю нужно понять, чего он хочет от работника, которого наняли: что конкретно он должен делать, чтобы было хорошо и ему, и компании. И важно сразу проговорить с человеком эти ожидания. Потому что иногда нового сотрудника словно бы выбрасывают в озеро из лодки: куда хочешь, туда плыви. И вот человек плывёт и не знает, доплыл ли он, и вообще, в ту ли сторону плыл?

Ещё пример. Один мой товарищ как‑то устроился в компанию, ему сообщили, чего от него ждут. При этом что‑то не подрасчитали, ожидания оказались огромными, и в первый месяц он выдал аж 250 рабочих часов. К концу этого месяца он не то что в этой компании работать не хотел, он уже в целом работать не хотел. Хотел в отпуск, говорил: «Всё, хватит, мне надоело».

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

Поэтому когда вы будете проговаривать ожидания от работника, сразу сообщите ему, что мы не высекаем это в камне, это не какая‑то недвижимая вещь. Всякое бывает, и как только мы узнаем, что изменилось что‑то, — дадим знать. И ты, если понимаешь, что переоценил свои силы или мы что‑то недооценили, не успеваешь, не получается, — скажи! Мы это выслушаем, мы открыты к диалогу, к разговору.

И не забывайте, пожалуйста, про промежуточный контроль. Хоть иногда приходите, заглядывайте, спрашивайте, как дела, какие сложности, чем помочь, где непонятно, что объяснить. Это не занимает много времени и сил. Просто спросить, посмотреть, а действительно ли в нужном направлении человек идёт. Нередко новички (даже опытные сениорные ребята) стесняются лишний раз спросить и попросить помощи. Поэтому могут зависнуть где‑то на дни, в то время как с вашей помощью справились бы за считанные часы или минуты.

Офбординг

Существует такое понятие, как «офбординг». Кто‑то использует его как синоним для слова «увольнение», но я же хочу его употребить в контексте того, как можно построить последние недели работы с уходящим сотрудником.

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

Мы наняли ей замену уже после того, как она ушла. Человек, пришедший на место, быстро и хорошо заонбордился. Примерно 80% своих задач и вопросов он закрыл этой инструкцией.

В остальных 20% ему помогли мы. Научили, вместе разобрались и попросили: «Теперь ты всё знаешь. Пожалуйста, дополни инструкцию, актуализируй её. Разберись и хорошими, понятными словами напиши». Он это сделал. Спустя 2–3 месяца мы наняли ещё одну сотрудницу, и она тоже хорошо заонбордилась по этой обновлённой инструкции. Её мы также проинструктировали, что если что‑то меняется, всё можно актуализировать.

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

Ещё немного советов

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

Ещё один важный момент: нужно подобрать подходящие вводные задачи новому сотруднику. С этим часто бывают проблемы.

Бывает, что человек приходит, и все: «О, новый человек пришёл! Сейчас посадим его багфиксить эту штуку, которая постоянно залипает». И в итоге человек багфиксит три месяца, а проект так и не понял, не разобрался, не изучил. Даёшь ему другую задачу про какой‑нибудь модуль, который рядом, а он не знает, что это такое. Умеет только вот эту небольшую гайку точить.

А бывает наоборот. Например, никому не хочется делать сложный рефакторинг ядра, потому что с ним проблем не оберёшься. Пришёл новый человек, и все такие: «Сениор, значит, сейчас мы ему задачищу дадим». И он сидит месяц, два. И вряд ли из его посиделок выйдет что‑то хорошее, потому что на ядре многое завязано. Он половину модулей сломал, не знает, как тестить, не знает бизнес‑логику, все кейсы. И проверять за ним потом плохо. И в итоге человек месяц‑два сидит с одной задачей, никак не может разобраться. И думает о себе, что его уволят, если он одну задачку сделать не может. В уныние впадает.

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

И заключительный совет: как отслеживать прогресс онбординга.

Видел, как один человек из тимлидского комьюнити под каждого сотрудника формирует доску в Trello и на ней следит за прогрессом нового сотрудника.

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

Компании разные, онбординг одинаковый

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

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

Везде это всё работало одинаково неплохо. Неоднократно я получал хорошие отзывы и от самих проходящих онбординг, и от тех, кто онбордит.

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

Итоги и TL;DR

Вот вы сейчас скажете: а тема‑то статьи «Система онбординга комфорт‑класса». В чём тут комфорт?

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

20% усилий, 80% результата. На мой взгляд, такой размен для большинства компаний вполне себе подходящий.

Итак, каким я вижу комфортный и эффективный онбординг:

• Не забудьте про стандартное welcome‑письмо со ссылкой на документы‑регламенты — это общий онбординг.

• Примите, что за локальный онбординг отвечает тимлид. То есть тимлид его готовит, а дальше решает: либо сам онбордит, либо делегирует и учит своих коллег.

• Обязательно готовьте инструкции и для проходящего онбординг новичка, и для ответственного за онбординг: кому, что и как нужно делать.

• Просите новичков, чтобы они эту инструкцию актуализировали. Если там что‑то неактуально или непонятно, то пусть пишут своими понятными словами.

• Готовьте вводные задачи, чтобы человек эффективно входил в рабочий процесс.

• Обозначьте ожидания, чтобы никто не выгорал, не делал бесцельную работу и не страдал потом от этого.

• Контролируйте процесс и прогресс онбординга. Не бросайте человека одного.

По моему мнению, с таким подходом онбординг точно станет комфортнее.

P. S. Если вам было интересно или полезно прочесть эту статью, то подписывайтесь на телеграм‑канал «Тимлид Очевидность», где пишу похожее про менеджмент, тимлидство и рабочие процессы.

А если вы любите подкасты (как люблю я), то есть ещё 2 подкаста, где я являюсь соавтором и соведущим.

«Кода кода» — и про технологии, и про менеджмент, и про вещи, которые в бытовой жизни интересны и применимы.

«Три тимлида заходят в бар» — строго про менеджмент и реальные истории из жизни руководителей разных уровней.