SM>ну программист вообще-то программы пишет (в основном), а тут людьми управлять (оценивать и тп)

Вот, тут самое интересное — программист не хочет участвовать в разработке системы аттестации,
но предмета кроме него никто не знает. С другой стороны, всегда есть готовый
аттестовать кого угодно отдел кадров/менеджер по персоналу etc. Только он не знает,
как. Получаем систему аттестации, которая выдает мусор на выходе, ну и недовольного
программиста на сладкое.

P>>Тема для меня важная. Делал систему аттестации в предыдущей фирме, тяжело шла, полгода баги выковыривали
Там мы это делали вместе с программистами. Тема вызвала живой интерес , так как уравниловка тоже
большинству не нравится. Если есть честный и публичный критерий оценки персонала, можно предпринять какие-то
шаги и получить большую зарплату. Задача системы аттестации — поощрять изменения в нужную сторону.
Поэтому если фирме нужны сертифицированные специалисты, нужно учитывать это при аттестации,
если нет — игнорировать сертификацию. Если фирма испытывает проблемы с "командным духом", нужно
поощрять тех, кто работает дружно и весело. Если фирма испытывает проблемы с качеством продуктов,
нужно поошрять тех, у кого на километр кода ошибок меньше. И так далее.

SM>талантливые и результативные — часто разные люди. Кто сможет оценить человека, если он пишет в 100 раз сопровождается (вроде хорошо) и тп. Как это понять не разбираясь в алгоритмах? в конкретных программах?

Мы вроде не алгоритмы и программы, мы же их создателей оцениваем?

Как документировано в Библии, оцениваем дерево по плодам его.
Плоды — не код, а прибыль фирмы. И ее потенциал приносить прибыль. Нужно отследить, кто эффективнее
превращает рабочее время в готовый продукт, и поошрять его зарплатой.

Кроме того, нужно учитывать, что:
-Фирме нужна гибкость, а ее дают светлые головы.
-Фирме нужна прочность, а ее дают исполнительные "рабочие пчелки".

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