Здравствуйте, 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 для программистов. Какие бизнес-цели и т.д. Главное, требуется согласовать формулировки, чтоб они были измеряемыми. Тема, хочу чтоб программисты работали лучше, эффективнее и т.д. не подойдут.
Подойдут:
Кол-во закрытых ошибок (т.е. эффективность меряем);
Кол-во багов в коде программиста в месяц, к примеру (повышаем качество кода);
M>1) Некое отношение трудозатрат к приоритетности (удельному коммерческому весу). Расчет типа: часы Х весовой коэф. Это не измеримый показатель. Вопросы: Кто и как рассчитывает весовой коэффициент, т.к. в пределе эта формула дойдет до абсурда.
M>2) Количество новых/изменившихся требований с момента утверждения ТЗ. Это вообще разработчики?!!!!
M>3) «Количество» экспертиз, которыми надо обладать для решения задачи. Хорошая штука, но нужно объективное мерило!!! Собственно ключевые задачи бизнеса не решает, скорее подойдет для системы грейдов