Три месяца закрывали вакансию сеньора разработчика, а может и все шесть. Прошло 12 собеседований, офер согласован, человек вышел. HR провёл welcome-встречу, выдал ноутбук и доступы, тимлид показал confluence — всё по процессу.
Через месяц кто-то спрашивает: «А как там Антон вообще?» Тимлид пожимает плечами: «Ну… делает задачи». HR отвечает: «Онбординг закрыт, всё ок». А сам Антон в это время тихо обновляет резюме, потому что не понимает, чего от него ждут, куда он вообще движется и есть ли тут смысл задерживаться. Ещё через месяц Антон уходит, компания теряет деньги, которые потратила на найм и адаптацию, в команде снова минус разраб.
Есть у компаний системная ошибка — онбординг в вакууме, который может проходить даже качественно, но в итоге оставляет сотрудника предоставленным самому себе.
Всем привет! Это Люба из команды SimpleOne HRMS. Расскажу, почему онбординг — это только первый шаг к долгой и счастливой жизни сотрудника в компании, а не конечная цель.
Почему формально онбординг есть, а реально он не работает
На вопрос «у вас есть онбординг?», компания скорее всего ответит «да». И не соврет! Есть чеклист, есть welcome-письмо, есть папка в confluence «Для новичков» (последний раз обновлялась в 2022-м). Есть встреча с командой в первый день. Все блага — к вашим услугам.
Но вот что происходит сразу после этого незатейливого ритуала:
Данные о сотруднике расползаются по четырём местам сразу: кадровые документы — в 1С, задачи — в Jira, договорённости с менеджером — в Telegram, ожидания на испытательный срок — в голове тимлида или в Google Docs, который уже никто не открывает.
Никто системно не отслеживает, как человек идёт. Есть синки, раз в неделю, если повезёт. Есть ощущение, что «в целом норм». Но нет ни контрольных точек, ни зафиксированных ожиданий, ни сигналов тревоги.
Испытательный срок заканчивается формально: либо «ну ок, оставляем», либо неожиданное «нам кажется, не подходит» — для обеих сторон сюрприз.
Корень проблемы не в том, что менеджеры не занимаются людьми. Они занимаются, но каждый по-своему, без общей структуры. В итоге онбординг работает ровно до момента, когда в чеклисте появляются все галочки. А дальше тишина.
Где ломается система
Онбординг можно условно разделить на три слоя:
Административный — «оформить и выдать»
Это все умеют делать: подписать документы, завести в системах, выдать доступы, добавить в рабочие чаты. Формально онбординг выполнен.
2. Операционный — «ввести в работу»
Уже сложнее, здесь нужно:
объяснить, как устроены процессы в конкретной команде,
передать контекст по задачам и проектам,
зафиксировать ожидания на испытательный срок — что считается успехом через 30, 60, 90 дней.
Этот слой в компаниях обычно неравномерный: где-то тимлид делает это интуитивно и хорошо, где-то человек разбирается сам. Системы нет, но может и повезти.
3. Карьерный — «понять, куда человек движется»
На этот слой почти никто не обращает внимание в рамках онбординга. Считается, что это задача на потом. Но именно тут могли бы заложиться ответы на вопросы, которые сотрудник задаёт себе уже в первые недели:
Есть ли здесь рост или я буду делать одно и то же?
Как меня будут оценивать — и по каким критериям?
Куда я могу вырасти через год?
Если ответов нет, человек начинает искать их снаружи компании.
Что должно быть вместо «ритуального онбординга»
Перестать воспринимать онбординг как событие и начать воспринимать его как начало управляемого процесса звучит как HR-лозунг. Но давайте переведём это на язык тимлида.
Когда онбординг системный, тимлид перестаёт быть единственным носителем информации о новом человеке. Не нужно держать в голове, что Антон ещё не разобрался с деплоем, что у него через неделю дедлайн по первой задаче и что вы вроде бы договорились про грейд — но нигде не записали.
Второй эффект — скорость. Чем чётче структура первых 90 дней, тем быстрее новый разработчик начинает работать автономно, потому что у него есть ориентиры: что от него ждут, как оценивают, куда двигаться. Без этого даже сильный спец тратит впустую первые недели в попытках угадать правила игры.
Вот как можно обеспечить системность, чтобы развивать и не терять членов команды с первого дня:
1. Сделать единый профиль сотрудника
С первого дня вся информация о человеке должна жить в одном месте: должность, роль, стек, руководитель, проекты, документы, история изменений. Это база, без которой всё остальное рассыпается.
2. Зафиксировать ожидания не только на 30/60/90 дней, но и после
Устных договорённостей не достаточно, нужен прозрачный документ, в котором написано:
что сотрудник должен освоить к концу первого месяца,
какие задачи закрыть к концу второго,
по каким критериям будет оцениваться испытательный срок.
3. Встроить онбординг в единый процесс оценки и развития
Не отпускайте людей в открытый космос, дайте им понятный карьерный трек, и зафиксируйте его.
Антон ушёл не потому что офер был получше, а потому что три месяца не понимал, куда движется — и никто не помог ему это понять. Онбординг здесь ни при чём, так же как и менеджмент, и тимлид, и эйчар. Проблема в том, что после адаптации ничего не началось, даже разговора о том, что дальше.
Чтобы этот разговор был проще, системнее и более своевременным, не стоит допускать расползания данных о человеке. Соберите их вместе, чтобы управлять его карьерой.
Был ли у вас свой Антон? Что в итоге пошло не так?