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

[fl1p]

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

В голове крутится один вариант, но он вызывает сомнения и содержит свои минусы:

Кол-во бонусов зависит от кол-ва и критичности найденных багов в единицу времени.

Штрафы тестровщик получает, если после сдачи проекта будет найден баг, который относится к какому-либо пункту спецификации (к примеру, если в спеке указано Valid CSS, а на деле он оказался невалидный). Иными словами штрафовать будут за несоответствие проекта всем предъявленным требованиям.

Минусы: каждый баг должен будет апрувится менеджером, т.к. критичность бага подтвердить может только он, а это слишком накладно для него.


Есть ли у вас какие-либо мысли по поводу доработки этой системы или же варинты других систем?

[Clauster]

Этот вариант неприменим.

[Darkus]

Бонус можно давать, к примеру, если после сдачи продукта от пользователей в течении некоторого времени N, не поступает жалоб на качество продукта (либо это такие специфичные ошибки, что их нельзя было отловить в процессе тестирования).
Также можно давать бонус за то, что в процессе тестирования выявлено много интересных ошибок, что были придуманы интересные\полезные тест-кейсы... в общем видно, что человек старается и болеет за качество продукта.
...
А штрафовать нужно за то, что он не выполняет своих прямых обязанностей . Или пишет, что мол протестировано, что всё ок, а тут же после него проходишь тест-кейсы и выясняешь, что на самом деле пропускает ошибки.
...
Считать же количество багов помноженное на их сложность за единицу времени - дело может быть и стоящее, но предположительно будет во вред, нежели в пользу. Учитывайте тогда и степень загруженности человека, его уровень знаний.. много каких факторов может влиять. Вам ведь не приходит в голову з.п. давать программисту в зависимости от того, сколько строк кода он написал. ( Вас просто порвут на британский флаг )

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

[EJik]

В голове крутится один вариант, но он вызывает сомнения и содержит свои минусы:

Кол-во бонусов зависит от кол-ва и критичности найденных багов в единицу времени.

А если в выпущенной версии программисты не сделали багов (чисто гипотетически такое же может быть ), то тестировщик не получит премии, хотя чесно выполнил свою работу?

Как вариант, можно рассматривать соотношение кол-во багов найденное отделом тестирования к кол-ву багов найденных после тестирования.

[sunlex]

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

Согласен.
Нельзя привязываться к метрике кол-во багов\их критичность\за какое время найдено и тд. Это вызовет лишь отклик человеческой хитрости:-)

Лучше разработать систему метрик оценивающих тестировщика в зависимости от его роли на проекте. Пример простейших ролей: просто тестер (тесты дизайнит, исполняет, баги ищет и тд) и лид тестер - планирует, отвечает за проект.
На тестера можно выбрать такие параметры как инициативность, английский, качество работы (здесь возможно привлечение метрики кол-во багов\их критичность\кол-во выбранных к фиксу), ответственность, communication skill и тд
На лида можно выбрать умение принимать решения, умение выставлять приоритеты, communication skill, навык планирования (включая умение пользоваться мс прожект ) и тд

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

[Skomoroh.roker]

Наш результат, как тестеров- не баги, а качественный продукт на выходе.

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

Думаю стоит подумать о количестве рекламаций от заказчика или ответственного лица на доставленные версии.

[fl1p]

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

Согласен.

Учитывайте тогда и степень загруженности человека, его уровень знаний.. много каких факторов может влиять. Вам ведь не приходит в голову з.п. давать программисту в зависимости от того, сколько строк кода он написал. ( Вас просто порвут на британский флаг )

Такие факторы как уровень знаний, степень заруженности и т.п. влияют на ЗП тестировщика. А бонусы - это грубо говоря призовы очки. Денежный эквивалент этого бонуса как раз таки и зависит от размера ЗП, т.е. от вышеперечисленных факторов. => чем выше уровень знаний, степень загруженности, производительность и старательность тестировщика, тем выше денежный эквивалент бонуса. Таким образом стоит вопрос: как посчитать кол-во этих бонусов?

[Rost]

Наш результат, как тестеров- не баги, а качественный продукт на выходе.

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

Такие факторы как уровень знаний, степень заруженности и т.п. влияют на ЗП тестировщика. А бонусы - это грубо говоря призовы очки. Денежный эквивалент этого бонуса как раз таки и зависит от размера ЗП, т.е. от вышеперечисленных факторов. => чем выше уровень знаний, степень загруженности, производительность и старательность тестировщика, тем выше денежный эквивалент бонуса. Таким образом стоит вопрос: как посчитать кол-во этих бонусов?

У меня к вам встречные вопросы, прежде чем что-то обсуждать:
1. Вы являетесь руководителем отдела тестирования?
2. Существует ли у вас практика штрафов для девелоперов за сделанные ошибки?
3. Вы видели человека который не ошибается?
4. Будут ли штрафоваться девелоперы на ряду с тестерами за найденную ошибку во время эксплуотации пользователем?

ИМХО вы взялись не с того конца.

Попробуйте положиться на мнение тест менеджера(ов). Они всегда знают кто в этом месяце отпахал, а кто был менее загружен. К тому же вы дадите им инструмент, пусть и не сильно убедительный, но в любом случае позволяющий без стеснения и разговоров с начальством обещать человеку бонусы за дополнительную работу.

[Darkus]

Таким образом стоит вопрос: как посчитать кол-во этих бонусов?

Скажу честно, у меня такой формулы нет
У нас на фирме такая система: если человек делает свою задачу вовремя, то ему даётся премия в размере 15% от оклада, если вся команда делает задачу вовремя, то командная премия - ещё 15% каждому...
Т.е. в случае успешного выполнения задачи в сроки - можно получить 30% премии.

[SALar]

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

Есть ли у вас какие-либо мысли по поводу доработки этой системы или же варинты других систем?

Да, есть. Никогда этого не делать.

PS. Сходите на тренинг по мотивации персонала.

[VLDCORP]

Внесу и свою лепту. Когда то прорабатывал такой вариант. Что из этого получилось можете оценить. Сразу скажу, что сам этим не пользуюсь. Просто не востребовано.

Может кому то будет полезно.

http://vldcorp.narod...ources/list.rar

[sunlex]

...
Может кому то будет полезно.

http://vldcorp.narod...ources/list.rar

Примерно это я имел в виду в своем посте. В моей фирме мы используем подобный набор доков-оценщиков.
Вроде работает:)

[fl1p]

У меня к вам встречные вопросы, прежде чем что-то обсуждать:
1. Вы являетесь руководителем отдела тестирования?
2. Существует ли у вас практика штрафов для девелоперов за сделанные ошибки?
3. Вы видели человека который не ошибается?
4. Будут ли штрафоваться девелоперы на ряду с тестерами за найденную ошибку во время эксплуотации пользователем?

1. Да.
2. Да. Штрафуют за сделанные ошибки и за невовремя сданные проект (1 час -1 штраф грубо говоря). Сколько штрафов начислять решает руководитель отдела.
3. Нет.
4. Только если клиент еще не заапрувил этот проект.

[Yury]

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

А зачем?
Какую проблему пытался решить начальник, давший Вам это задание?
Вы его об этом не спрашивали?

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

[van]

Согласен с предыдущим постом: какова цель введения этой бонусной системы, да и бонусов вцелом?

Если дополнение к совокупному доходу сотрудника, то сумма бонуса должна быть постоянной величиной и зависеть лишь от бюджета проекта.
Исключения:
- если человек явно забивает, то он его лишается
- если делает выдающиеся успехи, то сумма увеличивается (увеличение опять же зависит от возможностей бюджета проекта)

Если же бонус рассматривается, как мотивирующий фактор, то это не будет работать... Точнее, будет... Но только с точностью до наоборот: наличие бонуса - мотивировать не будет, а его отсутвие - будет демотивировать.
Здесь опять тоже правило - если даешь то всем (в зависимости от бюджета, опыта и знаний сотрудника), если не даешь, то никому.

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

Т.е. я все это к тому пишу, что если в компании есть такая практика - платить бонусы, то обязательно надо их платить :)
И зависеть они не в коем случае не должны от количества найденных ошибок или от количества написанных строчек кода или страниц текста :)

[Andrey_off]

В свое время в нашей конторе активно обсуждались вопросы поощрений(премии, грамоты, team buildings, переменные и постоянные составляющие ЗП и т.п. ), но прежде чем продолжить эту тему можно почитать, что думают об этом специалисты из других крупных компаний. For example: http://www.stickymin...&sopp=10&sidx=5
С удивлением обнаружил, что нашлись статьи, которые поддерживают всевозможные поощрения, а так же статьи, которые резко критикуют системы поощрений( используются аргументы типа - "Человек ждущий поощрения выполняет работу не лучше, чем инженер не ожидающий бонусов" и т.д.). Проанализировав подобные статьи становится понятно, что измерить работу одного инженера относительно другого очень сложно,особенно в тестовых подразделениях, в которых качество можно понять только анализируя данные по Escape Defect Analysis. Известно, что "дурачек" сидящий в команде гениев резко увеличивает результативность, отсюда, нельзя недооценивать таких "дурачков" лишая их поощрения. В результате в нашей организации до сих пор нет четкой системы поощрения и все возможные бонусы отдаются на усмотрение руковолителей подразделений и групп. Может это и не плохо?

[SrgK]

Как известно, тестирование, в отличие от программирования, является “невидимым” сервисом, и оценить его результаты, а тем более экономическую эффективность – задача далеко нетривиальная. А, если Вам, как тимлидеру, нужно придумать схему мотивации для своих сотрудников, то, по моему мнению, лучше сделать так, чтобы она была для них максимально удобна и выгодна. А для осуществления эффективного контроля над группой лучше использовать свои собственные лидерские качества.

[Guriy]

Мои имхо

Оценить работу тестировщика может только его непосредственный руководитель.

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

Подходить к оценке труда тестировщика на уровне человеко/дефекты или дефекто/часы категорически нельзя. Эта метрика для тех кто производит дефекты а не качественные продукты.

Оценка по конечному результату только после серьезного анализа и таймтрекинга.
Если дефект был внесен разработчиком в приложение уже после того, как эта часть приложения протестирована, и Вы накажете тестировщика, то скорее всего скоро Вам прийдется тестировать самостоятельно.

[Diogen]

[quote name='Darkus' date='Feb 1 2007, 07:56 AM']
...
А штрафовать нужно за то, что он не выполняет своих прямых обязанностей . Или пишет, что мол протестировано, что всё ок, а тут же после него проходишь тест-кейсы и выясняешь, что на самом деле пропускает ошибки.
...

Я сичтаю штрафы контерпродуктивными. Тех кто не выполняет своих обязанностей, знает об этом но ничего делать с этим не хочет или не может нужно менять на тех что хочет и может :)

Штрафы создают нездоровую атмосферу и препятствуют эффективному communication. Люди будут боятся делиться инфой которая может повлиять на их материальной состояние.

Премировать как тут правильно было сказано нужно по итогам проекта, а то и года. Это заставляет людей держать себя в тонусе и не расслабляться. Кому сколько зависит от вклада. Вклад не может быть измерен попугаями а складывается из того хорошего чтобы было замечено о человеке во время проекта минус плохое. Хороший менеджер всегда знает кто на каком месте в его команде по вкладу.

----
Best Wishes,
Vladimir

[floyder]

Что бы вы сказали по поводу следующей системы. Представим, что существует единый премиальный фонд на всю группу тестировщиков. Раз в период тим лид распределяет бюджет пропорционально вкладу каждого из участников в отчётный период. Если проекты провалены и нет причин выдавать премии, то 50% фонда можно перенести на следующий отчётный период, оставшиеся 50% придётся разделить среди коллектива.