Дисклеймер: если после прочтения этого текста вы захотите внедрить KPI для программистов — сходите прочитать еще и это.

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

Итак, какие цели преследует аттестация.

Цели

• Посмотреть текущий уровень разработчика.

• Узнать, какие направления человеку интересно развивать.

• Предоставить возможность развития в том же технологическом векторе, в котором идет Сибирикс, или в факультативном направлении (для общего развития).

• Дать разработчику обратную связь: положительную, либо отрицательную.

• Дать рекомендации: что лучше прокачать, что нужно подтянуть, что можно почитать.

Решение

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

Заполнение карты компетенции.

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

Сама аттестация.

Всегда происходит один на один с разработчиком.

Мы беседуем и сравниваем карты компетенции: текущую и предыдущие. Так можно отследить прогресс и смену ориентиров конкретного человека.

Дальше — анализируются потребности (технологические «хотелки») разработчика. Для того, чтобы помочь прокачать какую-то технологию, студия может предложить три варианта:

• Во-первых и самых главных — попробовать ставить человека на реальный боевой проект с подобной технологией, когда (и если) так выпадут звезды.

• Изучить факультативно. Тут два варианта. Предпочтительный — устроить хакатон, так получается больше практических знаний (так мы сделали Whoision, на минутку). Альтернативный — провести холивар по теме, а разработчика назначить докладчиком.

• Изучить самостоятельно. Тут все в руках самого программиста, помочь можем рекомендациями, что почитать, с кем в студии поговорить и можем поверить знания.

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

Кодревью.

Мной отсматривается код программиста — реальные проекты, над которыми он работал в последние полгода.

Совсем не факт, что кодревью выявит какие-то глубинные ошибки. Для этого нужно слишком много времени. Оно направлено, скорее, на формирование общего представления об уровне разработчика. Такое знание пригодится при формировании команд (опытные/новички) и при распределении задач внутри команды.

«Talk is cheap. Show me the code».

Linus Torvalds

Подведение итогов.

В результате разработчик получает три ценных директивы: что почитать, что подтянуть, что попробовать из нового.

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

Находка: в ходе аттестации мы также применяем вариацию известного «метода 360 градусов». Мы разговариваем с человеком, просим рассказать про конкретных людей, с которыми он работал, их сильных и слабых сторонах. Так как в Скраме все проекты делаются в небольших командах, то такой «инсайдер» может дать наиболее ценные рекомендации.

Чего нет в нашей системе аттестации — так это балльной системы и прочей формалистики.

Итого. Сложности внедрения

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

• Это отнимает очень много времени.

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

• Советы, которые вы даете по итогам аттестации — это и просто рекомендации, и императивные указания с занесением в персональный план и контролем выполнения.

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

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

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