Как мы организовали менторство в отделе фронтенда

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

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

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

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

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

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

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

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

При оценке компетенций мало просто сказать: тут я знаю хорошо, тут отлично, а тут плохо. Дело в том, что такие оценки очень субъективны и не дают общей картины. Чтобы дать более объективную оценку, мы описали все доступные в стеке компетенции широкими мазками и разработали шкалу баллов от 1 до 10, где каждый балл определяет уровень разработчика в данной компетенции. Например, 1 — когда-то читал, 10 — отлично применяет на практике и может объяснить каждый аспект. Каждый специалист отдела владеет всеми компетенциями из списка, но на различных уровнях.

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

Весь процесс менторства в шести шагах

Шаг 1. Закрепление ментора за специалистом

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

Шаг 2. Самопроверка компетенций

Ментор выдает специалисту компетенции для оценки себя по списку компетенций.

Шаг 3. Оценка компетенций ментором

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

Шаг 4. Составление листа аттестации

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

Шаг 5. Ежемесячный чекап

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

Шаг 6. Повторная аттестация

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

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

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

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

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

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

Краткий итог: было полезно, дайте две!

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

Для меня первая аттестация выглядела так:

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

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

Мы договариваемся с другими senior и teamLead разработчиками из группы компаний Kokoc. Так оценка будет объективной и позволит специалистам взглянуть на себя глазами независимого эксперта.

А еще у Landau есть телеграм-канал, в котором публикуем заметки про проекты в работе, интересные находки и процессы.

#менторство #разработка #личныйопыт #внутреннее_обучение #джуну