может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей?
используются ли эти показатели для подсчета успешности команда/проекта/конторы?
Здравствуйте, daisywheel, Вы писали:
D>может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей? D>используются ли эти показатели для подсчета успешности команда/проекта/конторы?
Мы используем собственно придуманные коэффициенты (скорее всего, кто-то это придумывал до нас):
— коэффициент исполнения плановых сроков. Считается от планового срока по задаче (согласовывается вместе с исполнителем) и его фактической протяженностью в часах
— коэффициент поддержки закрытой задачи — отношение времени, потраченного на задачу ко времени, потраченному на ее саппорт в дальнейшем. Фактически, отображает качество решения задач программистом.
Идеи, вероятно, не новы и можно придумать что-то еще, но это: "автомат Калашникова": простой и надежный способ, чтобы на цифрах без субъективщины показать, кто как работает.
S>- коэффициент поддержки закрытой задачи — отношение времени, потраченного на задачу ко времени, потраченному на ее саппорт в дальнейшем. Фактически, отображает качество решения задач программистом.
А почему это не коэффициент грамотности постановки задачи архитектором? Или грамотность составления требований самим заказчиком?
По-моему не совсем правильно такой коэффициент завязывать только на программиста.
Здравствуйте, Nikolay_Ch, Вы писали:
S>>- коэффициент поддержки закрытой задачи — отношение времени, потраченного на задачу ко времени, потраченному на ее саппорт в дальнейшем. Фактически, отображает качество решения задач программистом. N_C>А почему это не коэффициент грамотности постановки задачи архитектором? Или грамотность составления требований самим заказчиком? N_C>По-моему не совсем правильно такой коэффициент завязывать только на программиста.
надо же начинать с малого. сначала простые оценки для девелоперов и тестеров, потом введем зависимости от качества работы постановщика заданий
интересны подходы в других компаниях к оценке своей работы как отдельных людей так и команд и компании в целом.
N_C>>По-моему не совсем правильно такой коэффициент завязывать только на программиста. D>надо же начинать с малого. сначала простые оценки для девелоперов и тестеров, потом введем зависимости от качества работы постановщика заданий
Хм... Просто я думаю, что пока Вы дойдете до верха, программисты устанут отдуваться за ошибки других.
По-моему логичнее было-бы идти сверху вниз (по уменьшению ответственности).
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>>>По-моему не совсем правильно такой коэффициент завязывать только на программиста. D>>надо же начинать с малого. сначала простые оценки для девелоперов и тестеров, потом введем зависимости от качества работы постановщика заданий N_C>Хм... Просто я думаю, что пока Вы дойдете до верха, программисты устанут отдуваться за ошибки других. N_C>По-моему логичнее было-бы идти сверху вниз (по уменьшению ответственности).
статистика. с группы разработчиков можно получить статистику и сравнить данные между учасниками. одного "начальника" оценивать надо по другим критериям.
D>статистика. с группы разработчиков можно получить статистику и сравнить данные между учасниками. одного "начальника" оценивать надо по другим критериям.
Да нет, я не об этом...
Я говорю о том, что если эффективность разработчика оценивать только по критерию — "Сколько пришлось переделывать потом", никак не оценивая труд других перцев, то разработчик быстро может потерять энтузиазм — т.к. далеко не всегда количество переделок в будущем связано лишь только с его личным трудом.
Здравствуйте, daisywheel, Вы писали:
D>Приветствую!
D>может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей? D>используются ли эти показатели для подсчета успешности команда/проекта/конторы?
D>ссылки на умные книжки по теме приветствуются
D>спасибо.
Производительность в нашем нелегком деле измерена быть не может.
Кто скажет как ее измерить — пусть первый бросит в меня камень.-)
Как написано в одной книге Коуберна, единственное, что есть только одно измерение, которое работает: счастье пользователя.-))
Но поможет ли это вам во время разработки — большой вопрос.
Неплохо высказался на эту тему Robert Austin, чья цитата взята в статью Martin Fowler "The New Methodology".
---------------------------------------------------
Introducing measured management without good measures leads to its own problems. Robert Austin made an excellent discussion of this. He points out that when measuring performance you have to get all the important factors under measurement. Anything that's missing has the inevitable result that the doers will alter what they do to produce the best measures, even if that clearly reduces the true effectiveness of what they do. This measurement dysfunction is the Achilles heel of measurement-based management.
---------------------------------------------------
Но идея KPI в нашей области меня также волнует. Я пришел к выводу, что производительность это не поможет измерить, но вот сделать KPI как часть Employee Development and Contribution Process — вполне. Например, для юниоров получение сертификата по Java от Сана — чем не индикатор его роста? Условный рост от юниора к сеньору — чем не рост. Не просто так ведь введены грейды в больших лавках. Английский все знают? Нет! Значит пусть учат — тоже индикатор. Можно создать внутренний университет, где учить сотрудников. Там будут экзамены — достижимость определенных результатов также в отдельный индикатор. И раз в полгода(год) делать подсчет слонов, говорить о повышении зп, спрашивать о том, чего он хочет, как организация может помочь и т.д.
Но я не встречал IT компаний, где все это делают. Но всегда кто-то становится первым.-)
Здравствуйте, Live Wire, Вы писали:
LW>Но идея KPI в нашей области меня также волнует. Я пришел к выводу, что производительность это не поможет измерить, но вот сделать KPI как часть Employee Development and Contribution Process — вполне. Например, для юниоров получение сертификата по Java от Сана — чем не индикатор его роста? Условный рост от юниора к сеньору — чем не рост. Не просто так ведь введены грейды в больших лавках. Английский все знают? Нет! Значит пусть учат — тоже индикатор. Можно создать внутренний университет, где учить сотрудников. Там будут экзамены — достижимость определенных результатов также в отдельный индикатор. И раз в полгода(год) делать подсчет слонов, говорить о повышении зп, спрашивать о том, чего он хочет, как организация может помочь и т.д. LW>Но я не встречал IT компаний, где все это делают. Но всегда кто-то становится первым.-)
по-моему в IBS есть и грейды и чтобы переползти нужно что-то осваивать и т.п. ... т.е. "расти над собой". Интересно узнать насколько это эффективно работает у них.
Здравствуйте, Nikolay_Ch, Вы писали:
D>>статистика. с группы разработчиков можно получить статистику и сравнить данные между учасниками. одного "начальника" оценивать надо по другим критериям. N_C>Да нет, я не об этом... N_C>Я говорю о том, что если эффективность разработчика оценивать только по критерию — "Сколько пришлось переделывать потом", никак не оценивая труд других перцев, то разработчик быстро может потерять энтузиазм — т.к. далеко не всегда количество переделок в будущем связано лишь только с его личным трудом.
Почему? Если требования не меняются, а разработчик тратит время на устранение ошибок?
Здравствуйте, daisywheel, Вы писали:
D>может кто-то поделиться индикаторами производительности разработчика, которые используются в Вашей команде/конторе? Как рассчитывается производительность людей?
Нельзя ввести KPI для разработчиков, чтобы он так или иначе не повредил делу. Для многих специальностей возможно, для разработчиков — пока не получилось ни у кого. Для любого KPI можно привести пример пары сотрудников, один из которых объективно полезнее другого, а KPI у них различаются в обратную сторону. Кроме того, практика показывает, что при введении любого KPI программисты относительно быстро учатся его максимизировать во вред делу.
Здравствуйте, softilium, Вы писали:
S>- коэффициент исполнения плановых сроков. Считается от планового срока по задаче (согласовывается вместе с исполнителем) и его фактической протяженностью в часах
Здорово. Исполнитель штрафуется за появление непредвиденных проблем, обнаружающихся в ходе решения задачи, и поощряется за "надежные" по времени решения в духе затыкания дыр. Таким образом, разработчики, работающие над простыми и низкорисковаными задачами, легко поддающимися предсказанию сроков, будут в среднем иметь лучший показатель. Гут. Также этим показателем поощряется супернадежный перезаклад по срокам, с выносом мозга начальству на тему "как это сложно", и сопровождающим его пинанием балды в расслабленном режиме. Хороший показатель .
S>- коэффициент поддержки закрытой задачи — отношение времени, потраченного на задачу ко времени, потраченному на ее саппорт в дальнейшем. Фактически, отображает качество решения задач программистом.
Угу. Чем более критичен компонент, над которым работает программист, чем больше у этого компонента пользователей, репортящих баги, чем активнее он развивается, и чем сложнее у него логика — тем больше дадим ему по башке данным показателем. Показатель поощряет избегание наиболее полезной для пользователя и рискованной работы. Хорошо.
S>Идеи, вероятно, не новы и можно придумать что-то еще, но это: "автомат Калашникова": простой и надежный способ, чтобы на цифрах без субъективщины показать, кто как работает.
И никакой субъективщины, сразу видно, кто как работает. Как, гхм, автомат Калашникова. Какая зловещая и точная аналогия.
B>Почему? Если требования не меняются, а разработчик тратит время на устранение ошибок?
Потому, что это практически синтетика. Во-первых, чтобы не менялись требования, во-вторых, чтобы шло постоянное исправление ошибок в каком-то участке кода. В-третьих опять-же никто не смотрит из-за чего плодятся ошибки...
На моей практике, или меняются требования, тогда процент ошибок постоянен, или, если требования не меняются, то после всплеска количества ошибок, через некоторое время происходит спад, который уже учитывать просто незачем т.к. он уже не отражает ничего. Также, если не учитывать косяки архитектора, из-за которого и случаются самые страшные проблемы (я имею ввиду, что ошибки архитектора стоят дороже, чем разработчика), то будут огребать по башке совсем не те люди, которые должны.
Здравствуйте, Nikolay_Ch, Вы писали:
B>>Почему? Если требования не меняются, а разработчик тратит время на устранение ошибок? N_C>Потому, что это практически синтетика. Во-первых, чтобы не менялись требования, во-вторых, чтобы шло постоянное исправление ошибок в каком-то участке кода. В-третьих опять-же никто не смотрит из-за чего плодятся ошибки...
N_C>На моей практике, или меняются требования, тогда процент ошибок постоянен, или, если требования не меняются, то после всплеска количества ошибок, через некоторое время происходит спад, который уже учитывать просто незачем т.к. он уже не отражает ничего. Также, если не учитывать косяки архитектора, из-за которого и случаются самые страшные проблемы (я имею ввиду, что ошибки архитектора стоят дороже, чем разработчика), то будут огребать по башке совсем не те люди, которые должны.
По-моему, внедрение KPI для программистов — ритуальная жертва, приносимая их непосредственным начальником руководству компании, которое считает, что программисты сидят и целыми днями валяют дурака. Внедри KPI у себя в подразделении — и от тебя на полгода отвяжутся.
Почему на внедрение KPI иногда охотно идут сами руководители программистов? Потому что видят среди своих людей паршивую овцу и, стесняясь подойти и разобраться в причинах, либо просто уволить на фиг, начинают играть в справедливость.
Любые KPI обходится разработчиками элементарно. Как правильно говорил Спольски, люди очень изобретательны в поиске локальных максимумов. И все дыры заткнуть никому и никогда не удастся. Все, что можно получить в результате тотального внедрения — либо массовый уход программистов, либо снижение их толерантности к риску.
Мне однажды пришлось наблюдать апофеоз последнего варианта — я описал бизнес-процесс выполнения задач разработчиков в одной известной компании: любая задача из плана в Project проходила 12 шагов (в минимальном случае, максимум — 16) с подписью ответственного на бумаге по завершении каждого шага. Все хватались за голову при взгляде на эту схему, но признавали, что при существующем KPI по-другому нельзя — иначе виноватого найти будет нельзя и без месячной премии останутся все причастные, включая невиновных. Угадайте, как там обстояло дело со сроками? Правильно, люди предпочитали не рисковать и закладывались в оценках с большим запасом. И всем было хорошо, включая директора — вот в этом месяце этот без премии остался, а в прошлом — те двое, деньги экономим
Как говорится, если хочешь жить лучше — надо больше зарабатывать, а не меньше тратить. Увы, про это часто забывают.
Здравствуйте, nvb, Вы писали:
nvb>Мне однажды пришлось наблюдать апофеоз последнего варианта — я описал бизнес-процесс выполнения задач разработчиков в одной известной компании: любая задача из плана в Project проходила 12 шагов (в минимальном случае, максимум — 16) с подписью ответственного на бумаге по завершении каждого шага. Все хватались за голову при взгляде на эту схему, но признавали, что при существующем KPI по-другому нельзя — иначе виноватого найти будет нельзя и без месячной премии останутся все причастные, включая невиновных. Угадайте, как там обстояло дело со сроками? Правильно, люди предпочитали не рисковать и закладывались в оценках с большим запасом. И всем было хорошо, включая директора — вот в этом месяце этот без премии остался, а в прошлом — те двое, деньги экономим
nvb>Как говорится, если хочешь жить лучше — надо больше зарабатывать, а не меньше тратить. Увы, про это часто забывают.
А по-моему, лучше просто свалить нах из такой компании, где начальство занято только поисками крайних, и впредь стараться выявлять подобные случаи и обходить их за километр (для надёжности)...
Здравствуйте, Gaperton, Вы писали:
G>Нельзя ввести KPI для разработчиков, чтобы он так или иначе не повредил делу. Для многих специальностей возможно, для разработчиков — пока не получилось ни у кого. Для любого KPI можно привести пример пары сотрудников, один из которых объективно полезнее другого, а KPI у них различаются в обратную сторону. Кроме того, практика показывает, что при введении любого KPI программисты относительно быстро учатся его максимизировать во вред делу.
Работа у нас такая — надо максимизировать зарплату при минимизации телодвижений Такая вот жизненная задачка на оптимизацию
Такая вот жизненная задачка на оптимизацию 
