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

P>>-по способностям. Каждый руководитель дает оценку своим _непосредственным_ подчиненным.
P>>(если руководитель выставляет максимальный балл подхалимам, менять нужно руководителя, а не
P>>систему аттестации).

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

SM>если горячее питание это подвиг программиста, то надо уборщице сразу давать 10 балов!
Организация доп.питания в конторе, где менеджер проекта — не владелец фирмы (а так чаще всего и бывает) вполне может быть подвигом

P>>Сюда же — дополнительные баллы тем, кто сдал в этом периоде серьезные сертификационные экзамены,
SM>это вообще под большим вопросом, нгужны ли эти экзамены и что такое серьезные?
См. флейм про то, нужно ли высшее образование. Сертификация бывает разная.

P>>либо написал внутрифирменную методичку, и т.д.
SM>вообщем устроим ленинский зачет.
Зря глумишься. Внутрифирменная методичка — большое дело.

P>>-Плюс каждая команда имеет призовые баллы, которые она распределяет, извините, тайным голосованием.

P>>Затем определяется взвешенный балл каждому. Конкретные весовые коэффициенты — личное дело каждой фирмы.

SM>а когда работать? все время займет взвешевание, оценивание, головсование и тп и тд.
Раз в квартал тайное голосование — 5 минут. Более программиста не отвлекать — остальное делается менеджментом.

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

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

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

4.Проект должен иметь образ достижения и ограничения.
Ты не сформулировал образ достижения ("хочу, чтобы все было честно и само собой").
Представь себе ТЗ на софт: "хочу, чтобы оно делало то, что мне надо так,к ак мне нравится".

Стало быть, вот тебе план проекта от сетрифицированного PM, бесплатно
1.Определяется заказчик. В частной фирме -это владельцы, или уполномоченный ИМИ на это представитель.
Он будет принимать работу.

2.Проектная группа на этом этапе может состоять из одного человека. Он готовит на утверждение,
(а Заказчик утверждает) цели, ограничения,достижения и оценочные критерии проекта:
Цели: (например)
-увеличить ROI
-уменьшить текучесть кадров
Ограничения: (например)
-срок 3 месяца,
-N зарплаты тем, кто будет этим заниматься
— не более 1 уволившегося с мотивировкой "не нравится система аттестации"

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

Оценочные критерии:
-текучесть кадров в течение ... месяцев после внедрения системы, сравнительно с ...до,
показывает снижение текучести кадров на 5%

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

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

4.Далее для каждого элемента списка разрабатываем методику тестирования/выявления.

5.Выкидываем дублирующиеся/перекрывающиеся элементы и порождаем методичку по аттестации
6.С соизволения Заказчика начинаем тестовую аттестацию части персонала, случайной выборкой.
7.На основе полученных результатов Заказчик решает, закрыть проект по аттестации
как бессмысленный , доработато методичку или пустить в промышленную эксплуатацию.
8.Проводится аттестация всего персонала.
9.Через N месяцев проект оценивается по критериям, утвержденным на 2 шаге.

--------------
Чем тебе не алгоритм

Да, кстати, а размер фирмы какой?