Привет, Хабр! Я Серёжа Пиший, я тимлид продуктовой команды Android-разработки в направлении КИНО в Okko. В этой статье расскажу про онбординг. Это будет не инструкция, а скорее история о том, как мы справились с масштабированием нашей команды на двенадцать человек практически за раз. Возможно, наш опыт поможет наладить процесс онбординга и вам.

Исходные данные

Это я — счастливый тимлид четырёх разработчиков.

Все было просто, размеренно, под контролем:

• 30 человек в команде;

• одновременно нанимали и онбордили максимум 2-3 человек — не было больших скачков роста компании;

• каждому новичку — по ментору;

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

Никаких запар, всё прозрачно и понятно.

Что может пойти не так?

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

Отсюда сразу несколько нюансов:

• двенадцать новых разработчиков должны были прийти почти одновременно;

• процесс онбординга для них нужно провести быстрее обычного;

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

• на подготовку онбординга — всего месяц.

«Крайне интересная задача!» — подумал я и, конечно же, взялся за этот челлендж.

Наше решение — онлайн-курс

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

Почему именно курс?

• Курс одновременно проходит неограниченное количество человек;

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

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

Наконец, это позволяет минимально отвлекать текущую команду от разработки проекта.

Разделы курса

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

Единая задача для постепенного выполнения

За её основу взяли лайт-версию нашей фичи для ТВ — карточку контента с обложкой фильма, информацией о нём, кнопкой «Смотреть» и списком похожих фильмов. Работа с ней затрагивает все важные аспекты проекта — сеть, архитектуру, работу со списками. 

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

Видео-лекции с ответами на вопросы

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

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

Документация

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

Ссылки на полезные материалы

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

Чат для ревью

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

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

Первый запуск проекта

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

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

Введение

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

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

База

Проект построен по принципу модуляризации, а не монолита — об этом и рассказываем в этом разделе.

В лекции и документации новичок найдёт:

• принципы модуляризации,

• технический стек,

• навигацию,

• TEA,

• принципы работы с фичами.

Первая часть задачи

Приступаем к разработке фичи ContentCardLight:

• создаём пустой фрагмент с архитектурным скелетом,

• фича-флаг,

• открываем ContentCardLight под флагом с главной страницы приложения.

Код ревью

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

Плетём сеть

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

Вторая часть задачи

Создаём отдельный сетевой запрос для фичи:

• все прослойки — repository, use case, data source;

• модели данных для разных слоёв;

• стейт экрана ContentCardLight;

• вёрстка и отображение кавера фильма и названия.

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

Задача завершалась, естественно, код ревью.

Работа со списками

Лекция и документация включают в себя:

• ресайклеры, делегаты, uiType,

• систему управления фокусами и инструменты для дебага,

• инструменты бизнес-аналитики.

Заключительная часть задачи

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

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

• Модели данных для разных слоёв;

• Делегат для отображения списка;

• Добавление списка во фрагмент;

• Навигация на ContentCardLight по клику на похожий фильм.

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

Наконец — код ревью.

Дополнительные разделы

Рассказываем обо всём, чего не успели коснуться за время прохождения онбординга — CI/CD, устройство таких сложных фичей, как биллинг, авторизация и плеер, сущности нашего сервиса (как их называем, где они живут). FAQ дополняем каждый новый онбординг, потому что вопросы появляются и отвечать на них снова и снова не хочется.

В этот раздел внесли дополнительные полезные ссылки — внутренние на бэкенд и внешние на дополнительные материалы.

Результаты

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

Всего онбординг занимал от 3 до 5 недель — в зависимости от уровня разработчика и того, насколько он глубоко он вникал в проект.

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

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

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

Важные моменты

Главное — результат

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

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

Практическая направленность

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

Живое общение

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

Как похорошел онбординг при Серёже

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

Вот как он помогает нам сейчас:

• Время онбординга сократилось с 6-8 недель до 2-4 недель. При этом те, кто прошёл новый онбординг, оказываются более подготовлены к работе чем те, кто проходил его по старой схеме.

• Сократилась нагрузка на менторов. Если раньше ментор тратил в среднем 1-2 дня в неделю на помощь новеньким, сейчас — менее 1 дня в неделю. Ментор нужен не для того, чтобы учить разработчика и погружать в проект, а чтобы общаться с ним — рассказывать о проекте и команде, отвечать на вопросы, помогать советами и поддерживать. 

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

Заключение

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

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

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