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

Но что делать, если новобранцев не один и не пять? Что, если в одно прекрасное утро мы проснулись в новой реальности – реальности, где личный состав удвоился одномоментно? Здесь перестают работать дедовские методы «садись рядом – расскажу» и наступает хаос. О том, как этот хаос подчинить, расскажу в статье.

Благо, о грядущем апокалипсисе нам стало известно заранее. «Нам» – это небольшому стартапу внутри большого продукта «Золотая Корона. Денежные переводы». Некоторое время проект был подморожен и поддерживался силами маленькой команды, но очень скоро его оценили как перспективный, а далее – и вовсе флагманский. Как следствие, проект стали накачивать ресурсами и перебрасывать бойцов с других фронтов.

«Призыв» был очень разношёрстным. Параллельно с джунами, пришедшими «извне», к нам перешли сформированные фулстэк-команды в том виде, в каком они существовали на своих прежних проектах. Эти ребята не были новичками, но и проект был сложный: много слоёв интеграции, состоящей из мобильного приложения, бэкендов, ML системы распознавания изображений и скорринга, 1С и т.д. То есть даже опытного разработчика\тестировщика предстояло погрузить в бизнес-логику и техническую составляющую.
Чтобы завершить картину, добавлю, что стартаповские темпы развития на флагманском проекте никто сбавлять не собирался. Задачи сыпались непрерывно, и вариант «Горшочек, не вари, пока мы тут обучаем» был не про нас.

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

Коммуникация по новым правилам

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

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

Карта ̶с̶о̶к̶р̶о̶в̶и̶щ̶ ресурсов

Чтобы сократить число возможных вопросов и не повторять одно и то же из раза в раз, мы составили общедоступную карту ресурсов в вики-системе confluence и включили туда ссылки на все необходимые материалы:

Бизнесовый бэклог
Платформенные доски с задачами
Инструкции по прохождению флоу
Сиквенс-диаграммы и схемы статусов (состояний)
Инструкции по пользованию инструментами
Описание продукта
Style guide
Описание API
Репозитории
Регламенты

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

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

Ещё один блок, который мы включили в карту ресурсов, – список людей, принимающих решения, и экспертов в узких областях. Так новички могли адресовать вопросы прицельно, точно зная, к кому обратиться. «Но это же противоречит договорённости общаться только в общем чате!» – воскликнете вы и будете правы. Однако всегда есть ряд вопросов, имеющих единственного адресата, так что «дешевле» обратиться к нему напрямую.

Регламенты регламентами, а делать-то что?

А вот что: в этой же вики-системе мы составили план работ для каждой платформы (разработка, тестирование, mobile\back). Каждый такой план представлял собой гайд по погружению шаг за шагом, от теории к практике. В упрощённом виде это выглядело так:

Получить доступы, настроить окружение (ссылки на ресурсы)
Изучить продукт (снова ссылки)
Изучить соглашения, code style, регламенты (ну вы поняли)
Познакомиться с кодовой базой
Писать автотесты

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

Инвариант плана для тестировщиков заключался в прохождении тест-кейсов копии боевого регресса. Тест-кейсы мы храним в плагине JIRA Zephyr, они организуются в блоки с визуально наглядной динамикой прохождения. Тем самым мы убили сразу несколько зайцев:

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

Итог

В сухом остатке история нашего счастливого спасения выглядит так:

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

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

Как заонбордить целый взвод и остаться в живых