Re[5]: KPI для программистов - О работе

Здравствуйте, 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> — основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег)

и сколько денег вам приносит техподдержка внутренних продуктов???

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

M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.

Мне нравится как это объясняет Дорофеев: http://cartmendum.livejournal.com/60982.html

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

M>>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.

AAV>Мне нравится как это объясняет Дорофеев: http://cartmendum.livejournal.com/60982.html

Незавершённая статья.
Разовью идею с шариками. Может так случиться, что у одного из ведра достают 100 шариков, а у другого 200, т.к. его ведро тестирует более ответственный тестер.

Плюс в вёдрах у всех разное количество шариков. У кого-то может быть 50 шариков и 1 красный. А у кого-то 500 и 50 красных. Вопрос какой уровень багов приемлем для компании.

И наконец обычно 100 шариков вытаскивается не из моего ведра, а из общего. Соответственно, чем больший вклад я сделаю, тем больше багов найдут. Если кто-то возможно вообще не добавит в общее ведро никаких шариков, то багов у него не будет, ему что теперь премию давать?

S> — участие каждого участника проекта в распределении такого фонда

Вот с этого места бы поподробнее. Потому что и есть КПИ, а всё остальное просто инфраструктура вокруг это КПИ.

Здравствуйте, sharpcoder, Вы писали:
S> — основана только на экономических результатах проектов, отделов, направлений (т.е. считает не важно что ты делал, важно — сколько ты принес денег)
Руководителям компании важно, сколько принес денег каждый проект, в конце концов именно они эти проекты открывают и закрывают. Это их цель — сделать прибыль. Мне — не важно, я с этих денег ничего не имею, пусть я и добросовестно выполняю свою работу в рамках проекта, что мне отведён (а кто каким проектом занимается, решаю не я).
S> — прозрачна и понятна каждому сотруднику (четко описана, расчет по каждому проекту доступен каждому)
S> — прозрачное формирование премиального фонда по проектам и участие каждого участника проекта в распределении такого фонда
То есть получается, что в провальных проектах как бы все программисты работали в среднем плохо, а в успешных — как бы в среднем все хорошо? Насколько у меня есть опыт, на 95% провальность или успешность проекта зависит от менеджмента стратегического и оперативного. А может даже и на 100%. В конце концов менеджер может выбирать себе программистов, а программисты намного реже могут выбирать себе менеджера.

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

A>Руководителям компании важно, сколько принес денег каждый проект, в конце концов именно они эти проекты открывают и закрывают. Это их цель — сделать прибыль. Мне — не важно, я с этих денег ничего не имею, пусть я и добросовестно выполняю свою работу в рамках проекта, что мне отведён (а кто каким проектом занимается, решаю не я).

Попробуйте изменить свой подход, увидеть лес за деревьями и всё-же стараться делать прибыль, а не работать работу в рамках проекта. Проработаете так полгода-год, сами удивитесь, насколько всё поменяется и поймёте. Что и успешность проекта и Ваше вознаграждение и продвижение совсем не на 95% ... зависит от менеджмента стратегического и оперативного. А может даже и на 100%, а в большей степени зависит от Вас самого.

А потом уже сможете и менеджера себе выбирать граздо чаще, чем считаете.

A> В конце концов менеджер может выбирать себе программистов, а программисты намного реже могут выбирать себе менеджера.

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

_>Очёнь интересно, как это работает. Если Вас не затруднит, опишите.

Готов поспорить, что деталей мы не узнаем.

17.09.2010 13:02, starina_bz пишет:
>
> Очёнь интересно, как это работает. Если Вас не затруднит, опишите.
Да не работает оное никак, по той же причине, почему в Москве не
происходит землетрясений от 7 балов и выше.
А то, что чел пишет, это его вера в им же придуманные фиктивные цифры.

Posted via RSDN NNTP Server 2.1 beta

16.09.2010 19:47, mag745 пишет:
>
> Или как объяснить руководству ненужность этого, а лучше написать
> толковые инструкции.
Никак, если руководство бессмысленности данного не понимает.
Для тебя же совет (повторю написанное уже другими в теме) найти какие
типичные должностные инструкции, нарисовать большие таблички и там пусть
проставляют все циферки, ты эти циферки объединяешь в одну (формула не
имеет значения, можешь и rand использовать).
После ждешь месяц-два, если бредовость данного мероприятия до начальства
не доходит меняешь работу.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, starina_bz, Вы писали:
_>Попробуйте изменить свой подход, увидеть лес за деревьями и всё-же стараться делать прибыль, а не работать работу в рамках проекта. Проработаете так полгода-год, сами удивитесь, насколько всё поменяется и поймёте. Что и успешность проекта и Ваше вознаграждение и продвижение совсем не на 95% ... зависит от менеджмента стратегического и оперативного. А может даже и на 100%, а в большей степени зависит от Вас самого.
Я считаю, что моя задача за деревьями — делать пользователей счастливыми от моего сервиса. До прибыли цепочка сильно дальше получается, по моему сейчасному проекту её подсчитать напрямую вообще невозможно.

Да, хотел написать, что с моей точки зрения 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 пишет:
>
> самое адекватное что я видел: "Соответствие сроков реализации
> краткосрочных задач планам (составленных самим программистом) с
> поправкой на количество багов в реализации". Как от метрики, толку
> конечно не очень, зато учит народ правильно определять сроки, а не
> говорить: "щас покурю и за пол часа сделаю".
Это работает только в случае если программистам доверяют. Чего не
скажешь о многих манагерах, пишущих здесь.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, _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>>

Здравствуйте, 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 не представляется возможным. Т.е. на самом деле программист успел в срок, но формально заказчик еще неудосужился принять. Закачик — это подразделения нашей же компании, с ними договор об обязательствах не напишешь.

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

M>Я нашел сайт с KPI для разработки http://www.smartkpis.com/kpi/functional-areas/information-technology/application-development/

Там вполне нормальные метрики, которые можно использовать для оценки процессов в целом.
Далеко не все из них, кстати, есть смысл применять именно как KPI.
Многие из них являются обычными метриками качества (например "Software errors to application run time ratio").
Еще большей ошибкой было бы применять их для оценки отдельных программистов.
То же "количество повторных багов" хорошая метрика, но если сделать на ее основе формулу,
которая будет определять твою личную зарплату, то ничего хорошего не будет.

Ну а если "количество повторных багов" вдруг начинает зашкаливать некую "норму",
то это повод начать разбирательство почему так происходит.
Это может быть деградирующая архитектура.
Это может быть новички, которых кинули на амбразуры.
Причин может быть куча, и надо разбираться с ними, а не раздавать пряники/кнуты на основе цифири.

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

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

>>> Очёнь интересно, как это работает. Если Вас не затруднит, опишите.
V>>Да не работает оное никак, по той же причине, почему в Москве не
V>>происходит землетрясений от 7 балов и выше.
V>>А то, что чел пишет, это его вера в им же придуманные фиктивные цифры.

nvb>Мне кажется, в этой ветке стоит сменить тему на "KPI для проектов".

nvb>Топикстартер говорил про KPI для программистов (или отдела, что немного меньший маразм)

nvb>sharpcoder же говорит про KPI для проектов, а это совсем другая штука. Принципиально другая. Проект может быть оценен по формальным параметрам, программист — нет.

nvb>А по инерции многие, увидев три веселых буквы

"KPI", бросаются на них, как бык, на красную тряпку, не видя ничего остального

Потому что тема в заголовке — первоначальная, "KPI для программистов".

nvb>Лично я не вижу ничего плохого в премии всей проектной команде по окончании успешного проекта. Более того, я целиком и полностью "за"

Согласен, я начал говорить несколько о другом. До "KPI программистов" мы еще не доросли.
В ближайших наших планах внедрение KPI по направлению (совокупная рентабельность всего направления), с привязкой бонусов к руководителю департамента. KPI для менеджеров проектов (совокупная рентабельность их проектов).

Оценивать труд конкретного сотрудника не хотим. Т.к. вся команда должна разделять успех либо неудачу проекта.

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

P>у вас конечная цель какая, оценить эффективность и уволить или поднять з.п. за счет премий?
Вот как цель сфомулирована моим руководителем: Нам надо прежде всего научиться считать свои ресурсы и прозрачно это обосновывать руководству, иначе мы загнёмся под кучей бредовых задач.
Только я не понимаю причем здесь KPI. На лицо какое-то недопонимание.

P>дело в том, что производственный персонал не имеет отношения к марже, поэтому KPI здесь закладывать не получится. Можно заложить KPI к PM, рук. отделов, а для тех. персонала провести просто грейдирование по должностям, т.е. сделать сетку.
Согласен с этим.

P>Если закладываете KPI здесь важно помнить о показателях эффективности, для каждой компании они разные. Кроме того, здесь много сопутствующих документов и волокиты:
P>1) Положение о премировании
P>2) Положение об оплате труда (система оплаты, повременно — премиальная, оклад, премиальная и т.д.)
P>3) служебные записки о текущих/единовременных премиях, выгрузка приказов на отдел/каждого сотрудника
Это у нас есть. Есть коллективный договор. Как я понимаю цель KPI не только вышенаписанное, но и перевод с премирования по целям (сейчас каждому сотруднику ставятся цели на квартал) перейти на премирование по KPI.

P>Но на деле весь бюджет закладывают в начале года, а потом просто подгоняют под цифры.
Здесь не так.

Если тобой довольны — премия будет.

Не довольны — премии не будет.

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

Полностью согласен с Вами nvb. Спасибо за толковое разъяснение ситуации. Именно так и есть. Добавить здесь нечего.

Последую вашему совету.

Здравствуйте, 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>которая будет определять твою личную зарплату, то ничего хорошего не будет.
Полностью согласен. Это хорошие параметры для оценки работы команды. Но как показатель конкретного человека — не приемлемо. И именно как KPI.

B>Ну а если "количество повторных багов" вдруг начинает зашкаливать некую "норму",
B>то это повод начать разбирательство почему так происходит.
B>Это может быть деградирующая архитектура.
B>Это может быть новички, которых кинули на амбразуры.
B>Причин может быть куча, и надо разбираться с ними, а не раздавать пряники/кнуты на основе цифири.
С этим также согласен. Это не KPI, а просто удобный показатель, чтобы увидеть, что есть проблема, и приступить к ее поиску и принятия мер по ее решению.

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

V>>Это работает только в случае если программистам доверяют. Чего не
V>>скажешь о многих манагерах, пишущих здесь.

M>Сам набирал людей. Чаше всего они занижат сроки. Я их увеличиваю, т.к. сам 10 лет был программером и знаю, что сколько займет реально время.
M>Это у нас и так сделано: каждый программист говорит, сколько времени займет задача. Чаще всего если задача не завершается в срок, то это из-за того, что заказчик долго или совсем не отвечает на вопросы как именно он хотел бы чтобы было, или без первоначального дизайна начинает предлагать как улучшить дизайн, когда мы его уже сами сделали.
M>Просто этот разумный подход оформить в виде KPI не представляется возможным. Т.е. на самом деле программист успел в срок, но формально заказчик еще неудосужился принять. Закачик — это подразделения нашей же компании, с ними договор об обязательствах не напишешь.

Ну почему не подпишешь? Легко!
В той же компании:
Прогер получает вместе с ТЗ сопроводительный лист с указанными сроками, расписывается за получение задания и ставит дату. После завершения работы прогер идет к манагеру. Манагер всегда занят, поэтому ставит на листе роспись и дату сдачи, т.е. принятия к рассмотрению. Потом, когда придет время (иными словами, когда отложить рассмотрение уже совсем нельзя), манагер рассматривает работу и пишет замечания на том же сопроводительном листе, с датой. Прогер расписывается в получении замечаний, ставит дату и идет исправлять. Ну и так далее по кругу. Потом на одном листе это все не умещается, подшивается второй, третий...
Это я еще не все описал, на сопроводительном листе, кажется, 6 типов подписей для разных событий было, но назначение остальных я уже забыл. По сопоставлении дат и считался KPI. Ставился коэффициент сложности задачи, чтобы можно было усреднить за расчетный период.
Само собой, сопроводительные листы терялись, думаю, что иногда не случайно

Не спрашивайте меня, почему не использовался обычный трекер запросов — я этого тоже не мог понять. Привыкли, наверное...

Ноу-хау здесь никакого нет, мне ребята рассказывали, что подобная система с подписями работает в Боинге, но там эти листы сразу же сканируются и кладутся в электронную базу данных. Цель этого сбора данных в Боинге — фиксация персональной ответственности, а не расчет KPI. Там с ответственностью очень серьезно обстоят дела, все-таки не столовые ложки выпускают.

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

M>Это у нас есть. Есть коллективный договор. Как я понимаю цель KPI не только вышенаписанное, но и перевод с премирования по целям (сейчас каждому сотруднику ставятся цели на квартал) перейти на премирование по KPI.

Вам просто мозг пудрят чтобы найти крайнего если проект не окупит себя. При коллективном договоре KPI не закладываются, там % премирования определяется КТУ. С коллективных договоров не так просто соскочить, это менять форму оплаты труда. А это уже налоговая.

Введите грейдирование для технарей, это позволит перераспределить премиальный бюджет. А KPI привяжите к производственным планам, это для рук. и PM.

18.09.2010 11:08, mag745 пишет:
>
> Единственный параметр который мне нравится — это количество повторных
> багов, т.е. появляется ли баг еще раз после его исправления. Т.е. чинил
> одно — сломал другое, да еще то, что уже было починено.
А если то, что чинить приходится напоминает небоскреб построенный на
основе собачьей будки?
Т.е. код настолько ужасен, что починка в одном месте ломает в другом?

Posted via RSDN NNTP Server 2.1 beta

19.09.2010 16:40, mag745 пишет:
>
> Полностью согласен. Это хорошие параметры для оценки работы команды. Но
> как показатель конкретного человека — не приемлемо. И именно как KPI.
В чем разница здесь? Команда или человек. Я понимаю, если эта команда
или человек работает абсолютно независимо от других и не использует
никаких сторонних инструментов (такая сферическая команда в вакууме).

>
> С этим также согласен. Это не KPI, а просто удобный показатель, чтобы
> увидеть, что есть проблема, и приступить к ее поиску и принятия мер по
> ее решению.
Это разумно.

Posted via RSDN NNTP Server 2.1 beta

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

M>Вот как цель сфомулирована моим руководителем: Нам надо прежде всего научиться считать свои ресурсы и прозрачно это обосновывать руководству, иначе мы загнёмся под кучей бредовых задач.
M>Только я не понимаю причем здесь KPI. На лицо какое-то недопонимание.

Видимо ваше руководство не понимает зачем ему ИТ отдел и что же он так много денег просит... Это нормально для руководства.
Вы на кого вообще работаете? На внутренние подразделения или на стороннего заказчика?
Если на поддержку подразделений для начала просто предоставьте отчет сколько человекочасов занимает поддержка каждой системы/подразделения чтобы руководство понимало на что идут деньги. Может от чего то надо отказаться/передать на аутсорс.

KPI сотрудника есстно бред полный. Максимум попроектно или на подразделение как Вам уже до этого написали

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

F>Видимо ваше руководство не понимает зачем ему ИТ отдел и что же он так много денег просит... Это нормально для руководства.
F>Вы на кого вообще работаете? На внутренние подразделения или на стороннего заказчика?
F>Если на поддержку подразделений для начала просто предоставьте отчет сколько человекочасов занимает поддержка каждой системы/подразделения чтобы руководство понимало на что идут деньги. Может от чего то надо отказаться/передать на аутсорс.

Для этого надо трекер запросов ставить и обучать людей культуре работы с ним. А эта задача одномоментно не решается, в лучшем случае это месяц займет + затраты (рабочего времени) на обучение.
Под словом "людей" я подразумеваю не саму поддержку — они-то с радостью — а тех, кто выдает задание, заказчиков. Самые большие проблемы кроются именно в этом пункте. Я помню, как меня самого возмущало, когда наш IT-отдел отказался принимать мои заявки по телефону

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

21.09.2010 13:02, genre пишет:
>
> Проблема в этом подходе именно в этом. Штрафовать вообще нельзя.
>
> Вот если из этой методики убрать штрафы
Это правильно.

> и придумать как не дать
> программисту завысить сроки, то эта схема будет работать намного лучше.
Это возможно только высокой квалификацией менеджера.

Posted via RSDN NNTP Server 2.1 beta

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

>> Вот если из этой методики убрать штрафы
V>Это правильно.

>> и придумать как не дать
>> программисту завысить сроки, то эта схема будет работать намного лучше.
V>Это возможно только высокой квалификацией менеджера.

У меня стойкое ощущение, что я разговариваю с человеком абсолютно уверенным в том, что все программисты святые, а менеджеры идиоты. А если и не идиоты, то в живой природе почти не встречаются.
Если это так, то конструктивный диалог у нас вряд ли получится — в моём реальном мире всё совсем не так. И программисты не святые, за идею не работают, и менеждеры вменяемые бывает встречаются.

А чтобы не дать программисту завысить сроки существует куча разных методик. Начиная от разбиения задач на куски длиной в один день. До анализа статистики.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

А почему вы принимаете, что "легко рассчитываемый"?

Ни разу. Методика расчёта может быть весьма и весьма тяжёлой, учитывающей десятки/сотни/тысячи показателей, каждый из который необходимо или нормировать, или помножить на нетривиальным образом подобранный/высчитанный весовой коэффициент.

Если KPI у вас считается "легко", то это должно вызывать определённые подозрения

M>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.
M>И как вообще можно загнать работу программиста в рамки KPI?

Надо не так: требуется [для начала] вокруг работы програмиста выстроить измерения тех или иных показателей.

"Загонять" же "работу" очень сложно :о) потому что тогда люди начитают трудиться не на результат работы, а на показатель. Если вы с "рамками" ошибётесь, то это то, что вам и нужно, а вот если промахнётесь, то результат может оказаться плачевным.

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

Сложно. Но [с некоторой долей приближения] выполнимо.

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

ИМХО, это подсчитать возможно.

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

И это тоже.

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

Тут я не понимаю, что означает "экспертиза". Квалификация? Умение? Тогда и с этим не будет сложности.

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

Реально-реально. Это же какая отличная инженерная задача — измерить неизмеримое

Главное же вот что: скорее всего результат измерения окажется не совсем тем или даже совсем не тем, на что вы рассчитывали. Но эта погрешность напрямую зависит от того, на сколько точно вы можете сформулировать определение "эффективность работы програмиста"

Поэтому нужно не бояться а делать, считать, считать, …

M>Какие же параметры загнать в KPI?

Пляшите от ответа на вопрос, что для вас есть "эффективность работы програмиста", чем по-вашему её стоит измерять?

M>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.

ИМХО, это крайне важно. Но настолько глупо в большом количестве случаев получается, что может быть и действительно отказаться от этогобудет лучшим для всех

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

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

BZ>пусть начнут с kpi секретаря менеджера уборщиц, моющих пол в отделе техподдержки внутренних продуктов компании :)))

Это как раз легко, у секретаря это количество принятых и потерянных звонков, а так же выполненных поручений. У уборщиц чистый пол. У руководителя уборщиц это как ни странно тоже чистый пол, и расходы на квадратный метр чистого пола.

У программистов все сильно сложнее :)

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

nvb>И вот по истечении двух недель мы имеем то, что могли бы иметь через неделю, а то и раньше. Это с учетом того, что за невыполнение KPI зарплату резали на 20%. Если бы поднимали на те же 20 — было бы тоже самое, это ясно, надеюсь. Итого — мы увеличиваем время и расходы вдвое на пустом месте, из-за стремления к оплате по справедливости.

nvb>Может, ну ее на фиг, эту справедливость? Пусть будут трудяги и раздолбаи, главное, чтобы их соотношение было удовлетворительным.

Сказано, конечно, всё правильно. Только вот не учитывается тут мнение менеджмента. Менеджменту гораздо важнее иметь предсказуемость прогнозов/результатов. Гораздо важнее скорости выполнения большинства задач. И вот именно ради предсказуемости вся эта кухня и затеяна.

Гораздо важнее, что бы десять задач былди вополнены, как и предполагалось, за две недели, чем девять из них за неделю, а одна за три. По известному закону отрицательный "профит" от эотй одной задачи может с головой перекрыть выигрыш от девяти предыдущих.

nvb>Р.S. Процентов 30 народа считало такой подход ниже своего достоинства, и ставили реальные сроки. А поскольку из них они иногда вылетали, им резали зарплату, что отнюдь не добавляло лояльности к компании. Вопрос: а что же мы тогда, собственно, стимулируем?

Это "менеджмент по-русски"

с "резали зарплату". Конечно, идиотским способом реализации можно любую идею довести до абсурда.

21.09.2010 14:11, genre пишет:
>
> V>Это возможно только высокой квалификацией менеджера.
>
> У меня стойкое ощущение, что я разговариваю с человеком абсолютно
> уверенным в том, что все программисты святые, а менеджеры идиоты. А если
> и не идиоты, то в живой природе почти не встречаются.
Вот ты опять видишь только то, что хочешь видеть. Я видел великолепных
менеджеров и работал у них. Но видел и массу именно "эффективных русских
менеджеров" (не русских тоже, но меньше) от которых конторы через
некоторое время умирали.

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

>
> А чтобы не дать программисту завысить сроки существует куча разных
> методик. Начиная от разбиения задач на куски длиной в один день. До
> анализа статистики.
И как? Работает?

))))))
Подобная методика гарантирует завышение сроков раза в 2-3.

Posted via RSDN NNTP Server 2.1 beta

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

V>Вот ты опять видишь только то, что хочешь видеть. Я видел великолепных
V>менеджеров и работал у них. Но видел и массу именно "эффективных русских
V>менеджеров" (не русских тоже, но меньше) от которых конторы через
V>некоторое время умирали.

Именно поэтому во всех твоих сообщениях сквозит презрение к менеджменту во всех его проявлениях?

И главное я не вижу никакого конструктива — где хоть слово о том, как надо делать, а не о том что все козлы?
Не мешайте программерам работать, это не конструктив. Так работа не делается. Это очевидно любому, кто хоть раз был вынужден отвечать на вопросы о сроках и качестве.

V>Они работают за деньги, но если им не мешать подавляющее большинство
V>хочет сделать хорошо и отлично.

Подавляющее большинство хочет сделать быстро, получить зарплату и пойти домой к семье/хобби/телевизору/итд
И это нормально.

V>И как? Работает?

))))))
V>Подобная методика гарантирует завышение сроков раза в 2-3.
Да, работает.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

nvb>Может, ну ее на фиг, эту справедливость? Пусть будут трудяги и раздолбаи, главное, чтобы их соотношение было удовлетворительным.

Мое имхо, необходимость в адекватной оценке эффективности рядовых программеров назрела еще вчера.
При принятой системе мотивации, куда по вашему все будет скатываться? Раздолбаи будут становиться работягами, или наоборот, работяги, видя несправедливость, будут разочаровываться и превращаться в раздолбаев, направляя собственное трудолюбие на что-нибудь более полезное?

Конечно в единую формулу, как у конвеерных рабочих все не запихнуть, но можно попробовать более рыночные механизмы.
Интересно, пробовал ли кто-нибудь такой вариант:
Рассматривать каждого сотрудника, как фирму-субподрядчик.
Кто в первую очередь потребитель программерского труда? ПМ.
Вот пусть он и распределяет премии вместе с задачами среди своих непосредственных подчиненных.
Бюджет этих премий берется из общей премии на проект, из которой он также должен получать приличный кусок,
чтобы быть заинтересованным в первую очередь в успешности проекта, а не в откатах или спонсировании любимчиков.

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

_FR>Сказано, конечно, всё правильно. Только вот не учитывается тут мнение менеджмента. Менеджменту гораздо важнее иметь предсказуемость прогнозов/результатов. Гораздо важнее скорости выполнения большинства задач. И вот именно ради предсказуемости вся эта кухня и затеяна.

Предсказуемость несомненно важна. К сожалению не все менеджеры это понимают

Но общие затраты/трудоемкость/стоимость увы чаще еще важнее.
А иначе не было бы попыток "впихнуть невпихаемое" со стороны того же менеджмента.

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

B>Но общие затраты/трудоемкость/стоимость увы чаще еще важнее.
B>А иначе не было бы попыток "впихнуть невпихаемое" со стороны того же менеджмента.

Важность их пропорциональна тому, на сколько увеличиваются "затраты/трудоемкость/стоимость".

В рассматриваемом примере две недели супротив одной или даже трёх дней — ерунда. Когда же вместо шести месяцев требуется "предсказуемые" два года — действительно, такая "предсказуемость" мало интересна.

Ценность же введения метрик в том, что они отучают от

завтра ты ко мне ко мне подрулишь с просьбой поправить старый баг

вы будете трендеть у меня над ухом пол-дня

стихийные совещания по чужим задачам

я работаю по 10-12 часов вместо 8

И когда это "отучание" пройдёт, когда работа, из-за оглмдки и учёта "в уме" KPI выйден на качественно новый уровень, "затраты/трудоемкость/стоимость" уменьшатся (при условии, что всё будет сделано по науке, а не по тому "как хочу").

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

_FR>В рассматриваемом примере две недели супротив одной или даже трёх дней — ерунда. Когда же вместо шести месяцев требуется "предсказуемые" два года — действительно, такая "предсказуемость" мало интересна.

А почему вы считаете этот пример единственным? Снижается общая толерантность к риску у программистов и они завышают сроки. Человек получает премию за то, что сделал в срок, а не за то, что сделал быстро(проектная премия). Есть разница.

_FR>Ценность же введения метрик в том, что они отучают от
_FR>

завтра ты ко мне ко мне подрулишь с просьбой поправить старый баг

_FR>

вы будете трендеть у меня над ухом пол-дня

_FR>

стихийные совещания по чужим задачам

_FR>

я работаю по 10-12 часов вместо 8

_FR>И когда это "отучание" пройдёт, когда работа, из-за оглмдки и учёта "в уме" KPI выйден на качественно новый уровень, "затраты/трудоемкость/стоимость" уменьшатся (при условии, что всё будет сделано по науке, а не по тому "как хочу").

Похоже, вы заметили перенос программистом контекста

Программмист не хочет вводить вероятность и придумывает новые риски.
Ладно, похвалил, хватит

Какой такой "качественно новый уровень"? Да, KPI для программистов есть по определению, он — в голове у менеджера проекта. Попытки сделать его формализуемым обычно ведут к ухудшению процесса разработки. Слишком много параметров, об этом уже не раз говорили.

Причина здесь вот в чем. Как только мы формализуем KPI и сделаем его всеобщим достоянием, программисты тут же начнут искать локальные оптимумы. И они обязательно их найдут. Сделаете большой приз за отсутствие багов и маленький — за сроки — будут немилосердно завышаться сроки. Сделаете большой приз за сроки и большой за баги — все останется, как было до введения KPI, поскольку простое увеличение зарплаты программисту (а это именно оно) приведет лишь к меньшей текучке, и не более того. Чудес не бывает.

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

D>Конечно в единую формулу, как у конвеерных рабочих все не запихнуть, но можно попробовать более рыночные механизмы.

Можно конечно, но в итоге получите вы не программистов, а "бизнесменов" в миниатюре,
которые будут больше думать о "прибыле" чем о деле.
Зарплата и условия ее получения должны быть такими,
чтобы не отвлекать программиста от его основной деятельности
и чтобы он не смотрел на сторону.

Еще можно заделаться акционерным обществом и тогда
у работников появится возможность получать свой кусочек пирога

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

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

D>>Конечно в единую формулу, как у конвеерных рабочих все не запихнуть, но можно попробовать более рыночные механизмы.

B>Можно конечно, но в итоге получите вы не программистов, а "бизнесменов" в миниатюре,
B>которые будут больше думать о "прибыле" чем о деле.

Вот как раз бизнесмены больше всего и думают о деле, а не только медитируют на прибыли.
Да, получение прибыли — основная задача, но ее подзадачи — хорошо делать дела, без которых не получить этой самой прибыли.
У программистов скорее другая проблема, увлекшись реализацией какого-нить красивого алгоритма, зачастую забывают о том, для чего он вообще был нужен.
Сужу по себе, даже на сдельщине бывало такое.

B>Зарплата и условия ее получения должны быть такими,
B>чтобы не отвлекать программиста от его основной деятельности
B>и чтобы он не смотрел на сторону.

Давно проехали...

B>Еще можно заделаться акционерным обществом и тогда
B>у работников появится возможность получать свой кусочек пирога

Тоже хорошо конечно, только это уже не имеет отношения к KPI.
Эффективно разве что для небольших контор и стартапов.
А когда в компании кроме тебя еще 500 чел работает, твой вклад на общем фоне не заметен.
Получаем практически тоже самое с чего начинали, кто-то проникнувшись ответственностью перед коллективом будет вкалывать,
кто-то изучать финансовые показатели компании и думать, не пора ли свалить.

21.09.2010 15:10, genre пишет:
>
> Именно поэтому во всех твоих сообщениях сквозит презрение к менеджменту
> во всех его проявлениях?
Ну а как можно уважать "эффективных русских менеджеров"?

> Не мешайте программерам работать, это не конструктив.Так работа не
> делается.
Делается.

> Это очевидно любому, кто хоть раз был вынужден отвечать на
> вопросы о сроках и качестве.
Ты считаешь что твое мнение можно возвести в абсолют?

>
> V>Они работают за деньги, но если им не мешать подавляющее большинство
> V>хочет сделать хорошо и отлично.
>
> Подавляющее большинство хочет сделать быстро, получить зарплату и пойти
> домой к семье/хобби/телевизору/итд
Не надо обо всех судить по себе.

> V>И как? Работает? ))))))
> V>Подобная методика гарантирует завышение сроков раза в 2-3.
> Да, работает.
Так я ж и не говорю, что это всегда плохо завышать сроки в 2-3 раза.
Очень часто это, наоборот, наиболее эффективно с точки зрения попила бабла.

Posted via RSDN NNTP Server 2.1 beta

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

>> Это очевидно любому, кто хоть раз был вынужден отвечать на
>> вопросы о сроках и качестве.
V>Ты считаешь что твое мнение можно возвести в абсолют?

Ну предложи методику определения эстимейтов на проект силами программистов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

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

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

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

A>>>Руководителям компании важно, сколько принес денег каждый проект, в конце концов именно они эти проекты открывают и закрывают. Это их цель — сделать прибыль. Мне — не важно, я с этих денег ничего не имею, пусть я и добросовестно выполняю свою работу в рамках проекта, что мне отведён (а кто каким проектом занимается, решаю не я).

_>>Попробуйте изменить свой подход, увидеть лес за деревьями и всё-же стараться делать прибыль, а не работать работу в рамках проекта. Проработаете так полгода-год, сами удивитесь, насколько всё поменяется и поймёте. Что и успешность проекта и Ваше вознаграждение и продвижение совсем не на 95% ... зависит от менеджмента стратегического и оперативного. А может даже и на 100%, а в большей степени зависит от Вас самого.
K>Не надо простому программисту в конторе, где программист это ресурс пытаться увидеть лес, т.к.
K>- Не его зона материальной ответственности.
K>- Он всё равно ни на что не повлияет.

Это пассивная позиция.
Человек может очень сильно влиять на многое, любой. А уж на эффективность проекта — тем более.

K>- Вознаграждение оговорено в ТД.

Да. Но если человек работает не эффективно то его можно уволить. Если хорошо — можно премировать.

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

V>18.09.2010 11:08, mag745 пишет:
>>
>> Единственный параметр который мне нравится — это количество повторных
>> багов, т.е. появляется ли баг еще раз после его исправления. Т.е. чинил
>> одно — сломал другое, да еще то, что уже было починено.
V>А если то, что чинить приходится напоминает небоскреб построенный на
V>основе собачьей будки?
V>Т.е. код настолько ужасен, что починка в одном месте ломает в другом?

Есть такие программисты, у которых это в порядке вещей. Не хватает усидчивости всё обдумать сначала, а потом не хватает этой же усидчивости посмотреть что-же у него получилось. А этот параметр позволяет быстро выявить такого товарища и принять меры — либо человек поймет и научится думать прежде чем править и проверять себя, либо мы с ним расстаемся.
От кода это не зависит. Мы же рассматриваем ситуацию, когда код известен этому человеку, он же сам его и написал. Но возможен вариант сопровождения чужого кода и новый человек просто не знает, что на что влияет. Сложность кода может быть какой угодно. На понимание и въезжание нужно время, пока не въедет — повторные ошибки вполне обоснованы. Кстати когда они прекратятся — значит программер въехал в код.

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

V>19.09.2010 16:40, mag745 пишет:
>>
>> Полностью согласен. Это хорошие параметры для оценки работы команды. Но
>> как показатель конкретного человека — не приемлемо. И именно как KPI.
V>В чем разница здесь? Команда или человек. Я понимаю, если эта команда
V>или человек работает абсолютно независимо от других и не использует
V>никаких сторонних инструментов (такая сферическая команда в вакууме).

Тут я соглашусь. Всетаки эти параметры могут быть применены как к программисту, так и к команде в целом. Мы же всегда можем рассматривать одного программера как команду из одного человека.
Конечно если брать среднее кол-во ошибок на человека и т.д., то и в этом случае просто делим на 1.

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

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

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

Ни разу. Методика расчёта может быть весьма и весьма тяжёлой, учитывающей десятки/сотни/тысячи показателей, каждый из который необходимо или нормировать, или помножить на нетривиальным образом подобранный/высчитанный весовой коэффициент.
_FR>Если KPI у вас считается "легко", то это должно вызывать определённые подозрения

KPI не должен рассчитываться сложно, иначе он теряет наглядность, если я не могу себе объяснить что означает эта цифра и почему если полученный результат выходит за пределы какого-то диапазона — это плохо, а за пределы другого — это отлично. Рассчет должен быть четкий и понятный. Иначе это просто волшебные цифры. А раз так — будем подгонять их. Например, рассчет KPI для продавца — ему ставится план продаж, превысил — бонус, ниже — нет не только бонуса, но есть и антибонус. Всё четко и понятно. При работе с заявками: среднее время исполнения заявки — всё ясно любому. И для программиста KPI должен быть не сложнее. Или программисты не люди и им нужно всё считать только трехэтажными формулами

M>>Отдел занимается техподдержкой внутренних продуктов компании и результат влияния на доходы косвенный.
M>>И как вообще можно загнать работу программиста в рамки KPI?
_FR>Надо не так: требуется [для начала] вокруг работы програмиста выстроить измерения тех или иных показателей.
Согласен что надо. Ваше предложение? Какие параметры выстроить можно?

_FR>"Загонять" же "работу" очень сложно :о) потому что тогда люди начитают трудиться не на результат работы, а на показатель. Если вы с "рамками" ошибётесь, то это то, что вам и нужно, а вот если промахнётесь, то результат может оказаться плачевным.
Мой пост — это просьба о помощи. Напишите конкретное предложение. Общими фразами я уже сыт. Мне нужна конкретная помощь.

M>>Вот какие показатели предлагает руководство:
M>>1) Некое отношение трудозатрат к приоритетности (удельному коммерческому весу).
_FR>ИМХО, это подсчитать возможно.
Подсчитал. Кстати хороший показатель оказался. Показывает насколько важными для организациями задачами нагружен отдел. Очень полезно, чтобы выявить те задачи, которые следуют отдать на аутсорс или консультантам, работающим с пользователями напрямую. Но как KPI он не катит. Он показывает качественную работу, но ведь за то какие задачи дают на разработку программист ответсвености не несет. Т.е. как KPI для оценки работы программиста не подходит.

M>>2) Количество новых/изменившихся требований с момента утверждения ТЗ.
_FR>И это тоже.
Посчитать можно. Но бестолковое занятие. Показывает, насколько увеличился срок выполнения проекта при таком-то количестве новых требований и изменений. Это и так очевидно без подсчета. Как по этому параметру оценить работника? Что сказали делать, то он и делал.

M>>3) «Количество» экспертиз, которыми надо обладать для решения задачи.
_FR>Тут я не понимаю, что означает "экспертиза". Квалификация? Умение? Тогда и с этим не будет сложности.
Тут я тоже теряюсь. Знание каких-то конкретных технологий. И уровень знания. А кто будет определять уровень знания? Кто решает? Это уже не объективно. Или проводить сертификацию в технологиях — это накладно для компании.

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

Задача интересная. Это точно.

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

Ведь 80% проектов идут с перерасходом и денег и времени.

M>>Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией.
_FR>На прежни работах пытались. Выливалось всё [на мой строгий взгляд] в исключительно измерение того, на сколько своевременно предоставлен еженедельный отчёт

Это интересно и показательно.

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

M>>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.
_FR>ИМХО, это крайне важно. Но настолько глупо в большом количестве случаев получается, что может быть и действительно отказаться от этогобудет лучшим для всех

Отказаться не получится.

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

M>KPI не должен рассчитываться сложно, иначе он теряет наглядность, если я не могу себе объяснить что означает эта цифра и почему если полученный результат выходит за пределы какого-то диапазона — это плохо, а за пределы другого — это отлично. Рассчет должен быть четкий и понятный. Иначе это просто волшебные цифры. А раз так — будем подгонять их. Например, рассчет KPI для продавца — ему ставится план продаж, превысил — бонус, ниже — нет не только бонуса, но есть и антибонус. Всё четко и понятно. При работе с заявками: среднее время исполнения заявки — всё ясно любому. И для программиста KPI должен быть не сложнее. Или программисты не люди и им нужно всё считать только трехэтажными формулами

Можно и простыми и результат будет отличный, примерно такой http://www.rsdn.ru/forum/flame.comp/3917527.1.aspx

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

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

M>>KPI не должен рассчитываться сложно, иначе он теряет наглядность, если я не могу себе объяснить что означает эта цифра и почему если полученный результат выходит за пределы какого-то диапазона — это плохо, а за пределы другого — это отлично. Рассчет должен быть четкий и понятный. Иначе это просто волшебные цифры. А раз так — будем подгонять их. Например, рассчет KPI для продавца — ему ставится план продаж, превысил — бонус, ниже — нет не только бонуса, но есть и антибонус. Всё четко и понятно. При работе с заявками: среднее время исполнения заявки — всё ясно любому. И для программиста KPI должен быть не сложнее. Или программисты не люди и им нужно всё считать только трехэтажными формулами

FR>Можно и простыми и результат будет отличный, примерно такой http://www.rsdn.ru/forum/flame.comp/3917527.1.aspx

Классный пример.

Для того, чтобы этого не было и сужествуют менеджеры.

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

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

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

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

Фигня

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

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

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

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

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

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

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

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

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

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

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

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

Pzz>По-моему, надо начинать неторопясь искать другую работу...

Сто пудов! А то это работодатели кроме того что денег платят, так им еще и измеримый результат подавай! Вот ведь кровососы!

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

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

M>>Или как объяснить руководству ненужность этого, а лучше написать толковые инструкции.

AAV>Мне нравится как это объясняет Дорофеев: http://cartmendum.livejournal.com/60982.html

Полная херня написана. Особенно вот эта аналогия:

Давайте на минутку забудем о том, что программисты пишут код и в этом коде потом кто-то ищет баги. Задачи все разные, люди еще более разные… Предположим, что эти цифры я получил в ходе очень простой игры:
У каждого из ребят есть ведро
В ведре насыпано 100 красных шариков, 900 белых и все это хорошо перемешано
Каждый из ребят закрывает глаза, и наугад вытягивает 100 шариков
Потом в выборке каждого мы считаем число красных шариков (типа багов)

Почему херня? Да потому что девелоперы не с закрытыми глазами педалят. Это как раз их задача номер 1, им за это деньги и платят: сидеть с открытыми глазами, скрипеть мозгами и реализовывать то, что необходимо по проекту. Если уж автор статьи так любит аналогии, интересно что он скажет вот на такую задачу:
Автор строит дом и ему нужно развести электричество (выключатели, распаечные коробки, розетки ну и т.п.). Он зовет электрика, с которым договаривается, что тот за оговоренную сумму сделает ему эту работу. Электрик копается месяц, а в конце на этапе приема/сдачи работы оказывается, что треть розеток и выключателей не работает — заплатит ли автор все 100% оговоренной суммы? Крупно сомневаюсь.

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

G>Автор строит дом и ему нужно развести электричество (выключатели, распаечные коробки, розетки ну и т.п.). Он зовет электрика, с которым договаривается, что тот за оговоренную сумму сделает ему эту работу. Электрик копается месяц, а в конце на этапе приема/сдачи работы оказывается, что треть розеток и выключателей не работает — заплатит ли автор все 100% оговоренной суммы? Крупно сомневаюсь.

Это опять же неверная аналогия. Правильно так: треть розеток заклеили обоями, половину проводки порвали при монтаже батарей, а треть выключателей располагается в точном соответствии с планом, но за мебелью.

Электрик совершенно справедливо будет требовать 100% оплаты, потому, что когда он это делал все работало и уже проблем автора в том, что он пожлобился на прораба.

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

Pzz>>По-моему, надо начинать неторопясь искать другую работу...

G>Сто пудов! А то это работодатели кроме того что денег платят, так им еще и измеримый результат подавай! Вот ведь кровососы!

Они не только результат хочут, они еще хочут, чтобы програмизды строем ходили. Некоторым это нравится, впрочем, ходить строем и чтобы порядок был. Не понимаю, почему эти некоторые в армию на контракт не идут, им так должно быть комфортно по идее.

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

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

Ни разу. Методика расчёта может быть весьма и весьма тяжёлой, учитывающей десятки/сотни/тысячи показателей, каждый из который необходимо или нормировать, или помножить на нетривиальным образом подобранный/высчитанный весовой коэффициент.
_FR>>Если KPI у вас считается "легко", то это должно вызывать определённые подозрения

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

Железная логика

Вы имеете в виду какую-то конкретную методику расчёта KPI или просто озвучиваете своё мнение? Поищите всё-таки информацию по теме от квалифицированных советчиков. Начать можно отсюда: http://www.kpilib.ru, например вот.

_FR>>"Загонять" же "работу" очень сложно :о) потому что тогда люди начитают трудиться не на результат работы, а на показатель. Если вы с "рамками" ошибётесь, то это то, что вам и нужно, а вот если промахнётесь, то результат может оказаться плачевным.
M>Мой пост — это просьба о помощи.

В первую очередь — ознакомьтесь подробно с тем, как рассчитывают KPI буржуины для самых разных специальностей. Если вы дилетантски подойдёте к данному вопросу, наслушавшись и попытавшись повторить, то ничего хорошего не выйдет. Ну разве что вам требуется сделать дело "для галочки" и втиреть очки руководству

Если же нет — то, чем вам поручено заняться не только очень ответственная задача, но и сложная. И подхода требует соответствующего.

M>Напишите конкретное предложение. Общими фразами я уже сыт.

Без "общих фраз" никак. То, за что вы взялись, имеет огромную теоритическую и практическую базу

M>Мне нужна конкретная помощь.

Для оказания конкретной помощи требуется очень конкретные знания о вашей ситуации: для одной компании эффективными являются сотрудники, отвечающие неким одним требованиям, а для другой — отвечающие совсем другим. Ничего не зная о том, что важно вашим руководителям, ничего конкретно сказать нельзя.

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

M>Здравствуйте, Glоbus, Вы писали:

G>>Автор строит дом и ему нужно развести электричество (выключатели, распаечные коробки, розетки ну и т.п.). Он зовет электрика, с которым договаривается, что тот за оговоренную сумму сделает ему эту работу. Электрик копается месяц, а в конце на этапе приема/сдачи работы оказывается, что треть розеток и выключателей не работает — заплатит ли автор все 100% оговоренной суммы? Крупно сомневаюсь.

M>Это опять же неверная аналогия. Правильно так:

А, ну тебе конечно виднее

M>Электрик совершенно справедливо будет требовать 100% оплаты, потому, что когда он это делал все работало и уже проблем автора в том, что он пожлобился на прораба.

Ты наверное стройкой и ремонтами никогда не занимался

Прораб — это самое большое попадалово во всей этой кухне

Если возможность есть (а для мегасупердевелоперов это не составляет никаких проблем — по крайней мере не должно) нужно самому быть прорабом.

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

Pzz>Здравствуйте, Glоbus, Вы писали:

Pzz>>>По-моему, надо начинать неторопясь искать другую работу...

G>>Сто пудов! А то это работодатели кроме того что денег платят, так им еще и измеримый результат подавай! Вот ведь кровососы!

Pzz>Они не только результат хочут, они еще хочут, чтобы програмизды строем ходили. Некоторым это нравится, впрочем, ходить строем и чтобы порядок был. Не понимаю, почему эти некоторые в армию на контракт не идут, им так должно быть комфортно по идее.

Ходить строем — само собой маразм. Но к метрикам это никак не относится. И к порядку в конторе тоже.

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

Pzz>>Они не только результат хочут, они еще хочут, чтобы програмизды строем ходили. Некоторым это нравится, впрочем, ходить строем и чтобы порядок был. Не понимаю, почему эти некоторые в армию на контракт не идут, им так должно быть комфортно по идее.

G>Ходить строем — само собой маразм. Но к метрикам это никак не относится. И к порядку в конторе тоже.

Результат работы программистов измеряется даже не в строках кода, а в написанных, отлаженых и работающих продуктах. А отнюдь не в тех дебильных метриках, которые можно замерить.

Проблема в том, что программирование существенно отличается от работы на токарном станке и результат работы не выражается линейной (или, хотя бы, монотонной) функцией от объема затраченных усилий, просиженного на работе времени, потерянного зрения и т.п.

23.09.2010 21:18, mag745 пишет:
>
> V>А если то, что чинить приходится напоминает небоскреб построенный на
> V>основе собачьей будки?
> V>Т.е. код настолько ужасен, что починка в одном месте ломает в другом?
>
> Есть такие программисты, у которых это в порядке вещей. Не хватает
> усидчивости всё обдумать сначала, а потом не хватает этой же усидчивости
> посмотреть что-же у него получилось.
Ты невнимательно прочитал то, что я написал выше. По очень многим
причинам (и программисты часто самая последняя причина) в конкретный
момент времени код некоего продукта может напоминать коромысло с двумя
ведрами. Долив воды в одно, поднимется другое.

Posted via RSDN NNTP Server 2.1 beta

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

Pzz>Здравствуйте, Glоbus, Вы писали:

Pzz>>>Они не только результат хочут, они еще хочут, чтобы програмизды строем ходили. Некоторым это нравится, впрочем, ходить строем и чтобы порядок был. Не понимаю, почему эти некоторые в армию на контракт не идут, им так должно быть комфортно по идее.

G>>Ходить строем — само собой маразм. Но к метрикам это никак не относится. И к порядку в конторе тоже.

Pzz>Результат работы программистов измеряется даже не в строках кода, а в написанных, отлаженых и работающих продуктах. А отнюдь не в тех дебильных метриках, которые можно замерить.

Оки, ну давай обсудим. Как ты определяешь что продукт готов, отлажен и работает? Более того — просто работать продукту недостаточно — нужно чтобы он работал как требуется, а не как решила левая пятка девелопера в прошлый четверг. А это уже — формальные кретерии.

Pzz>Проблема в том, что программирование существенно отличается от работы на токарном станке и результат работы не выражается линейной (или, хотя бы, монотонной) функцией от объема затраченных усилий, просиженного на работе времени, потерянного зрения и т.п.

А кто-то пытается определить результат по затраченным усилиям? Имя, сестра, имя! Я как раз и предлагаю судить о работе по результату: сколько времени заняло, насколько пролетели мимо кассы, сколько косяков напороли, процентный вклад каждого вида косяков по приоритетам (баги Urgent/High/Medium/Low...), по типам (UI, функционал, производительность,...). Всего-то 5-7 показателей, считаются руками в экселе за 5 минут, но вкупе с другими наблюдениями сказать нам могут об оооочень много

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

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

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

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

M>Как-то доводилось работать с компанией, где подобные метрики внедрялись. Результат не из самых веселых.
M>Работа на "красивые циферки" оказалась приоритетнее работы на хороший качественный результат.

Метрики разные бывают — как правильные, так и нет

M>Да и есть классические примеры, как то же измерение производительности программистов в строчках кода. Вот то, о чем вы говорите может скатиться в подобную бредятину.

Один дурацкий пример неправильной метрики не говорит о том, что метрики как таковые не работают вообще

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

G>Оки, ну давай обсудим. Как ты определяешь что продукт готов, отлажен и работает? Более того — просто работать продукту недостаточно — нужно чтобы он работал как требуется, а не как решила левая пятка девелопера в прошлый четверг. А это уже — формальные кретерии.

По наличию факта согласия заинтересованных сторон. Hint: в создании продукта не только девелопер участвует.

Pzz>>Проблема в том, что программирование существенно отличается от работы на токарном станке и результат работы не выражается линейной (или, хотя бы, монотонной) функцией от объема затраченных усилий, просиженного на работе времени, потерянного зрения и т.п.

G>А кто-то пытается определить результат по затраченным усилиям? Имя, сестра, имя! Я как раз и предлагаю судить о работе по результату: сколько времени заняло, насколько пролетели мимо кассы, сколько косяков напороли, процентный вклад каждого вида косяков по приоритетам (баги Urgent/High/Medium/Low...), по типам (UI, функционал, производительность,...). Всего-то 5-7 показателей, считаются руками в экселе за 5 минут, но вкупе с другими наблюдениями сказать нам могут об оооочень много

То, что человек вставляет много зловредных косяков, может говорить о том, что у него руки-крюки, а может о том, что он писал самую сложную часть проекта. Другие критерии примерно столь же сомнительны.

С другой стороны, любой вменяемый тим-лидер знает, на кого в своей команде он может положиться, а кого терпит по принципу, "ну хорошо, что хоть эту работу он делает". В терминах галочек в ёкселе это не выражается. Надо доверять немного людям и прислушиваться к их мнению

Именно поэтому я считаю, что если компания начинает внедрять формальные системы учета и контроля, это означает, что человеческие отношения скоро эту компанию покинут, и поэтому надо неторопясь искать новую работу

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

Pzz>С другой стороны, любой вменяемый тим-лидер знает, на кого в своей команде он может положиться, а кого терпит по принципу, "ну хорошо, что хоть эту работу он делает". В терминах галочек в ёкселе это не выражается. Надо доверять немного людям и прислушиваться к их мнению

Так почему бы этому вменяемому тим-лидеру не дать дополнительную возможность стимулировать девелоперов деньгами, а не только красивыми речами о важности проекта и тп?

Может тот, кого приходиться терпеть, так работает от того, что не видит смысла стараться, и больше сил уделяет шабашкам.
А тот, на кого он привык полагаться, все еще не теряет надежды на то, что его усилия наконец-то будут оценены по достоинству, и вот-вот разочаруется.

Pzz>Именно поэтому я считаю, что если компания начинает внедрять формальные системы учета и контроля, это означает, что человеческие отношения скоро эту компанию покинут, и поэтому надо неторопясь искать новую работу

Насчет формальных, совершенно согласен, большое зло там, где работу невозможно оценивать формальными методами.
Так почему бы не оценивать неформальными? Просто оценить на глазок, Вася сделал 80% работы, а Петя только 20%, соответственно и премии получат столько же.
Если ПМ вменяемый, и сам заинтересован в успешности проектов, то будет стараться распределять по справедливости.
Хотя конечно, если Вася шибко увлеченный чел, и безо всяких премий готов вкалывать, то премию и так и так не получит

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

D>Так почему бы этому вменяемому тим-лидеру не дать дополнительную возможность стимулировать девелоперов деньгами, а не только красивыми речами о важности проекта и тп?

В некоторых конторах дают. Но это далеко не всегда хорошо работает, и далеко не всем нравится.

Я, например, не люблю такой стиль работы не с какой стороны — ни как начальник, ни как подчиненный. Мне больше нравятся не месячные премии, а когда хорошим людям не забывают вполне регулярно поднимать зарплату.

D>Может тот, кого приходиться терпеть, так работает от того, что не видит смысла стараться, и больше сил уделяет шабашкам.
D>А тот, на кого он привык полагаться, все еще не теряет надежды на то, что его усилия наконец-то будут оценены по достоинству, и вот-вот разочаруется.

Большинство людей мотивированны не деньгами — при условии, что они получают зарплату, близкую к среднерыночной.

D>Так почему бы не оценивать неформальными? Просто оценить на глазок, Вася сделал 80% работы, а Петя только 20%, соответственно и премии получат столько же.
D>Если ПМ вменяемый, и сам заинтересован в успешности проектов, то будет стараться распределять по справедливости.
D>Хотя конечно, если Вася шибко увлеченный чел, и безо всяких премий готов вкалывать, то премию и так и так не получит

Если Вася — человек, на которого я всегда могу полагаться, моя забота следить о том, чтобы Васе не забывали зарплату поднимать. А Петя, если он лодырь и разгильдяй, я не буду за его зарплату хлопотать перед начальством. А премии эти, ну их нафиг, от них суета и нервотрепка одна.

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

G>На самом деле такие показатели нужны, и при том не только руководству, а и самому программеру — иначе на основании чего он будет через полгода работы просить повышения з/п? Типа "ну я ведь крутой перец! А вы видели мои экспертизы? Да я вам прямо щас их достану!"
G>На вскидку, можно предложить следующие KPI:

Именно, что навскидку. Давайте копнем чуть глубже.

G>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).

Уже обсуждалось. Безбожное завышение сроков, чтобы в него уложиться. Сжатие сроков извне ведет к рискованному, агрессивному расписанию, поскольку есть и нормальные люди. Хорошо описано у Йордона, "Путь камикадзе" или Death March

G>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.

Прямое влияние на сроки. Программеры будут искать локальный оптимум функции двух переменных — сроков и багов. Совершенно не факт, что у этой функции окажется только один оптимум. Почитайте cartmendum-а AKA Макс Дорофеев — очень красиво и с юмором.
Предвижу возражение — но ведь мы и хотим при помощи KPI сдвинуть баланс в ту или иную сторону. Увы, этот баланс для каждого индивидуален. Один неделю пишет, день ловит баги, а у другого обстоит ровно наоборот.

И это еще не самое страшное. Глобальная проблема заключается в том, что люди станут избегать сложных и неделимых задач, т.к. они непредсказуемы. А это уже ведет к остановке профессионального роста программеров в компании. Естественно, руководство это, хоть и поздно, но заметит и начнет делать одних людей более равными, чем другие. У них испортятся отношения с остальными... ну и так далее.

Ни разу не слышал про KPI для программистов в достаточно зрелой компании, где есть хорошие ПМы. В таких компаниях обычно есть формальные оценки, но они делаются ПМами на основе личных наблюдений, и уж совсем не за количеством строк или багов. 360 фидбэк и т.п.

G>Если у вас контора, скажем так, "продуктовая", т.е. вы педалите свой продукт, и при этом у вас открытый диалог внутри конторы и все могут вносить предложение по продукту, процессам и т.п., и соотвественно эти предложения обсуждаются, внедряются/отклоняются, то можно еще считать такой показатель как количество внесенных предложений за год, количество принятых руководством как полезные — в умных книжках пишут, что это очень распространенная хрень у японцев и последнее время немцев и американцев в автоотрасли (тойота с ее бережливым производством ну и т.п.). Плюс это позволяет выявить людей, которые "не на своих местах" — скажем чувак у вас значится девелопером и педалит вроде бы неплохо, но при это имеет отличное видение бизнеса, понимание продукта, маркетинговых моментов, хорошее чутье относительно процессов, происходящих в конторе ну и т.п. Опять же повторюсь: для такой процедуры нужно понимание ее необходимости и полезности как в верхах, так и среди персонала — однако такой консенсус в одном месте и в одно время встречается крайне редко, а зачастую даже не привествуется одной из сторон.

О! А вот это уже гораздо лучше. Стимулируется рост и селекция работников. Правда, к KPI в его классическом понимании это уже имеет весьма отдаленное отношение

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

Pzz>Здравствуйте, Glоbus, Вы писали:

G>>Оки, ну давай обсудим. Как ты определяешь что продукт готов, отлажен и работает? Более того — просто работать продукту недостаточно — нужно чтобы он работал как требуется, а не как решила левая пятка девелопера в прошлый четверг. А это уже — формальные кретерии.

Pzz>По наличию факта согласия заинтересованных сторон. Hint: в создании продукта не только девелопер участвует.

Откуда заинтересованная сторона узнает что продукт "готов, отлажен и работает"? Как она, сторона эта, это проверит? На глазок?

Pzz>>>Проблема в том, что программирование существенно отличается от работы на токарном станке и результат работы не выражается линейной (или, хотя бы, монотонной) функцией от объема затраченных усилий, просиженного на работе времени, потерянного зрения и т.п.

G>>А кто-то пытается определить результат по затраченным усилиям? Имя, сестра, имя! Я как раз и предлагаю судить о работе по результату: сколько времени заняло, насколько пролетели мимо кассы, сколько косяков напороли, процентный вклад каждого вида косяков по приоритетам (баги Urgent/High/Medium/Low...), по типам (UI, функционал, производительность,...). Всего-то 5-7 показателей, считаются руками в экселе за 5 минут, но вкупе с другими наблюдениями сказать нам могут об оооочень много

Pzz>То, что человек вставляет много зловредных косяков, может говорить о том, что у него руки-крюки, а может о том, что он писал самую сложную часть проекта. Другие критерии примерно столь же сомнительны.

Не понял выделенное — косяки они и в африке косяки — хоть в "мегасложной части кода", хоть в диалоговом окне с одной кнопочкой ОК.

Pzz>С другой стороны, любой вменяемый тим-лидер знает, на кого в своей команде он может положиться, а кого терпит по принципу, "ну хорошо, что хоть эту работу он делает". В терминах галочек в ёкселе это не выражается. Надо доверять немного людям и прислушиваться к их мнению

Галочки в экселе дополняют картину, а точнее сказать — делают ее реалистичной. Потому как очень часто бывает так, что ты вроде думаешь, что на человека можно положиться, а вот галочки в экселе показывают, что последние 2-3 месяца он твоим доверием злоупотребляем.

Pzz>Именно поэтому я считаю, что если компания начинает внедрять формальные системы учета и контроля, это означает, что человеческие отношения скоро эту компанию покинут, и поэтому надо неторопясь искать новую работу

Дружище, компания — это прежде всего способ зарабатывания денег, и человеческие отношения там могут культивироваться только как один из способов мотивации коллектива. Если человеческие отношения перерастают в панибратство (а так зачастую и бывает, когда люди видят, что контроля за ними нету, и что попив пивка в тимлидом или проджект манагером можно авторитетно ему доказать, что он на самом деле не забивает на работу, а это типа клиент плохой, проект галимый ну и т.п.), то это первый гвоздь в гроб конторы.

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

nvb>Здравствуйте, Glоbus, Вы писали:

G>>На самом деле такие показатели нужны, и при том не только руководству, а и самому программеру — иначе на основании чего он будет через полгода работы просить повышения з/п? Типа "ну я ведь крутой перец! А вы видели мои экспертизы? Да я вам прямо щас их достану!"
G>>На вскидку, можно предложить следующие KPI:

nvb>Именно, что навскидку. Давайте копнем чуть глубже.

G>>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).

nvb>Уже обсуждалось. Безбожное завышение сроков, чтобы в него уложиться. Сжатие сроков извне ведет к рискованному, агрессивному расписанию, поскольку есть и нормальные люди. Хорошо описано у Йордона, "Путь камикадзе" или Death March

Поэтому нужно быть technical enought, чтобы понимать, насколько реалистичны предлагаемые сроки. Для нормального проджект-менеджере, или тим лида, которые с этими же самыми людьми каждый день бок о бок педалит оценить реалистичность вообще не проблема, и не только оценить, а и аргументированно доказать это своим подчиненым, чтобы не было конфронтации.

G>>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.

nvb>Прямое влияние на сроки. Программеры будут искать локальный оптимум функции двух переменных — сроков и багов. Совершенно не факт, что у этой функции окажется только один оптимум. Почитайте cartmendum-а AKA Макс Дорофеев — очень красиво и с юмором.
nvb>Предвижу возражение — но ведь мы и хотим при помощи KPI сдвинуть баланс в ту или иную сторону. Увы, этот баланс для каждого индивидуален. Один неделю пишет, день ловит баги, а у другого обстоит ровно наоборот.

Но в сумме все равно получается неделя+день — т.е. 6 дней

Плюс к тому: для понижения бажности кода никто не мешает вместе с KPI использовать такие вещи как стандарты кодирования, код-ревью и т.п. Должна быть вообще комплексная деятельность — на одних голых KPI никуда не уедешь. но они реально необходимы.

nvb>И это еще не самое страшное. Глобальная проблема заключается в том, что люди станут избегать сложных и неделимых задач, т.к. они непредсказуемы. А это уже ведет к остановке профессионального роста программеров в компании. Естественно, руководство это, хоть и поздно, но заметит и начнет делать одних людей более равными, чем другие. У них испортятся отношения с остальными... ну и так далее.

Таких вот "сложных и неделимых задача" всего дай бог чтоб 10% от общего объема было — если ты конечно не чистой наукой занимаешься. Для этих 10%можно проявить гибкость и устанавливать менее строгие KPI — скажем, просто: сделал/не сделал — и оценивать по ним.

nvb>Ни разу не слышал про KPI для программистов в достаточно зрелой компании, где есть хорошие ПМы. В таких компаниях обычно есть формальные оценки, но они делаются ПМами на основе личных наблюдений, и уж совсем не за количеством строк или багов. 360 фидбэк и т.п.

А KPI личные наблюдения ни разу не отменяют — эти техники друг друга дополняют.

G>>Если у вас контора, скажем так, "продуктовая", т.е. вы педалите свой продукт, и при этом у вас открытый диалог внутри конторы и все могут вносить предложение по продукту, процессам и т.п., и соотвественно эти предложения обсуждаются, внедряются/отклоняются, то можно еще считать такой показатель как количество внесенных предложений за год, количество принятых руководством как полезные — в умных книжках пишут, что это очень распространенная хрень у японцев и последнее время немцев и американцев в автоотрасли (тойота с ее бережливым производством ну и т.п.). Плюс это позволяет выявить людей, которые "не на своих местах" — скажем чувак у вас значится девелопером и педалит вроде бы неплохо, но при это имеет отличное видение бизнеса, понимание продукта, маркетинговых моментов, хорошее чутье относительно процессов, происходящих в конторе ну и т.п. Опять же повторюсь: для такой процедуры нужно понимание ее необходимости и полезности как в верхах, так и среди персонала — однако такой консенсус в одном месте и в одно время встречается крайне редко, а зачастую даже не привествуется одной из сторон.

nvb>О! А вот это уже гораздо лучше. Стимулируется рост и селекция работников. Правда, к KPI в его классическом понимании это уже имеет весьма отдаленное отношение

Ты очень ошибаешся

В том же lean production это как раз один из наиболее "любимых" KPI — количественная оценка инициативности сотрудника.

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

GG>>>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).

nvb>>Уже обсуждалось. Безбожное завышение сроков, чтобы в него уложиться. Сжатие сроков извне ведет к рискованному, агрессивному расписанию, поскольку есть и нормальные люди. Хорошо описано у Йордона, "Путь камикадзе" или Death March

G>Поэтому нужно быть technical enought, чтобы понимать, насколько реалистичны предлагаемые сроки. Для нормального проджект-менеджере, или тим лида, которые с этими же самыми людьми каждый день бок о бок педалит оценить реалистичность вообще не проблема, и не только оценить, а и аргументированно доказать это своим подчиненым, чтобы не было конфронтации.

Немного разовьем высказывание. Тимлид хорошо разбирается в технической части и хорошо знает, на что способны его люди. Вопрос — а зачем ЗДЕСЬ вводить KPI? Что конкретно не устраивает руководство? Тимлид, зная все и вся, выдает реалистичный план-график, который выполняется. Такие тимлиды редко, но бывают (например, у меня были), и единственный вопрос, который им нужно задавать — не требуется ли чем-нибудь еще помочь? Лезть к ним с KPI — верх глупости. Если у такого тимлида в команду затесалась паршивая овца — гораздо проще эту овцу убрать и взять нового человека, чем играть в справедливость и ломать работающую устоявшуюся систему вводом KPI.

Вы не принимаете во внимание человеческий фактор. Программист не любит ходить строем, и чем он выше уровнем, тем меньше он любит муштру и тем больше имеет возможностей послать компанию на фиг, если в ней что-то не понравилось. Когда он пьет пиво в кругу близких друзей, он обычно хвастается свободным графиком, а не интересными задачами или зарплатой. Для него любое новое ограничение — повод задуматься о смене работы. Установите точное время прихода и штрафуйте за опоздания — очень скоро вы потеряете часть команды.

А архитектора вы как собираетесь оценивать? А еще священные коровы будут?

G>>>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.

nvb>>Прямое влияние на сроки. Программеры будут искать локальный оптимум функции двух переменных — сроков и багов. Совершенно не факт, что у этой функции окажется только один оптимум. Почитайте cartmendum-а AKA Макс Дорофеев — очень красиво и с юмором.
nvb>>Предвижу возражение — но ведь мы и хотим при помощи KPI сдвинуть баланс в ту или иную сторону. Увы, этот баланс для каждого индивидуален. Один неделю пишет, день ловит баги, а у другого обстоит ровно наоборот.

G>Но в сумме все равно получается неделя+день — т.е. 6 дней

В озере в среднем по колено воды, но корова все-таки утонула. Куда именно сместится баланс? А если в желательную сторону у 10 формоклепателей и в нежелательную сторону у одного человека, который пишет ядро системы? Или подстраивать KPI под каждого человека? Так жизни не хватит.

G>Плюс к тому: для понижения бажности кода никто не мешает вместе с KPI использовать такие вещи как стандарты кодирования, код-ревью и т.п. Должна быть вообще комплексная деятельность — на одних голых KPI никуда не уедешь. но они реально необходимы.

Ну хоть признали, что на голых KPI никуда не уедешь. Зачем они необходимы — я не понимаю. На мой взгляд, обезличка оценки программистов через KPI никакой пользы не приносит, и применяется только тогда, когда уровень менеджеров ниже плинтуса, когда менеджеры не способны самостоятельно управлять коллективом (или их начальство так считает, что случается даже чаще).

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

nvb>Здравствуйте, Glоbus, Вы писали:

GG>>>>1. По каждому таску, возложенному на благородного дона — среднее время задержки при выполнении задания (расчитывается по результатам, сделал вовремя — плюс, опережение графика является доп.плюсом, отстование — соотвественно минусом).

nvb>>>Уже обсуждалось. Безбожное завышение сроков, чтобы в него уложиться. Сжатие сроков извне ведет к рискованному, агрессивному расписанию, поскольку есть и нормальные люди. Хорошо описано у Йордона, "Путь камикадзе" или Death March

G>>Поэтому нужно быть technical enought, чтобы понимать, насколько реалистичны предлагаемые сроки. Для нормального проджект-менеджере, или тим лида, которые с этими же самыми людьми каждый день бок о бок педалит оценить реалистичность вообще не проблема, и не только оценить, а и аргументированно доказать это своим подчиненым, чтобы не было конфронтации.

nvb>Немного разовьем высказывание.

Ага, давай

nvb>Тимлид хорошо разбирается в технической части и хорошо знает, на что способны его люди. Вопрос — а зачем ЗДЕСЬ вводить KPI?

Ответ прост: подчиненные этого тимлида — люди, а людям свойственно менятся, это динамичные системы, а это значит что под влиянием тех или иных факторов они могут начать педалить лучше, а могут хуже, могут вообще бунт устроить по каким-то политическим мотивам ну и т.п. Так вот КПИ позволяют выявить тенденции. К примеру: дев Вася очень хорошо кодит, но 2 недели наз он разбежался со своей девченкой и у него депресняк. Вполне вероятно, что Вася не настолько сильный человек, чтобы оставлять личное за дверью и педалить также эффективно всегда — вот и получается, что проблемы в личной жизни будут аффектить его работу. А КПИ позволят нам выявить следствия этого: отставание от графика, или увеличившееся число багов, или большее количество переоткрытых багов ну и т.п. И вот эти показатели позволяют нам задуматься — а мож с ним поговорить, узнать чем вызван спад в работе? Расскажет — классно, не расскажет — будем искать обходные пути узнать (черех ХР, других сотрудников ну и т.п.) — это уже другой комплекс мероприятий. Самое главное что мы в РЕАЛЬНОМ времени получили быструю обратную связь. Самая простая аналогия — тахометр в машине. Мы можем очень хорошо знать свю машину, заботиться о ней и все такое, но с помощью тахометра мы можем на ранней стадии определить неполадки в двигле или сопутствующих системах — скажем начали обороты плавать.

nvb>Что конкретно не устраивает руководство? Тимлид, зная все и вся, выдает реалистичный план-график, который выполняется. Такие тимлиды редко, но бывают (например, у меня были), и единственный вопрос, который им нужно задавать — не требуется ли чем-нибудь еще помочь? Лезть к ним с KPI — верх глупости. Если у такого тимлида в команду затесалась паршивая овца — гораздо проще эту овцу убрать и взять нового человека, чем играть в справедливость и ломать работающую устоявшуюся систему вводом KPI.

Ключевое здесь выделено — тебе как менеджеру или работодателю этих тимлидов нужно построить работу так, чтобы от них независеть, или по крайней мере зависить минимально. С точки зрения работодателя идеал — это когда у тебя куча легкозаменяемых и контролируемых винтиков. Насчет "лезть к ним с КПИ верх глупости" — не согласен. КПИ — это РЕАЛЬНЫЕ приборы, которые помогают тимлиду оценивать подчиненных не наоснове своих чувств, а на основе реально значащих показателей.

nvb>Вы не принимаете во внимание человеческий фактор. Программист не любит ходить строем, и чем он выше уровнем, тем меньше он любит муштру и тем больше имеет возможностей послать компанию на фиг, если в ней что-то не понравилось. Когда он пьет пиво в кругу близких друзей, он обычно хвастается свободным графиком, а не интересными задачами или зарплатой. Для него любое новое ограничение — повод задуматься о смене работы. Установите точное время прихода и штрафуйте за опоздания — очень скоро вы потеряете часть команды.

Выделенное — вообще высосано из пальца

Насчет кто любит, а кто не любит муштру: муштру никто не любит, а вот порядок любят многие. Про потерю части команды — да, вполне вероятно, но я могу поступить и таким образом: я могу просто заткнуть им рты деньгами — банально дать з/п выше рыночной, при этом отжимая тоже больше чем в среднем по отрасли. И вот тут уже проблема у девелопера: с повышением з/п сразу поднимается уровень потребления, и отказаться от этого уровня наааамного тяжелее, чем приходить на работу к определенному времени и тратить 10 мин в день на заполнение тайм репорта. Скажу даже больше: когда недовольный товарищ потом пойдет по собеседованиям он может просто банально обломаться — окажется, что он не то что инкриса не может получить, а даже того уровня что у него есть щас, никто не предлагает. Сразу отвечу на вопрос "откуда взять доп.деньги, чтобы заткнуть девов": если расчеты верны и комплекс мер выбран правильно, то работа компании банально будет эффективнее — отсюда доппоступления. И самый прикол в том, что я лично знаю такие конторы — то есть это не мои фантазии. В общем и целом: КПИ — это составляющая целого комплекса из других мер и подходов, которые в сумме позволят оперативно реагировать на происходящее, если надо — быстро эволюционировать, измениться.

nvb>А архитектора вы как собираетесь оценивать? А еще священные коровы будут?

По результатам того, что он нааръитектурил. В простонародье это называется lessons learned: по завершении проекта подбивается итог — какие проблемы были, чем вызваны и т.п. Если окажется, что этот мегаархитектор напорол боков, при этом у меня в команде оказася человек, который эти бога смог выявить на ранних стадиях (для этого в компании есть такая вещь, как докладная записка), но всилу своей крутизны архитектор на эти замечания забил, то тут очень велик шанс того, что архитектор будет разжалован, а его место займет вот тот проницатильный бойкий пионер.

G>>>>2. Точно также по каждому таску (модулю, куску функционала) — а) количество багов, найденных тестерами, б) количество багов, которые были переоткрыты (т.е. чувак вроде починил, запостил в соурс сейф, а оказывает он лажу напедалил и поскакало все по новому кругу) ну и т.п.

nvb>>>Прямое влияние на сроки. Программеры будут искать локальный оптимум функции двух переменных — сроков и багов. Совершенно не факт, что у этой функции окажется только один оптимум. Почитайте cartmendum-а AKA Макс Дорофеев — очень красиво и с юмором.
nvb>>>Предвижу возражение — но ведь мы и хотим при помощи KPI сдвинуть баланс в ту или иную сторону. Увы, этот баланс для каждого индивидуален. Один неделю пишет, день ловит баги, а у другого обстоит ровно наоборот.

G>>Но в сумме все равно получается неделя+день — т.е. 6 дней

nvb>В озере в среднем по колено воды, но корова все-таки утонула. Куда именно сместится баланс? А если в желательную сторону у 10 формоклепателей и в нежелательную сторону у одного человека, который пишет ядро системы? Или подстраивать KPI под каждого человека? Так жизни не хватит.

Под каждого человека может и не хватит, а вот под определенный набор/тип тасков — вполне.

G>>Плюс к тому: для понижения бажности кода никто не мешает вместе с KPI использовать такие вещи как стандарты кодирования, код-ревью и т.п. Должна быть вообще комплексная деятельность — на одних голых KPI никуда не уедешь. но они реально необходимы.

nvb>Ну хоть признали, что на голых KPI никуда не уедешь.

Покажи мне, где я говорил иное?

nvb>Зачем они необходимы — я не понимаю.

Суммируя все выше сказанное: за тем же, зачем в автомобиле есть тахометр, спидометр, указатель уровня топлива, давления масла, заряда батареи ну и т.п. Зачтем же, зачем комании нужна бухгалтерия — цифры не обманишь: можно сколько угодно кричать, что твой продукт или твоя услуга меганравятся пользователям и клиентам, но если у тебя убытки, то тут шапкозакидательством ничего не решишь — только детальный анализ.

nvb>На мой взгляд, обезличка оценки программистов через KPI никакой пользы не приносит, и применяется только тогда, когда уровень менеджеров ниже плинтуса, когда менеджеры не способны самостоятельно управлять коллективом (или их начальство так считает, что случается даже чаще).

Управлять коллективом на одном чутье может получится только у реальных гениев управления — я таких за 8+ лет практики и в 5 разных конторах с персоналом от 5 до 300 человек ни разу не встречал. Более того, даже в бизнесе В ЦЕЛОМ все эти гении известны поименно: Сталин, Карлос Гон, Рэй Крок и еще наверное не более 10 других. Ты хочешь, чтобы твой бизнес зависил от гениев, от настроения примадонн? А если твоему гению завтра конкурент предложит не просто прибавку к з/п, а целый share в его бизнесе и он свалит — что будем делать с разбитым корытом (читай — неуправляемым бизнесом), у которого ты останешся? Или ты думаешь, что гении бизнеса и управления на каждом шагу? Реальность такова, что 99% людей (и мы с тобой в том числе) — слабые люди, подверженные переменам настрония, климатическим изменениям ну и т.д. и т.п., и задача процесса (частью которого должны быть КПИ) — снижение вот таких вот несистемных рисков.

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

G>Ходить строем — само собой маразм.

Справедливости ради стоит заметить, что если надо чтоб относительно большая группа людей быстро и эффективно куда то переместилась пешим порядком то построиться в колонну и идти строем будет самое оно.
Но только для таких применений, да.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Ответ прост: подчиненные этого тимлида — люди, а людям свойственно менятся, это динамичные системы, а это значит что под влиянием тех или иных факторов они могут начать педалить лучше, а могут хуже, могут вообще бунт устроить по каким-то политическим мотивам ну и т.п. Так вот КПИ позволяют выявить тенденции. К примеру: дев Вася очень хорошо кодит, но 2 недели наз он разбежался со своей девченкой и у него депресняк. Вполне вероятно, что Вася не настолько сильный человек, чтобы оставлять личное за дверью и педалить также эффективно всегда — вот и получается, что проблемы в личной жизни будут аффектить его работу. А КПИ позволят нам выявить следствия этого: отставание от графика, или увеличившееся число багов, или большее количество переоткрытых багов ну и т.п. И вот эти показатели позволяют нам задуматься — а мож с ним поговорить, узнать чем вызван спад в работе? Расскажет — классно, не расскажет — будем искать обходные пути узнать (черех ХР, других сотрудников ну и т.п.) — это уже другой комплекс мероприятий. Самое главное что мы в РЕАЛЬНОМ времени получили быструю обратную связь. Самая простая аналогия — тахометр в машине. Мы можем очень хорошо знать свю машину, заботиться о ней и все такое, но с помощью тахометра мы можем на ранней стадии определить неполадки в двигле или сопутствующих системах — скажем начали обороты плавать.

Извини, сейчас жутко занят, поэтому не могу ответить подробно. Если кратко — ты говоришь про систему сбора метрик, называя ее KPI. Но это разные вещи. Метрики нужны и очень важны, и они используются и в KPI, но KPI подразумевает (полу)автоматическое принятие решения по метрикам. Это принятие решения возведено в ранг закона, т.е. если Вася из-за девушки снизил производительность, ему надо однозначно резать зарплату. Даже если из-за этого он уйдет из компании, потому что иначе другие завопят: а почему мне режут зарплату, а Васе нет? Разрушится вся система, основанная на KPI. Либо менеджеру придется вилять и обманывать людей, что тоже приведет к краху.
Система же метрик предполагает, что у тебя документированы изменения параметров производительности сотрудников, но ты сам волен принимать решение, и не обязан за него отчитываться.

Поэтому, если везде в тексте заменить слово KPI на слово "метрики" — соглашусь с тобой почти во всем, кроме того, что нужно стремиться к переводу программиста в разряд легкозаменяемого винтика. Даже не буду объяснять, почему

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

nvb>Здравствуйте, Glоbus, Вы писали:

G>>Ответ прост: подчиненные этого тимлида — люди, а людям свойственно менятся, это динамичные системы, а это значит что под влиянием тех или иных факторов они могут начать педалить лучше, а могут хуже, могут вообще бунт устроить по каким-то политическим мотивам ну и т.п. Так вот КПИ позволяют выявить тенденции. К примеру: дев Вася очень хорошо кодит, но 2 недели наз он разбежался со своей девченкой и у него депресняк. Вполне вероятно, что Вася не настолько сильный человек, чтобы оставлять личное за дверью и педалить также эффективно всегда — вот и получается, что проблемы в личной жизни будут аффектить его работу. А КПИ позволят нам выявить следствия этого: отставание от графика, или увеличившееся число багов, или большее количество переоткрытых багов ну и т.п. И вот эти показатели позволяют нам задуматься — а мож с ним поговорить, узнать чем вызван спад в работе? Расскажет — классно, не расскажет — будем искать обходные пути узнать (черех ХР, других сотрудников ну и т.п.) — это уже другой комплекс мероприятий. Самое главное что мы в РЕАЛЬНОМ времени получили быструю обратную связь. Самая простая аналогия — тахометр в машине. Мы можем очень хорошо знать свю машину, заботиться о ней и все такое, но с помощью тахометра мы можем на ранней стадии определить неполадки в двигле или сопутствующих системах — скажем начали обороты плавать.

nvb>Извини, сейчас жутко занят, поэтому не могу ответить подробно. Если кратко — ты говоришь про систему сбора метрик, называя ее KPI. Но это разные вещи.

Да ну? http://ru.wikipedia.org/wiki/KPI

KPI — это инструмент измерения поставленных целей.

— это синоним метрик.

nvb>Метрики нужны и очень важны, и они используются и в KPI, но KPI подразумевает (полу)автоматическое принятие решения по метрикам. Это принятие решения возведено в ранг закона, т.е. если Вася из-за девушки снизил производительность, ему надо однозначно резать зарплату.

Все написанное выше (и в том числе выделенное) — не более чем твои домыслы.

nvb>Система же метрик предполагает, что у тебя документированы изменения параметров производительности сотрудников, но ты сам волен принимать решение, и не обязан за него отчитываться.

nvb>Поэтому, если везде в тексте заменить слово KPI на слово "метрики" — соглашусь с тобой почти во всем, кроме того, что нужно стремиться к переводу программиста в разряд легкозаменяемого винтика. Даже не буду объяснять, почему

Не надо сливать. КПИ и метрики это одно и то же.

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

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

Это неправильное определение, в расшифровке аббревиатуры нет ни единого упоминания о доходах компании.

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

На предыдущей работе у нас была следующая система

1. Программист (каждый) в начале месяца накидывал себе на месяц в Excel план задач (задача — не менее 2 часов и не более 3 дней) так, чтобы покрыть весь рабочий месяц. Задачи берутся из пула задач. Пул задач формируется менеджером совместно с тимлидом/архитектором. План выглядит как "задача" — "запланированное на задачу время". Отгулы/отпуска точно также записываются в план. Время на планирование/отчётность — тоже.
2. Программист программирует месяц. Задачи делаются, информация о потраченном времени записывается в куда угодно. Да, естественно есть много внезапных задач, они тоже делаются и инфа о них записывается в туда же.
3. В конце месяца программист делает Excel-отчёт, в виде "задача" — "запланированное на задачу время" — "потраченное время" — "скорректированное время". "Скорректированное время" присутствует только там, где потраченное время больше, чем запланированное. По идее, менеджер должен проверить каждый случай превышения времени, и если оно объективно, то скорректированное время устанавливается равным фактически потраченному. На практике это делали сами программисты, а менеджеры, если возникали сомнения, могли повлиять на это время. Неприходы на работу по уважительным причинам также считались как задачи и должны были войти в отчёт.
4. Отчёт, в конце концов, выдавал некую цифру в процентах, для негулявшего и не перерабатывающего сотрудника как правило равнявшуюся 100%. По сути, это получался процент общего рабочего времени, потраченного именно на работу. Это и был KPI.

Плюсы такой системы:

* У программистов всегда есть работа
* Программисты учатся оценивать сроки
* Народ перестаёт мыслить дедлайнами и начинает мыслить "чистым" временем
* Топ-менеджмент мог в любой момент узнать, за что данный конкретный программист получил свои деньги в предыдущем месяце (и обсудить этот вопрос с ПМ, если возникали какие-то вопросы)

Минусы:

* Слишком частые внезапные вызывают частые переключения контекста разработчиков, на что уходит довольно много времени (была идея перейти с месячного цикла на недельный, с мораторием на внезапные задачи до наступления следующей недели — не считая шоустопперов, конечно)
* Очередной менеджер попытался довести процесс до маразма, заставляя разработчиков логировать задачи продолжительностью от 5 минут и заносить всё это в Jira. В результате 60% команды единомоменто ушли из конторы.

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

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

G>Да ну? http://ru.wikipedia.org/wiki/KPI
G>

G>KPI — это инструмент измерения поставленных целей.

G> — это синоним метрик.

G>Не надо сливать. КПИ и метрики это одно и то же.

По вашей же ссылки.

KPI — это инструмент измерения поставленных целей. Если показатель, который вы придумали не связан с целью, то есть не образуется исходя из ее содержания, тогда нельзя использовать данный термин.

метрики — это показатель, который не связан ни какой целью.

К примеру, Вася пишет 300 LOC в день. — это просто метрика

A KPI,

Если Вася пишет меньше 300 LOC он бездельник и его надо депримировать
Если Вася пишет больше 500 LOC он крутой програмист, и ему надо премировать.

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

G>Да ну? http://ru.wikipedia.org/wiki/KPI
G>

G>KPI — это инструмент измерения поставленных целей.

G> — это синоним метрик.

Нет, это не так.
Вот одна из презентаций на эту тему:
http://www.slideshare.net/dennis.mortensen/the-difference-between-a-kpi-and-a-metric

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

G>>Не надо сливать. КПИ и метрики это одно и то же.

T>По вашей же ссылки.

T>KPI — это инструмент измерения поставленных целей. Если показатель, который вы придумали не связан с целью, то есть не образуется исходя из ее содержания, тогда нельзя использовать данный термин.
T>

T>метрики — это показатель, который не связан ни какой целью.

T>К примеру, Вася пишет 300 LOC в день. — это просто метрика

T>A KPI,

T>Если Вася пишет меньше 300 LOC он бездельник и его надо депримировать
T>Если Вася пишет больше 500 LOC он крутой програмист, и ему надо премировать.

Нет, Globus прав, по крайней мере, формально, я признаю. Целью не обязательно являются деньги, по определению KPI. Могут быть не менее важные показатели, например, способность программиста к коммуникации. Другое дело, что ее померить сложно — она носит качественный характер, а не количественный.

Кстати, в моем сознании коммуникабельность привязана к деньгам — если программер взял ТЗ и без единого вопроса ушел к себе, а через неделю принес никому не нужный результат — потому что не спрашивал про спорные пункты, а делал на свое усмотрение — наверно, я десять раз подумаю, прежде чем поднимать ему зарплату. И не надо мне про плохое ТЗ говорить.

А если цели нет — зачем тогда нужна метрика? Она же не с неба сваливается, ее надо собирать, интерпретировать, отвлекая ценные ресурсы.

Другое дело, что руководство, которое KPI продавливает, в 9 случаях из 10 интересуют только измеряемые, финансовые параметры. Поэтому обычно KPI в сознании большинства людей (и прошлого меня в том числе

связаны с премированием-депремированием.

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

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
	Дата:	16.09.10 16:47
	Оценка:

	От:	olegkr
	Дата:	16.09.10 18:22
	Оценка:	26 (4)

	От:	bkat
	Дата:	16.09.10 18:23
	Оценка:

	От:	BulatZiganshin
	Дата:	16.09.10 18:32
	Оценка:

	От:	_Dinosaur
	Дата:	16.09.10 18:37
	Оценка:	1 (1)

От:	Pzz	https://github.com/alexpevzner
Дата:	16.09.10 21:57
Оценка:	9 (3) +8

От:	bastrakov	http://bastrakof.livejournal.com/
Дата:	17.09.10 03:05
Оценка:

	От:	sharpcoder
	Дата:	17.09.10 03:48
	Оценка:	1 (1)

От:	Kernan	https://rsdn.ru/forum/flame.politics/
Дата:	17.09.10 15:21
Оценка:

От:	_FRED_	@ViIvanov
Дата:	21.09.10 11:18
Оценка:

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	21.09.10 11:19
Оценка:

	От:	Glоbus
	Дата:	30.09.10 07:03
	Оценка:	6 (1) -1

	От:	CreatorCray
	Дата:	30.09.10 18:11
	Оценка:	1 (1)

От:	A.Lokotkov	http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата:	20.12.10 16:33
Оценка:

От:	Valery A. Boronin	linkedin.com/in/boronin
Дата:	23.01.11 22:10
Оценка:

	От:	nvb
	Дата:	17.09.10 17:47
	Оценка:	117 (21) +4