Здравствуйте, mag745, Вы писали:

M>Здравствуйте!

M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.

Правильно, мудрое руководство.

M>Исходя из краткого определения KPI — это ключевой легко рассчитываемый параметр, который влияет на доходы компании.
M>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.

M>И как вообще можно загнать работу программиста в рамки KPI?

Можно

M>В литературе по KPI написано:
M>Работу технических специалистов (бухгалтеров, инженеров, программистов) проще описывать должностной инструкцией. А подобрать для них справедливую «линейку» очень сложно.

M>Вот какие показатели предлагает руководство:

А ну давайте-ка глянем...

M>1) Некое отношение трудозатрат к приоритетности (удельному коммерческому весу).

Фигня

M>2) Количество новых/изменившихся требований с момента утверждения ТЗ.

Тоже фигня — как это относится к девелоперам? Может это все-таки вопрос к отделу маркетинга?

M>3) «Количество» экспертиз, которыми надо обладать для решения задачи.

А есть не поньимат чито бить экспертиза? Судебно-медецинская экспертиза? Или трассологическая?

M>На мой взгляд это параметры, которые нереально посчитать.

... а также очень трудно вообще понять

M>Ранее я сталкивался с такими параметрами: сколько задач сделано, по плану или сверх плана, дисциплина – фиксировалось время когда пришел – когда ушел, написание стольких-то ТЗ за год, написать патент. Но это вообще смешные показатели. Можно еще строки кода считать.

M>Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией.
M>Какие же параметры загнать в KPI?
M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.

На самом деле такие показатели нужны, и при том не только руководству, а и самому программеру — иначе на основании чего он будет через полгода работы просить повышения з/п? Типа "ну я ведь крутой перец! А вы видели мои экспертизы? Да я вам прямо щас их достану!"
На вскидку, можно предложить следующие KPI:
1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).
2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.
Если у вас контора, скажем так, "продуктовая", т.е. вы педалите свой продукт, и при этом у вас открытый диалог внутри конторы и все могут вносить предложение по продукту, процессам и т.п., и соотвественно эти предложения обсуждаются, внедряются/отклоняются, то можно еще считать такой показатель как количество внесенных предложений за год, количество принятых руководством как полезные — в умных книжках пишут, что это очень распространенная хрень у японцев и последнее время немцев и американцев в автоотрасли (тойота с ее бережливым производством ну и т.п.). Плюс это позволяет выявить людей, которые "не на своих местах" — скажем чувак у вас значится девелопером и педалит вроде бы неплохо, но при это имеет отличное видение бизнеса, понимание продукта, маркетинговых моментов, хорошее чутье относительно процессов, происходящих в конторе ну и т.п. Опять же повторюсь: для такой процедуры нужно понимание ее необходимости и полезности как в верхах, так и среди персонала — однако такой консенсус в одном месте и в одно время встречается крайне редко, а зачастую даже не привествуется одной из сторон.