Дисклеймер: если после прочтения этого текста вы захотите внедрить KPI для программистов — сходите прочитать еще и это.
Недавно я писал о том, как были придуманы карты компетенции и как мы применяем их на стажерах. Сами карты были придуманы в помощь для аттестации программистов. Сама аттестация — дело сложное, муторное, и часто — неблагодарное.
Итак, какие цели преследует аттестация.
Цели
- Посмотреть текущий уровень разработчика.
- Узнать, какие направления человеку интересно развивать.
- Предоставить возможность развития в том же технологическом векторе, в котором идет Сибирикс, или в факультативном направлении (для общего развития).
- Дать разработчику обратную связь: положительную, либо отрицательную.
- Дать рекомендации: что лучше прокачать, что нужно подтянуть, что можно почитать.
Решение
Для того, чтобы вся схема работала, мы разработали и внедрили такую модель аттестации:
Шаг 1. Заполнение карты компетенции. Перед аттестацией ее заполняет каждый разработчик. Если будете внедрять, обязательное требование — сделать заполнение карты компетенции регулярным.
Шаг 2. Сама аттестация. Всегда происходит один на один с разработчиком.
Мы беседуем и сравниваем карты компетенции: текущую и предыдущие. Так можно отследить прогресс и смену ориентиров конкретного человека.
Дальше — анализируются потребности (технологические «хотелки») разработчика. Для того, чтобы помочь прокачать какую-то технологию, студия может предложить три варианта:
- Во-первых и самых главных — попробовать ставить человека на реальный боевой проект с подобной технологией, когда (и если) так выпадут звезды.
- Изучить факультативно. Тут два варианта. Предпочтительный — устроить хакатон, так получается больше практических знаний (так мы сделали Whoision, на минутку). Альтернативный — провести холивар по теме, а разработчика назначить докладчиком.
- Изучить самостоятельно. Тут все в руках самого программиста, помочь можем рекомендациями, что почитать, с кем в студии поговорить и можем поверить знания.
В связи с последним в карту компетенции сейчас добавили список литературы: книг, без понимания которых «крутым» себя считать вряд ли можно. Ну или, по крайней мере, они сильно ускоряют процесс наращения крутизны.
Шаг 3. Кодревью. Мной отсматривается код программиста — реальные проекты, над которыми он работал в последние полгода.
Совсем не факт, что кодревью выявит какие-то глубинные ошибки. Для этого нужно слишком много времени. Оно направлено, скорее, на формирование общего представления об уровне разработчика. Такое знание пригодится при формировании команд (опытные/новички) и при распределении задач внутри команды.
«Talk is cheap. Show me the code».
Linus Torvalds
Шаг 4. Подведение итогов. В результате разработчик получает три ценных директивы: что почитать, что подтянуть, что попробовать из нового.
Например, в ходе одной из аттестаций мы с разработчиком решили, что ему нужно прокачаться в Линуксе. В итоге снесли на его рабочей машине винду.
Находка: в ходе аттестации мы также применяем вариацию известного «метода 360 градусов». Мы разговариваем с человеком, просим рассказать про конкретных людей, с которыми он работал, их сильных и слабых сторонах. Так как в Скраме все проекты делаются в небольших командах, то такой «инсайдер» может дать наиболее ценные рекомендации.
Чего нет в нашей системе аттестации — так это балльной системы и прочей формалистики.
Итого. Сложности внедрения
Если вы захотите внедрить у себя что-то подобное, то будьте готовы как минимум к трем трудностям:
- Это отнимает очень много времени.
- Не каждому руководителю хочется этим заниматься: говорить, выяснять и уточнять, чтобы не было недопонимания и недомолвок.
- Советы, которые вы даете по итогам аттестации — это и просто рекомендации, и императивные указания с занесением в персональный план и контролем выполнения.
Когда-то давно я писал про выведение KPI для разных специалистов, текст всё еще очень актуальный, можете присоединяться к дискуссии, если что. А если лениво читать, то вывод там был вполне однозначный: KPI для разработчиков — не работает. Но какой-то измеритель все равно быть должен — в нашем случае это аттестации.
Цель аттестации: не судить разработчика, а помочь ему расти. По результатам пары успешных аттестаций у разработчика может случиться апгрейд зарплаты. По-хорошему, аттестацию нужно проводить регулярно (пару раз в год).
Мысли и замечания предлагаю смело высказывать ниже, с удовольствием послушаю и отвечу!
Автор: zevvssibirix
