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

В общем-то как я обсуждал - решается тендерами. Хотя согласен, что проблема не самая большая.

>”дешевле - не значит лучше”

У каждой задачи, должны быть четкие критерии приемки. В том числе
- Прохождение тестов
- Написание юниттестов
- Review кода с кем-то и т.п.
В таком случае, будет минимальный уровень приемлемого качества.

“Чисто технический, казалось бы, момент с конкретизацией финрасчетов. Даже три момента.”

Ответ - автоматизация. На самом деле конкретной зарплаты не выплачиваются. Сделал задачу и ее приняли, получил оговоренную сумму.

Да, это поднапряжет сначала. Но на самом деле, это напряжет только в нужную сторону, человек почувствует связь между деланием и получением. Сейчас связь очень слабенькая.

>3.”Каждый сам за себя”

Да, тут все будет злее чем сейчас.
Из приведеного примера - когда запорол переговорщик. Так вот, если он запорол - его и надо по идеи наказывать. А то сейчас получается, что наказываются все (и вот это вызывает гораздо больше злости, чем когда наказывается виновный).

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

Так, что в целом я согласен - схема злая. Особенно она будет злая для тех, кто
а) Ничего не делал и получал зарплату
б) Занимался всякой херней, вместо своих обязанностей
в) Частенько ошибался и его ошибки расхлебывали все хором

Просто уже очень много людей подпадают под категорию а), б) и в). Причем и программистов и менеджеров и топ менеджеров. Естественно им прийдется не сладко в таком случае.

А вот реальных проблемы мне видится три.
1.Старо, как мир - “дешевле - не значит лучше”. Вася взялся реализовать задачу за $100 и два дня, выиграв “тендер” у Пети, предлагавшего сделать тоже самое за $300 и неделю. Все супер - но - что если руководитель на основании знания своих кадров допускает, что реализация Пети будет намного более качественна?

2.Чисто технический, казалось бы, момент с конкретизацией финрасчетов. Даже три момента.
2.1.Это “обычную” зарплату, даже почасовую, сможет начислить простая расчетчица Люба. А чтобы задокументировать все эти “тендеры” - потребуются уже гораздо более серьезные средства. В частности, дополнительные штатные единицы, разработка специальных регламентов - чтобы все было по-серьезному и поддавалось контролю.
2.2.Врач должен лечить, кухарка - готовить, программист - программировать. Если вместо того, чтобы готовить обед посетителям, повар в ресторане займется подсчетом своей зарплаты - “сколько я получу за бифштекс, сколько за полпорции ухи” и т.д. - настанет бардак. Ему попросту будет некогда к плите подходить. А предложенная технология предлагает программистам как раз таки заниматься не своими прямыми обязанностями, а подсчетами экономики своей деятельности.

3.”Каждый сам за себя”
С внедрением предложенного подхода может выяснится две прелюбопытнейших вещи.
3.1.Не секрет, что кроме сладких конфеток бывает еще и черная работа. На которую невозможно предложить “интересные условия”. Если у руководителя нет возможности распорядиться - “так, Серега, берешь вот эту задачу и решаешь” - то либо задача вообще не будет решена, либо придется бегать за Серегой и его заинтересовывать. Обычный подход, когда сегодня Серега занимается черной работой, а завтра ему это компенсируют более интересным (в любом смысле) заданием здесь не прокатит. Простейший пример - исправить косяк в закрытом проекте, который вел уволившийся специалист. Да, это не Серегин косяк, казалось бы - надо ему заплатить. Но с другой стороны - Серега работает в команде, а не подвизается фрилансером, что накладывает свои обязательства.
3.2.То же самое, но в чуть более широком смысле. Неправильно думать, что если программа написана очень хорошо, но из-за недоработок… ну, скажем, переговорщиков с заказчиком проект запорот - то программист не при чем, и заплатите ему сполна. Это если бы он был внештатным аутсорсником - тогда да. А до тех пор, пока мы все в одной лодке - подход “проект-то завален, но лично я-то все сделал нормально, заплатите премию” некорректен, т.к. приводит к спихиванию вины на товарищей и фактическому оставлению командира один на один с проектом (режим “я прокукарекал, а там хоть не рассветай”).

Трудозатраты считаются легко.

Однако размер задачи не равен размеру кода или -”дефект денсити”.
Собственно говоря, в это и утыкается…

Для электрика посчитать размер задачи “установка розетки” - реально. Для программиста нету типовой задачи а-ля “установка розетки).

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

Индифидуальность кода вычислется из настроек SVN’а ( иже с ними).

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

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

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

Если интересно, могу скинуть учебник как эти точки считать.
Так же рекомндую Стива Макконнелла “Сколько стоит проект”, а так же его бесплатную программу Construx Estimate, собственно в ней и делал оценки.