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

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

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

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

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

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

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

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

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

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

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

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

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

·         Бизнесовый бэклог

·         Платформенные доски с задачами

·         Инструкции по прохождению флоу

·         Сиквенс-диаграммы и схемы статусов (состояний)

·         Инструкции по пользованию инструментами

·         Описание продукта

·         Style guide

·         Описание API

·         Репозитории

·         Регламенты

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

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

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

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

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

·         Получить доступы, настроить окружение (ссылки на ресурсы)

·         Изучить продукт (снова ссылки)

·         Изучить соглашения, code style, регламенты (ну вы поняли)

·         Познакомиться с кодовой базой

·         Писать автотесты

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

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

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

2) наглядность процесса – всегда можно посмотреть динамику прохождения

3) обучение не на кошках, а на полном клоне боевых задач

Итог

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

1.       Ввели комфортную для всех коммуникативную парадигму

2.       Минимизировали вопросы

3.       Смогли погрузить новичков в область требований с их максимальной автономностью, не затратив на обучение всё наше рабочее время

4.       Совместили теорию и условно боевую практику

5.       Сделали процесс прозрачным и контролируемым несмотря на массовость

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

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


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

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

Обнаруженный в 2017 году вредонос Trisis до сих пор остается настоящим кошмаром для промышленности. Его цель – вывести из строя систему противоаварийной защиты предприятия, лишив автоматику и персонал...
1С Битрикс: Управление сайтом (БУС) - CMS №1 в России по версии портала “Рейтинг Рунета” за 2018 год. На рынке c 2003 года. За это время БУС не стоял на месте, обрастал новой функциональностью...
На сегодняшний день у сервиса «Битрикс24» нет сотен гигабит трафика, нет огромного парка серверов (хотя и существующих, конечно, немало). Но для многих клиентов он является основным инструментом ...
Если Вы используете в своих проектах инфоблоки 2.0 и таблицы InnoDB, то есть шанс в один прекрасный момент столкнуться с ошибкой MySQL «SQL Error (1118): Row size too large. The maximum row si...
Некоторое время назад мне довелось пройти больше десятка собеседований на позицию php-программиста (битрикс). К удивлению, требования в различных организациях отличаются совсем незначительно и...