Предпосылки к написанию статьи: см. http://www.proza.ru/2014/10/11/1498
Постараюсь изложить свои мысли в виде тезисов, без лишней "воды".
Научный подход к стимулированию труда инженерно-технических работников, на мой взгляд, основывается на следующих принципах:
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% от не зависящей от индивидуальных результатов работы суммы вознаграждения работника за период выполнения работы по проекту (априорно - из предположения полного отсутствия ошибок и соответствия ТЗ). По результатам опытной эксплуатации выявляются ошибки, которые понижают указанную сумму.
"Половинный" размер коэффициента при исправлении ошибок, на мой взгляд, справедлив: не будет стимула нарочно допускать ошибки в процессе разработки, а с другой стороны, будет стимул исправлять ошибки в срок.
02.11.2008