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

Я возглавляю стрим Компьют (Вычислительные Ресурсы, говоря проще) в быстрорастущем облачном провайдере с осени 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.

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

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

2. Специфика управления: рассказа о компании предваряет собой рассказы о других стримах, их лидерах, зонах ответственности, особенности матричной структуры управления.

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

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

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

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

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

• из этого выделить более и менее критичные моменты, более дорогие и менее в исполнении. Многие потребности закрываются почти бесплатно;

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

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

• после каждого онбординга (или по завершению испытательного срока) получать фидбек от нового коллеги. Всё равно нужны встречи формата 1-1 или по подведению промежуточных результатов испытательного срока, на них фидбек может быть двусторонний;

• онбординг нужен не только разработчиком, почти 2/3 из описанного нужно рассказывать всем коллегам. Тестировщикам и аналитикам такие встречи тоже нужны и тоже полезны;

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

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

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

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