Да, хотел написать, что с моей точки зрения KPI проекта — это сигнал руководителю для перераспределения ресурсов между проектами, а не для наказания-поощрения исполнителей.
Здравствуйте, mag745, Вы писали:
M>Здравствуйте!
M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом. M>... M>Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией. M>Какие же параметры загнать в KPI? M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
Как-то доводилось работать с компанией, где подобные метрики внедрялись. Результат не из самых веселых.
Работа на "красивые циферки" оказалась приоритетнее работы на хороший качественный результат.
Да и есть классические примеры, как то же измерение производительности программистов в строчках кода. Вот то, о чем вы говорите может скатиться в подобную бредятину.
Здравствуйте, mag745, Вы писали:
M>Какие же параметры загнать в KPI?
самое адекватное что я видел: "Соответствие сроков реализации краткосрочных задач планам (составленных самим программистом) с поправкой на количество багов в реализации". Как от метрики, толку конечно не очень, зато учит народ правильно определять сроки, а не говорить: "щас покурю и за пол часа сделаю".
Здравствуйте, starina_bz, Вы писали:
_>Здравствуйте, Aptekar, Вы писали:
A>>Руководителям компании важно, сколько принес денег каждый проект, в конце концов именно они эти проекты открывают и закрывают. Это их цель — сделать прибыль. Мне — не важно, я с этих денег ничего не имею, пусть я и добросовестно выполняю свою работу в рамках проекта, что мне отведён (а кто каким проектом занимается, решаю не я).
_>Попробуйте изменить свой подход, увидеть лес за деревьями и всё-же стараться делать прибыль, а не работать работу в рамках проекта. Проработаете так полгода-год, сами удивитесь, насколько всё поменяется и поймёте. Что и успешность проекта и Ваше вознаграждение и продвижение совсем не на 95% ... зависит от менеджмента стратегического и оперативного. А может даже и на 100%, а в большей степени зависит от Вас самого.
Не надо простому программисту в конторе, где программист это ресурс пытаться увидеть лес, т.к.
— Не его зона материальной ответственности.
— Он всё равно ни на что не повлияет.
— Вознаграждение оговорено в ТД.
_>А потом уже сможете и менеджера себе выбирать граздо чаще, чем считаете.
В Ильин день, видимо.
17.09.2010 17:03, XuMuK пишет: > > самое адекватное что я видел: "Соответствие сроков реализации > краткосрочных задач планам (составленных самим программистом) с > поправкой на количество багов в реализации". Как от метрики, толку > конечно не очень, зато учит народ правильно определять сроки, а не > говорить: "щас покурю и за пол часа сделаю".
Это работает только в случае если программистам доверяют. Чего не
скажешь о многих манагерах, пишущих здесь.
Здравствуйте, _Dinosaur, Вы писали:
_D>Здравствуйте, sharpcoder, Вы писали:
S>>У нас в компании считаются KPI проектов. S>>Детали рассказывать не буду, но в основе лежат простые принципы: S>> — основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег) _D>Пример: _D>Компания планирует выполнить три проекта П1, П2 и П3 для одного нового заказчика. _D>Контракт на проект П1 подписан, а контракты на остальные проекты под вопросом. _D>Объем работ по проекту П1 существенно меньше чем по проекту П2. _D>Компания планирует проект П1 выполнить с убытком, проект П2 с максимальной прибылью, проект П3 со стабильным доходом. _D>Вопрос: _D>Начислит ли система премии сотрудникам за выполнение проекта П1?
P.M. проекта П1 будет иметь долю в бонусах с проектов П2 и П3, даже если в них он не P.M. Рядовые сотрудники с П1 не получат ничего.
Но у нас есть такая штука, как инвестиционные проекта. В таких случаях компания может увеличить стоимость проекта вложив в нее свои деньги (заранее запланированный и согласованный объем). Тоже самое и для проектов по разработке продуктов и выполнения внутренних проектов.
К примеру, нужно нам разработать ряд отчетов для нашей KPI системы. Мы определяем сколько компания может заплатить за это, и участники проекта при выполнении проекта с запланированными трудозатратами получат хороший бонус.
S>> — прозрачна и понятна каждому сотруднику (четко описана, расчет по каждому проекту доступен каждому) S>> — прозрачное формирование премиального фонда по проектам и участие каждого участника проекта в распределении такого фонда _D>это большой плюс
S>>Система очень крутая и после ее введения рентабельность компании выросла не менее чем на 20%. _D>Где-нибудь можно почитать про эту крутую систему?
Нет, мы сами ее придумали. Точнее позаимствовали основные идеи у одного нашего клиента, и доработали под свои нужды. Ее наличие считаем конкурентным преимуществом.
Здравствуйте, Aptekar, Вы писали:
A>Здравствуйте, sharpcoder, Вы писали: S>> — основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег) A>Руководителям компании важно, сколько принес денег каждый проект, в конце концов именно они эти проекты открывают и закрывают. Это их цель — сделать прибыль. Мне — не важно, я с этих денег ничего не имею, пусть я и добросовестно выполняю свою работу в рамках проекта, что мне отведён (а кто каким проектом занимается, решаю не я).
Здесь как в футболе. Либо команда выиграла и каждй футболист получит кучу денег. Либо проиграла и все футболисты не получат, в том числе и форвард, который забил 1 гол.
S>> — прозрачна и понятна каждому сотруднику (четко описана, расчет по каждому проекту доступен каждому) S>> — прозрачное формирование премиального фонда по проектам и участие каждого участника проекта в распределении такого фонда A>То есть получается, что в провальных проектах как бы все программисты работали в среднем плохо, а в успешных — как бы в среднем все хорошо? Насколько у меня есть опыт, на 95% провальность или успешность проекта зависит от менеджмента стратегического и оперативного. А может даже и на 100%. В конце концов менеджер может выбирать себе программистов, а программисты намного реже могут выбирать себе менеджера.
Успешность проекта зависит от всего. От правильной оценки его стоимости, профессионализма менеджмента, профессионализма исполнителей, профессионализма заказчика, даже от удачи/неудачи.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, starina_bz, Вы писали:
_>>Очёнь интересно, как это работает. Если Вас не затруднит, опишите.
B>Готов поспорить, что деталей мы не узнаем.
Здравствуйте, Vzhyk, Вы писали:
V>17.09.2010 13:02, starina_bz пишет: >> >> Очёнь интересно, как это работает. Если Вас не затруднит, опишите. V>Да не работает оное никак, по той же причине, почему в Москве не V>происходит землетрясений от 7 балов и выше. V>А то, что чел пишет, это его вера в им же придуманные фиктивные цифры.
Вам не кажется ваша позиция несколько ограниченной?
Здравствуйте, sharpcoder, Вы писали:
S>Успешность проекта зависит от всего. От правильной оценки его стоимости, профессионализма менеджмента, профессионализма исполнителей, профессионализма заказчика, даже от удачи/неудачи.
Все проще.
Прибыль компании считается легко и эти вещи естественно надо считать
и еще неплохо сообщать о них всем сотрудникам.
Вы, кстати, это делаете?
Это и будет объективная оценка стоимости, профессионализма менеджмента,
профессионализма исполнителей, профессионализма заказчика и тому подобное.
Квартальный отчет о делах коммпании весьма неплохой мотиватор.
Но KPI для программистов, которая учитывает прибыль компании, все равно будет профанацией
и инструментом для менеджмента, который не хочет работать с персоналом.
Переложить все на формулу — это ведь так просто
Здравствуйте, XuMuK, Вы писали:
M>>Какие же параметры загнать в KPI?
XMK>самое адекватное что я видел: "Соответствие сроков реализации краткосрочных задач планам (составленных самим программистом) с поправкой на количество багов в реализации". Как от метрики, толку конечно не очень, зато учит народ правильно определять сроки, а не говорить: "щас покурю и за пол часа сделаю".
Давайте попробуем оценить этот подход. Я работал в компании (месяц, больше не выдержал), где внедрили эту систему. Диалог имел место на моих глазах (меня попросили посмотреть со стороны).
Подходит менеджер к программеру с ТЗ (а его придется писать, смысл KPI вообще теряется, если цель четко не определена): скока?
Программер: 2 недели
Менеджер: офигел? Да я за 3 дня напишу
Программер: так у тебя и зарплата зело побольше, и опыт не сравнить с моим
Менеджер: хорошо, давай разбирать по пунктам
Дальше программер оценивает сроки с учетом всех рисков (вот чему программеры действительно хорошо обучаются при KPI — это выявлять риски!) и получается уже не 2 недели, а 2 с половиной.
Менеджер: млин, но риски же не все реализуются! Хорошо, если половина сработает. Давай введем коэффициент для вероятности наступления каждого риска.
Программер: Это как? Если завтра ты ко мне ко мне подрулишь с просьбой поправить старый баг, мне тебя на фиг посылать, или денег лишаться? И почему моя зарплата должна зависеть от того, на что я не могу влиять — например, придет будущий заказчик (О, еще один риск!) и в лучшем случае вы будете трендеть у меня над ухом пол-дня, а в худшем — я сам буду с ним пол-дня трендеть? А стихийные совещания по чужим задачам, где вы орете, как резаные? Я ведь программировать в таких условиях не могу, как мне это время скомпенсировать? А то, что я работаю по 10-12 часов вместо 8, как будем учитывать? Давай тогда еще на полтора умножим, если играем по-честному.
Менеджер: черт с тобой (таких программеров у него еще десяток, их тоже надо успеть окучить), хоть за две-то недели сделаешь?
Программер: ну ладно, мы с тобой долго работаем, постараюсь для тебя. Но все посторонние баги правим только после приемки этой задачи. И по этой задаче время на исправление багов оцениваем отдельно.
Менеджер: ладно, договорились
Дальше понятно. Задача делается за 2 недели, ни днем меньше. Программер же не враг себе, чтобы сдать через неделю — иначе на следующей, похожей, больше недели не получить. Еще один, не столь очевидный минус — программист учится обманывать, придумывает несуществующие работы и т.п. А следить за тем, чем каждый программер реально занимается — невыполнимо.
И вот по истечении двух недель мы имеем то, что могли бы иметь через неделю, а то и раньше. Это с учетом того, что за невыполнение KPI зарплату резали на 20%. Если бы поднимали на те же 20 — было бы тоже самое, это ясно, надеюсь. Итого — мы увеличиваем время и расходы вдвое на пустом месте, из-за стремления к оплате по справедливости.
Может, ну ее на фиг, эту справедливость? Пусть будут трудяги и раздолбаи, главное, чтобы их соотношение было удовлетворительным.
Р.S. Процентов 30 народа считало такой подход ниже своего достоинства, и ставили реальные сроки. А поскольку из них они иногда вылетали, им резали зарплату, что отнюдь не добавляло лояльности к компании. Вопрос: а что же мы тогда, собственно, стимулируем?
Здравствуйте, mag745, Вы писали:
M>Здравствуйте!
M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.
у вас конечная цель какая, оценить эффективность и уволить или поднять з.п. за счет премий?
дело в том, что производственный персонал не имеет отношения к марже, поэтому KPI здесь закладывать не получится. Можно заложить KPI к PM, рук. отделов, а для тех. персонала провести просто грейдирование по должностям, т.е. сделать сетку.
Если закладываете KPI здесь важно помнить о показателях эффективности, для каждой компании они разные. Кроме того, здесь много сопутствующих документов и волокиты:
1) Положение о премировании
2) Положение об оплате труда (система оплаты, повременно — премиальная, оклад, премиальная и т.д.)
3) служебные записки о текущих/единовременных премиях, выгрузка приказов на отдел/каждого сотрудника
Но на деле весь бюджет закладывают в начале года, а потом просто подгоняют под цифры.
Здравствуйте, mag745, Вы писали:
M>Руководство требует разработать и внедрить в отделе разработки ПО систему оценки результатов работы програмистов и отдела в целом.
M>Исходя из краткого определения KPI — это ключевой легко рассчитываемый параметр, который влияет на доходы компании. M>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.
M>И как вообще можно загнать работу программиста в рамки KPI? M>В литературе по KPI написано: M>Работу технических специалистов (бухгалтеров, инженеров, программистов) проще описывать должностной инструкцией. А подобрать для них справедливую «линейку» очень сложно.
Правильно рассуждаете. Имеет место быть выход за пределы предметной области.
KPI приносят эффективность только там, где:
1. Существует отлаженный, устоявшийся бизнес-процесс. В Макдональдсе, например. У продажников. У землекопов. У строителей.
2. (частичное следствие из 1) Цена замены работника невелика. Новичок начинает приносить прибыль через неделю-другую обучения.
3. Индивидуальные результаты поддаются четкой оценке (план по продажам выполнен, канава прорыта на 200м)
Ни один из перечисленных параметров не относится к труду программиста. И к проектной активности вообще. KPI создан по заказу и для функциональных организаций.
Тем не менее, можно рассматривать программерскую контору как функциональную "фабрику проектов" и привязывать KPI к результатам(!) проектов, а не к людям. Тогда сразу становится легче и понятнее цели и параметры KPI. Собственно, так и делают в зрелых организациях. А внутри проекта бонусы распределяет менеджер, который знает, как работали его люди.
M>Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией.
Уже поделились ниже. Обновляйте резюме, и чем скорее, тем лучше. Лучше уйти сейчас, сохранив хорошие воспоминания о своем руководстве
M>Какие же параметры загнать в KPI? M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
Никак. Руководство сходило на тренинг, а там промывают мозги качественно, за плечами у лекторов долгий опыт. Вы с ними не сможете тягаться, увы.
И вины лекторов тут никакой нет. Они не пишут в анонсах тренинга, что полученные знания применимы только в функциональной организации, поскольку с проектным управлением им сталкиваться попросту не приходилось. Да и если даже имели дело — зачем им уменьшать размер аудитории?
Здравствуйте, Vzhyk, Вы писали:
>> Очёнь интересно, как это работает. Если Вас не затруднит, опишите. V>Да не работает оное никак, по той же причине, почему в Москве не V>происходит землетрясений от 7 балов и выше. V>А то, что чел пишет, это его вера в им же придуманные фиктивные цифры.
Мне кажется, в этой ветке стоит сменить тему на "KPI для проектов".
Топикстартер говорил про KPI для программистов (или отдела, что немного меньший маразм)
sharpcoder же говорит про KPI для проектов, а это совсем другая штука. Принципиально другая. Проект может быть оценен по формальным параметрам, программист — нет.
А по инерции многие, увидев три веселых буквы "KPI", бросаются на них, как бык, на красную тряпку, не видя ничего остального Потому что тема в заголовке — первоначальная, "KPI для программистов".
Лично я не вижу ничего плохого в премии всей проектной команде по окончании успешного проекта. Более того, я целиком и полностью "за"
Здравствуйте, nvb, Вы писали:
nvb>Давайте попробуем оценить этот подход. Я работал в компании (месяц, больше не выдержал), где внедрили эту систему. Диалог имел место на моих глазах (меня попросили посмотреть со стороны).
[cut]
nvb>Может, ну ее на фиг, эту справедливость? Пусть будут трудяги и раздолбаи, главное, чтобы их соотношение было удовлетворительным.
Я полагаю после такого развёрнутого ответа тему можно сворачивать.
nvb>Р.S. Процентов 30 народа считало такой подход ниже своего достоинства, и ставили реальные сроки. А поскольку из них они иногда вылетали, им резали зарплату, что отнюдь не добавляло лояльности к компании. Вопрос: а что же мы тогда, собственно, стимулируем?
Текучку
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, sharpcoder, Вы писали:
S>P.M. проекта П1 будет иметь долю в бонусах с проектов П2 и П3, даже если в них он не P.M. Рядовые сотрудники с П1 не получат ничего.
Это минус.
Результаты выполнения проекта П1 могут повлиять на принятие решения по заключению контракта на проекты П2 и П3.
На мой взгляд, бонусы должны быть предусмотрены и для рядовых сотрудников.
S>Но у нас есть такая штука, как инвестиционные проекта. В таких случаях компания может увеличить стоимость проекта вложив в нее свои деньги (заранее запланированный и согласованный объем). Тоже самое и для проектов по разработке продуктов и выполнения внутренних проектов. S>К примеру, нужно нам разработать ряд отчетов для нашей KPI системы. Мы определяем сколько компания может заплатить за это, и участники проекта при выполнении проекта с запланированными трудозатратами получат хороший бонус.
Решается ли при этом проблема недооценки/переоценки стоимости работ?
Реализован ли какой-нибудь механизм защиты от злоупотреблений?
Завидую людям, которые могут себе позволить никуда не спешить.
Здравствуйте, nvb, Вы писали: nvb>Топикстартер говорил про KPI для программистов (или отдела, что немного меньший маразм)
Именно для программистов, а не проектов. Проект легко (ну не легко, но можно) оценить по формальным параметрам: срок выполнения, деньги, чаще всего это описано уже в договоре, какие бонусы за сокращение сроков и какие санкции за срыв сроков. KPI считать можно. В моем же случае нужно посчитать KPI для каждого отдлельного программиста, при том что работа не проектная (сделал и забыл), не разработка многоверсионного продукта, а поддержка существующей системы, ее развитие и доработка по желанию заказчика, функциональность добавляется не версиями, а сделалти — тут же внедрили. Поэтому оценивать требуют труд каждого отднльного программиста, насколько он хорош.
nvb>sharpcoder же говорит про KPI для проектов, а это совсем другая штука. Принципиально другая. Проект может быть оценен по формальным параметрам, программист — нет.
Тут я согласен. Но выбор — либо разработать систему KPI либо постепенно искать другую работу. С другой стороны уже стало интересно, а можно ли все же как-то оценить работу. Потому что сейчас можно оценить просто, человек справляется с задачами или нет, делает их в приемлемый срок или нет (притом что в техподдержке сроки бывают только: "нужно было еще вчера сделать").
Здравствуйте, Vzhyk, Вы писали:
V>16.09.2010 19:47, mag745 пишет: >> >> Или как объяснить руководству ненужность этого, а лучше написать >> толковые инструкции. V>Никак, если руководство бессмысленности данного не понимает. V>Для тебя же совет (повторю написанное уже другими в теме) найти какие V>типичные должностные инструкции, нарисовать большие таблички и там пусть V>проставляют все циферки, ты эти циферки объединяешь в одну (формула не V>имеет значения, можешь и rand использовать). V>После ждешь месяц-два, если бредовость данного мероприятия до начальства V>не доходит меняешь работу.
Хороший совет. Я нашел сайт с KPI для разработки http://www.smartkpis.com/kpi/functional-areas/information-technology/application-development/
Более 60 KPI для разрабтчиков. Ничего подходящего там. Они хорошо показывают статистику, но реально оценить хорошую/плохую работу не дают возможности.
Например, считаем кто сколько багов сделал: тот кто писал много нового кода закономерно имеет больше всех багов, а кто вылизывал старый код — естественно минимум багов.
Единственный параметр который мне нравится — это количество повторных багов, т.е. появляется ли баг еще раз после его исправления. Т.е. чинил одно — сломал другое, да еще то, что уже было починено. Но опять же это очень спорный вопрос, если сложность проекта зашкаливает и заказчик сам постоянно мечется незная, что лучше для него.
Здравствуйте, Vzhyk, Вы писали:
V>17.09.2010 17:03, XuMuK пишет: >> >> самое адекватное что я видел: "Соответствие сроков реализации >> краткосрочных задач планам (составленных самим программистом) с >> поправкой на количество багов в реализации". Как от метрики, толку >> конечно не очень, зато учит народ правильно определять сроки, а не >> говорить: "щас покурю и за пол часа сделаю". V>Это работает только в случае если программистам доверяют. Чего не V>скажешь о многих манагерах, пишущих здесь.
Сам набирал людей. Чаше всего они занижат сроки. Я их увеличиваю, т.к. сам 10 лет был программером и знаю, что сколько займет реально время.
Это у нас и так сделано: каждый программист говорит, сколько времени займет задача. Чаще всего если задача не завершается в срок, то это из-за того, что заказчик долго или совсем не отвечает на вопросы как именно он хотел бы чтобы было, или без первоначального дизайна начинает предлагать как улучшить дизайн, когда мы его уже сами сделали.
Просто этот разумный подход оформить в виде KPI не представляется возможным. Т.е. на самом деле программист успел в срок, но формально заказчик еще неудосужился принять. Закачик — это подразделения нашей же компании, с ними договор об обязательствах не напишешь.
Там вполне нормальные метрики, которые можно использовать для оценки процессов в целом.
Далеко не все из них, кстати, есть смысл применять именно как KPI.
Многие из них являются обычными метриками качества (например "Software errors to application run time ratio").
Еще большей ошибкой было бы применять их для оценки отдельных программистов.
То же "количество повторных багов" хорошая метрика, но если сделать на ее основе формулу,
которая будет определять твою личную зарплату, то ничего хорошего не будет.
Ну а если "количество повторных багов" вдруг начинает зашкаливать некую "норму",
то это повод начать разбирательство почему так происходит.
Это может быть деградирующая архитектура.
Это может быть новички, которых кинули на амбразуры.
Причин может быть куча, и надо разбираться с ними, а не раздавать пряники/кнуты на основе цифири.
