На связи — Катя Лысенко и третья часть статьи о системе онбординга. В первых двух (ч.1 и ч. 2) мы разобрали основы: как подготовить почву, выстроить маршрут и создать понятный трек для новичка. Но структура — это только половина системы. Вторая половина — то, что делает её живой: регулярная рефлексия, честный разговор и поддерживающая среда, где человек не боится расти и пробовать.

Self-Assessment
Self-Assessment — это внутренняя точка осознанной оценки развития. Он строится на пяти принципах: регулярность, факты, конкретика, анализ изменений и запрос обратной связи.
Первый раз мы проводим эту практику через три месяца после выхода на работу, дальше — каждые полгода или по запросу. В оценке мы опираемся на измеримые результаты и конкретные кейсы, например: «Я был хорош в кейсе Х, это отметили Вася и Петя, вот прямые цитаты из отзывов», а не на общее: «Я хорош в коммуникации».
Фактически Self-Assessment — это внутреннее ретро новичка: что получилось, где просел, что помогло и что мешало. Если нужна обратная связь — сотрудник сам запрашивает ее у тех, кто может дать конструктивную оценку.
Не причиняйте пользу — спрашивайте
Запуская Self-Assessment, мы просим сотрудника оценить себя по набору пунктов: достижения и цели, производительность, навыки и компетенции, коммуникация и сотрудничество, развитие, план на следующий период. Благодаря этому персональные цели обновляются естественным образом — человек сам формулирует, куда хочет двигаться. И мы не «причиняем пользу», указывая, кем ему нужно стать.
В моей карьере были примеры, когда мне говорили, куда двигаться внутри компании. Например, пытались засунуть в политику. А я — аполитичный человек. Мне там трудно и я не умею «шаркать ножками», не могу сидеть на совещаниях, особенно долго и молча. Поэтому политика — точно не моё. Не могу туда вырасти — и не хочу.
Спросите, чего человек хочет. Сопоставьте это с тем, как видите его развитие. Вполне возможно, найдётся золотая середина — то самое пересечение между интересами сотрудника и возможностями команды. Это будет честный, рабочий вин-вин.
Иногда человек годами ходит вокруг своей настоящей траектории. Один из моих кейсов: сильный QA с 15 годами опыта думал, что его путь — разработка. А выяснилось, что всю жизнь его тянуло в SRE, но когда-то ему «объяснили», что QA туда путь закрыт. Стоило поговорить — и дорога нашлась.
Рост — это не про изменение позиции и должности, не про горизонтальные и прочие переходы. Это вполне может быть про углубление собственной экспертизы.
Если затронуть возраст, то от сотрудника в возрасте за 40, а у меня были ребята, кому 60+, я не ожидаю услышать на Self-Assessment про желание попробовать что-то новое для себя. Он уже столько попробовал в этой жизни — какое новое? Но человек продолжает что-то учить, развиваться и не становится «тотемным животным». И это важно. Например, говорит, что посмотрел на работу тестирования и решил изучить питон, чтобы самому накидывать интеграционные тесты, так как ему это в кайф!
А если человек не хочет большего?
Бывает, сотрудник не хочет развиваться дальше. Тогда мы возвращаемся к коллаборации — про заинтересованность команды и заинтересованность новичка.

Если команда — про развитие, а новичок — нет, вы уже не мапитесь по ценностям.
Представьте команду, где все хотят учиться, развиваться, пробовать новое. И появляется тот, кто говорит: «Я отсидел восемь часов — дальше не моё. У вас инцидент? Да гори оно огнём, я уже вышел из системы». В этом случае неважно, насколько хорош специалист — он просто не подходит вам по культуре.
Персональные цели могут быть связаны с реализацией проектных задач
Пример из жизни: на собеседование выходит скиловый фронтенд-разработчик и сразу говорит — с бизнесом не общаюсь, задачи с коммуникацией не ставьте. Мы спокойно это приняли, потому что было кому говорить с бизнесом.
Проходит два месяца — этот разработчик начинает ходить на демо и встречи рабочих групп. И внезапно выясняется: он прекрасно умеет договариваться, классно понимает продукт, может объяснить, зачем команде именно такое решение, и вообще ведёт себя как отличный продуктовый инженер. Просто раньше его напрягала политика, а когда убрали «надстройку» и оставили суть — коммуникацию, аргументацию, — всё получилось.
Но такие вещи не увидишь за неделю. Поэтому цели мы часто формулируем после первого Self-Assessment, когда картина более прозрачная.
Для Self-Assessment нужны условия
Self-Assessment живёт там, где безопасно говорить честно. Это открытая оценка, которую человек делает. Но если за откровенность наказывают, инструмент теряет смысл.
У нас это выглядит примерно так:
— «Я затащил 25 задач».
— «Я вижу 19 точно твоих. А по остальным тебе помогали. Ты тоже их учитываешь?»
— «Да. Я сам организовал этих людей и договорился».
— «Отлично. Я не знал, что ты это сделал».
Мы спокойно проходим расхождения, уточняем и разговариваем. И у нас есть корпоративная программа психотерапии, как часть поддержки. Так мы научились открыто обсуждать сложные темы и очень хорошо находим, где конфликты и рассинхронизации. А Self-Assessment стал не формальной процедурой, а рабочим инструментом, который помогает расти.
Инструменты онбординга
В онбординге три ключевых инструмента:
Помощь бадди
Регулярные встречи 1:1
Обратная связь
Инструмент 1: помощь бадди
Бадди не наставник и не учитель. Это человек, который сопровождает новичка, помогает разобраться в структуре, подсказывает, куда идти и к кому стучаться, и просто держит рядом «точку опоры», пока тот втягивается в работу.
Ключевые принципы:
Выбирается добровольно. Никого не назначаем из-под палки.
Выступает в качестве навигатора, а не «тренера по всем вопросам».
У бадди есть такая же памятка, как у новичка — в том числе с подсказкой, как понять, что ему самому нужна помощь.
Основная мотивация бадди — чтобы как можно быстрее появился коллега, который будет делать не фигню. Бывает, что за роль бадди сразу тянет руку несколько человек, просто потому что им интересно посмотреть, как работает смежная вертикаль. И это ок: у нас нет правила «бэкендера к бэкендеру, фронта к фронту». Бадди может быть из любой роли, потому что это больше не про техническую поддержку, а про человеческую.
За это время бадди также качают навыки менторинга и коучинга. Основная работа ложится на первые полтора месяца новичка в команде. Другие полтора месяца и далее в основном включают встречи 1:1, на которых бадди спрашивает, как проходит работа и выясняет какие-то моменты.
Когда бадди обращается за помощью
Первое, что должен уметь диагностировать бадди — усталость от роли или когда нет коннекта с новичком. Но есть ещё несколько ситуаций, когда важно обратиться к лиду или менеджеру:
На адаптацию новичка уходит больше двух часов в день
Это сигнал, что с онбордингом что-то не так. Причина может быть в том, как составили план, или с тем, что бадди взял на себя больше.
Новичок пропускает запланированные встречи без уведомления
Иногда — по уважительной причине (визит к врачу, болезнь, форс-мажор). Но если человек говорит: «Ой, я забыл» или «Я не знал, зачем идти, поэтому не пошёл», — это сигнал для бадди, что пора обсуждать вопрос с лидом.
Другие проблемы, блокирующие адаптацию
Например, бадди три недели подряд просит новичка прочитать один и тот же кусок документации. На четвёртую встречу новичок говорит: «Я всё ещё не понял, давай ты мне ещё раз расскажешь?» С этим нужно разбираться. Возможно, не работает связка бадди-новичок, а возможно, последний просто не онбордится, и пора принимать решения.
У роли бадди есть чёткая граница: он про адаптацию. А для развития новичку может понадобиться наставник.
Кто может быть наставником
Наставником может быть любой человек в компании. Эту роль можно распределить между разными коллегами, разгрузив разработку и подключив другие вертикали. Если вы живёте по DDD и бизнес играет роль BizDev, часть менторинга часто естественно ложится и на них: они хорошо понимают домен и техническую сторону решения.
Чем выше позиция новичка, тем слабее работает модель «один выделенный наставник». У сильных специалистов шире кругозор: им нужен не один человек, а несколько менторов по разным аспектам
Чтобы построить такую сеть осмысленно, полезно смотреть не на должности, а на «фигуру» компетенций — shape:
I-shaped — одна глубина;
T-shaped — глубина плюс базовая широта;
π/Comb/M-shaped — две, три или больше вертикалей с растущими издержками на поддержание глубин;
E-shaped — про зрелость: опыт, исполнение, исследование и внедрение.
Практический смысл простой: определите, где у человека настоящая глубина, какие «стыки» он закрывает, и куда ему двигаться — вширь или вглубь. И давайте ему наставников под эти зоны. И опять же, вместо игры в «угадайку» всегда лучше спросить напрямую.
Практика фигур естественно сочетается с кадровыми принципами: акцент смещается от культурной «похожести» (cultural fit) к культурной «добавленной ценности» (cultural add). Не «впишись в нашу среду», а «дополни нас новыми перспективами при общих ценностях и понятном культурном коде». На фоне недавних корпоративных обсуждений курса на «эффективность и открытость» (в том числе вокруг Google и их череде сокращений) всё чаще читается одна и та же мысль: сильные команды строят не из одинаковых людей, а из разных специалистов, которые усиливают друг друга.
В практику онбординга это переводится просто. Сначала разведите роли: бадди — про адаптацию, наставник — про развитие. Затем распределите менторинг между несколькими наставниками по ключевым доменам, особенно если вы наняли человека за его «сложную фигуру» компетенций. Наконец, фиксируйте главный вопрос найма и развития: какую добавленную ценность этот кандидат приносит культуре команды и где именно её усиливает. И тогда бадди поможет войти в контекст, наставник — вырасти по «фигурной» траектории, а культурная добавка — сделать команду сильнее, а не просто одинаковее.
Инструмент 2: встречи 1:1
Мы активно и много используем встречи 1:1. Разные роли подключаются с разной частотой — в зависимости от задач.
Встречи с бадди
Самые частые 1:1. В первые недели созваниваемся два раза в неделю: отвечаем на вопросы, разбираем сложности, сверяемся по плану. Дальше ритм снижается, но связь остаётся постоянной.
Встречи с лидом
Раз в месяц лид смотрит, как человек встраивается в процессы и интегрируется в команду (что получается, где буксует), помогает скорректировать курс и даёт обратную связь по работе.
Встречи с менеджером
Первый контакт — в конце первого месяца, потом — на третий и шестой. Такой ритм позволяет держать связь без перегруза, особенно если у менеджера несколько команд. Его задача — встроить человека в кластер и понять, насколько совпадают ожидания.
Встречи с лидом структурного подразделения
Это тот самый лид всея QA, всея фронта, всея бэка (а иногда — Java, PHP и т.д.). Он отвечает за внедрение инженерных практик по вертикали. Например, если команда пока не готова к автотестам, а компания туда уже движется. Тимлид говорит: «Сейчас не до того». А лид QA говорит: «Ок, если тебе не хватает экспертизы, моя задача тебе её дать. Давай, покажу, как это делается в других командах».
Частота встреч — примерно как у менеджера. Задача — определить цели новичка в рамках структурного подразделения. Тем для разговоров чуть меньше, зато важны сами направления: не потерять человека в развитии, даже если текущая команда ещё не дотянулась.
Это «лид всея фронта/бэка/QA»: тот, кто отвечает за инженерные практики по вертикали. Он подключается примерно с той же частотой, что и менеджер, но с другим фокусом: развитие по профессии.
Если команде пока «не до автотестов», а компания туда уже идёт, человек не должен застревать. Лид вертикали помогает: показывает лучшие практики, делится опытом других команд и формирует цели развития именно как специалиста.
Встречи с HR
HR подключаются точечно: на старте, на контрольных точках (90 и 180 дней), а также по запросу — когда новичку нужна консультация или безопасное пространство, чтобы проговорить свои вопросы.
В онбординге HR-встречи играют роль отдельного слоя поддержки. Это важно по нескольким причинам:
HR как точка опоры. Менеджер для новичка — фигура авторитетная и часто формальная. Если между ними возникает напряжение или непонимание, новичка просто не останется безопасной площадки, где проговорить сомнения и трудности. HR в таких встречах становятся точкой доверия, где можно честно обсудить проблемы, не опасаясь, что это будет воспринято как «сопротивление».
HR видит то, что не замечает менеджер. Руководителями в ИТ часто становятся инженеры. Это сильные специалисты, но далеко не у всех хорошо развиты социальные навыки. Их не учили слушать, диагностировать эмоциональное состояние команды, ловить первые признаки выгорания или напряжения. HR же работают с людьми профессионально и могут заметить сигналы ещё до того, как они начнут мешать работе.
HR снижают риски скрытых конфликтов. На этапе онбординга особенно важно вовремя увидеть, где что-то трёт — в коммуникации, процессах, ожиданиях. HR в роли нейтральной стороны могут аккуратно разрулить ситуацию, пока она не переросла в проблему.
HR как носитель культуры. Через такие 1:1 транслируется культурная норма компании: у нас принято говорить о проблемах, искать решения и помогать друг другу, а не замалчивать. Для новичка это важный ориентир.
По сути, HR-встречи в онбординге — это не про контроль, а про профилактику: предотвращение выгорания, недопонимания и скрытых конфликтов. Это инструмент, который делает культуру компании живой.
При такой многоуровневой системе встреч каждый участник закрывает свою часть:
лид — про процессы и команду,
менеджер — про стратегию и ожидания,
лид вертикали — про развитие по профессии,
HR — про состояние, поддержку и культуру.
И тут есть правило, которое мы придерживаемся: «Что сказано на 1:1 — остаётся на 1:1». Делится человек или нет — его решение. Граница открытости всегда проговаривается.
Где проходит граница зоны HR и команды
Разделение между зоной HR и зоной команды зависит от того, куда именно вы хотите онбордить.
В первую очередь сотрудник встраивается не в «компанию вообще», а в команду. Именно там создаётся рабочая среда, процессы, нормы общения, туда человек приносит ценность, там у него появляются первые успехи и сложности.
На следующем уровне — онбординг к руководителю: здесь появляется личный контур доверия и выравнивания ожиданий.
А если в компании есть ещё и системный подход — тогда человек онбордится и в саму компанию. А HR закрывают эту часть и становятся устойчивой опорой вне команды.
Если компания ограничивается формальными видео про ценности и портретами руководителей — берите ответственность за онбординг в свои руки.
Инструмент 3: обратная связь
Обратная связь в нашей команде максимально прозрачна и не обезличена. Мы открыто говорим, кто с чем согласен, кто в чём не уверен, и обсуждаем это вживую.
Если у кого-то есть фидбэк, он даёт его по собственной инициативе. Есть ещё обратная связь, которую мы запрашиваем в рамках Self-Assessment.
Я могу прийти к команде и попросить комментарии по конкретным пунктам: достижения, производительность, навыки, коммуникация, развитие, планы на следующий период. И увижу, кто что сказал.
Чтобы вся система работала, мы сознательно прокачивали навык быстрой и корректной обратной связи. Запрашивали тренинг у HR, составили свою памятку, регулярно напоминаем друг другу, что фидбэк нужно давать, а не держать в голове. Иногда после ретро в задачах появляется: «Поговорить с Машей. Дать обратную связь по демо».
Обращу внимание, что это не всегда развивающая критика, вроде: «Ребята, обратите внимание — там и там плохо». Обратная связь может быть и подкрепляющей: «Вы сделали зашибись, вся команда вам за это признательна! Это очень круто, спасибо. Если будете продолжать так же, нам будет очень комфортно». Такой подтверждающей связью, которую несём вовне, мы добиваемся сильно больше успехов, чем развивающей. Но, конечно, развивающую давать тоже приходится.
Что даёт такая система онбординга
Быстрый старт и выход на сложные задачи. Новые сотрудники начинают осмысленно выполнять задачи уже через полтора месяца после выхода. А сложные задачи с архитектурной проработкой и доменной логикой спокойно берут через три месяца.
Да, у нас на входе не джуны, а уверенные миддл+. Но команда живёт по DDD, все пишут документацию, и нет такого, что кто-то «не занимается архитектурой». Все занимаются и проектируют.
Ценность каждого и распределённая экспертиза. У нас ребята понимают, в чем ценность каждого члена команды, и друг другом очень дорожат. Человек видит, что классного умеет делать другой, и понимает, что всегда может прийти и попросить его в этом прокачать. И никто не откажет. Могут сказать: «Сейчас не успеваю», но обычзательно договорятся и проработают вместе. Это классно.
Например, к нам пришёл человек, который раньше писал на Java и Kotlin. А у нас — JS. На старте мы оценили его уровень в JS как джуниор/джуниор+. Меньше чем полгода спустя команда оценила его как сеньора. И это не пустая оценка — человек глубоко погрузился, а мы перестроили процессы, чтобы быстро заонбордить его к себе. Я не имею в виду, что дело только в онбординге. Конечно, мы практикуем код-ревью, кросс-ревью, есть кодстайл и гайды. Бэкендеры читают фронтовые тесты, QA смотрят автотесты от всех, чтобы глубже погружаться в домен. Всё это суммарно даёт результат.
Мотивация как внутренняя сила, а не задача менеджера. Мотивацией прежде всего управляет сам человек, а потом команда. В частности, поэтому мы и говорим про коллаборацию. Когда она есть — всё работает, в этом как раз скрыта мотивация. Когда нет — заинтересовать будет сложно.
Бывают те самые задачи «не по вайбу», но это называется ошибкой найма. Мы не будем «продавать» сотруднику задачу и уговаривать её сделать. Но мы точно объясним, зачем она нужна, если человек не понял. Потому что работает простой принцип: «Если ты не понимаешь, зачем делать задачу — её не надо делать».
Масштабируемость подхода. Количество людей в команде не имеет значения. Процесс работает начиная с двух человек (одному просто скучно быть командой). И до того момента, пока вы можете считать, что у вас только одна команда. Я бы сказала, что 10−12 — это потолок. Дальше появляются уже две, три, пять команд, кластер, вертикаль, но онбордите вы всегда в команду.
Цикличность и постоянная доработка процесса. Имплементация процесса заняла у нас три итерации. После каждой — фидбек, доработки, обновление материалов, исправление дыр. У нас был непрерывный цикл улучшений, которые появлялись с выходом каждого нового сотрудника.
Скрытый текст
К моменту выхода статьи я сменила работу, но принесла в новую компанию эти же принципы — и мы внедрили подход тоже за три итерации до уровня «автоматизма».
После выхода каждого новичка мы запрашивали обратную связь и обновляли план, материалы и процессы. К существенным доработкам, которые обычно завершаются за этот период, я отношу:
выравнивание матрицы доступов;
обновление palybook и базы знаний по инцидентам;
материалы встреч с инфраструктурными командами;
блок «онбординг от гильдий»;
очное обучение от бизнеса с домашними заданиями;
«первый пользовательский сценарий» для быстрого погружения;
разведение ролей бадди и наставника;
добавление метрик (TTFD/TTSV) и контрольных точек на 90/180 дней;
регулярный Self-Assessment.
Выводы
1. Онбординг нужен не только новичкам
Любой человек уязвим в новой среде — независимо от того, пришёл он извне или перешёл внутри компании. Онбординг нужен не только «новичкам», но и «старичкам» при ротации — вторировании, инсорсинге, переходе между командами и доменами. Каждый переход — это по с��ти новый старт, требующий поддержки.
2. Три распространённых типа онбординга, которые не помогают адаптироваться
«Вот море — плыви» — неэффективный и рискованный подход, где отсутствует система. Новичок остаётся без поддержки и быстро теряется.
HR-онбординг, включающий только базовые материалы и ритуалы. Здесь не хватает вовлечения команды и реальных рабочих задач.
Онбординг, основанный на постановке целей на испытательный срок — выглядит как суррогат процесса: задачи есть, но контекста нет, поэтому результат предсказуемо слабый.
3. Онбординг — стратегический инструмент
Для новичка: помогает снизить стресс, ускорить адаптацию, получить честную обратную связь и не «выпасть» по дороге.
Для команды: позволяет быстрее получить «рабочие руки и мозги», новую экспертизу, и не терять ресурсы на переобучение.
Для компании: помогает контролировать удержание, снижать текучку, выращивать лояльность и культуру.
4. Онбординг держится на коллаборации — все участники вносят вклад
Это не процесс, навязанный HR или лидом, а сотрудничество между командой и новым сотрудником. Успех будет там, где команда готова включаться, новичок замотивирован и хочет встраиваться, и нет перекоса, что кто-то онбордит нового коллегу в одиночку.
5. Хороший онбординг — многоступенчатый маршрут
От базовых вещей, вроде подготовки рабочего места, доступов и старта с поддержкой бадди, чтобы снизить стресс первых дней и недель, до конкретного плана на первые три месяца и затем ещё три, включая встречи и Self-Assessment как инструмент осознания прогресса.
Может показаться, что этот онбординг очень насыщен информационно и перегрузит новичка. Но в действительности гораздо важнее, в каком формате это преподнести. Мы разбиваем план на большие промежутки времени и каких-то базовых знаний по домену ждём только через 1,5 месяца.
6. Инициатива должна исходить из команды
Онбординг работает, если строится изнутри, а не спускается сверху. Это команде нужны рабочие руки, экспертиза и снижение нагрузки на найм, а значит можно доработать процесс под себя.
7. Бадди — опора, а не учитель
Человек в этой роли сопровождает, подсказывает, помогает не потеряться, но может быть даже не носителем экспертизы. И берёт эту задачу добровольно. Если нет бадди, то вероятнее, менеджер тащит всё на себе.
8. Встречи 1:1 как основа коммуникации
Частые и честные 1:1 создают фундамент доверия, особенно в первые 3–6 месяцев. Эти встречи не касаются синхронизации задач, но проходят как важные, развивающие разговоры. Частота в рамках онбординга может быть разной, в зависимости от роли роли второго участника (бадди, лид, менеджер, HR, вертикальный лид).
9. Self-Assessment — как способ расти в открытой среде
Self-Assessment — регулярный, открытый и безопасный формат для осознанной оценки человеком себя и своих результатов, не для оценки сверху. На нём обсуждается: что человек сделал, что он думает о результате, кто помог, какие выводы.
С этой практикой нужно осторожно: нет смысла внедрять её в команде с токсичной культурой, если между коллегами нет доверия, условий для рефлексии и внутренней готовности.
10. Что даёт такой онбординг
Сильный онбординг — это способ быстрее вырастить, понять и сохранить специалиста в команде. Такая модель ускоряет выход на продуктивность (за 1,5 месяца — простые задачи, за 3 месяца — сложные), развивает экспертизу за счёт среды, а не только индивидуальных усилий, делает ценность каждого видимой и уменьшает цену ошибок найма. В результате команда развивается как система.
Скрытый текст
Приглашаем вас на профессиональную конференцию по интеграции процессов разработки, тестирования и эксплуатации DevOps Conf! Вас ждут 2 дня практики, интерактива и нетворкинг для DevOps, SRE и инженеров эксплуатации.
В этом году DevOpsConf пройдёт в формате конференции развития.
Конференция развития — инструмент решения задач, а не потребления контента. Она становится больше практикумом, чем лекциями.
