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

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

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

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


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

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

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

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

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

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

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

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

Проблема в этом подходе именно в этом. Штрафовать вообще нельзя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И это тоже.

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

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

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

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

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

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

Сколько сделано по-плану/сверх того — отличный показатель эффективности. Прочее — ради фона с невысоким весовым коэффициентом учитывать очень даже можно так же.

M>Если кто-то сталкивался с этим или у вас внедрена система оценки по KPI для программистов — поделитесь, пожалуйста, информацией.

На прежни работах пытались. Выливалось всё [на мой строгий взгляд] в исключительно измерение того, на сколько своевременно предоставлен еженедельный отчёт

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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