Всем привет!

Я — Михаил, руководитель филиала в Питере.

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

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

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

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

На эти вопросы мы нашли свои ответы и решили построить систему в 4 этапа:

1. Формирование общих требований (грейдов) для специалистов четырех основных направлений: frontend-разработка, backend-разработка, devops, QA.
   
   
2. Проведение тестирования каждого сотрудника для оценки его текущего уровня.
   
   
3. Беседа с каждым по результатам тестирования.
   
   
4. Формирование индивидуального плана развития для каждого сотрудника.
   
   

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

В среднем по больнице мы считаем:

• junior'ом — сотрудника, который в состоянии качественно выполнить четко поставленную техническую задачу. За ним требуется постоянный присмотр, code review, в случае необходимости — помощь;
  
  
• middl'ом — того, кто может отвечать за часть проекта, работать с нечетким ТЗ и указывать на его недостатки. В состоянии при помощи пары «джунов» довести отдельно взятый функционал до продакшена;
  
  
• senior'ом — терминатора в некотором роде, который полностью понимает, как и что работает в проекте (вплоть до тонкостей работы выбранных серверных технологий). Может в короткие сроки решить любой вопрос, даже не технического характера. Берет на себя ответственность за проектные решения, принятые коллегами.
  

В плане хард-скиллов получилось четыре документа для backend- и frontend-разработчиков, QA и DevOps. Три составных части каждого грейда, если говорить грубо, — это:

1. Знание своей предметной области и основных инструментов специалиста в этой области.
   
2. Понимание и навыки для нашего стэка технологий.
   
3. Базовые софт-скиллы.
   

Для примера приведу выдержку из грейда junior backend-разработчика:

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

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

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

Давайте разберемся с этапом тестирования и зачем он нужен.

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

Мы постарались к закрытым вопросам с вариантами ответов добавить также открытые, где есть возможность порассуждать. Ну и как же без задач на написание кода!

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

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

Пример одного из них (для middle backend-разработчика) можно посмотреть и пройти здесь. Он рассчитан примерно на 40 минут спокойного и вдумчивого прохождения.

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

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

Я бы в таком случае поинтересовался, почему именно svg, в чем отличие растрового и векторного формата, побеседовал бы об их размере, о том, от чего он зависит, попросил бы привести примеры еще пары форматов изображений. Думаю, подход понятен =)

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

После беседы мы проставляем результат в каждом разделе грейда. К примеру, если в грейде 8 пунктов, а знания оценены на 4 — значит, это 50 %. Возьмем для примера результат аттестации backend-стажеров в одной из наших команд:

Я, как тимлид, вижу, что три моих сотрудника находятся на половине пути между стажером и полноценным junior backend-разработчиком, а остальные два уже близки к цели.

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

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

Пример плана развития

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

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

В итоге система не только позволила управлять процессом, но и замотивировала людей учиться и развиваться. Раньше путь от «джуна» до «миддла» составлял 8–14 месяцев. Теперь это занимает 6–9 месяцев. Кроме того, мы заметили, что команда стала гораздо лучше концентрироваться на нужных для наших проектов скиллах, стала более ответственной, что положительно сказалось на качестве и скорости работы.

Казалось бы, все идет хорошо. Скиллы оценены, планы развития составлены, тимлид и команда довольны. Но здесь мы не оцениваем как софт-скиллы, так и корректное применение хард-скиллов в конкретном проекте. Наверняка большинству тимлидов знакома ситуация, когда классный специалист не вписывался в команду, а также очень компанейский сотрудник оказывался не в состоянии решить даже простейшие задачи. Для решения этих задач мы тестируем систему аттестаций софт-скиллов и защиты кода из боевых проектов. Все в соответствии с грейдами, разумеется =) Если тема интересна, расскажем подробнее в следующих статьях.