Как мы строим масштабируемый процесс онбординга при гиперросте команды разработки

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Всем привет, меня зовут Степан Фоменко, и я разработчик Miro в команде, которая занимается поддержкой баз данных и миграцией основных данных из Redis в Postgres. В этой статье расскажу, как мы изменили процесс онбординга в командах разработки в условиях резкого роста количества инженеров.

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

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

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

Как было раньше

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

При всей теплоте и ламповости этого подхода есть две причины, которые не позволили нам применить его при росте команды:

  • Сложность системы постоянно увеличивается, нужно привлекать всё больше технических экспертов, чтобы рассказать новичку о важных изменениях;

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

Как работает сейчас 

Мы довольно сильно изменили процесс: отказались от очных встреч с экспертами, создали большую базу знаний из статей и видео по процессам, архитектуре и внутреннему устройству продукта, запустили роль онбординг-ментора и разработали детальный недельный план на весь период адаптации. Сейчас онбординг у нас длится примерно 2,5 месяца.

Онбординг план

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

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

Пример чеклиста третьей недели онбординга
Пример чеклиста третьей недели онбординга

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

Онбординг ментор

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

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

Сложности, с которыми мы столкнулись при трансформации процесса онбординга

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

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

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

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

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

Советы

Несколько советов, которые могут быть полезны вне зависимости от вашего объёма найма. 

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

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

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

Итоги

Внедрив новый процесс онбординга, мы получили следующие плюсы:

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

  • Гарантированное покрытие важных тем с помощью видео и документации;

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

  • Прозрачные ожидания от новичка в ходе онбординга;

  • Снятие нагрузки с экспертов в предметных областях.

Всё это вместе дало нам возможность эффективно масштабировать онбординг при большом найме. 

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

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

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

Источник: https://habr.com/ru/company/miro/blog/556278/


Интересные статьи

Интересные статьи

В одном из наших проектов используется Edge-модуль, работающий на широком наборе оборудования c процессором ARM, типа Raspberry Pi. Данное устройство используется для то...
Появившиеся в 2006 году сервисы Google по работе с текстовыми документами (Google Docs) и таблицами (Google Sheets), дополненные 6 лет спустя возможностями работы с вирту...
Вопрос разработки и приготовления плейбуков по реагированию на инциденты сейчас очень активно обсуждается и порождает разное количество подходов, поиск баланса в которых крайне важен....
Диаграмма вычислительной микросхемы в процессоре Intel Lakefield: одно ядро Core (Sunny Cove) и четыре ядра Atom (Tremont) Десять лет назад ARM представила гетерогенную архитекту...
Отсутствие уязвимости в CPU лучшее что может быть, но как проверить есть ли они, эти уязвимости? Как выясняется в современных процессорах они буквально "пачками". И счастливому обладате...