Оценка эффективности работы программиста

[IMB]

Уважаемые, а может ли кто-нибудь поделится методикой оценки эффективности работы программиста?
Думаю во многих организациях, которые занимаются разработками есть система премировния сотрудников по результатам сдачи этапов проекта или проекта целиком. Так как думается ради одной зарплаты люди работать не будуть или она должна быть существенно более высокой, чем выплачивается.
Рассмотрим конкретный случай, я выполняю фунции embedded программиста, т.е. выполняю весь спектр работ от модификации/написания драйверов, до сборки системы со всем необходимым софтом и подготовкой системы для производства. Не будем говорить, что, наверное, это не совсем правильно. Сейчас от нас руковдство просит предоставить некие коэффициенты для оценки трудоёмкости проделанной работы которые потом будут учитыватся при расчёте времени на проект и премии.
Понятно, что код который я пишу сам можно оценить в количестве строк, размере файлов и т.д., т.е. выразить некими реальными параметрами. Да, наверное это не всегда верно, но будем считать, что программисты не будут скатываться до "индийского" кода. Но тут возникает вопрос, как оценить работу по интеграции готово продукта в проект. Скажем недавно я запускал на нашей плате 3G от Мегафона и WiMax. Не тайна, что вся последовательность сводится, как правило, к классической триаде - configure && make && make install. Но в одном случае всё этим и решается, а в другом, надо проделать всё это для десятка зависимостей и написать некое количество программной обвязки, такой как управляющие скрипты. И это ещё без учёта возможных правок в исходном коде. Проще говоря, уже труднее привязать проделанную работу к некому реальному параметру.
Понятно, что можно свести всю оценку к виду готово или нет в срок. Но тогда возникает большая вероятность, что трудные, но перспективные проекты могут никогда и не начаться, так как существует вероятность того, что программист во время не успеет, скажем в силу новизну применяемой технологии.
В таком ключе можно ещё очень долго и пространно рассуждать и я с удовольствием выслушаю ваши соображения по данному вопросу, но давайте вернёмся к нашим баранам.
Может ли кто-нибудь поделится методикой оценки эффективности работы программиста? Или если не кокретной методикой, хотя я с удовольствием взгляну на цифровое выражение данного вопроса, а опытом применяемым на вашем месте работы или в проекте.
Спасибо.

[Crazy]

Ответа на такие вопросы как бы должна давать дисциплина Метрология программного обеспечения.
К примеру это http://www.viva64.com/ru/a/0045/
Хотя к некоторым метрикам я отношусь скептически.

[azsx]

К примеру это http://www.viva64.com/ru/a/0045/

статью пролистал - она мне не понравилась.

а может ли кто-нибудь поделится методикой оценки эффективности работы программиста?

взгляните с точки зрения работодателя. Мы имеем в штате работников, которые занимаются не пойми чем и в итоге только дают (или не дают) результат своей работы. Может быть, за воротами стоит специалист, который будет работать в три раза быстрее, а может быть нам надо молится на наших специалистов. Так как мы работы этой не понимаем - это гадания.
По хорошему нам нужен постоянный психолог - который лучший друг всех, к примеру на должности ОК. Этот психолог и скажет нам доволен как слон наш работник или давно и активно ищет работу. Также было бы прекрасно, если на 10 программистов мы бы имели одного начальника, который понимает кто и чем занимается, а также осознает сложность решаемых задач. Тогда вопрос о премиях будет снят, правда если начальник и психолог будут честны и объективны (что бывает не всегда).
Премия распределённая не пойми как может обидеть людей (тем кто целый месяц пахал, а премию не получил). Я встречаю очень много увольнений, именно не из-за мелкой оплаты, а недовольством на руководство. Стоит ли экономия вашей премии уволенных программистов?
Вывод: в очень крупных компаниях пойдут и всякие метрики, типа как в статье. Там все крутятся в жерновах системы, к метрикам все приспособятся, трудоголики будут работать вне зависимости от формы начисления оплаты... На средних и небольших фирмах разумнее распределять всю премию на отдел, иногда умножая ее на понятный всем и относительно стабильный для каждого работника - коэффициент. Коэф. можно привязать к языкам на которых кодит программист или к стажу. Премия может идти от прибыли.
зы
скромно замечу - это просто один из вариантов преиминования. Часто складываются такие ситуации, когда с фирмы увольняются все ключевые работники. Малейшие ошибки (допустим в вашей фирме предлодженный способ распредения примий будет фиговым) - и вы пойдете обивать пороги агенств по трудоустройству

[IMB]

К примеру это http://www.viva64.com/ru/a/0045/

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

По хорошему нам нужен постоянный психолог - который лучший друг всех, к примеру на должности ОК. Этот психолог и скажет нам доволен как слон наш работник или давно и активно ищет работу. Также было бы прекрасно, если на 10 программистов мы бы имели одного начальника, который понимает кто и чем занимается, а также осознает сложность решаемых задач. Тогда вопрос о премиях будет снят, правда если начальник и психолог будут честны и объективны (что бывает не всегда).
Премия распределённая не пойми как может обидеть людей (тем кто целый месяц пахал, а премию не получил). Я встречаю очень много увольнений, именно не из-за мелкой оплаты, а недовольством на руководство. Стоит ли экономия вашей премии уволенных программистов?

По-видимому я не совсем чётко выразился, я являюсь как раз представителем прогаммистов, а не руководства. А так как у нас есть некое несогласие с позицией руководства, то, для ведения предметного разговора, оно нас попросило подготовить конкретные предложения и в частности некие коеффициенты для расчёта премиальных.
Описанный Вами случай идеален, а потому не достижим. Руководство в принципе не может, да наверное и не должно, знать всех тонкостей проделанной работы, пускай лучше у него болит голова о закупке комплектующих, печате плат и других организационных вопросах. Другая причина недостижимости - достаточно быстрая смена технологий и требований. Если пару лет назад под наши задачи хватало четырёхслойной платы со стандартными элементами, то сейчас уже делаются шестислойные платы с BGA и PLIS.

[IMB]

Премия может идти от прибыли.

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

[Crazy]

К примеру это http://www.viva64.com/ru/a/0045/

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

Тут придется нагуглить и полистать источники, что бы можно было ими оперировать.
Вручную считать ничего не придется http://www.google.com/custom?hl=ru&cli...0%3Atsq8didf9x0

Потом расскажешь как их применил.

[BIgAndy]

Уважаемые, а может ли кто-нибудь поделится методикой оценки эффективности работы программиста?

Спасибо.

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

[Crazy]

Если у вас на предприятии ведется нормирование делятельности, то очень просто, перевыполнили план - вам премия.

В том то и дело, нет никакого плана, что бы его перевыполнить.
К примеру когда пишется ПО на заказ, то остаток бюджета делится и распределяется как премия.

[drBatty]

Может ли кто-нибудь поделится методикой оценки эффективности работы программиста?

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

[azsx]

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

+1. Потому платить надо не за... (какие бы умные схемы там не предлагали), а для того, чтобы работник был доволен своей оплатой! И относится к работнику так, чтобы он был доволен отношением к себе. Платить за надо предпринимателю со стороны, а работник в офисе на зп - это другое...

Описанный Вами случай идеален, а потому не достижим.

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

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

Не совсем согласен с вами. Вы путаете логистику и экономистов (добавлю, технических директоров) с руководством. Другой вопрос, что начальникам подчас так нравится распределять бюджет. Особенно, если кроме этой функции и росписей не глядя - никакой иной работы руководитель не выполняет

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

Согласен на все 100% - вы не должны. Но руководство, которое не может заставить работать коллектив как одну команду, пора бы уже того... Это именно в вашем примере.
зы
задача руководителя - это не разобраться, что такое бга или плис. Задача руководителя вдохновить вас разобраться в этом; убедится, что вы работаете; убедится, что рабочий процесс не нарушается нигде из-за лени работников; проверять, чтобы не предвиденные обстоятельства не влияли на рабочий процесс; смотреть, чтобы умных новеньких - съедали, а старенькие не бежали и т.п.

[Denjs]

старая печня о главном)))

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

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

Первое можно оценить с помощтью "метрик кода", и не только.
Есть тот-же FPA который не метрики кода исследует, а считает "сложность проекта". (FPA вообще работает с требованиями и описанием изменений в системе. никаких дибильных SLOC. Потому что описать в SLOC изменение структуры БД - это слишком за уши привязано)).
Как вы будете натягивать сложность проекта на эффективность работы програмиста - ваше дело.(FPA - это метод оценки трудоемкости, хотя если его сделать постфактум, и сравнить с другими метриками - то можно что то посчитать) В трудоемкость она ересчитывается с помошью производительности, которую надо рассчитать на основании уже сделанных проектов.

А второе (внедрение, анализ, проектирование) - это "просто" работы, которые оценивать с помощь "метрик кода" - весьма странно.

И ВАЖНО: (вбейтеэто в головы ваших менеджеров) : метрики кода, можно сранивать только ваши собственные: ваши текущие - с вашими старыми. т.е. нельзя сравнивать "между группами", работающии над разнми проектами.
Проекты и систем - слишком разные.


Нормирования и прочее ? во первых это не делается "просто так", а во вторых - это все за уши притянуто...

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

________________

Сейчас от нас руковдство просит предоставить некие коэффициенты для оценки трудоёмкости проделанной работы которые потом будут учитыватся при расчёте времени на проект и премии.

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

Тот же показатель какой метрики - он в некотором смысле "дибилен" сам по себе. это просто цифра. смысл этой цифры можно понять только в контексте и деталях того, как она считалась.. Полагаться на ту-же "производительность баллов сложности в час" посчитанную постфактум - проблемно. А сколько раз в ходе разработки менялись требования? FPA вам посчитает только сложность перехода от исходного сотсояния к конечному варианту - т.е. фактически - "кратчайшее/прямое расстояние" между исходным состоянием и конечным. но премировать-то вас должны за работу - "за проделанный путь". Если вы переделывали код 3 раза, 3 раа меняли направление движение - потому как требования менялись - то что делать?

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