На связи — Катя Лысенко и вторая часть статьи о системе онбординга новых людей в команду. Здесь поговорим о маршруте, ролях и последовательности в управлении адаптацией. Освежить в памяти материал вы можете по ссылке на первую часть.
В структуре онбординга, которую мы внедрили, получилось три ключевых части:
Геймификация — всё, что происходит до выхода, плюс квесты первых дней и встречи.
План онбординга — подробный маршрут, направляющий новичка через обучение, знакомства и задачи.
Self-Assessment — регулярная точка саморефлексии, через которую новичок понимает, куда движется и что с ним происходит.
Геймифицированная часть
Наш онбординг начинается задолго до первого рабочего дня. Холиварный вопрос — должен ли он вообще начинаться до того, как сотрудник вышел на работу. Кто-то скажет, это не онбординг, а пребординг и зона ответственности HR. Но мы смотрим иначе.
Наши HR делают свою важную часть: сопровождают кандидата, держат контакт, следят, чтобы он не «соскочил» после оффера. Но у команды здесь тоже есть задачи.
Одну классную практику я подсмотрела в крупной международной компании. После того как кандидат принял оффер (или даже отказался), ему отправляют подробную анкету про весь процесс интервью: понравились ли этапы, хватало ли информации о команде, насколько подготовленными были интервьюеры. И это не «для галочки»: HR реа��ьно собирают ответы, анализируют и обновляют материалы и процесс. Такой цикл обратной связи позволяет быстро чинить проблемы в найме и снижает уровень стресса у следующего поколения кандидатов.
До выхода сотрудника
Возможно, вы видели ролик, когда джун выходит на работу в крупную корпорацию:
«Сегодня первый день! Ну, я начну работать!»
— «Нет, ты будешь проходить тесты службы информационной безопасности».
Проходит два дня, тесты пройдены, ждёт первую задачу:
— «Теперь-то можно?»
— «Нет, теперь — получать доступы».
Проходит неделя — ноутбук не доехал, на своём работать нельзя. Потом — спринт на середине, поэтому: «Просто почитай базу знаний».
И вот две недели человек всё ещё нигде — потерян в какой-то бюрократической проволочке.
Мы тоже теряли на этом время, но быстро поняли, что многое можно автоматизировать или хотя бы заранее подготовить. Так родилась первая часть онбординга. В неё входит подготовка рабочего места, информационные материалы и назначение бадди.
Подготовка рабочего места
Мы заводим отдельную задачу: профили, логины, пароли, учётки — весь стартовый набор. Эту задачу курирует тимлид: следит, чтобы она появилась и двигалась по процессу, а выполняют обычно админы.
Нам понадобилось время, чтобы научиться договариваться. Мы подготовили для админов полную документацию: что подготовить для выхода сотрудника на конкретную позицию.
Раньше задачами на получение доступов занимался HR-департамент. Формально — чтобы снять нагрузку с команды. По факту это оказалось неэффективным звеном: HR не понимали технических нюансов, часто не хватало доступов, возникали лишние согласования, всё затягивалось. В итоге мы аккуратно вывели HR из этого процесса и передали ответственность тем, кто отвечает за инфраструктуру.
Что мы сделали:
Выработали единую матрицу доступов под команду с вариативностью по ролям (например, DEV, QA).
Определили базовые наборы доступов, которые требуются всем: VPN, Git, CI/CD, баг-трекинг, документация, внутренняя вики и т.д.
Согласовали базовый набор с ИБ заранее, чтобы не бегать за апрувом под каждого новичка. Теперь он выдаётся автоматически.
Для нестандартных доступов (например, временный доступ к продовой инфраструктуре) создаются отдельные задачи, с явными сроками и обоснованием.
Аналогично структурировали процесс с техникой: HR получают от команды рекомендации (например, «лучше Mac», до двух мониторов и т.п.), но сотрудник может выбрать — Mac, Unix или Windows.
Дополнительно навели порядок в ролях:
Разграничили, кто отвечает за выдачу конкретных доступов: часть — у админов, часть — у девопсов, часть — у службы ИБ. До этого координационной модели не было, и разные доступы «висели» на случайных людях.
Разделили стандартные и нестандартные запросы, чтобы сотрудник с первого дня мог спокойно настроить рабочее окружение, а не бегать за правами.
Отдельная оговорка: мы финтех, наше кредо — «безопасная безопасность». Типичная модель — выдавать доступы по капле, по одному за раз, с идеей «а вдруг украдут код». Мы сознательно отказались от этого подхода, потому что:
украденный код без контекста и инфраструктуры почти всегда бесполезен;
если у вас есть сотрудники с доступом к продовой БД с данными клиентов — проблема не в онбординге, а в безопасности в целом.
Поэтому мы выстроили процесс, при котором всё нужное сотруднику — и техника, и доступы — предоставляется максимально быстро, централизованно, с понятной матрицей и ответственными. Чтобы первые дни ушли на встраивание, а не на согласования.
Информационные материалы
Лид заранее формирует список материалов: что можно дать новичку ещё до выхода, а что — только после. Всё согласуем с ИБ, чтобы случайно не рассказать критичную информацию раньше времени.
Назначение бадди
На период онбординга у новичка нет обучающего наставника, но есть бадди, который который ведёт его по программе, корректирует план и помогает не потеряться. Кандидат на эту роль всегда выбирается заранее и должен «словами через рот» подтвердить, что согласен. И подготовиться к выходу коллеги:
изучить план онбординга;
актуализировать его под конкретного человека;
создать все встречи;
если чего-то не хватает — решить вопрос с лидом или менеджером.
План онбординга — не шаблон, а гибкая конструкция. Изначально за составление программы и её актуализацию отвечали я как менеджер и лид. Затем ядром команды её дотюнили, и теперь это зона ответственности бадди: он адаптирует план под конкретного новичка — его позицию, опыт, грейд и предыдущий контекст — и при необходимости перестраивает блоки.
Бадди снижае�� нагрузку с команды. У нас всегда либо кто-то онбордится, либо только завершил этот этап. И если каждый раз вовлекать всю команду, чтобы организовать онбординг, мы сойдём с ума — это заберёт слишком много ресурсов.
Важно понимать, что информационные материалы не статичны. Мы сознательно дополняем их после каждого онбординга. В финальном Self-Assessment есть обязательный пункт: что было полезно, чего не хватало, что можно улучшить. Мы просим новичков дать фидбек — и помочь нам сделать процесс лучше.
Более того, мы просим каждого в процессе онбординга дополнять свой персональный план, превращая его в живой документ, к которому можно возвращаться и спустя месяцы. Это помогает не только запомнить важные вещи, но и начать формировать свою базу знаний, набор ссылок и ориентиров по проекту. Мы не настаиваем на конкретном формате: кому-то удобны списки, кому-то схемы, кто-то переписывает всё в свой Notion или wiki. Единственная просьба — делиться хотя бы частью материалов. Это помогает актуализировать общую базу знаний и облегчает жизнь следующему поколению новичков.
Но есть граница: не всё индивидуальное нужно превращать в универсальное. Один человек может хотеть детализацию до уровня «куда нажать и сколько раз», которая другим только помешает. Поэтому мы фильтруем фидбек и оставляем то, что действительно полезно для следующих поколений.
Вот примеры улучшений, которые мы включили после обратной связи:
Инструкция по проведению первого платежа как клиента (или любого основного процесса в вашей компании/команде) — обычно эти материалы уже есть у support. Очень полезно для платформенных команд, которые не видят пользовательский UI.
Списки полезных контактов из других команд, особенно из инфраструктурных. Мы добавили встречу-знакомство новичков с админами, DevOps, SRE и Сloud-инженерами.
Отдельный раздел о работе с инцидентами и внештатными ситуациями — появился после того, как новичку по воле случая достался инцидент: один коллега был в отпуске, другой заболел.
Онбординг от гильд-мастеров. Этот блок появился, когда в компании окрепли гильдии. Их задача — помочь новичку не застрять в «командных шорах» и видеть, как устроены практики на уровне всей компании.
Коротко: гильдия — это сообщество специалистов одной области, а гильд-мастер координирует обмен опытом и лучшими практиками. Поэтому часть онбординга мы отдали: они дают широкий контекст, показывают стандарты и то, как принято «правильно» работать за пределами одной команды.
Квест первого рабочего дня
В первый рабочий день обязательно происходит встреча с HR, знакомство с бадди и встреча с командой.
Welcome-встреча с HR
Вначале новичок подписывает основные документы: трудовой договор, NDA, согласие на публикацию фото на корпоративном портале (хотя можно и отказаться).
У нас не очень большая компания и HR могут уделить больше времени каждому. Они не просто оформляют формальности, а помогают погрузиться в корпоративную среду: проводят экскурсию по офису, рассказывают, где завтрак и обед, где кофе и переговорки, где сидит команда и как устроен быт.
А ещё знакомят с ключевыми людьми, объясняют, к кому обращаться с разными вопросами, и дают первые ориентиры по внутренней культуре. Это неформальный, но очень ценный шаг: он помогает новичку быстрее почувствовать себя частью команды и снижает тревожность в первые дни.
2. Знакомство с бадди
На рабочем месте новичка встречает бадди. Первый день должен быть тёплым, чтобы новичок переживал как можно меньше — независимо от возраста и опыта.
3. Встреча с командой
Для знакомства с командой есть как минимум три варианта:
Знакомство на этапе собеседований, когда часть команды участвует в процессе оценки.
Знакомство после финальных собеседований, но до выхода — чтобы дать человеку больше контекста о будущей рабочей среде.
Формат, когда новичок впервые видит команду в начале работы.
Не всегда удаётся познакомить новичка с командой до выхода — тогда мы закладываем эту встречу на первый рабочий день.
Я сознательно не продвигаю ни один из вариантов как единственно верный — это вопрос внутренней культуры конкретной компании и команды. Но есть исключение: на управленческие позиции (лиды, менеджеры и выше) знакомство с командой до выхода считаю обязательным. Бывают кейсы, когда человек выходит, общается пару дней и понимает: работать он готов где угодно, только не с этой командой. А если пересобрать команду ему не дают, обе стороны оказываются в положении вынужденного сосуществования с разными ценностями. Итог — страдание и разрыв.
Но я встречала и другие примеры: команда просила не знакомить её с кандидатами заранее (речь не о менеджерских ролях), ссылаясь на занятость и доверие к тем, кто проводит интервью. Аргумент звучал так: «если собеседует тот, кто понимает наши ценности, значит, и человек нам подойдёт — зачем лишние встречи».
Есть и промежуточный вариант: предложить кандидату познакомиться с командой, но решение оставить за ним. Кому-то важно пообщаться заранее, кому-то достаточно контакта на интервью. И да — мы стараемся приурочить знакомство новичка и команды к обеду или к кофе после обеда. Чтобы первое общение прошло без стресса, в неформальной и дружеской атмосфере.
4. Проверка рабочего места
Новичок подписывает соглашение об использовании техники и ПО — это приносит сисадмин. Вместе они проверяют, что на рабочей машине установлено всё необходимое, открыты доступы и готово рабочее окружение. Обычно мы ставим стандартный набор софта заранее, а потом уточняем, что добавить.
На все эти шаги уходит почти весь день с учётом перерывов.
Квест второго рабочего дня
Если первый день — это знакомство и раскачка, то второй — уже погружение в контекст. Здесь новичку предстоит:
Обсудить план онбординга.
Познакомиться с культурой компании и рабочими процессами команды.
Проговорить персональные цели.
Обсуждение плана онбординга — длинная встреча новичка и бадди на полтора-два часа. Бадди рассказывает: кто он, чем занимается, как его найти, какие встречи запланированы, в какой последовательности они идут и с кем новичку предстоит взаимодействовать. После этого у человека появляется чёткая картина, как устроены следующие этапы его пути.
На этой же встрече (или на следующей) бадди объясняет культуру команды и рабочие процессы. Например, наша команда живёт по Kanban, а мы понимаем, что далеко не все с ним работали. Более того, не все вообще жили по Agile. Поэтому важно, чтобы человек, услышав «стендап», «каденция» или «груминг», не начал паниковать. Или не упал в обморок от фразы «У нас есть для тебя обратная связь», решив, что его в этот момент увольняют.
Считаю, что проговаривать всё устно — один из основных инструментов.
Если после всех встреч остаётся время, новичок начинает потихоньку изучать материалы и вникать в то, что ему предстоит делать.
Полгода встреч
Дальше ещё шесть месяцев встреч. Я искренне считаю, что онбординг за три месяца испытательного срока — это не так уж много. А онбординг за месяц-полтора, как об этом обычно говорят, даже странно — ты немножечко себе врёшь.
Конечно, бывают случаи, когда человек за пару месяцев успевает погрузиться в специфику компании, и это здорово. Но будем честны: если у вас сложный домен и вы нанимаете мидла, а тем более джуна, то сначала нужно обучить процессам и домену, по дороге показать работу с кодом и много другой специфики. А ещё есть культура компании и команды.
Важно дать человеку время нормально всё усвоить. Наша задача — чтобы к концу шестимесячной адаптации коллега мог рассказать, как работает весь продукт, почему реализована та или иная фича, и как она должна быть исполнена в конечной реализации. Тогда считаем, что онбординг удался.
Что важно успеть новичку к концу первых шести месяцев:
Проверить, что получены документы.
К концу онбординга у нас появляется проверка на получение документов. Это бюрократический процесс: вне зависимости от страны сотруднику нужно что-то подать, что-то забрать или активировать. Мы расписываем это заранее.
Подготовить Self-Assessment.
Процедура, когда человек самостоятельно оценивает, как он прошёл путь, чего достиг, куда хочет дальше. И запрашивает обратную связь.
Пройти встречу-оценку на 90 дней с руководителем (менеджером и лидом) и HR-департаментом.
Через три месяца, в середине онбординга, смотрим, как складывается взаимодействие, соответствует ли сотрудник роли и насколько совпадают наши ожидания.
Пройти встречу-оценку на 180 дней с руководителем(ями) и HR-департаментом о завершении испытательного срока.
На этой встрече мы финализируем онбординг: дальше сотрудник официально считается встроенным в команду и может участвовать в формировании карты компетенций StarMap. Мы формируем её все вместе, чтобы видеть, каких компетенций не хватает и вовремя их закрывать.
StarMap — это практический инструмент оценки и развития команды. По сути, карта компетенций, которая показывает:
где каждый находится по скиллам и уровню зрелости;
кто может быть ментором, а кому нужна поддержка;
какие зоны новичок закрывает уже сейчас, а куда нужно вложиться;
кого и под какие задачи нанимать;
как выстраивать развитие и мотивацию;
как организовать внутреннее обучение и менторство.
Лет 6–8 назад StarMap был на слуху у всех — особенно в HR и team-management. Сейчас же часто встречаю ситуацию, когда даже опытные HR-специалисты либо не используют его, либо вообще не слышали. Хотя инструмент по-прежнему рабочий: просто его вытеснили новые модные презентационные фреймворки и «one-pager’ы», которые проще вставить в красивые слайды. А зря.
План онбординга
План онбординга — это основная памятка, путеводный лист, который помогает новичку не потеряться в задачах. Доступ к странице только у четверых: новичка, бадди, лида и менеджера. В ней собрано всё:
Образовательные ресурсы и ссылки.
База знаний.
Задачи на получение железа и доступов.
Важные встречи и их смысл.
Стартовые ориентиры, чтобы не заблудиться.
У плана три основные цели:
Понимание, что ожидается на испытательный срок со стороны новичка.
Мы прописываем, что ожидаем от нового коллеги: приоритеты, даты, контрольные точки. Это ориентиры — куда примерно он должен прийти, потому что на момент выхода мы сами до конца не знаем, кто перед нами. Это может оказаться вовсе не хороший Automation QA, а отличный перформер; не классный бэк, а крутой DevOps. Наша задача как команды и компании — разобраться за период онбординга и встроить сотрудника в то место, где он сможет раскрыться.
2. Прозрачность и понимание всеми сторонами процесса и прогресса.
3. Организация погружения и вовлечение сотрудника.
В плане мы детально расписываем: когда и какую минимальную базу нужно изучить, какие доменные знания усвоить, где и что про это написано.
Из чего состоит онбординг
Всё начинается с общих вводных:
Контакты бадди
Задача на получение доступов
Задача на получение железа
Дальше мероприятия плана. Они разбиты на несколько блоков:
Что изучить самостоятельно
Это список материалов: база знаний, документация, гайды по внутренним процессам. Есть и отдельная база, собранная через техтолки, демо и внутренние доклады — всё, что касается специфики работы. Новичок изучает это сам, но велик шанс, что бадди ещё и «погоняет» его по ключевым разделам.
Например, наша команда живёт по Domain-Driven Design. У нас единый язык, и мы считаем, что каждый должен его понимать. Если человек за 3–6 месяцев не научился отличать потенциального клиента от клиента — значит, где-то недоработали и мы, и он. Наша задача — сократить количество таких ситуаций.
2. С кем встретиться
Иногда новичку нужно познакомиться не только с командой, но и с коллегами из других отделов — BizDev, маркетинг, саппорт.
3. Календарь обучения
Мы выстроили порядок обучающих активностей, чтобы информация ложилась в голову последовательно:
Обучение от саппорта. На понятном языке, часто с юмором, объясняют, как работают продукты компании. Онлайн или в формате встреч-разговоров.
Командное обучение. Здесь мы объясняем наши продукты, техпроцессы и особенности конкретной команды. В смешанном формате.
Обучение от бизнеса. Глубокое погружение в домен: к этому моменту новичок уже хотя бы примерно понимает терминологию. Проводится только очно.
Раз в три месяца бизнес собирает всех новичков и четыре дня подряд по шесть часов «выгружает» им знания о том, как всё устроено. Иначе нельзя: домены сложные, и чтобы их понять, надо услышать, обсудить, спросить и переварить.
Это не массово распространённая практика, но она даёт отличные результаты. И решает сразу несколько задач:
формирует общее понимание бизнеса и разработки процессов и продукта (плюс небольшой шажок в сторону закрепления единого языка по DDD);
знакомит бизнес-подразделения и разработку, снимает ощущение, что IT — безликий набор интровертов, и помогает наладить связи;
помогает выстроить живые рабочие связи.
Каждый этап обучения завершается проверкой знаний. После обучения от саппорта это «вопрос-ответ», чтобы понять, что усвоилось. Бизнес даёт «домашки». Нормальная практика проверки — не экзамен, а разговор: «Расскажи, как ты понял» или «Нарисуй процесс». И когда вся команда работает на досках, это выглядит органично.
Также в мероприятия плана онбординга включены:
4. Сценарии для проведения тестовых действий: регистрация, платёж, и т.п. (+ инструкции по развёртыванию проекта и т.п.).
5. Ссылка на первую задачу.
6. Ссылка на первую БОЛЬШУЮ задачу, которую человек должен сделать сам — полноценная поставка ценности.
Первая задача не обязательно одна. Это может быть набор небольших задач, чтобы человек смог раскачаться и узнать что-то новое. А БОЛЬШАЯ задача — это «точка невозврата»: «Я начал отвечать за что-то на проде».
Персональные цели
Мы не сторонники идеи ставить человеку цели в самом начале, но получается по-разному. Поэтому у нас так:
Если ста��товые цели всё же были сформулированы — отлично, они попадают в план онбординга.
Если нет — не страшно. Мы приходим к ним после первого Self-Assessment (через три месяца после начала работы).
На этом практическая часть онбординга заканчивается. Мы собрали маршрут на полгода вперёд, определили роли, расписали встречи и выстроили последовательность контекста. Но сам по себе маршрут ничего не даст, если внутри команды нет среды, в которой человек может расти: безопасной обратной связи, регулярных разговоров, честных ожиданий и живой коммуникации.
Именно эти элементы делают процесс не формальностью, а механизмом развития и удержания. О них и пойдёт речь в третьей части.
Скрытый текст
А пока мы приглашаем вас на профессиональную конференцию по интеграции процессов разработки, тестирования и эксплуатации DevOps Conf! Вас ждут 2 дня практики, интерактива и нетворкинг для DevOps, SRE и инженеров эксплуатации.
В этом году DevOpsConf пройдёт в формате конференции развития.
Конференция развития — инструмент решения задач, а не потребления контента. Она становится больше практикумом, чем лекциями.
