Немного о системе оплаты труда программистов.

одобряю

В целом хорошо, но не понятно, откуда берутся оценки времени (дата завершения) и оценки качества выполнения.

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

Может быть часть задач оставлять на сдельной оплате и не учитывать их в S_t и S_m ?

> В начале методики вы упомянули про "так и аврального латания дыр в чужих проектах". Думаю в этом случае методика может оказаться плохо подходящей, например, может сложится такая ситуация, что начальство потребует "срочно, до завтра исправь этот проект", а реально исправлить получится через 2-е суток, да еще и с ошибками (так как надо было быстрее). В результате человек работал 2-ое суток и это только снизило его итоговую премию. Может быть часть задач оставлять на сдельной оплате и не учитывать их в S_t и S_m ?

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

> В целом хорошо, но не понятно, откуда берутся оценки времени (дата завершения) и оценки качества выполнения.

Это определяет менеджер проекта.

В общем-то это вместе с оценкой бюджета времени на задачу - самое уязвимое место. Всё отдано на откуп PM-мам с опорой на тестеров (естественно с возможность со стороны кодеров оспорить явно некорректные значения. Отчет о задачах доступен для ознакомления всем заинтересованным лицам в любое время.)

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

В общем, выскажу достаточно старую банальность: все эти дурацкие методики не нужны.

a) При наличии любой формальной методики есть способ "работать на зарплату", при этом с минимальными усилиями.

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

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

P.S. по поводу замечания к статье: отпускные можно высчитывать как среднюю зарплату за предыдущий некоторый промежуток времени (например, 6 мес.)

>Чувствительность бюджета времени Vt к неточностям оценки

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

>Не всегда ошибки проявляются сразу

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

>Идея выделять задачи с иммунитетом на время выполнения и качество не очень хочется, особенно если учесть, что отставание по срокам для авральных задач наиболее болезненно.

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

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

> ввести премию за экономию строк кода

Ноо, на perl.

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

Довольно ценное замечание. К тому же кроме указанных параметров у каждой задачи есть такой, как приоритет ('low','normal','high'). Получается, что в зависимости от его значения коэффициенты могут меняться.

>>ввести премию за экономию строк кода

Лучше уж премию за "читабельность" кода - а на Perle можно такую экономию провернуть ... - потом полгода будешь разбираться ...

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

Насчет "кода без багов" - это глупость ибо такого кода не бывает - лучше премию зв "быстрое исправление багов" ...

> лучше премию зв "быстрое исправление багов" ...

Угу, к релизу аккуратно добавляешь десяток-другой мелких багов, а потом быссстренько их исправляешь и едешь на Канары :)

фигня если честно.

> фигня если честно.

Фигня сама мысль о какой-то возможности загнать всё в цифру или реализация кривовата?

Сама мысль.

>Фигня сама мысль о какой-то возможности загнать всё в цифру

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

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

ИМХО феерическая хуйня.

Почитай книжку "Искусство пасти котов" и вообще литературу по менеджменту и управлению персоналом.

> "Искусство пасти котов"

В русском переводе: Дж. Ханк Рейнвотер, "Как пасти котов: наставление для программистов, руководящих другими программистами" (J. Hank Rainwater, "Herding Cats: A Primer for Programmers Who Lead Programmers").

>В нормальном коллективе все про всех знают, кто на что способен, от кого насколько что зависит в проекте и т.п., поэтому зарплату можно исчислять чисто субъективно.


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

> сама идея фигня, труд программистов, разработчиков трудно оценивать - тут большая степень недетерминированности

Ну спорить не стану. Поставить под такой контроль программистов идея не самая хорошая.

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

2Sun-ch: благодарю, с сим литературным произведением знаком :-).

Глупости, тем самым вы породите нездоровую конкуренцию. Пока люди будут биться за бонусы ваш проект провалиться. Потому, что люди не будут единым целым.

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

Ато все по митингам шатаются, от одной пьянки с партнерами до другой. Улыбаются, произносят дежурные мантры: "эффективность", "управляемость", "риск-менеджмент", "даунсайзинг", "кост-эффектив"... А в чем состоит труд программиста банально не знают и не хотят узнавать. И цена их мнению 0 рублей 0 копеек.

http://citforum.ru/SE/project/antipatterns/

http://local.joelonsoftware.com/mediawiki/index.php/%D0%9C%D0%B5%D1%82%D0%BE%...

>Но когда вы предлагаете людям деньги за то, что они сами хотят делать, они, так или иначе, страдают от так называемого Эффекта Подмены Мотивации. "Я, наверное, пишу безглючный код, потому что мне платят за это премию", - думают они, и внешняя мотивация вытесняет внутреннюю. Поскольку внешняя мотивация действует гораздо слабее, то получается, что вы на самом деле снизили желание людей делать свою работу хорошо. Если вы прекратите платить людям премию, или они решат, что им не так уж нужны деньги, то они перестанут думать, что хотят писать безглючный код.

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

> уступая место нормальным рыночным отношениям.

А это и есть нормальные рыночные отношения. Чисто субъективно две стороны (работник и работодатель) договорились и без доп. сложностей. Когда какую-то из сторон взаимоотношения устраивать перестали, договор разрывается. Нафига формальности?

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

Спасибо, текст интересный.

>Лучше уж премию за "читабельность" кода

Это труднее объективно оценивать. Разве что по времени исправления "багов" - но это зависит от многих факторов, типа квалификации исправляющего, которые, возможно, ещё сложнее оценить.

>тем самым вы породите нездоровую конкуренцию ... Потому, что люди не будут единым целым

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

У нас в инсте народ в дипломах рассчитывает зарплату пропорционально кол-ву написанных строк. Вроде достаточно объективно. =)

Пишите на ассемблере.