Xpoint
   [напомнить пароль]

Как измерить программиста?

Метки: [без меток]
2004-05-10 12:11:46 [обр] Сергей Сирик(8/737)[досье]

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

  1. Измеряемость - очень желательно, чтобы можно было померять какую-то величину, а не абстрактно сказать "он/она хорошо работает".
  2. Достижимость - совсем не надо, чтоб цель была заоблачной, очень даже наоборот. Но с другой стороны она не должна быть такой уж простой.
  3. "Независимость" - желательно, чтобы критерий не сильно зависел от внешних факторов - как то ошибки проджект менеджеров в определении сроков :)

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

Вот что общественность может предложить по этому поводу?

Заранее спасибо.

спустя 2 часа 55 минут [обр] Антон Дюжев(0/4)[досье]

Критерий простой. Работа, выполненная программистами должна:

  1. Удовлетворять требованиям заказчика
  2. Укладываются в сроки

Все.

Остальное - не поддается никаким теориям и следовательно решается по каждому конкретному случаю и (самое главное) человеку отдельно.

Хинт: На проблемы нужно смотреть ширше, а с людями быть мяхше (c) "Приключения Шурика"

спустя 7 часов [обр] SHillA(0/-1)[досье]
Остальное - не поддается никаким теориям и следовательно решается по каждому конкретному случаю и (самое главное) человеку отдельно.

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

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

спустя 12 часов [обр] Николай Бубело(0/113)[досье]
Сергей Сирик[досье]
А кто должен оценивать?
Работодатель?
Заказчик?
Коллеги?
Сам программист?
В зависимости от этого критерии будут разными (существенно, возможно, даже, полярно)
спустя 1 час 32 минуты [обр] ddd(0/36)[досье]
Измеряемо можно оценить каменьщика - норматив 100 кирпичей в день.Он положил 140?Легко высчитать кофициент(полезность).А программиста измеряемо можно оценить только по количеству строчек написаного кода :).
спустя 22 минуты [обр] Денис Гетман(0/228)[досье]
 Ага. Чем меньше он строчек написал для решения задачи, тем лучше. ;-)
спустя 19 минут [обр] ddd(0/36)[досье]
Денис Гетман[досье]
Вот не повезло тем,кто на ассемблере писать будет. :)
спустя 52 минуты [обр] Sergei Erjemin (webdragon)(4/182)[досье]

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

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

Методов расставления оценок тоже более чем достаточно... для компании переполненной новаторами и индивидуалистами (а пожоже интернет-компании в 90% случаев такие) подойдет метод оценки 360-градусов.

спустя 1 час 11 минут [обр] Денис Гетман(0/228)[досье]
 Тогда задача оценки программиста выйдет на первый план. :-)
Причем сами программисты пусть и пишут программу оценки своей деятельности.
А вообще-то не представляю себе другого способа оценки деятельности программиста, кроме как его непосредственным начальником.
спустя 1 час 29 минут [обр] Сергей Сирик(8/737)[досье]

Оценивать буду в частности я, как ПМ :) Но потом надо будет показывать эту оценку руководству, и аргументировать, что это правильная оценка (в плане критериев :)

Sergei Erjemin (webdragon)[досье]
А где про этот сам метод 360 почитать мона :?) Думаю, что PMI управление мы пока не практикуем, хотя хочется наверное :) Вот с критериев и начнем практиковать :))) Спасибо.

спустя 2 часа 18 минут [обр] Владимир Палант(0/4445)[досье]
Вам, случайно, не сюда: Joel on Measurement, Joel on Incentive Pay?
спустя 1 день 5 часов [обр] Марьяна(0/305)[досье]

Не совсем понятно на что будут влиять выставленные оценки - на уровень зарплаты или на бонусы. В случае с зарплатой очень важно избегать потенциально субъективных критериев и сохранять четкие границы между уровнями. "Измеряемых" критериев, если знать специфику фирмы, должно хватать (знания определенных технологий, владение какими-то внутренними специализированными пакетами, сертификация, владение иностранными языками и т.д.) Такие вещи как продуктивность труда, дисциплинированность, коммуникабельность могут слишком сильно зависеть от личного впечатления непосредственного начальника и на зарплате (еще и в явном виде!) отражаться не должны. Лучше, чтобы между уровнями зарплат были большие зазоры - таким образом проще проводить черту между их описаниями (и соответственно, впоследствии трудно будет подвергать сомнению принадлежность конкретного девелопера к определенному уровню), плюс это дает дополнительную возможность небольшого маневра в неких узких рамках, когда излишняя демагогия только вредит.

Что касается бонусов, то их как раз и стоит выдавать за субъективные оценки. Пусть девелопер будет сколь угодно талантлив, но если он не находит способа продуктивного сотрудничества с непосредственным начальством, то фирма в целом проигрывает и лучше, чтобы девелопер об этом знал. Статейка, приведенная Володей выше, обязательный к прочтению материал, так как при первой выдаче бонусов слезы, сопли и депрессии практически непредотвратимы. Недооценивать это психологический удар по команде в самом деле не стоит. С другой стороны, поощрять счастливое неведение лентяев тоже не всегда выгодно, и разбор полетов фирме может быть полезен не только для motivating people up, но и out :]

спустя 9 часов [обр] Сергей Сирик(8/737)[досье]

Именно на зарплату, на ее систематическое повышение. Бонусы - это сейчас премии за успешно и в срок сданный проект, и тут-то как раз все более чем объективно :))

Вот щас очередной проект запущу и пойду все читать :)

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

спустя 5 дней [обр] Sergei Erjemin (webdragon)(4/182)[досье]
Сергей Сирик[досье]
360-градусов — это когда оценки каждый выставляет каждому (ну может кроме себя). Естесвено все это делается так чтобы только менеджер знал кто какие оценки поставил. Ну и т.к. он имеет еще и свое видение + конкретные цели по специалистам он начинает людей в группы так формировать чтобы "одобрямса" не получалось... Т.е. если все оценивают друг-друга ровно (т.е. ты хвалишь меня а я тебя) то он формирет группы так чтобы люди понимали что лучше оценивать по честному (т.е. если лодыря кто-то оценил хорошо, то пусть с ним в команде и работает).
спустя 1 месяц 24 дня [обр] z...(3/47)[досье]

Чуть уточнюSergei Erjemin (webdragon)[досье]'a, а то может быть не до конца понятно.

Суть методики 360, что оценки сотруднику ставят:

  1. Его подчиненные;
  2. Его "коллеги" (т.е. находящиеся на одном уровне иерархии с ним);
  3. Его руководство.

В "обычных методиках" аттестации обычно присутствует п.3, редко п.2, ну а п.1 - очень-очень редко (еще бы, ведь руководитель от своих подчиненных может СТОЛЬКО о себе узнать :) ).

спустя 2 дня 1 час [обр] Sergei Erjemin (webdragon)(4/182)[досье]

z...[досье]
Совершенно справедливо. Но все-таки п.3 это больше для аттестации (о чем уважаемый z...[досье] и сказал). Для оперативного управления (премирования, мотивирования и пр.) менеджеру п.3 не нужен (пусть этот пункт более высокое руководство волнует).

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

спустя 4 месяца 17 дней [обр] Андрей Иванов(0/3)[досье]
Где-то читал, что 90% работы может сделать 90% более-менее упорных сотрудников.
Честно говоря, с трудом представляю себе организацию, где надо строить длинную лестницу из программистов.
Солидарен с Марьяна[досье] насчёт большого разрыва между двумя ступеньками. Тогда ступенек может быть пара-тройка и заморачиваться сильно не придётся.
спустя 1 час 41 минуту [обр] Владимир Палант(0/4445)[досье]
Ну-ну... А я где-то читал, что 90% работы делает 10% сотрудников. Мои наблюдения это подтверждают (это в Германии - надеюсь, что в России положение менее катастрофичное).
спустя 53 минуты [обр] Сергей Сирик(8/737)[досье]
В общем и целом тема потеряла по ряду причин свою практическую остроту, засим определять ее теоретическую полезность и время жизни отдаю на усмотрение модератора.
спустя 1 час 7 минут [обр] Андрей Иванов(0/3)[досье]

Владимир Палант[досье]
Там же по-русски написано, что "могут".
Давайте объясню подробнее...

Вопрос в сабже: "Как измерить программиста?".
И участники обсуждения приводят в пример "удовлетворять", "укладываться в сроки", "качественно и быстро". Всё это может быть достигнуто 90% трудолюбивых и аккуратных сотрудников. Но есть 10% (по объёму!) работ, которые предыдущие 90% выполнять (в лучшем случае) будут очень долго. То есть, все эти приведённые критерии хорошо работают в случае бонусов, но не в случае повышения ЗП.
Я не вижу причины повышать ЗП сотруднику только за то, что он вовремя сдал проект. Это норма. Вот если благодаря сотруднику себестоимость проектов снижается на 20%, вот тогда да, имеет смысл повышать ему ЗП. Например, я могу работать за троих средней руки программистов потому что несмотря на то, что набирать текст они будут быстрее меня, закончим мы практически одновременно (потому что я почти всё буду писать сразу "набело" в силу моей опытности), напишу с меньшим количеством логических ошибок, работать оно будет быстрее и поддерживать мой код будет существенно дешевле.
Ведь неправильно платить мне столько же, сколько и одному из тех троих?

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

спустя 9 дней [обр] Sergei Erjemin (webdragon)(4/182)[досье]
Андрей Иванов[досье]
Премировать за "проект в срок" нужно. Просто нужно одновременно сокращать сроки проектов (т.е. если программист сдает все вовремя, то его надо премировать и возможно повышать ЗП, но при этом сокращать сроки для следующих проектов). Т.о. получам повышение ЗП за повышение производительности. Очень нормально. Особенно если производительность растет быстрее ЗП (а так и есть, т.к. первоначально сроки могут сокращаться значительно а ЗП не так значительно).
спустя 8 дней [обр] Андрей Иванов(0/3)[досье]
Sergei Erjemin (webdragon)[досье]
Премировать в срок нужно в случае, если вы закладываете часть ЗП в премию. То есть, вы, не афишируя этого, ведёте систему штрафов - хорошо сделал, получил полную ЗП, плохо сделал, недополучил часть ЗП. А если не закладываете, то о чём разговор?
Вот пример: я плачу своему сотруднику 500 долларов. Для его опыта/квалификации/среднего_уровня_ЗП_по_профессии это очень хорошо. Платить ему премию за то, что он уложился в срок, я не считаю необходимым, но за сдачу раньше срока премию, конечно, дать можно. Другое дело, что всё остаётся на своих местах, кроме ЗП - она становится 300 долларов, что является обычным или чуть ниже обычного, вот в этом случае да, за сдачу в срок надо давать премию, которая, как я выше говорил, является просто невычтенным штрафом.
спустя 4 дня [обр] ddd(0/36)[досье]
она становится 300 долларов, что является обычным или чуть ниже обычного
Мне кажется может получится так, что исходя из зарплаты на работу придется нанимать специалистов тоже "обычного или чуть ниже обычного" уровня квалификации, что для работодателя не есть хорошо.
спустя 8 дней [обр] Sergei Erjemin (webdragon)(4/182)[досье]

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

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

спустя 1 месяц 4 дня [обр] Андрей Иванов(0/3)[досье]

ddd[досье]
Я рассматривал два варианта оплаты труда. Брать один кусок одного из вариантов и сравнивать его с другим вариантом смысла не имеет. Потому что имея оклад 300 можно иметь бонусы на 3000 и это будет существенно лучше, чем просто 500.

Sergei Erjemin (webdragon)[досье]
Ну да, я примерно о том же говорю. В контексте "ЗП меньше" имеется в виду она сразу будет 300 + бонусы, а не просто уменьшится с 500 до 300.

спустя 5 дней [обр] Sergei Erjemin (webdragon)(4/182)[досье]

Андрей Иванов[досье]
Только не надо вводитьновыке системы оплаты труда сразу наскоком... Даже если людям все кучу раз объяснить и рассказать они будут настороженно относится к подобным новациям (если не враждебно). Сделайте некий переходный период. Например, несколько месяцев люди будут получать по-старому, но видеть сколько бы они получили по новой схеме оплаты... при этом надо дать возможность выбрать по какой схеме получать... И тут есть одна тонкость. Выбрать они должны ЗАРАНЕЕ. Т.е. в момент когда стало ясно, что ты получил по одной и другой схеме уже ничего изменять нельзя...

Кстати, имеет смысл сделать информацию о зарплате открытой (правда не для каждого типа организационной культуры)... Это привнесет еще один элемент мотивации и добавит дух соревновательности. Реальные суммы выплат могут быть спрятанны за некоей системой баллов. А вот стоимть балла в денежном выражении для каждого сотрудника уже может быть закрытой информацией.

спустя 6 дней [обр] Андрей Иванов(0/3)[досье]
А я и не ввожу ничего. Я предлагаю варианты оплаты =)
Будете вы вводить у себя или не будете вводить - не моё дело. Просто здесь прозвучало мнение, что штрафовать нельзя. А я говорю, что штрафовать можно. И показал как можно штрафовать. А как вы это будете вводить у себя, если будете, зависит от ситуации.
Powered by POEM™ Engine Copyright © 2002-2005