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

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

Мой личный опыт онбординга тоже всегда начинался с того, что вот проект/продукт, вот команда, вот задача, греби. Мне приходилось самой искать людей, кто расскажет о системе, покажет кейсы. Чаще всего это были тестировщики, кстати. Приходилось искать документацию, вычитывать её, а сроки по задаче идут. Ещё из сложного в моём опыте онбординга — это угадать принятый в копании или отдельной команде формат оформления задач разработчикам. Часто майнинг такой информации — это поиск людей, кто может и готов рассказать, как надо, или метод проб и ошибок. Ещё из моего опыта: сложности на первых этапах были с узнаванием процессов. Где‑то они были описаны, но описание и реальность немного отличались, а где‑то процессы не были описаны совсем. Тогда так же приходилось пробиваться к знаниям самостоятельно. Выходило так, что выплываешь — молодец, а не выплываешь — увы.

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

Меня зовут Борисова Екатерина, я старший системный аналитик в компании Bimeister. Погнали!

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

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

А теперь подробнее про онбординг и испытательный срок.

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

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

Соответственно, со второй недели новый аналитик получает свою первую задачу. Эту задачу он делает вместе с наставником. Основной уклон в то, чтобы разобраться в процессе и глубже погрузиться в продукт: пощупать его руками, самому переложить бизнес‑кейсы на систему, определить, как заявленную проблему можно решить через автоматизацию в системе. Новичок с наставником обсуждают заявленную проблему, вместе брейнштормят решение, ходят на все встречи по задаче. Наставник как бы «за ручку» ведёт своего подопечного по задаче, но не решает её за него, это важно. Первый, кто принимает результат работы по первой задаче — это тоже наставник. Он проводит ревью технического задания и даёт рекомендации по улучшению и доработке, если такие есть. По ходу выполнения первой задачи наставник может дать рекомендации в более глубоком изучении той или иной части системы, технологии, методики и т. д., — всему, что пригодится в работе.

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

Обычно наставник плотно работает с подопечным примерно 1,5 месяца, постепенно отпуская его. Работа строится таким образом: первые недели наставник проводит ежедневные часовые встречи с подопечным. Встречи строятся таким образом: наставник рассказывает и показывает порцию материала по системе, это может быть какой‑то функциональный блок или даже небольшой модуль, дальше отвечает на вопросы новичка, может задавать свои. Обязательно идёт обсуждение планов на день и результатов предыдущего дня. Дальше по мере освоения продукта и выполнения первой задачи количество и длина встреч сокращается. Например, где‑то с 3-й недели достаточно бывает синка по 15–30 минут, где в основном наставник отвечает на вопросы подопечного. Тут уже становится понятна скорость и самостоятельность аналитика, уже не нужно обсуждать планы и результаты. Примерно с 4-й недели достаточно синка пару раз в неделю, так же сессия вопрос‑ответ. Чем дальше, тем меньше. В основном после 1,5 месяцев мы отменяем синки. Но, хоть уже нет регулярных встреч с наставником, он продолжает быть в полной доступности для своего подопечного. Цифры собраны средние, понятно, что кому‑то нужно больше времени, кому‑то меньше.

Так же для новых сотрудников каждую неделю проходит ретро адаптации — это 30 минутная встреча, на которой мы пытаемся ответить на вопросы: что было хорошо, что было сложно, на что обратить внимание. Делимся идеям по улучшению процессов, развитию и т. д. Результат обсуждения фиксируем на доске ретро. Всячески приветствуем, если новый аналитик подсвечивает проблемы в процессах или продукте, предлагает улучшения. Цель данных встреч — открыто делиться идеями, корректировать ход адаптации, искать пути улучшения процессов в компании (куда без этого). Кстати, ретро мы отменяем так же после того, как новый сотрудник становится самостоятельным. Тут возникает резонный вопрос, а испытательный срок считается пройденным? Неформально мы считаем да, но формально он продолжается все 3 месяца.

Кстати, схожие системы наставничества есть ещё у коллег‑аналитиков из Точки. Только в Точке коллеги в течении 3-х месячного периода меняют команды, области знаний. Мы же стараемся сразу погружать новичка в конкретный продукт, соответствующую предметную область и в работу с конкретной командой. Классный подход с продолжительным менторством даже после адаптации есть у Redmadrobot. Мы тоже не бросаем коллег на произвол судьбы после прохождения испытательного срока. После наставника заботу об аналитике начинает лид аналитиков. Лид находится постоянно в контакте с командой аналитиков, следит за температурой, контролирует, чтобы градус не повышался, помогает составить план роста и помогает ему следовать. Если всё же кто‑то начинает подгорать, то лид помогает снять напряжение. Более подробно про работу внутри команды и с командой лучше рассказывать в отдельной статье.

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

Что мы получили благодаря нашей методике онбординга:

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

2. Процесс идёт комфортнее для новичка. Наставник всегда рядом, готов подсказать, рассказать, направить в нужную сторону.

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

В качестве заключения хочу приложить опробованный нами и хорошо себя зарекомендовавший шаблон онбординга из миро — https://miro.com/miroverse/new‑employee‑onboarding‑for‑product‑teams/?social=copy‑link

И вот, как мы его использовали: