Чем характерен неудачник или пессимист, или человек, впавший в депрессию — он все воспринимает в черном свете, неверно трактует факты, обладает искаженным мировоззрением (обычно основанном на принципе "все плохо, что-либо делать смысла не имеет", сам предложить ничего не может) и считает, что мир состоит из таких же людей как он сам.
Давайте разберем статью (автор в итоге делает вывод, что система плоха — я утверждаю, что система правильная, а вся проблема — в людях, которые ее реализуют):
...аттестации, заключавшейся в проставлении оценок в качественных категориях вроде "хорошо работает в команде" по пятибальной шкале, причём, в действительности, допустимы были только оценки 3 и 4..."
Распределение оценок: Запретить выставление только оценок 3 и 4. Оценки должны отражать работу человека (все равно начальник должен это делать, чтобы не выдавать премии случайным образом). Это должен обеспечивать менеджер. Менеджеры предоставляли предложения по премированию наверх, где они полностью игнорирвались, и в результате все получали премиальные случайного размера.
Таким образом, система не работала из-за людей, которые выдавали премии произвольным образом. Вряд ли авторы системы так бы и вписали: "проставить справделивые оценки 10 тысячам сотрудникам, а потом выдать премии, не взирая на оценку.".
Эта система никогда не принимала в расчёт тот факт, что у людей есть разные и уникальные таланты, которые необходимы для хорошей работы команды в целом...
Почему опять обвиняется система? — оценку сотруднику ставит его начальник: если он не учел уникального таланта в оценке, хотя должен был учесть, — значит надо менять начальника. Например, система может предполагать такое правило "если человек регулярно помогает другому подразделению (или члену своей команды и т.п.), его оценка увеличивается на 1 балл".
...Влияние аттестаций на настроение сотрудников несимметрично: отрицательные оценки сильно обижают людей, а положительные никак не влияют ни на настроение, ни на производительность. Те, кто их получает, и так работают хорошо. Положительная оценка намекает, что они прогибаются, чтобы получить похвалу... как собаки Павлова, работающие за подачку, а не как профессионалы, действительно заботящиеся о качестве своей работы...
Да, действительно: положительная оценка никак не сказывается на производительности, поскольку кто их получает, и так работает хорошо. Цель оценки не в этом. Цель в том, чтобы показать другим сотрудникам на кого надо ровняться, с кого брать пример в работе. Вот на что на самом деле "намекает" хорошая оценка. Цель отрицательной оценки — показать человеку, что так работать нельзя. И ничего страшного — нормальные люди делают выводы и улучшают свою работы (если же выставить хорошую оценку за плохую работу — это т.н. "абсолютная ошибка менеджера"). Если человек обиделся — значит он неадекватен и его надо увольнять (либо он должен уволиться сам). Японский и американский менеджемент (например компания Intel) подразумевает в обязательном порядке ежегодное увольнение 10% худших сотрудников — вместо них берется эквивалентное количество новых. В природе так обновляются клетки организма.
Я бы хотел задать автору вопрос: Почему в личной жизни такая система работает? Если девушка говорит молодому человеку, что "он — потрясающий", он не думает, что она относится к нему как к ребенку и ухаживает за ней только ради этой похвалы. Все понятно, что похвала воспринимается искренне. Или, если девушка говорит, что "он — плохой" (например, она говорит, что у него из рта плохо пахнет). Я думаю, что нормальный человек просто почистит зубы, или сходит к стоматологу. Автор статьи утверждает, что нормальный человек — обидится и уйдет от девушки (уволится по собственному).
Подводя итог, могу сказать, что дело не в системе — дело в людях. Все упирается в то, что важно не только СПРАВЕДЛИВО ОЦЕНИТЬ, еще важно КАК это сделать. Никакая система не может разжевать некомпетентному менеджеру как все сделать правильно (в том числе отойти от системы и сделать исключение из правила), чтобы достичь ГЛАВНУЮ ЦЕЛЬ — чтобы люди были довольны работой, и чтобы производительность была максимальна, а некомпетентные сотрудники (включая, кстати, и менеджеров) в компании не работали. Поэтому бессмыслено во всем обвинять систему. Обвинять надо конкреных исполнителей.
Здравствуйте, SergeMukhin, Вы писали:
>> СПРАВЕДЛИВО ОЦЕНИТЬ
SM>это все очень смахивает на коммунизм. Если делать правильные оценки, то все будет хорошо! Так не бывает — это идиализм.
Критиковать легко — предложите свою систему, не основанную на постоянном и регулярном оценивании труда каждого сотрудника компании. То, что все будет работать на самомотивации — это утопия для фирмы, где работает больше 30 человек.
GUI>Критиковать легко — предложите свою систему, не основанную на постоянном и регулярном оценивании труда каждого сотрудника компании. То, что все будет работать на самомотивации — это утопия для фирмы, где работает больше 30 человек.
Взвешенная система баллов. По итогам отчетного периода назначаются баллы:
-по командам проектов (всем в команде один и тот же балл). Проект уместился в бюджет и срок — 10, совершенно провален -0,
все остальное — посреди. Параметры проекта измеримы. Этот показатель поощряет хорошие команды.
-по способностям. Каждый руководитель дает оценку своим _непосредственным_ подчиненным.
(если руководитель выставляет максимальный балл подхалимам, менять нужно руководителя, а не
систему аттестации).
-по прецедентам. Дается всем, кто совершил что-то героическое, например, разработал STL
или организовал горячее питание своей команды вечером (или умудрился не работать сверхурочно, но все успел... .Вроде того, как в Гарри Поттере соревновались факультеты
Сюда же — дополнительные баллы тем, кто сдал в этом периоде серьезные сертификационные экзамены,
либо написал внутрифирменную методичку, и т.д.
-Плюс каждая команда имеет призовые баллы, которые она распределяет, извините, тайным голосованием.
Затем определяется взвешенный балл каждому. Конкретные весовые коэффициенты — личное дело каждой фирмы.
Здравствуйте, promsoft, Вы писали:
GUI>>Критиковать легко — предложите свою систему, не основанную на постоянном и регулярном оценивании труда каждого сотрудника компании. То, что все будет работать на самомотивации — это утопия для фирмы, где работает больше 30 человек.
P>Взвешенная система баллов. По итогам отчетного периода назначаются баллы:
P>-по командам проектов (всем в команде один и тот же балл). Проект уместился в бюджет и срок — 10, совершенно провален -0,
это можно сделать только после закрытия проекта, а оценки надо выставлять каждуй месяц (квартал) P>все остальное — посреди. Параметры проекта измеримы. Этот показатель поощряет хорошие команды.
все всегда говорят, что все нормально а на последней стадии выясняется, что сделано едва половина
P>-по способностям. Каждый руководитель дает оценку своим _непосредственным_ подчиненным. P>(если руководитель выставляет максимальный балл подхалимам, менять нужно руководителя, а не P>систему аттестации).
1. выше рукводителя может и не быть, он и хозяин. увольняться? чтобы только поддержать систему оценок?
2. как поменять руководителя? т.е. я долже идти к более высокому руководителю, а тот выберет сторону непосредственного и мне капец? или кто-нибудь верит в общественное мнение?
P>-по прецедентам. Дается всем, кто совершил что-то героическое, например, разработал STL P>или организовал горячее питание своей команды вечером (или умудрился не работать сверхурочно, но все успел... .Вроде того, как в Гарри Поттере соревновались факультеты
если горячее питание это подвиг программиста, то надо уборщице сразу давать 10 балов!
P>Сюда же — дополнительные баллы тем, кто сдал в этом периоде серьезные сертификационные экзамены,
это вообще под большим вопросом, нгужны ли эти экзамены и что такое серьезные?
P>либо написал внутрифирменную методичку, и т.д.
вообщем устроим ленинский зачет.
P>-Плюс каждая команда имеет призовые баллы, которые она распределяет, извините, тайным голосованием.
P>Затем определяется взвешенный балл каждому. Конкретные весовые коэффициенты — личное дело каждой фирмы.
т.е. опять приходим, что оценка — личное дело фирмы. алгоритма нет.
P>По-моему, так.
а когда работать? все время займет взвешевание, оценивание, головсование и тп и тд.
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 шаге.
Здравствуйте, GUID, Вы писали:
GUI>Чем характерен неудачник или пессимист, или человек, впавший в депрессию — он все воспринимает в черном свете, неверно трактует факты, обладает искаженным мировоззрением (обычно основанном на принципе "все плохо, что-либо делать смысла не имеет", сам предложить ничего не может) и считает, что мир состоит из таких же людей как он сам.
Это Джоел-то — пессимист и неудачник, который сам ничего предложить не может? Ну-ну. Обожаю письма, начинающиеся с развернутого наезда, который должен сразу обозначить всю крутизну автора. Дать, так сказать, понять, кто он, и кто все остальные. По большей части, конечно, кто остальные.
GUI>Давайте разберем статью (автор в итоге делает вывод, что система плоха — я утверждаю, что система правильная, а вся проблема — в людях, которые ее реализуют):
Знаете что, есть вещи, которые либо понятны человеку сразу, либо уже никакие объяснения не помогут. Эта статья Джоела как раз такая — очевидна и понятна даже ребенку.
Как вы там писали? "неверно трактует факты, обладает искаженным мировоззрением". Вот, как раз поэтому объяснения и не помогут. Вам.
Здравствуйте, promsoft, Вы писали:
SM>>если горячее питание это подвиг программиста, то надо уборщице сразу давать 10 балов! P>Организация доп.питания в конторе, где менеджер проекта — не владелец фирмы (а так чаще всего и бывает) вполне может быть подвигом
мы все еще говорим об IT? И при чем тут подвиг повара?
P>>>Сюда же — дополнительные баллы тем, кто сдал в этом периоде серьезные сертификационные экзамены, SM>>это вообще под большим вопросом, нгужны ли эти экзамены и что такое серьезные? P>См. флейм про то, нужно ли высшее образование. Сертификация бывает разная.
про ВО речи здесь нет, не надо стрелки переводить, а о сертификации по программированию? и какие Вы считаете серьезными?
P>>>либо написал внутрифирменную методичку, и т.д. SM>>вообщем устроим ленинский зачет. P>Зря глумишься. Внутрифирменная методичка — большое дело.
я просто не понимаю, чем методичка может помочь в работе программиста? Последний раз я их вмдел в советской конторе еще до перестройки.
P>>>Затем определяется взвешенный балл каждому. Конкретные весовые коэффициенты — личное дело каждой фирмы.
SM>>а когда работать? все время займет взвешевание, оценивание, головсование и тп и тд. P>Раз в квартал тайное голосование — 5 минут. Более программиста не отвлекать — остальное делается менеджментом.
SM>>т.е. опять приходим, что оценка — личное дело фирмы. алгоритма нет. P>Посылки. P>1.Программист предназначен приносить прибыль работодателю. P>Именно по тому, насколько он приносит ему прибыль, работодатель и должен его оценивать.
P>2.Прибыль он пожет приносить по-разному. Например, выдавать на гора километры кода. P>Или искать ошибки в километрах кода. Или генерировать белый шум, из которого рождаются P>идеи. Или служить психологическим буфером в команде, снижая текучесть кадров.
P>3.Поскольку фирмы разные, персонал нужно оценивать по-разному. P>То есть либо ты находишь фирму, в которой все так же, как у тебя, и пытаешься перенять их систему оценок, либо разрабатываешь свою. С точки зрения управления проектами очень немного разницы между разработкой P>системы аттестации и разработкой текстового редактора.
P>4.Проект должен иметь образ достижения и ограничения. P>Ты не сформулировал образ достижения ("хочу, чтобы все было честно и само собой"). P>Представь себе ТЗ на софт: "хочу, чтобы оно делало то, что мне надо так,к ак мне нравится".
пп с 1 по 4 общие слова.
P>Стало быть, вот тебе план проекта от сетрифицированного PM, бесплатно P>1.Определяется заказчик. В частной фирме -это владельцы, или уполномоченный ИМИ на это представитель. P>Он будет принимать работу.
P>2.Проектная группа на этом этапе может состоять из одного человека. Он готовит на утверждение,
так тут их больше одного может быть!
P>(а Заказчик утверждает) цели, ограничения,достижения и оценочные критерии проекта: P>Цели: (например) P>-увеличить ROI P>-уменьшить текучесть кадров P>Ограничения: (например) P>-срок 3 месяца, P>-N зарплаты тем, кто будет этим заниматься P>- не более 1 уволившегося с мотивировкой "не нравится система аттестации"
вот-вот, наняли одного социолога на зарплату одного уволенного программиста. Долой социологов! Работу программистам, а не методистам!
P>Достижения: (например) P>-внутрифирменная методичка по аттестации (чтобы после увольнения того, кто это разработает, все не умерло) P>-одна полная проведенная аттестация
вот оно! достижение аттестации — сама аттестация!!! тогда достижение программирование — само программирование!
P>Оценочные критерии: P>-текучесть кадров в течение ... месяцев после внедрения системы, сравнительно с ...до, P>показывает снижение текучести кадров на 5%
5% чего угодно — ошибка измерений.
P>-статистика по успешно выполненным задачам/подпроектам по подразделениям показывает, что существует P>четкая корреляция между успешностью подразделения и его средним баллом.
как в передачи "здоровье": все дети, которые посещают бассейн не болеют. Так скорее наоборот, те кто не болеет — посещают. А здесь если проект успешно закончен, мы тут же ему 10 баллов и получаем отменную корреляцию.
P>3.Далее некоторое время на системный анализ (IDEF0 в зубы, карандаш в руки, и вперед) процесса P>разработки.
ну вот, пусть пишут социологи программы, а мы методички начнем.
P> Вкупе с целой кучей полезной информации получаем список факторов, влияющих на P>текучесть кадров и результативность подразделений. P>Выкидываем из этого списка все, что не связано с личными качествами исполнителей, и P>утверждаем этот список заказчиком.
P>4.Далее для каждого элемента списка разрабатываем методику тестирования/выявления.
P>5.Выкидываем дублирующиеся/перекрывающиеся элементы и порождаем методичку по аттестации P>6.С соизволения Заказчика начинаем тестовую аттестацию части персонала, случайной выборкой. P>7.На основе полученных результатов Заказчик решает, закрыть проект по аттестации P>как бессмысленный , доработато методичку или пустить в промышленную эксплуатацию. P>8.Проводится аттестация всего персонала. P>9.Через N месяцев проект оценивается по критериям, утвержденным на 2 шаге.
P>-------------- P>Чем тебе не алгоритм
Одно из свойств алгоритма, что он должен когда-нибудь заканчиваться. Здесь этого не видно.
P>Да, кстати, а размер фирмы какой?
SM>я просто не понимаю, чем методичка может помочь в работе программиста? Последний раз я их вмдел в советской конторе еще до перестройки.
Значит, в таких конторах работал.
Coding standards, документация на процесс разработки, тестирования...
Тот же RUP, если задуматься, есть большой набор методических указаний (т.е. методичек).
CMM и ISO 900X оценивают зрелость процесса и претензии на качество по большому количеству признаков,
но все крутится вокруг двух вопросов — наличия методичек и людей, которые следят за тем, чтобы им
следовать.
В RSDN есть рекомендации по оформлению статей, правила цитирования и так далее.
Ты думаешь, эти документы с неба упали? Их люди писали. Думаешь, они не помогают в работе? ....
Министерство обороны США, министерство атомной энергетики той же страны периодически выпускают методички,
и их потом называют по цвету обложки — фразу "класс защиты C2 по Оранжевой книге" слышал когда-нибудь?
P>>Да, кстати, а размер фирмы какой?
SM>размер какой фирмы?
Извиняйте, последний вопрос был к автору топика.
Вот он же, уточненный:
Сволько прогрммистов в фирме, в которой автор топика собирается внедрять/улучшать аттестацию?
Если 10 человек, то Joel Spolsky прав — нечего тут аттестировать. У него, кстати, фирма небольшая.
Если 1000 человек, то без команды, которая будет разрабатывать систему аттестации, не обойтись.
SM>Долой социологов! Работу программистам, а не методистам
Зачем социологи? Обычная программистская задача оптимизации сложной существующей системы.
Социологи в таких вещах ничего не понимают.
Давай определимся — это ведь не "священные войны", правда? Тогда чего шумишь не по делу?
Тема для меня важная. Делал систему аттестации в предыдущей фирме, тяжело шла, полгода баги выковыривали
Сейчас дело идет потихоньку к созданию новой системы аттестации. Я немножко с другой
стороны баррикады, меня аттестуют раз в год на собрании владельцев фирмы , а я уже решаю, аттестовывать
ли остальных и как это делать. Понятно, что проблема сложная. Хочется систему аттестации,
которая бы поошряла талантливых и результативных людей.
Здравствуйте, promsoft, Вы писали:
SM>>я просто не понимаю, чем методичка может помочь в работе программиста? Последний раз я их вмдел в советской конторе еще до перестройки.
P>Значит, в таких конторах работал.
ну да, я так и сказал
P>Coding standards, документация на процесс разработки, тестирования... P>Тот же RUP, если задуматься, есть большой набор методических указаний (т.е. методичек).
P>CMM и ISO 900X оценивают зрелость процесса и претензии на качество по большому количеству признаков, P>но все крутится вокруг двух вопросов — наличия методичек и людей, которые следят за тем, чтобы им P>следовать.
P>В RSDN есть рекомендации по оформлению статей, правила цитирования и так далее. P>Ты думаешь, эти документы с неба упали? Их люди писали. Думаешь, они не помогают в работе? ....
это их работа, а не отдельная вещь за которую Вы премии хотите выдавать.
P>Министерство обороны США, министерство атомной энергетики той же страны периодически выпускают методички, P>и их потом называют по цвету обложки — фразу "класс защиты C2 по Оранжевой книге" слышал когда-нибудь?
так это и С++ стандарт можно методичкой назвать
SM>>Долой социологов! Работу программистам, а не методистам P>Зачем социологи? Обычная программистская задача оптимизации сложной существующей системы.
ну программист вообще-то программы пишет (в основном), а тут людьми управлять (оценивать и тп)
P>Социологи в таких вещах ничего не понимают.
это точно
P>Тема для меня важная. Делал систему аттестации в предыдущей фирме, тяжело шла, полгода баги выковыривали P>Сейчас дело идет потихоньку к созданию новой системы аттестации. Я немножко с другой P>стороны баррикады, меня аттестуют раз в год на собрании владельцев фирмы , а я уже решаю, аттестовывать P>ли остальных и как это делать. Понятно, что проблема сложная. Хочется систему аттестации, P>которая бы поошряла талантливых и результативных людей.
талантливые и результативные — часто разные люди. Кто сможет оценить человека, если он пишет в 100 раз больше кода (вроде хорошо), но он выполняется в 10 раз медленее (вроде плохо), но зато хорошо сопровождается (вроде хорошо) и тп. Как это понять не разбираясь в алгоритмах? в конкретных программах?
Здравствуйте, promsoft, Вы писали:
P>Извиняйте, последний вопрос был к автору топика.
P>Вот он же, уточненный: P>Сволько прогрммистов в фирме, в которой автор топика собирается внедрять/улучшать аттестацию?
P>Если 10 человек, то Joel Spolsky прав — нечего тут аттестировать. У него, кстати, фирма небольшая. P>Если 1000 человек, то без команды, которая будет разрабатывать систему аттестации, не обойтись.
Автор сказал: S> Эта напасть в основном присуща западным компаниям или только нашим? По моему глупость это полная и отличная возможность рассчитатся с неугодными. подробноси тут:
Вы уверены, что он собирается где-то внедрять аттестации?
SM>>Долой социологов! Работу программистам, а не методистам P>Зачем социологи? Обычная программистская задача оптимизации сложной существующей системы. P>Социологи в таких вещах ничего не понимают.
Вспомнилось, почему-то, как одна моя знакомая (крайне язвительная особа) как-то очень к месту сказала:
"Да я вообще не знаю предмета, в котором программисты не разбирались бы лучше всех".
P>Давай определимся — это ведь не "священные войны", правда? Тогда чего шумишь не по делу? P>Тема для меня важная. Делал систему аттестации в предыдущей фирме, тяжело шла, полгода баги выковыривали P>Сейчас дело идет потихоньку к созданию новой системы аттестации. Я немножко с другой P>стороны баррикады, меня аттестуют раз в год на собрании владельцев фирмы , а я уже решаю, аттестовывать P>ли остальных и как это делать. Понятно, что проблема сложная. Хочется систему аттестации, P>которая бы поошряла талантливых и результативных людей.
Ну, для этого система должна уметь механически и надежно отличать талантливых и результативных от всех остальных, чего ни одна система делать не умеет и не будет уметь. Это прерогатива людей, а не систем. От руководства здесь все зависит, все равно результат аттестаций при любой системе будет подгонятся под оценку руководства на всех уровнях. Аттестации — это игра в объективность.
Если у вас вменяемый менеджмент среднего звена, то система аттестаций в лучшем случае ничего не испортит. В худшем — читайте Джоела. Это не теоретические измышления скучающего Джоела, а описания очевидца.
Здравствуйте, Gaperton, Вы писали: G>"Да я вообще не знаю предмета, в котором программисты не разбирались бы лучше всех".
Ну да G>Если у вас вменяемый менеджмент среднего звена, то система аттестаций в лучшем случае ничего не испортит. В худшем — читайте Джоела. Это не теоретические измышления скучающего Джоела, а описания очевидца.
Джоела читаем, соглашаемся. Я вроде бы нигде на него не наезжал, очень уважаемый мною автор.
У Джоела, кстати, на сайте лежит их "окончательная компенсационная политика" , которая
является хорошим примером организации аттестационной работы в небольших фирмах.
SM>ну программист вообще-то программы пишет (в основном), а тут людьми управлять (оценивать и тп)
Вот, тут самое интересное — программист не хочет участвовать в разработке системы аттестации,
но предмета кроме него никто не знает. С другой стороны, всегда есть готовый
аттестовать кого угодно отдел кадров/менеджер по персоналу etc. Только он не знает,
как. Получаем систему аттестации, которая выдает мусор на выходе, ну и недовольного
программиста на сладкое.
P>>Тема для меня важная. Делал систему аттестации в предыдущей фирме, тяжело шла, полгода баги выковыривали
Там мы это делали вместе с программистами. Тема вызвала живой интерес , так как уравниловка тоже
большинству не нравится. Если есть честный и публичный критерий оценки персонала, можно предпринять какие-то
шаги и получить большую зарплату. Задача системы аттестации — поощрять изменения в нужную сторону.
Поэтому если фирме нужны сертифицированные специалисты, нужно учитывать это при аттестации,
если нет — игнорировать сертификацию. Если фирма испытывает проблемы с "командным духом", нужно
поощрять тех, кто работает дружно и весело. Если фирма испытывает проблемы с качеством продуктов,
нужно поошрять тех, у кого на километр кода ошибок меньше. И так далее.
SM>талантливые и результативные — часто разные люди. Кто сможет оценить человека, если он пишет в 100 раз сопровождается (вроде хорошо) и тп. Как это понять не разбираясь в алгоритмах? в конкретных программах?
Мы вроде не алгоритмы и программы, мы же их создателей оцениваем?
Как документировано в Библии, оцениваем дерево по плодам его.
Плоды — не код, а прибыль фирмы. И ее потенциал приносить прибыль. Нужно отследить, кто эффективнее
превращает рабочее время в готовый продукт, и поошрять его зарплатой.
Кроме того, нужно учитывать, что:
-Фирме нужна гибкость, а ее дают светлые головы.
-Фирме нужна прочность, а ее дают исполнительные "рабочие пчелки".
Трудности в том, чтобы превратить эти тезисы в систему аттестации, а не в том, чтобы разобраться
в конкретной программе/алгоритме.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, GUID, Вы писали:
GUI>>Чем характерен неудачник или пессимист, или человек, впавший в депрессию — он все воспринимает в черном свете, неверно трактует факты, обладает искаженным мировоззрением (обычно основанном на принципе "все плохо, что-либо делать смысла не имеет", сам предложить ничего не может) и считает, что мир состоит из таких же людей как он сам.
G>Это Джоел-то — пессимист и неудачник, который сам ничего предложить не может? Ну-ну. Обожаю письма, начинающиеся с развернутого наезда, который должен сразу обозначить всю крутизну автора. Дать, так сказать, понять, кто он, и кто все остальные. По большей части, конечно, кто остальные.
GUI>>Давайте разберем статью (автор в итоге делает вывод, что система плоха — я утверждаю, что система правильная, а вся проблема — в людях, которые ее реализуют):
G>Знаете что, есть вещи, которые либо понятны человеку сразу, либо уже никакие объяснения не помогут. Эта статья Джоела как раз такая — очевидна и понятна даже ребенку.
G>Как вы там писали? "неверно трактует факты, обладает искаженным мировоззрением". Вот, как раз поэтому объяснения и не помогут. Вам.
Вы же сами на следующий день разгромили Джоела: здесь
: "Ну, для этого система должна уметь механически и надежно отличать талантливых и результативных от всех остальных, чего ни одна система делать не умеет и не будет уметь. Это прерогатива людей, а не систем. От руководства здесь все зависит, все равно результат аттестаций при любой системе будет подгонятся под оценку руководства на всех уровнях. Аттестации — это игра в объективность.
Если у вас вменяемый менеджмент среднего звена, то система аттестаций в лучшем случае ничего не испортит. В худшем — читайте Джоела. Это не теоретические измышления скучающего Джоела, а описания очевидца."
Джоэл обвиняет во всем систему, а обвинять надо людей в менеджменте, как вы верно заметили. Следовательно, Джоэл заблуждается, когда описывает как была плоха система, в то время как надо описывать как были плохи конкртеные менеджеры: Вася, Петя и т.д.
Идея конечно с методичками и с обедами звучит клево, но как бы после этого контора не превратилась в лит. издание с изрядной долей снабженцев.
Я просто не совсем понимаю зачем оценивать каждый месяц работников. Само собой разумеется как сказал товарищ выще вполне логично оценивать по окончании прожекта. Тогда с довольно приличной долей объективности появится возможность оценить вклад каждого в успех. Тем более в числовом отношении. Если предплоложить, что есть нечто вроде списка обязанностей и задач каждого члена команды, содержащего расчетное время выполнения каждой задачи и фактическое время, затраченное на каждую задачу (количественная характеристика). Кроме того, есть баг-репорт по которому можно определить качество работы каждого модуля и соответсвенно определиь, асколько успешно товарищ справлялся с задачей (качественный показатель). Плюс если по каким то причинам человек отвлекался от текущего прожекта (например суппорт какого-нить старющего продукта) можно сделать скидку с определенным коэффициентом и посмотреть как это повлияет на количественный показатель(не на качественный!). И таким образом можно будет вполне объективно узнать ОТНОСИТЕЛЬНУЮ ценность работника. Но опять же повторюсь — все это возможно применить исключительно по окончании прожекта (или какой-либо его значительной части — например отдельной версии или в том духе).
В принципе не понимаю необходимости проводить аттестацию или подобную проверку сотрудников чаще чем раз в полгода а то и раз в год.
Здравствуйте, Glоbus, Вы писали:
G> Я просто не совсем понимаю зачем оценивать каждый месяц работников. Само собой разумеется как сказал товарищ выще вполне логично оценивать по окончании прожекта.
Если речь идет о сопровождении — логично оценивать каждый месяц т.к. окончание у таких "проектов" отдаленное и эфемерное. А по окончанию каждой версии-патча так это замучаться можно.
G> Тогда с довольно приличной долей объективности появится возможность оценить вклад каждого в успех. Тем более в числовом отношении. Если предплоложить, что есть нечто вроде списка обязанностей и задач каждого члена команды, содержащего расчетное время выполнения каждой задачи и фактическое время, затраченное на каждую задачу (количественная характеристика).
Опять же в случае сопровождения — необьективно это. Очень необьективно. Если расчетное время исследования проблемы/выполнения задачи оценено неверно, что вполне может быть при сопровождении, а человек постарался сделать добросовестно и потратил больше времени, его оценят хуже чем того, кто сделал тяп-ляп и этим потянул кучу других проблем.
И оценить такое может только тот кто видел код. То есть коллеги работающие с тем же кодом, лидер который этот код ревьювит.
G> Кроме того, есть баг-репорт по которому можно определить качество работы каждого модуля и соответсвенно определиь, асколько успешно товарищ справлялся с задачей (качественный показатель).
А это, только если у каждого свой кусочек в который больше никто грязными ручками не лезет. Если есть общие библиотечки которые достаточно часто меняются это совсем уж нереально.
G> В принципе не понимаю необходимости проводить аттестацию или подобную проверку сотрудников чаще чем раз в полгода а то и раз в год.
По окончанию проекта нормально, если проект длится от месяца до полугода. Меньше нет смысла, больше — расслабляет людей.
Все имхо конечно.
.Вроде того, как в Гарри Поттере соревновались факультеты 
Обожаю письма, начинающиеся с развернутого наезда, который должен сразу обозначить всю крутизну автора. Дать, так сказать, понять, кто он, и кто все остальные. По большей части, конечно, кто остальные. 
