Онбординг в ИТ-команде: как довести новичка до первой задачи за неделю

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

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

Что на самом деле тормозит новичка

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

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

Процессы передаются устно. «Спроси у Пети, он покажет» — самый дорогой способ передачи знаний: он тратит время двоих, повторяется с каждым новым сотрудником и каждый раз рассказывается немного по-разному.

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

План первой недели, который реально работает

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

День 1 — доступы и карта местности

Все доступы должны быть выданы до выхода, а не в первый день. Это единственный пункт, который стоит проверить накануне лично.

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

День 2 — окружение

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

День 3 — первое изменение

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

День 4 — процессы команды

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

День 5 — обратная связь в обе стороны

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

Почему инструкции окупаются быстрее, чем кажется

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

Инструкция окупается ещё в двух местах, о которых обычно не думают:

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

Как описывать процессы, чтобы ими пользовались

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

Что помогает:

1. Один процесс — одна инструкция. Не «работа с CRM», а «как завести сделку» и «как перевести сделку в оплату» отдельно.
2. Шаги с экранами. Скриншот каждого шага с подсветкой нужного элемента снимает 90% вопросов.
3. Ожидаемый результат. В конце шага должно быть написано, что должно получиться — иначе человек не понимает, всё ли он сделал правильно.
4. Живые ссылки. Инструкция, которую нужно скачивать в PDF, не будет открыта. Инструкция по ссылке или по QR-коду рядом с рабочим местом — будет.

Собирать такие инструкции вручную долго: скриншоты, стрелки, подписи, потом всё это устаревает после первого редизайна. Поэтому команды переходят на сервисы, которые собирают инструкцию автоматически — например, Demiqo записывает действия в браузере и превращает их в пошаговый интерактивный гайд со скриншотами, а для процессов «руками» (склад, касса, оборудование) инструкцию можно собрать из фотографий на телефоне.

Чек-лист: что описать в первую очередь

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

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

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

Коротко

Хороший онбординг — это не приветственный подарок и не экскурсия по офису. Это отсутствие блокеров: доступы выданы заранее, окружение поднимается по инструкции, первая задача проходит весь путь до продакшена, а процессы описаны так, что их можно посмотреть, а не выспрашивать. Тогда к концу недели новый человек не «вливается», а работает.