Сообщений в теме: 6

[XXX]

Всем привет!

Поставлена задача разработать схему премирования сотрудников отдела тестирования по срезам месяц\квартал\год. Может у кого-то уже есть подобные схемы?)Или кто может подсказать на тему оценки тестировщиков?

[lives_mobile]

Есть два подхода:

• индивидуальный
• общий

 

В первом случае, каждому рассчитывается премия индивидуально.

Во втором:

• устанавливается одинаковый  % от оклада . Но поскольку ЗП у всех отличается, размер премии будет тоже отличаться. 
• есть сумма, которую делим на всех членов команды
• ...

 

Рассмотрим один из подходов к первому варианту. 

Премия=вклад в проект%+переработки%

 

Т.е. к примеру предположим, что максимальная премия будет 50% от годового оклада.

Эти 50% складываются из 30% вклада в проект + 20%переработок.

Иванов:

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

- на проект пришел два месяца назад, поэтому особого вклада не вносит

= 5 + 0 = 5%

 

Сидоров:

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

- главный тестировщик на проекте. эксперт по продукту. кроме своих непосредственных задач, помогает еще и другим.

= 10 + 25 = 35%

[Сергей]

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

Я бы вот что предложил:

1. отдел небольшой, организация без особой бюрократии - подход общий

2. бюрократия, аутсорсеры и т.п. - подход индивидуальный: забываете о тестировании, вводите метрики, грейды, время работы, строите графики и оцениваете людей (гуль в помощь)

[SALar]

Если качество или производительность труда программиста можно повысить с помощью материального стимулирования, то этого программиста следует уволить.

 

 

 

(с) Андрей Орлов "Записки автоматизатора"

 

Подпишусь под каждым словом. 

Ну и еще, это третья "смертельная болезнь" по Демингу.

 

KPI - самый надежный из всех известных мне способов убить производственный поток. 

 

Цитата: Леонид от 12 Октября 2015, 13:17:47

"Когда я слышу слово KPI, рука тянется к предохранителю браунинга" почти (с). 

 

Не. Тут нужен ТОС-1 «Буратино» https://ru.wikipedia.../Буратино_(РСЗО)

 

И еще обсуждение KPI: http://www.uml2.ru/f...hp?topic=6440.0

[Tishka]

На текущий момент наблюдаю применение kpi на  разработчиках.

Выглядит это весьма плачевно, так как далеко не всегда можно оценить эффективность, потому, что:

- часто бывают ситуации что время на выполнение задачи тратится больше времени(не по вине разработчика), что сбивает статистику разработчику

- бывают случаи неправильно поставленного времени на задачу

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

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

- бывают исключительные ситуации когда был выбран тим-лидом неправильный стек технологий для проекта, в результате чего kpi разработчиков этого проекта занижается

 

К чему были приведены эти пункты?

Да к тому, что если в такие ситуации попадает разработчик, то перед ним 2 выхода:

- работать за бесплатно

- делать быстрее и молится чтобы тестировщик не кинул ему баги на исправление по выполненной задаче.

 

В первом случае это обидно разработчику. Во втором -  страдает качество проекта.

В результате мы имеем такую ситуацию:

Все вложились по временным рамкам, у всех чудесный kpi, но вот проект говно.

 

И когда такое "чудо" попадает в руки тестировщика, то зачастую(личный опыт) это просто ужас.

И первой мыслью бывает: "А не втащить разрабу промеж глаз?"

Но если поразмыслить, то он не виноват, что его загнали в рамки метрики.

 

Те кто задаются вопросом оценки эффективности тестировщиков, задумайтесь:

"Вы действительно хотите попробовать этот хаос на себе?"

 

ИМХО kpi может быть полезен, исключительно как второстепенный/вспомогательный инструмент.

P.S. Все выше приведенные аргументы основаны исключительно на наблюдении.

[SALar]

- бывают случаи неправильно поставленного времени на задачу

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

 

 

Не бывает правильного времени на задачу. http://blog.shumoos.com/archives/303 и http://blog.shumoos.com/archives/304

 

Если программист закончит раньше, он просто не должен об этом сообщать. И еще он всегда должен затягивать время, чтобы нормы были больше и был "запас". Об этом прекрасно написал Голдратт в "критической цепи". Сам факт наличия оценки увеличивает время проекта в 1.5 - 2 раза.

 

 

 

ИМХО kpi может быть полезен, исключительно как второстепенный/вспомогательный инструмент.

 

Не может. "Хочешь избавиться от конкурента - внедри у него kpi "

[Little_CJIOH]

В ЦРТ пару лет назад внедряли систему оценки эффективности тестирования и разработки в целом.

Если есть оттуда кто - поделитесь результатом.