понедельник, 20 сентября 2010 г.

[prog.work] Интересная дискуссия о KPI для программистов

На RSDN в прошлый четверг завели интересную тему: KPI для программистов. Не знаю, во что она превратиться со временем, но пока я рекомендую её к прочтению – там и сообщений не много, и по теме все. В особенности следует обратить внимание на сообщения пользователя nvb (раз, два, три).

Меня самого интересует все, что связано с KPI (т.е. key perfomance indicator) для программистов. Поскольку у начальства некоторое время назад возникло желание ввести какие-то формальные критерии оценки работы сотрудников. Сам я к таким идеям отношусь крайне негативно. Посему, собственно, некоторое время назад и возникла тема про хитрожопых программистов. Имхо, любая формальная система оценок, навязанная разработчикам, станет целью их усилий. Т.е. люди вместо того, чтобы сосредоточиться на выпуске программного продукта, будут заниматься подгонкой формальных показателей. Говорю об этом со всей ответственностью, поскольку лично я бы этим занимался.

Ну да ладно, вернемся к упомянутому обсуждению на RSDN. Что в нем еще важно? А важно количество советов “ищи новую работу”. Советов от программистов. Имхо, это очень показательно. Данную тему нужно показывать том-менеджерам, которым моча в голову у которых появилась идея оценивать разработчиков софта так же, как и сборщиков на конвейере. С комментарием: “Хотите разогнать своих программистов? Тогда вы на верном пути!”

13 комментариев:

имя комментирует...

единственная видимая мне реальная точка приложения KPI -- это оценка работы самых младших программистов, *при условии*, что задание им полностью устно разжевывается старшими (какие будут классы, какие скользкие моменты не пропустить), думать им не надо (а надо ТОЛЬКО писать код и тесты, содержание которых тоже разжевано) и их отвлечения от проекта фиксируются

имя комментирует...

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

имя комментирует...

при этом, очевидно, догадываться -- это очень важная работа (если не сказать самая важная), ведь не догадавшись (как в том примере с лицензией) и даже отмазавшись от заказчика текстом договора, все равно получим недовольного заказчика

eao197 комментирует...

По сути, все так и есть. Парадокс в том, что чем выше занимаемая должность у человека, тем хуже он это понимает.

Ну и про junior-ов... Имхо, критерий оценки у них может, например, такой: выкатили им N замечаний по коду с объяснением претензий и дается время на исправление. Затем замеряется, сколько из этих N было исправлено.

Но даже это уже ненужные формальности. И так же субъективные. Поскольку один и тот же junior с одним наставником может хорошо работать, а с другим -- быть вообще по нулям. Тут уже психология обоих индивидумов играть начнет.

имя комментирует...

тут не согласен

исправлять им придется то, что вызвало затруднения, значит это не столь однородная вещь, чтобы ее оценивать численно

а вот считать че-нить типа functional complexity на разжеванном коде, который можно писать не приходя в сознание :-) это более похоже

имя комментирует...

а насчет психологии и совместимости -- полностью согласен

но мне все-таки кажется полезной идея рассчитывать объем работы юниоров в каких-то метриках, без денежно-организационных выводов, просто для информации и анализа самих метрик

имя комментирует...

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

так что малоглючащий libastral -- неотъемлемый интструмент опытного программиста :-)

eao197 комментирует...

@имя

>но мне все-таки кажется полезной идея рассчитывать объем работы юниоров в каких-то метриках, без денежно-организационных выводов, просто для информации и анализа самих метрик

Все еще будучи программистом (да и большим раздолбаем по жизни) мне вообще не нравится идея расчитывать какие-то метрики.

Здесь вообще наблюдается столкновение интересов. Менеджеры хотят предсказуемости и прозрачности. Программисты не могут обеспечить ни того, ни другого. Лично у меня эта неспособность вызывает когнитивный диссонанс ;) -- начинаю чувствовать себя никчемным работником, не оправдывающим ожидания начальства. Временами только вродженный+приобретенный пофигизм спасают от углубленного копания в себе.

имя комментирует...

> Все еще будучи программистом (да и большим раздолбаем по жизни) мне вообще не нравится идея расчитывать какие-то метрики.

Короче, они тебя потеряли.

Я тоже раздолбай, но когда мне хочется че-то достичь, меня начинают интересовать метрики типа "а насколько я продвинулся к цели".

имя комментирует...

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

я бы это попытался до них довести

eao197 комментирует...

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

Отличная аналогия! :up:

Unknown комментирует...

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

Я руковожу программистами и знаю как это непросто. Но я уверен, что "неоценивать" работу разработчиков нельзя. Должны быть критерии.

eao197 комментирует...

@Alexander:

Надеюсь, что достаточно подробно ответил здесь: http://eao197.blogspot.com/2011/04/progwork-kpi.html