Возможно, я не совсем ясно выразился, но на мой взгляд, оценка труда консультанта должна быть следствием принятого в вашей компании технологии разработки(изготовления). Т.е. одно от другого не отделимы.
Maksimus написал:
Один хороший консультант Вася мало работал, но сдружился с Главбухом Заказчика Валей
А где гарантия, что он не сдружится с Вами? К тому же дружба это не главное и порой это даже хорошо, потому что такие люди лучше понимают друг друга. Совсем другое, что дружба может повлиять на выполнение работы с отрицательным результатом, вот здесь как раз и нужно подумать руководителю проекта, как организовать работу так чтобы это было не выгодно Главбуху.
Maksimus написал:
2. Проектом нужно управлять, а следовательно понимать как, куда, зачем он движется; что/кто тормозит проект, почему это происходит; что нужно изменить чтобы ускорить внедрение и т.д. (о какой "удовлетворенности" буем говорить здесь?);
Работа пойдет гораздо быстрее и продуктивнее, если это понимать будете не только вы, но и заказчик, об этом говорится (если не ошибаюсь) в одной из лекции по процессу внедрения SAP. Важно, чтобы заказчик чувствовал свою значимость и участие в проекте, если этого нет, то значит заказчику не нужно все что вы делаете.
(Примечание: под заказчиком я понимаю не только Директора, но и того человека, который будет использовать ПО)
Maksimus написал:
А программист Петя написал прекрасную сложную программу, которую Вася не удосужился как следует потестить и сдать Заказчику в этом месяце. Следовательно, Васе надо заплатить хорошую ЗП, а Пете плохую.
А кто решал, что Петя написал прекрасную сложную программу? И как Вы оценили, что Вася ее не удосужился как следует потестить? А что значит "как следует"? Значит ли это что Вася должен был запустить ее 10 раз? А может быть это Петя написал плохую программу и теперь делает виноватым Васю?
Это все очень субъективно. Но... спрашивается, а почему вы решили, что Вася решил "подставить" Петю, ведь они оба работают на "результат", и если работа не будет выполнена, то неполучит ни Вася, ни Петя свою з/п.
Maksimus написал:
5. Лояльность к предприятию - если консультант/программист выполняет план (без срыва) и не задерживается - все молодцы, лояльность в норме; если консультант/программист не выполняет план (срывает сроки), не задерживается - он не заинтересован в результате; если консультант/программист не выполняет план (срывает сроки), но старается успеть за счет выходных, переработок или пересмотра плана работ - заинтересован => лоялен.
Возможно я не прав. Но лояльность - это как весы, где с одной стороны амбиции консультанта/разработчика (или проще говоря, его представления о его возможностях), а с другой стороны это оценка его способностей руководителем проекта. Если вы можете удержать это в равновесии, то сотрудник будет лоялен, если нет, то его лояльность очень быстро исчезнет.
Таким образом получается, что нужно задумываться не о системе оценки, а об организации взаимодействия в команде и с заказчиком. Я не стал рассматривать все пункты, но думаю и так понятен ход мыслей. Возможно я не прав, но я считаю, что нужно думать сначала о процессе разработки/сопровождения/консультирования/внедрения, а система оценки появится сама собой.