M>>И как вообще можно загнать работу программиста в рамки KPI? B>Можно, но не нужно.
Здесь главное вот что нужно понимать: KPI есть то, что мы хотим оптимизировать.
хотим оптимизировать время разработки? надо учитывать его. количество багов? надо считать их.
Прибыль компании нужна?
нужно ставить премию сотрубникам в зависимости от прибыли компании.
Здравствуйте, 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) «Количество» экспертиз, которыми надо обладать для решения задачи. Хорошая штука, но нужно объективное мерило!!! Собственно ключевые задачи бизнеса не решает, скорее подойдет для системы грейдов
Здравствуйте, mag745, Вы писали:
M>Здравствуйте, bkat, Вы писали:
B>>Здравствуйте, mag745, Вы писали:
M>>>Я нашел сайт с KPI для разработки http://www.smartkpis.com/kpi/functional-areas/information-technology/application-development/
B>>Там вполне нормальные метрики, которые можно использовать для оценки процессов в целом. B>>Далеко не все из них, кстати, есть смысл применять именно как KPI. B>>Многие из них являются обычными метриками качества (например "Software errors to application run time ratio"). B>>Еще большей ошибкой было бы применять их для оценки отдельных программистов. B>>То же "количество повторных багов" хорошая метрика, но если сделать на ее основе формулу, B>>которая будет определять твою личную зарплату, то ничего хорошего не будет.
...
Здравствуйте, dimaserm, Вы писали:
D>Подойдут: D> Кол-во закрытых ошибок (т.е. эффективность меряем); D> Кол-во багов в коде программиста в месяц, к примеру (повышаем качество кода);
Динамика прибыли на одного девелопера подойдет ? А то руководству бывают не очень понятны специфические метрики и их связь с эффективностью. И, случается, руководство понимает, что спецметрики можно натягивать в любую сторону. Например, имеем версию, полную багов, и с кривой архитектурой. Начинаем редизайн и, одновременно, измерение KPI. Работа кипит, метрики зашкаливают, а компания в жутком минусе. И как тут быть?
Здравствуйте, _Dinosaur, Вы писали:
M>>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом. _D>Посоветуйте им следующую методику: _D>1. Намочите указательный палец и поднимите его перед собой вверх, ногтем к себе.
Большой палец, большой. Такие ошибки в методике недопустимы!
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, nvb, Вы писали: nvb>Ноу-хау здесь никакого нет, мне ребята рассказывали, что подобная система с подписями работает в Боинге, но там эти листы сразу же сканируются и кладутся в электронную базу данных. Цель этого сбора данных в Боинге — фиксация персональной ответственности, а не расчет KPI. Там с ответственностью очень серьезно обстоят дела, все-таки не столовые ложки выпускают.
Про NASA аналогичные истории бывшие сотрудники рассказывали.
... << RSDN@Home 1.2.0 alpha 4 rev. 1481>>
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, mag745, Вы писали:
M>Здравствуйте! M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.
Как успехи? Что удалось измерить? Что удалось внедрить? Что в итоге получилось?
? А то руководству бывают не очень понятны специфические метрики и их связь с эффективностью. И, случается, руководство понимает, что спецметрики можно натягивать в любую сторону. Например, имеем версию, полную багов, и с кривой архитектурой. Начинаем редизайн и, одновременно, измерение KPI. Работа кипит, метрики зашкаливают, а компания в жутком минусе. И как тут быть?
