Постараюсь изложить свои мысли кратко, без лишней "воды".

Научный подход к стимулированию труда инженерно-технических работников основывается на следующих принципах:

1. Объективность - должны быть определены объективные критерии оценки результатов труда.
2. Результативность (или эффективность) - в случае недостаточной отдачи от стимулирования критерии и степень вознаграждения следует пересматривать.
3. Справедливость - при определении критериев необходимо учитывать принципы социальной справедливости.

Цели грамотно проведённого стимулирования:

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

Как известно, стимулирование труда базируется на "трёх китах":

1. Материальное стимулирование (денежные суммы, ценные подарки);
2. Моральное стимулирование (благодарственные письма и грамоты, объявление победителей соревнования в торжественной обстановке, доска почёта и т.п);
3. Продвижение работника вверх по карьерной лестнице.

Применительно к ИТР (инженеры-конструкторы, инженеры-технологи, инженеры-программисты) рационально использовать, к примеру, следующие критерии оценки результатов труда (эти критерии должны быть официально сообщены всем участникам соревнования и не должны допускать неоднозначных трактовок):

1. Количественные показатели работы.
2. Качественные показатели работы, приведённые к количественным экспертным оценкам.

ОЦЕНКА ПО ЭТАПАМ РАБОТЫ

Существуют следующие стадии процесса разработки изделий (программного обеспечения):

1. НИР
2. ОКР

Рассмотрим ОКР.
Стадии:

1. Построение концептуальной модели системы
2. Построение логической модели системы (конструкторской документации)
3. Разработка алгоритмов (технологических процессов и операций)
4. Кодирование (изготовление опытного образца)
5. Отладка
6. Испытания опытного образца (альфа- и бета- версии)
7. Ввод в промышленную эксплуатацию

Для примера рассмотрим пункт 2.

Для разработчика {ПО+БД} этот пункт, как правило, включает разработку ER-схемы функционирования одной или нескольких подсистем предприятия. Выражаясь более конкретно, это структурная схема базы данных (БД).
В данном случае не играет роли, создана ли эта схема изначально либо получена в результате применения операции Reverse Engineering ("обратная разработка") к уже созданным метаданным БД.

Полученная схема тестируется на предмет соответствия следующим критериям:

1. Экспертные оценки для определения полноты отражения предметной области.
2. Степень унификации (например, использование доменов или повторяющихся фрагментов кода в ХП и триггерах);
3. Степень нормализации реляционной структуры ("золотая середина", зависит от конкретной группы сущностей предметной области);
4. Количество и качество комментариев
5. Приемлемая скорость выполнения типовых запросов (типовые запросы - фрагменты будущих отчётов).

Как видим, для определения ряда характеристик необходимо привлечение независимых экспертов, что не всегда возможно.

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

ОЦЕНКА ПО РЕЗУЛЬТАТАМ ЭКСПЛУАТАЦИИ

Основные принципы:

1. Регулярно собирается информация о выявленных ошибках и неточностях, несоответствии ТЗ в ходе работы изделия.
2. Вся информация делится на несколько групп:
А. Пожелания
Б. Мелкие ошибки, не приводящие к сбоям системы либо неправильным результатам обработки данных
В. Ошибки, приводящие к неправильным результатам обработки данных
Г. Ошибки, приводящие к сбоям в работе системы.

Каждой ошибке присваивается свой "понижающий коэффициент" (-xi). При исправлении ошибки в срок прибавляется этот же коэффициент, но с обратным знаком и вдвое меньший (+0,5xi). За несвоевременно исправленные ошибки ничего не прибавляется.
Предположим, за переданную в опытную эксплуатацию работу была начислена дополнительная премия в размере 100% от не зависящей от индивидуальных результатов работы суммы вознаграждения работника за период выполнения работы по проекту (априорно - из предположения полного отсутствия ошибок и соответствия ТЗ). По результатам опытной эксплуатации выявляются ошибки, которые понижают указанную сумму.
"Половинный" размер коэффициента при исправлении ошибок, на мой взгляд, справедлив: не будет стимула нарочно допускать ошибки в процессе разработки, а с другой стороны, будет стимул исправлять ошибки в срок.