Рассмотрим ситуацию. В понедельник выходит новый разработчик. Ему выдают ноут, отправляют ссылку на внутреннюю документацию и сразу дают задачу. Через неделю он всё ещё собирает доступы и пытается понять, к кому идти с вопросами. Через месяц у руководителя могут быть вопросы к его скорости, хотя проблема началась ещё до первого рабочего дня.

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

Разберём, как провести разработчика от финального собеседования до самостоятельной работы и не оставить его один на один с корпоративной документацией — если она вообще есть.

Задача онбординга — уменьшить неопределённость

В первые дни новый сотрудник пытается собрать сразу несколько карт:

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

Даже опытный разработчик не сможет быстро разобраться во всём сразу. Он может хорошо знать Go, Kafa, Postgres, даже балансировать деревья в голове, но при этом ничего не знать о предметной области, истории принятых решений и правилах новой команды.

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

Влияние на бизнес

Расходы начинаются ещё до выхода сотрудника. HR вместе с руководителем уточняет требования к кандидату, ищет людей, проводит первые интервью, координирует следующие этапы и готовит оффер. Лид разбирает резюме и проводит технические собеседования, а IT-команда готовит технику, учётную запись и доступы.

Если подбор ведёт штатный HR, отдельного счёта за вакансию нет, но подбор не становится бесплатным. Компания оплачивает рабочие часы HR, а в это время он не может заниматься другими вакансиями. При работе с агентством цена видна сразу: на момент публикации Lucky Hunter указывает стоимость IT-подбора от 16% годового дохода специалиста. Если кандидат получает 250 000 рублей в месяц, услуги агентства начинаются примерно от 480 000 рублей: 250 000 × 12 × 16%. Это не средняя цена рынка, а пример расчёта по открытому тарифу конкретного агентства.

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

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

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

Не приукрашивать работу

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

Если в команде есть дежурства, недостаточно сказать: «Иногда мы дежурим». Важно объяснить, как часто это происходит, бывают ли ночные вызовы и работа в выходные, на какие инциденты нужно реагировать, кто помогает во время дежурства и как оно компенсируется.

То же самое относится к стеку и архитектуре. Не стоит рассказывать кандидату, что в проекте «чистая архитектура, порты и адаптеры», если после выхода он увидит обычный MVC с бизнес-логикой в контроллерах, покрытие тестами около 40% и версию фреймворка на четыре мажорных релиза ниже актуальной.

Устаревший стек или накопившийся технический долг сами по себе не всегда делают работу плохой. Проблема возникает, когда обещания расходятся с реальностью. Лучше честно описать текущее состояние, а если есть реальный план изменений — показать его и объяснить, какую роль в этих изменениях предлагают новому разработчику.

Подготовить первый рабочий день

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

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

Процесс выдачи техники, подготовки учётных записей и основных доступов стоит заранее описать и по возможности автоматизировать.

Перед выходом сотрудника стоит проверить:

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

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

Помню случай: разработчиков просто пригласили на встречу «Знакомство с новым лидом». До неё никто не объяснил, что меняется и почему. У команды сразу возник вопрос: «А что случилось со старым лидом?» Этого напряжения можно было избежать одним сообщением заранее.

План онбординга не обязан быть большим документом. Достаточно перечислить этапы, добавить ссылки на документацию и указать проверяемые результаты. Формулировка «изучить архитектуру» бесполезна. Результат «найти проблемы с загрузкой профиля и предложить оптимизацию» уже можно проверить.

В конце первой недели должен быть результат

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

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

Первая встреча

Руководитель проводит первую встречу один на один и объясняет:

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

На этой же встрече руководителю стоит познакомить новичка с ментором и прямо объяснить его роль: «Познакомься с Денисом. Он поможет тебе погрузиться в проект. Не стесняйся задавать ему вопросы — глупых вопросов здесь нет».

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

Договориться об ожиданиях

Испытательный срок — не формальность, а двусторонняя проверка. Компания смотрит, как человек справляется с работой. Человек смотрит на компанию: совпали ли обещания с реальностью, подходят ли ему продукт, команда, процессы и сама роль.

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

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

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

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

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

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

Поднять окружение без боли

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

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

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

Инструкция по запуску должна отвечать хотя бы на вопросы:

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

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

Продукт

Разработчик и ментор изучают основные пользовательские сценарии продукта. После этого новый сотрудник пробует продукт сам: создаёт аккаунт и выполняет ключевые действия.

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

Первая небольшая задача

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

Цель такой задачи ознакомить разработчика с рабочим циклом и заранее обнаруживает недостающие доступы, устаревшие инструкции и непонятные правила.

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

Показывать продукт, а не только код

Фраза «почитай документацию там все понятно» перекладывает ответственность за погружение на новичка. Документация нужна, но без контекста непонятно, в каком порядке её читать и какие страницы уже устарели. Более того устаревшая документация только может сбить.

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

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

Если новичок находит битую ссылку или шаг, который устарел, следует исправить документацию и не тянуть с этим. Следующему человеку будет проще, а команда постепенно увидит реальные слабые места своего онбординга.

Разделить роли руководителя и ментора

Один человек может совмещать несколько ролей, но зоны ответственности лучше назвать явно.

Роль За что отвечает С какими вопросами идти
Руководитель Цели, приоритеты, ожидания и обратная связь Что от меня ждут? Что сейчас важнее? Как оценивается результат?
Ментор Профессиональное и техническое погружение Почему система устроена так? Какой подход выбрать? Как проверить решение?

Ментор — это коллега, которому можно без неловкости задать простой вопрос. Он помогает сориентироваться, знакомит с людьми и объясняет неформальные правила.

Хороший ментор знает контекст команды, готов отвечать на вопросы и имеет для этого время. Если назначить его формально и не освободить от части текущей работы, новичок не получит нужной помощи, а у ментора появится скрытая нагрузка.

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

Помочь войти в команду

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

В первые недели помогают простые вещи:

  • карта команды с зонами ответственности — например, страница в confluence;
  • участие в планировании, ретро и демо;
  • объяснение правил коммуникации и принятия решений;
  • список команд, с которыми придётся взаимодействовать.

Не нужно устраивать десять встреч подряд в первый день: это вымотает и новичка, и коллег. Лучше распределить знакомства на одну или две недели и перед каждой встречей объяснять её цель. Например: «С Мариной обсуди задачи по треку, а с Ольгой — как вы будете тестировать изменения». Так знакомство не превращается в поток имён, которые невозможно запомнить.

К концу второй недели сотрудник должен понимать, кто принимает решения и где искать помощь.

Самостоятельность не должна зависеть от календаря

Через три месяца один разработчик уже уверенно ведёт свою область, другому всё ещё нужна помощь с частью задач.

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

На практике переход выглядит так:

  1. руководитель или ментор объясняет цель, шаги и способ проверки;
  2. разработчик предлагает подход, а ментор помогает его уточнить;
  3. стороны договариваются о результате, ограничениях и контрольных точках;
  4. разработчик выполняет задачу самостоятельно и обращается за помощью при необходимости.

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

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

Как понять, что адаптация идёт по плану

Испытательный срок не стоит оценивать по количеству коммитов или закрытых задач. Задачи различаются по сложности, а результат в первые недели сильно зависит от доступов, документации и помощи команды.

Результаты должны быть конкретными и зависеть от роли:

  • запустить проект и пройти основные пользовательские сценарии;
  • выполнить небольшие задачи с поддержкой ментора;
  • выполнить задачу среднего размера;
  • научиться находить владельца проблемы и вовремя сообщать о блокере.

Это ориентиры на испытательный срок. Их можно пересматривать, если изменились задачи команды или компания не успела оформить доступы. Руководитель тоже берёт обязательства: организовать доступы, дать контекст, быть доступным для вопросов и регулярно обсуждать прогресс.

Руководителю важно оценивать не только сотрудника, но и качество самого онбординга:

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

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

Завершить онбординг отдельной встречей

Испытательный срок не должен заканчиваться молча. Нужна отдельная встреча, на которой руководитель и сотрудник подведут итоги адаптации.

На ней стоит обсудить:

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

Результат разговора лучше коротко зафиксировать. Это не табличка с оценками, а общая точка отсчёта: что человек уже делает самостоятельно, какую поддержку получает дальше и чего стороны ждут друг от друга.

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

Короткий чек-лист для руководителя

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

В первый день: на первом 1:1 еще раз обсудить взаимные ожидания, познакомить с командой, проверить инструменты и календарь первой недели.

В первую неделю: показать продукт вживую, пройти один сценарий по коду, дать небольшую задачу и обсудить результат.

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

К концу испытательного срока: давать больше самостоятельности, сверить результаты с планом и договориться о следующих целях.

Хороший онбординг не делает человека полностью независимым за несколько дней. Он последовательно убирает лишнюю неопределённость, даёт безопасный первый опыт и помогает команде передавать ответственность без резкого перехода от «тебе всё покажут» к «теперь разбирайся сам».