- PVSM.RU - https://www.pvsm.ru -
Дисклеймер: если после прочтения этого текста вы захотите внедрить KPI для программистов — сходите прочитать еще и это [1].
Недавно я писал о том, как были придуманы карты компетенции [2] и как мы применяем их на стажерах. Сами карты были придуманы в помощь для аттестации программистов. Сама аттестация — дело сложное, муторное, и часто — неблагодарное.
Итак, какие цели преследует аттестация.
Для того, чтобы вся схема работала, мы разработали и внедрили такую модель аттестации:
Шаг 1. Заполнение карты компетенции [3]. Перед аттестацией ее заполняет каждый разработчик. Если будете внедрять, обязательное требование — сделать заполнение карты компетенции регулярным.
Шаг 2. Сама аттестация. Всегда происходит один на один с разработчиком.
Мы беседуем и сравниваем карты компетенции: текущую и предыдущие. Так можно отследить прогресс и смену ориентиров конкретного человека.
Дальше — анализируются потребности (технологические «хотелки») разработчика. Для того, чтобы помочь прокачать какую-то технологию, студия может предложить три варианта:
В связи с последним в карту компетенции сейчас добавили список литературы: книг, без понимания которых «крутым» себя считать вряд ли можно. Ну или, по крайней мере, они сильно ускоряют процесс наращения крутизны.
Шаг 3. Кодревью. Мной отсматривается код программиста — реальные проекты, над которыми он работал в последние полгода.
Совсем не факт, что кодревью выявит какие-то глубинные ошибки. Для этого нужно слишком много времени. Оно направлено, скорее, на формирование общего представления об уровне разработчика. Такое знание пригодится при формировании команд (опытные/новички) и при распределении задач внутри команды.
Linus Torvalds
Например, в ходе одной из аттестаций мы с разработчиком решили, что ему нужно прокачаться в Линуксе. В итоге снесли на его рабочей машине винду.
Находка: в ходе аттестации мы также применяем вариацию известного «метода 360 градусов». Мы разговариваем с человеком, просим рассказать про конкретных людей, с которыми он работал, их сильных и слабых сторонах. Так как в Скраме все проекты делаются в небольших командах, то такой «инсайдер» может дать наиболее ценные рекомендации.
Чего нет в нашей системе аттестации — так это балльной системы и прочей формалистики.
Если вы захотите внедрить у себя что-то подобное, то будьте готовы как минимум к трем трудностям:
Когда-то давно я писал про выведение KPI [1] для разных специалистов, текст всё еще очень актуальный, можете присоединяться к дискуссии, если что. А если лениво читать, то вывод там был вполне однозначный: KPI для разработчиков — не работает. Но какой-то измеритель все равно быть должен — в нашем случае это аттестации.
Цель аттестации: не судить разработчика, а помочь ему расти. По результатам пары успешных аттестаций у разработчика может случиться апгрейд зарплаты. По-хорошему, аттестацию нужно проводить регулярно (пару раз в год).
Мысли и замечания предлагаю смело высказывать ниже, с удовольствием послушаю и отвечу!
Автор: zevvssibirix
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/news/61278
Ссылки в тексте:
[1] прочитать еще и это: http://blog.sibirix.ru/2012/09/26/kpi-as-genocide/
[2] карты компетенции: http://blog.sibirix.ru/2014/04/18/competence_card/
[3] карты компетенции: https://docs.google.com/a/sibirix.ru/spreadsheet/ccc?key=0AmFQKnqjkGFKdGJKNVN0QlUwRnFsY3M2QlNiUVl1QkE#gid=1
[4] так мы сделали Whoision: http://blog.sibirix.ru/2013/09/13/hackatone/
[5] холивар по теме: http://blog.sibirix.ru/tag/holywarmodeon/
[6] Источник: http://habrahabr.ru/post/224923/
Нажмите здесь для печати.