Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.
Исходя из краткого определения KPI — это ключевой легко рассчитываемый параметр, который влияет на доходы компании.
Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.
И как вообще можно загнать работу программиста в рамки KPI?
В литературе по KPI написано:
Работу технических специалистов (бухгалтеров, инженеров, программистов) проще описывать должностной инструкцией. А подобрать для них справедливую «линейку» очень сложно.
Вот какие показатели предлагает руководство:
1) Некое отношение трудозатрат к приоритетности (удельному коммерческому весу).
2) Количество новых/изменившихся требований с момента утверждения ТЗ.
3) «Количество» экспертиз, которыми надо обладать для решения задачи.
На мой взгляд это параметры, которые нереально посчитать.
Ранее я сталкивался с такими параметрами: сколько задач сделано, по плану или сверх плана, дисциплина – фиксировалось время когда пришел – когда ушел, написание стольких-то ТЗ за год, написать патент. Но это вообще смешные показатели. Можно еще строки кода считать.
Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией.
Какие же параметры загнать в KPI?
Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
Здравствуйте, mag745, Вы писали:
M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
Нарисовать произвольные цифры и забить.
M>И как вообще можно загнать работу программиста в рамки KPI?
Можно, но не нужно.
M>Какие же параметры загнать в KPI?
Лучше никакие.
M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
Думаю объяснять бесполезно.
В лучшем случае поймут сами (через года 2-3 после внедрения KPI)
Здравствуйте, mag745, Вы писали:
M>Исходя из краткого определения KPI — это ключевой легко рассчитываемый параметр, который влияет на доходы компании. M>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.
пусть начнут с kpi секретаря менеджера уборщиц, моющих пол в отделе техподдержки внутренних продуктов компании
Здравствуйте, mag745, Вы писали:
M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.
Посоветуйте им следующую методику:
1. Намочите указательный палец и поднимите его перед собой вверх, ногтем к себе.
2. Если палец холодеет спереди (т.е. с подушечки) дела идут плохо.
3. Если палец холодеет со стороны ногтя, значит жизнь наполняет паруса и есть движение вперед!
Завидую людям, которые могут себе позволить никуда не спешить.
Здравствуйте, mag745, Вы писали:
M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.
По-моему, надо начинать неторопясь искать другую работу...
Здравствуйте, mag745, Вы писали:
M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом. M>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.
я знаю 2 точных способа оценить влияния работы на результат для обслуживающих должностей.
1) убрать сотрудника (отдел целиком) и проследить падение доходов компании. практика показывает, что разница между убиранием одного и пяти почти геометрическая. так что я бы всем отделом ушел в отпуск на недельку. будет тема на поговорить.
2) заставить пользователей услуги оценивать свои пользования. ну например "надо помыть пол — 10 рублей". помыли, значит заработали 10 рублей для компании. отказались мыть за эти деньги — значит стоит дороже. можно так же взять цены привлеченной клиринговой компании для сравнения. есть шанс, что оценивать привнесенный коммерческий результат сразу перестанут.
M>Вот какие показатели предлагает руководство: M>1) Некое отношение трудозатрат к приоритетности (удельному коммерческому весу).
угу. пусть заказчик услуги выставляет цену. ну типа: один "надо срочно — 100". второй "надо срочнее — 1000". третий "надо офигеть сейчас — 100500".
делаем третьему. привнесенный результат — 100500. первому вообще не делаем.
M>2) Количество новых/изменившихся требований с момента утверждения ТЗ.
угу. можно оценить каждое требование по времени выполнения. а время — почасовой ценой на рынке для привлеченного специалиста.
M>3) «Количество» экспертиз, которыми надо обладать для решения задачи.
ну тоже вариант. оклад для специалиста необходимого профиля. подставите свои зарплаты +20%.
M>На мой взгляд это параметры, которые нереально посчитать.
реально.
M>Ранее я сталкивался с такими параметрами: сколько задач сделано, по плану или сверх плана, дисциплина – фиксировалось время когда пришел – когда ушел, написание стольких-то ТЗ за год, написать патент. Но это вообще смешные показатели. Можно еще строки кода считать.
можно и строки кода. практика показывает монстрообразное разрастание исходников.
автогенераторы кода становятся жутко популярными. за минуты можно нагенерить мегобайты классов.
M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
что-то обьяснить руководству можно только в случае, если руководство готово слушать и слышать.
если нет канала обратной связи, то надо или выполнять, или приспосабливаться. удачи. во
Здравствуйте, 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 проектов.
Детали рассказывать не буду, но в основе лежат простые принципы:
— основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег)
— прозрачна и понятна каждому сотруднику (четко описана, расчет по каждому проекту доступен каждому)
— прозрачное формирование премиального фонда по проектам и участие каждого участника проекта в распределении такого фонда
Система очень крутая и после ее введения рентабельность компании выросла не менее чем на 20%.
Здравствуйте, sharpcoder, Вы писали:
S>У нас в компании считаются KPI проектов. S>Детали рассказывать не буду, но в основе лежат простые принципы: S> — основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег)
Пример:
Компания планирует выполнить три проекта П1, П2 и П3 для одного нового заказчика.
Контракт на проект П1 подписан, а контракты на остальные проекты под вопросом.
Объем работ по проекту П1 существенно меньше чем по проекту П2.
Компания планирует проект П1 выполнить с убытком, проект П2 с максимальной прибылью, проект П3 со стабильным доходом.
Вопрос:
Начислит ли система премии сотрудникам за выполнение проекта П1?
S> — прозрачна и понятна каждому сотруднику (четко описана, расчет по каждому проекту доступен каждому) S> — прозрачное формирование премиального фонда по проектам и участие каждого участника проекта в распределении такого фонда
это большой плюс
S>Система очень крутая и после ее введения рентабельность компании выросла не менее чем на 20%.
Где-нибудь можно почитать про эту крутую систему?
Завидую людям, которые могут себе позволить никуда не спешить.
Здравствуйте, sharpcoder, Вы писали:
M>>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.
S> — основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег)
и сколько денег вам приносит техподдержка внутренних продуктов???
Здравствуйте, ArhAngelVezel, Вы писали:
M>>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
AAV>Мне нравится как это объясняет Дорофеев: http://cartmendum.livejournal.com/60982.html
Незавершённая статья.
Разовью идею с шариками. Может так случиться, что у одного из ведра достают 100 шариков, а у другого 200, т.к. его ведро тестирует более ответственный тестер.
Плюс в вёдрах у всех разное количество шариков. У кого-то может быть 50 шариков и 1 красный. А у кого-то 500 и 50 красных. Вопрос какой уровень багов приемлем для компании.
И наконец обычно 100 шариков вытаскивается не из моего ведра, а из общего. Соответственно, чем больший вклад я сделаю, тем больше багов найдут. Если кто-то возможно вообще не добавит в общее ведро никаких шариков, то багов у него не будет, ему что теперь премию давать?
Здравствуйте, sharpcoder, Вы писали: S> — основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег)
Руководителям компании важно, сколько принес денег каждый проект, в конце концов именно они эти проекты открывают и закрывают. Это их цель — сделать прибыль. Мне — не важно, я с этих денег ничего не имею, пусть я и добросовестно выполняю свою работу в рамках проекта, что мне отведён (а кто каким проектом занимается, решаю не я). S> — прозрачна и понятна каждому сотруднику (четко описана, расчет по каждому проекту доступен каждому) S> — прозрачное формирование премиального фонда по проектам и участие каждого участника проекта в распределении такого фонда
То есть получается, что в провальных проектах как бы все программисты работали в среднем плохо, а в успешных — как бы в среднем все хорошо? Насколько у меня есть опыт, на 95% провальность или успешность проекта зависит от менеджмента стратегического и оперативного. А может даже и на 100%. В конце концов менеджер может выбирать себе программистов, а программисты намного реже могут выбирать себе менеджера.
Здравствуйте, Aptekar, Вы писали:
A>Руководителям компании важно, сколько принес денег каждый проект, в конце концов именно они эти проекты открывают и закрывают. Это их цель — сделать прибыль. Мне — не важно, я с этих денег ничего не имею, пусть я и добросовестно выполняю свою работу в рамках проекта, что мне отведён (а кто каким проектом занимается, решаю не я).
Попробуйте изменить свой подход, увидеть лес за деревьями и всё-же стараться делать прибыль, а не работать работу в рамках проекта. Проработаете так полгода-год, сами удивитесь, насколько всё поменяется и поймёте. Что и успешность проекта и Ваше вознаграждение и продвижение совсем не на 95% ... зависит от менеджмента стратегического и оперативного. А может даже и на 100%, а в большей степени зависит от Вас самого.
А потом уже сможете и менеджера себе выбирать граздо чаще, чем считаете.
A> В конце концов менеджер может выбирать себе программистов, а программисты намного реже могут выбирать себе менеджера.
Здравствуйте, sharpcoder, Вы писали:
S>У нас в компании считаются KPI проектов. S>Детали рассказывать не буду, но в основе лежат простые принципы: S> — основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег) S> — прозрачна и понятна каждому сотруднику (четко описана, расчет по каждому проекту доступен каждому) S> — прозрачное формирование премиального фонда по проектам и участие каждого участника проекта в распределении такого фонда
Очёнь интересно, как это работает. Если Вас не затруднит, опишите.
17.09.2010 13:02, starina_bz пишет: > > Очёнь интересно, как это работает. Если Вас не затруднит, опишите.
Да не работает оное никак, по той же причине, почему в Москве не
происходит землетрясений от 7 балов и выше.
А то, что чел пишет, это его вера в им же придуманные фиктивные цифры.
16.09.2010 19:47, mag745 пишет: > > Или как объяснить руководству ненужность этого, а лучше написать > толковые инструкции.
Никак, если руководство бессмысленности данного не понимает.
Для тебя же совет (повторю написанное уже другими в теме) найти какие
типичные должностные инструкции, нарисовать большие таблички и там пусть
проставляют все циферки, ты эти циферки объединяешь в одну (формула не
имеет значения, можешь и rand использовать).
После ждешь месяц-два, если бредовость данного мероприятия до начальства
не доходит меняешь работу.
Здравствуйте, starina_bz, Вы писали: _>Попробуйте изменить свой подход, увидеть лес за деревьями и всё-же стараться делать прибыль, а не работать работу в рамках проекта. Проработаете так полгода-год, сами удивитесь, насколько всё поменяется и поймёте. Что и успешность проекта и Ваше вознаграждение и продвижение совсем не на 95% ... зависит от менеджмента стратегического и оперативного. А может даже и на 100%, а в большей степени зависит от Вас самого.
Я считаю, что моя задача за деревьями — делать пользователей счастливыми от моего сервиса. До прибыли цепочка сильно дальше получается, по моему сейчасному проекту её подсчитать напрямую вообще невозможно.
