Наставничество: как я с этим жил

—

от автора

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

Почему я решил стать наставником

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

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

Онбординг в предметную область и процессы

Погружение в предметную область и процессы на моей практике было двух типов:

  • непосредственно наставником

  • через план погружения

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

В этом варианте можно выделить несколько важных вех:

  1. Рассказ про предметную область

  2. Упоминание основных терминов

  3. Предоставление ссылок на JIRA, Confluence, TeamCity и прочие ресурсы, которые используются

  4. Рассказ, где что лежит

  5. Описание работы с инструментами

  6. Рассказ о проекте, приложении или сайте

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

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

Идея оформить и задокументировать этот процесс пришла от одного из project manager. По итогу, я решил расширить ее до плана, который опишу ниже.

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

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

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

Дальше связанные блоки — основные приложения компании и схема их взаимодействия. Это рассказ о том, что мы конкретно делаем.

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

Часто задаваемые вопросы, FAQ. Так как первым способом погружения человека у меня на практике было непосредственно наставником, я уже по глазам человека понимал, в какой момент и что он спросит. Собирал для себя статистику, чтобы понять, что чаще всего проседает. Это помогает и поменять программу, и сформировать этот самый список FAQ.

Но и он не гарантия отсутствия новых вопросов. Более того, я прошу их задавать! Если ответы на них были в FAQ, я об этом говорю, такое случается. Это можно пережить. А вот упустить новый значимый вопрос нельзя.

Сравнение вариантов онбординга

Вариант первый: «Наставник → погружение»

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

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

Как ни странно, этот способ в целом обычно занимает меньше времени. И в этом плане коллеги, которым предлагают быть наставниками, часто задаются вопросом «а что я буду делать со своей обычной работой?» Так вот, быть наставником — это тоже очень важная ее часть! И пока происходит погружение нового сотрудника, она основная. Это полезный опыт, чтобы самому еще раз качественно погрузиться в рабочие процессы, взглянуть на них глазами другого человека.

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

Еще здесь влияет человеческий фактор: можно что-то забыть упомянуть. Так много информации можно рассказать, что можно остановиться дольше на одном процессе, а другой рассказать скомкано, потому что времени мало осталось.

Такой способ наставничества — это рутина и повторение. Вначале еще интересно, но когда это тридцатый человек, уже процесс надоедает.

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

Вариант второй: «план → погружение»

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

С экономией времени всё очень субъективно. В среднем при погружении через наставника на новичка тратится примерно 2–3 дня (максимум 4) по 4–6 часов, а по плану — 1–2 часа в день, но растянуто дней на 5. Здесь подразумевается время до первой боевой задачи. А работа с ним — отдельная история.

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

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

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

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

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

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

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

Общие заметки про онбординг

Знакомство с воркфлоу

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

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

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

Вот основные проблемы, которые есть в работе с воркфлоу:

  • чаще всего они запутанные

  • некоторые их переходы неочевидны

  • уникальные для каждого проекта и типа задач

  • проектов может быть МНОГО

  • типов задач ЕЩЕ БОЛЬШЕ

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

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

Знакомство с задачами

У наставников чаще всего возникает четыре вопроса:

  • когда?

  • какие?

  • как контролировать?

  • как проверять?

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

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

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

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

У такого подхода тоже есть свои положительные и отрицательные стороны. Так, к плюсам можно отнести привлечение к реальным задачам, а не «синтетике» или неактуальному старью. Это помогает организовать плавный вход в рабочий процесс и получить быструю пользу от нового человека. И потом, работает же…

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

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

Работа в команде

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

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

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

Ну и самое очевидное: не увиливать от коммуникаций самому. Быть открытым и дружелюбным. Ведь ваша задача как наставника комфортно погрузить нового человека в команду и ее рабочий процесс.

Как это обычно происходит

1. Принимаем новичка от эйчаров и начинаем погружение:

  • ссылки на план погружения,

  • ссылки на документацию,

  • ссылки на ресурсы компании,

  • ссылки на ссылки.

2. Молимся, чтобы вопросов было немного

3. Понимаем, что молитвы не были услышаны, и отвечаем на вопросы

  • раз за разом

  • и еще разик

4. Выдаем начальные задачи для ознакомления

5. Инструктируем, кого трясти с вопросами по задаче

6. Проверяем, ревьювим, направляем

7. Повторяем предыдущие три пункта

…

PROFIT!!!

Ответы на самые часто задаваемые вопросы начинающего наставника

Вместо заключения

Никогда не знаешь, когда тебя назначат наставником. Специально к этой деятельности не готовят. Это не прописано в оффере, так как может потребоваться вдруг, как получилось и у меня.

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

Будет здорово, если моя статья поможет решиться на этот ответственный шаг — стать наставником. А может, даже найти призвание — кто знает?


ссылка на оригинал статьи https://habr.com/ru/company/custis/blog/692540/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *