Для минимизации субъективизма при выставлении оценок и напряженности взаимоотношений между сотрудниками и администрацией,
которая может возникать вследствие ошибочного оценивания, выработана описанная в этом документе система правил
Мне она говорит только о том, что начальство не хочет по человечьи
работать с подчененными и всю отвественность за принятие решений
перекладывает на формулу.
Любая "объективная" формула по определению будет фальшива.
От субъективизма при оценке человеческой работы никуда не деться,
да и не нужно стремиться полностью от этого избавляться.
Мы все люди и этим все сказано.
Нельзя ставить зарплату в такую прямую зависимость от таких оценок.
Штрафы вообще, на мой взгляд, только деморализуют и совершенно
не способствуют повышению мотивации.
Работник, пока он на фирме, должен быть счастлив и доволен,
каким бы он балбесом не был.
Вместо того, чтобы понижать зарплату или штрафовать,
его надо просто увольнять, если пара внушений не привела к результату.
Вообще зарплата должна быть фиксированной.
Периодически ее стоит пересматривать (скажем раз в полгода — год).
За особые заслуги надо премировать.
Но штрафовать — ни в коем случае.
P.S. Такие жуткие формулы оценки работников я встречал только в российских конторах.
Это что, особенность российской ментальности, довести все до такого абсурда?
Думаю даже педантичные немцы до такого бы не додумались.
Re: Обсудим положение об оценке работы разработчиков ПО?
Как мне кажется — нужна простая схема бонусов (без штрафов) которая позволила бы сотруднику гарантированно добавить некоторую сумму к зарплате при выполнении её пунктов...
А там каждый нелентяй себя покажет!.. и фирма при этом только выиграет.
ИМХО, плохо когда вводятся штрафы за опоздание при бонусах за овертайм... Хуже правда было бы если бы бонусы за присутствующий овертайм вообще отсуствовали...
Re: Обсудим положение об оценке работы разработчиков ПО?
Во первых спасибо за информацию.. способ расчета действительно интересный..
Но хотелось бы "придраться" и задать несколько вопросов:
vav1. Вопрос выполнения задания в срок (параметр TL), вообще говоря, строится на весьма субъективной оценке сроков выполнения.
Введение градаций этого параметра, должно, наверно, привести к злоупотреблению им — заказчику выгодно занизить сроки, разработчику завысить.
Не кажется ли 10ти-бальная шкала слишком широкой?
попробую предположить как это должно использоваться:
успел [существенно] раньше (вообще говоря, риски были переоценены, никто не виноват.) — 0 или 1
в срок — (0)
все-таки не успел (ни на что не повлияло, но осадок остался) — 0 или -1
существенно не успел (недооценены риски, но почему бы не отыграться на всех?) — -1 или -2
что делать с остальными баллами?
Задача с (оценочной) трудоемкостью неделя завершена за 4 дня. Сколько баллов за нее? а если 2, 10?
Возможно есть примеры, демонстрирующие систему оценивания, на все 10 баллов?
vav2. Вопрос о "нормальном и достаточном уровне документирования" (параметр Doc).
Едины ли правила оценивания или индивидуальны? Есть ли эффект "привыкания" (когда требования к качеству документации растет за мастерством работника)?
Учитывая то, что обсуждаемый документ предназначен для широкого круга лиц, как бы Вы оценили его "уровень документирования"?
vav3. Нет ли терминологической неточности (двусмысленности), в определении параметра G?
Нарушением графика работ мы называем опоздания и ранние уходы с работы. "Графиком работ" можно называть и план выполнения заданий...
Может, например, "нарушение распорядка дня" лучше отражает суть параметра?
И, учитывая то, что у нас уже есть параметр, со схожим применением (в параметре D учитывается "..самовольное отсутствие на работе, создавшее проблемы и неудобства.."), не является ли это "двойным наказанием" (опоздал на 35 мин и не присутсвовал на важном совещании)?
Так как документ представлен как полный, то существенные причины, приводящие к G++ не рассматриваются?
vav4. Что мы будем делать с нашим несовершенным календарем? Как считать IM_месяца в месяцах, отличных от февраля?
vav5. Выражение N как дни*9 означает 9ти часовой рабочий день, что обедать сотрудник обязан в компании или что-то другое?
vav6. Что является спецификой документа для оценки именно _разработчиков_ПО_, а не допустим, производства визитных карточек?
Re[2]: Обсудим положение об оценке работы разработчиков ПО?
B>Для минимизации субъективизма при выставлении оценок и напряженности взаимоотношений между сотрудниками и администрацией,
B>которая может возникать вследствие ошибочного оценивания, выработана описанная в этом документе система правил
B>Мне она говорит только о том, что начальство не хочет по человечьи B>работать с подчененными и всю отвественность за принятие решений B>перекладывает на формулу. B>Любая "объективная" формула по определению будет фальшива.
Тем более что коэффициенты в этой формуле будут весьма субъективны
Re[3]: Обсудим положение об оценке работы разработчиков ПО?
Здравствуйте, Vadimio, Вы писали:
B>>Любая "объективная" формула по определению будет фальшива.
V>Тем более что коэффициенты в этой формуле будут весьма субъективны
Точно.
Зато применение формулы с субъективными коэффициентами дает ощущение объективности.
В общем, это размывание и уход от ответственности со стороны менеджмента.
Re: Обсудим положение об оценке работы разработчиков ПО?
Мое мнение: ребята, не страдайте х...й. Невозможно формально оценить усилия, прилагаемые работником.
В качестве альтернативы могу предолжить следующую схему: на каждый отдел при выдаче зп назначается премия.
Если отдел отработал нормально — ее размер стандартный. Отдел _сильно_ подвел фирму — премия уменьшается вплоть до ее лишения. Отдел отработал хорошо — премия на отдел увеличивается.
А дальше уже дело отдела (работников или начальнкиа) как премию делить.
Опционально указанием начальства премия увеличивается конкретному работнику за особые заслуги.
... << Rsdn@Home 1.1.4 beta 1 >>
Re: Обсудим положение об оценке работы разработчиков ПО?
Много было сказано про объективность субъективной формулы, основанной на ещё более субъективных коэффициентцах.
Ответьте лучше на вопрос — ЗАЧЕМ? Чего именно вы хотите добиться таким образом?
И лучший ли это способ добиться желаемого?
Re: Обсудим положение об оценке работы разработчиков ПО?
Дассс... уехал из Н-ска 5 лет назад, а менеджемнт там как был нулевой так нулевым и остался...
The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell (c)
Re: Обсудим положение об оценке работы разработчиков ПО?
Первая реакция:
На 100% согласен с kittown. На%%%ть хотят
Конструктив:
1.
N — месячная норма рабочего времени, выражается в часах (количество рабочих дней *9)
А я, глупый, думал, что рабочий день у нас — 8 часов. Противоречит нормам ТК.
2.
При увольнении сотрудника выплачивается компенсация за неиспользованный отпуск в размере 1/11 от оклада за каждый проработанный без отпуска месяц.
Противоречит нормам ТК.
3.
В случае болезни сотрудника
LW<1, за время пропуска по болезни выплачивается комренсация в размере 60% от оклада пропроционально отношению времени пропуска к N. На руки выдается сумма расчётной з/п и компенсации за время пропуска по болезни.
Противоречит нормам ТК.
4. Вся формула в целом противоречит нормам ТК, кстати. Вот если б премия так вычислялась (при фиксированном базовом окладе) — то пожалста! А так — нонсенс.
4. В формуле 13 параметров!!!!! ТРИНАДЦАТЬ!! Это трындец, дорогая редакция. Я думаю, что результаты этой формулы будут удивительны не только для программеров, но и для манагеров. Контроль над 13 параметрами — это ж практически невозможно.
5. Резюме: НАХ!
Re: Обсудим положение об оценке работы разработчиков ПО?
Просто мое личное мнение:
Есть моя зарплата, о которой мы с вами договариваемся при моем устройстве к вам на работу.
Если вы по каким-либо причинам вдруг начинаете считать, что я должен получить денег меньше -- мы с вами расстаемся. Либо по вашей инициативе, либо по моей.
Другими словами, моя зарплата -- это МИНИМУМ о котором мы с вами договаривались. Ее можно только повышать.
Абсолютно правильно было сказано про бонусы и про штрафы, опять же из личного опыта, бонусы стимулируют, штрафы озлобляют.
Re[2]: Обсудим положение об оценке работы разработчиков ПО?
Здравствуйте, Nikolaus, Вы писали:
N>Здравствуйте, SW-soft, Вы писали:
SS>>Положение об оценке работы разработчиков программного обеспечения
N>Мое мнение: ребята, не страдайте х...й. Невозможно формально оценить усилия, прилагаемые работником. N>В качестве альтернативы могу предолжить следующую схему: на каждый отдел при выдаче зп назначается премия. N>Если отдел отработал нормально — ее размер стандартный. Отдел _сильно_ подвел фирму — премия уменьшается вплоть до ее лишения. Отдел отработал хорошо — премия на отдел увеличивается. N>А дальше уже дело отдела (работников или начальнкиа) как премию делить. N>Опционально указанием начальства премия увеличивается конкретному работнику за особые заслуги.
Угу — программирование это командная игра — на отдел такая штука будет работать, а на отдельных программистов точно нет(вне зависимости от формул, поэтому я исходный документ даже читать заленился)
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re: Обсудим положение об оценке работы разработчиков ПО?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
