Добро пожаловать на борт.

Я возглавляю стрим Компьют (Вычислительные Ресурсы, говоря проще) в быстрорастущем облачном провайдере с осени 2024 года. Мы (и стрим Сетей) отвечаем на облачные примитивы, на которых строятся буквально все другие облачные продукты. За это время стрим столкнулс�� с настоящими вызовами, некоторые процессы пришлось выстраивать.

Когда первый раз мне HR`ы сообщили, что наш оффер принят, я столкнулся с тем, что хоть про онбординг‑адаптацию и говорят, конкретных гайдов и статей нет. На мысль о том, что «что‑то надо с этим делать» меня натолкнула коллега с другого направления, которая постоянно жаловалась на трудности адаптации и отсутствие информации. У нас, конечно, информации было достаточно в конфлюенсе, но, она не была структурирована для быстрого погружения нового сотрудника. Это был тревожный звоночек. Мы тратили месяцы на сложный технический отбор (воронка в 2-3% от кандидатов), находили сильных специалистов, а затем рисковали потерять их в первые же недели из‑за некачественных процессов и информационного голода.

Я исходил из простой мысли: высокий порог входа в наш продукт — данность. Облака, Kotlin, сложная кодовая база — от этого никуда не деться. Значит, нельзя позволить, чтобы к ней добавился хаос в процессах. А задача лида — построить чёткий маршрут, по которому новичок сможет комфортно присоединиться к проекту.

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

Часть 1. Контекст: где мы плывём

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

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

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

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

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

Часть 2. Быстрый старт: ответы до вопросов

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

Первое, что я сделал – написал документацию:

собрал список ссылок на внутренние системы:
- git (набор репозиториев)
- ссылки на UI платформы на стендах (DEV, TST)
- ссылки на Jira
- k8s dashboard (DEV, TST)
- DB URL (DEV, TST)
- kafka URL, kafkaUI URL (DEV, TST)
- ссылки на группы документаций в confluence по продуктам и командам
- ссылки на документацию по орг. структуре
- ссылки на общеплатформенную архитектуру (группу страниц)
- ссылки на Graphana UI
- ссылки на UI платформы виртуализации (DEV, TST)
- Vault URL
- Nexus URL
- S3 minio URL (DEV, TST)
написал статью по получению и использованию сертификатов для локальной разработки
написал очень короткую статью по настройке рабочего места. Аналогичная была написана для всех разработчиков 2 года назад, но уже сильно устарела. Новая статья была уже в неймспейсе стрима и рядом со списком ссылок. Статья содержит перечень необходимого софта.

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

Часть 3. Встречи: знакомство с командой

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

рассказ о платформе виртуализации (от архитектора)
рассказ-демонстрация о нашей облачной платформе (веду я или аналитики). Общий обзор о целях и ценностях, о текущем состоянии.
рассказ-лекция об архитектуре платформы. На момент создания онбординга у нас было уже две архитектуры, я рассказывал в основном про новую. Рисовал схемы. Далее пришлось разделить на две встречи.
рассказ о принципах и правилах, этапах разработки, ветвления git, ответственности. Всегда я вел.
рассказ о структуре компании, стримах, их ролях в процессах. В компании используется матричный принцип управления. О нем рассказываю я на техническом собеседовании или кто-то из коллег после него, но, как показывает практика, повтор и описание нюансов взаимодействия очень полезна новичкам. Сначала я вел такие встречи, потом делегировал аналитику.
позже добавили дополнительную встречу по организацию данных в базах данных. Вёл коллега-разработчик.

Все встречи подразумевались в офисе, в переговорной, с рисованием на доске. Для всех новичков я просил первые две недели приходить в офис ежедневно. Это важный этап знакомства с командой и компанией. Длительность каждой встречи час. Для большинства встреч этого как раз хватает для рассказа, и остается время на 2-3 вопроса. Ставил встречи каждый день в середине дня. Более короткие встречи, например, о процессах разработки и матричной структуре управления, дают около получаса времени на обсуждение трудностей, ответов на вопросы, которые у нового коллеги уже могли накопиться за несколько дней работы.

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

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

На самом деле всё это было несложно придумать и организовать, и это не формальность, и не принудиловка. Эти встречи призваны снизить порог вхождения в наш стрим, а он высокий даже несмотря на высокий уровень утверждённых кандидатов (middle+/senior-) по нескольким причинам:

облачные технологии. Определённые повышенные требования, например, к надёжности. Определённые особенности. Большинство людей не имели опыта работы в облаках, многие пользовались облаками лишь минимально (для хранение) или не пользовались.
стрим Компьют разрабатывает IaaS, то есть сервисы, на основе которых разрабатываются более сложные решения (PaaS, SaaS), а, значит, требования к качеству должны быть ещё выше. И качество должно быть с этапа построения аналитики. У многих не было такого опыта, такого жёсткого контроля качества и чистоты.
kotlin. Почти ни у кого из кандидатов не было опыта работы, а если и был, минимальный (пет-проекты или юнит-тесты).

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

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

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

Часть 4. Принципы построения цикла встреч

Инкрементальность: От общего к частному, от продукта к коду.
Интерактивность: Не монолог, а диалог. После каждой встречи — время на вопросы.
Разные спикеры: Новичок знакомится не только с лидом, но и с архитектором, аналитиком, ключевым разработчиком.
Офлайн-формат (где возможно): Первые две недели — в офисе. Важно для нетворкинга и неформального общения.

Встречи показали себя с хорошей стороны, со временем коллеги оценили полезность.

Далее я доработал документацию:

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

Онбординг стал более полным, а встречи более предсказуемыми (регламентированными) и структурированными. Такая программа адаптации постепенно сглаживала все аспекты высокого порога вхождения:

Облачные нюансы: контекст нашего бизнеса, а, значит, базовый контекст нашей разработки, всех её процессов и целей. Встречи по продукту, по компании задают вектор, а последующие встречи по архитектуре фокусируются не на «как писать микросервис», а на специфике облачного провайдера: потоки данных в интеграционных взаимодействиях, применяемые технологии, концепция квот и лимитов.
Специфика управления: рассказа о компании предваряет собой рассказы о других стримах, их лидерах, зонах ответственности, особенности матричной структуры управления.
Специфика стека: поскольку по большей части kotlin используется и код на нем исполняется так же, как и на java, прошедшим наши технические интервью разработчикам не нужно слишком много усилий на его изучение. Вместо сухой документации мы создали гид «Из Java в Kotlin». В нем были не основы синтаксиса, а разбор наших реальных паттернов: как мы используем data-классы, корутины для фоновых задач, упрощаем существующий код и уменьшаем время непосредственно на сам кодинг. Плюс отдельная встреча с разработчиком-носителем этой экспертизы, который может ответить на появившиеся вопросы. Вообще, с течением времени сама команда стала носителем экспертизы, существенно упрощая адаптацию будущим новичкам.
Специфические требования к качеству: рассказывая по процессы, мы рассказываем не просто про формальное ревью, а про ревью на разных стадиях разработки продукта: постановки, кода, результатов теста. Мы стараемся мотивировать людей самим проводить ревью, тем самым ещё и снижаем стресс или страхи перед ревью их будущих MRов. Возможно, благодаря и этим разговорам на старте работы нового участника команды мы добились работающего кросс-ревью без принуждения, по инициативе самих разработчиков. К слову сказать, растёт интерес к ревью кода и у аналитиков, сейчас даже некоторые небольшие правки контрактов в проектах выполняются силами только аналитиков.

Часть команды – часть корабля

Так и плывём куда-то в сторону светлого будущего.

Какие выводы я сделал. Для успешного построения онбординга нужно:

надо узнавать у коллег, чего им не хватает/не хватало, причём интерес могут представлять фидбеки коллег из смежных команд или смежных должностей;
из этого выделить более и менее критичные моменты, более дорогие и менее в исполнении. Многие потребности закрываются почти бесплатно;
набросать где-то в документации приблизительные блоки статей и встреч онбординга;
дальше что-то заполнить самому, что-то возможно делегировать, если по одному из направлений онбординга кто-то из коллег обладает большей экспертизой и желает помочь;
после каждого онбординга (или по завершению испытательного срока) получать фидбек от нового коллеги. Всё равно нужны встречи формата 1-1 или по подведению промежуточных результатов испытательного срока, на них фидбек может быть двусторонний;
онбординг нужен не только разработчиком, почти 2/3 из описанного нужно рассказывать всем коллегам. Тестировщикам и аналитикам такие встречи тоже нужны и тоже полезны;
делать выводы по пройденному пути и возвращаться к первому пункту, корректируя регламенты и процесс.

В итоге у моего стрима образовался целый раздел онбординга. Впосле��ствии другие стримы стали создавать похожие страницы, некоторые ссылались на нашу документацию как исходную. Сейчас поиск в confluence по слову «онбординг» дает ещё 5 разделов документации, в разных пространствах, для разных стримов.

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

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

Онбординг без стресса