Как оценивать и одновременно мотивировать группу тест-дизайна?!

Встаёт вопрос о разработке схемы оценки работы группы тест-дизайна и расчёте на основе оценки заработной платы!

Эта схема должна также мотивировать сотрудников работать качественно (расплывчатое понятие, но всё же) и эффективно...

Подскажи у кого есть какие-то наработки в этом направлении.

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

Эта схема должна также мотивировать сотрудников работать качественно (расплывчатое понятие, но всё же) и эффективно...

Не будет работать. Дэн Пинк о мотивации.
И где-то есть перевод.

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

Это не мотивация называется.

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

Это не мотивация называется.

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

Про мотивацию могу сказать только одно - ничто так лучше не мотивирует, как деньги :)

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

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

потому, что остальные группы уже работают по определённым схемам....

Неплохой вариант проверки - дать тест дизайн человеку, который не видел софта и тестов... если человек сможет выполнить тесты по указанному документу, значит уже неплохо :)

это субъективная оценка.... но как её привязать к заработной плате?!

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

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

http://motivateme.ru/feedback/239/
http://motivateme.ru/book/

Встаёт вопрос о разработке схемы оценки работы группы тест-дизайна и расчёте на основе оценки заработной платы!

На основе чего оцениваете эффективность тест-дизайна? Метрики должны быть комплексными, чтобы не считать только количество кейзов, а то получится как в анекдоте "Скорость печати 3000 символов в минуту, но такая фигня получается" :)
Как оценить результативность тест-дизайнеров?
- По количеству кейзов
- Через ревью кейзов
- Через оценку эффективности оптимизации ресурсозатрат на тестинг (тоже ревью, но на основании ROI)
- Через оценку кейзов тестерами на предмет понятности, юзабилити
- Через оценку бажности компонентов, доверенных определённым тест-дизайнерам, после релиза (это измерить сложнее всего, но важнее всего мотивировать тест-дизайнеров именно на этот пункт!)
- Через оценку уровня знаний (всех, требуемых для тест-дизайна. А то может получиться так, что у сотрудника классные показатели потому, что ему выделяются самые простые задачи т.к. с более трудными он не справится)
- По личностным компетенциям (коммуникации, дисциплина, и всё что Вам ВАЖНО. Важно значит ВАЖНО, а не добавлено для галочки :))

Все вышеперечисленные пункты ИМХО важны, и все кроме второго можно сделать цифровыми, авторасчитываемыми и т.д.

Эта схема должна также мотивировать сотрудников работать качественно (расплывчатое понятие, но всё же) и эффективно...

Мотивирует не схема, а то, как Вы её преподнесёте.
1) Указывайте цели на следующий период. Какие показатели необходимо улучшить сотруднику и до какого значения, чтобы рассчитывать на повышение?
2) Давайте регулярный фидбек - чаще, чем раз в полгода. Оптимально - каждый месяц. Люди зачастую не знают, что работают неэффективно.
3) Делайте свой фидбек конструктивным. Не критикуйте, а обсуждайте варианты улучшения текущего положения вещей. Вообще, конструктивный фидбек сам по себе является мотивацией.
4) Согласуйте формат оценки с сотрудниками. Если Вы это предварительно не сделаете, но проведёте и повлияете на их зарплаты, то недовольные будут демотивированы втройне: они будут уверены в Вашей субъективности, в том что метрики неправильные, и т.д. Если предварительно с ними согласуете - они будут согласны со справедливостью Ваших действий.
5) Обсуждайте с тест-дизайнерами конечный, а не промежуточный результат. Если кейзов много, они классные, но из-за каких-то мелочей их не выполняли и пропустили кучу багов - то это вина тест-дизайнера. И это надо объяснять. Поэтому, тест-дизайнер должен знать, что он работает не на кейзы, а на оценку качества с использованием его кейзов.

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

потому, что остальные группы уже работают по определённым схемам....

Неплохой вариант проверки - дать тест дизайн человеку, который не видел софта и тестов... если человек сможет выполнить тесты по указанному документу, значит уже неплохо :)

это субъективная оценка.... но как её привязать к заработной плате?!

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

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

Я бы не рискнул завязывать эффективность работы тест дизайнера на деньги через количество тест кейсов, которые он написал.
И мотивировать "Вася написал больше строк кода тест кейсов, чем Петя", тоже гиблое дело".
А вот если человек сказал, что ему нужно 2 дня, утвердили, он справился вовремя и после ревью не выявили пропущенных моментов, это уже хороший мотиватор и возможно привязать это к деньгам в виде премии. Ещё советую почитать книжку "Мотивируйте меня правильно", там много полезного написано...

Я бы не рискнул завязывать эффективность работы тест дизайнера на деньги через количество тест кейсов, которые он написал.
И мотивировать "Вася написал больше строк кода тест кейсов, чем Петя", тоже гиблое дело".
А вот если человек сказал, что ему нужно 2 дня, утвердили, он справился вовремя и после ревью не выявили пропущенных моментов, это уже хороший мотиватор и возможно привязать это к деньгам в виде премии. Ещё советую почитать книжку "Мотивируйте меня правильно", там много полезного написано...

Согласен, на объём не стоит мотивировать... это может привести к генерации кучи бесполезных кейсов, которые к тому же надо будет просмотреть для контроля...
Но ведь ревью - это субъективная оценка + ко всему это будет требовать очень много времени :(


Уместна ли оценка тест-кейсов по их актуальности, т.е. если занесён баг по тест-кейсу, но оказывается, что это вовсе не баг и найден в результате недоработок тест-кейса?!

Как оценить результативность тест-дизайнеров?
- По количеству кейзов
- Через ревью кейзов
- Через оценку эффективности оптимизации ресурсозатрат на тестинг (тоже ревью, но на основании ROI)
- Через оценку кейзов тестерами на предмет понятности, юзабилити
- Через оценку бажности компонентов, доверенных определённым тест-дизайнерам, после релиза (это измерить сложнее всего, но важнее всего мотивировать тест-дизайнеров именно на этот пункт!)
- Через оценку уровня знаний (всех, требуемых для тест-дизайна. А то может получиться так, что у сотрудника классные показатели потому, что ему выделяются самые простые задачи т.к. с более трудными он не справится)
- По личностным компетенциям (коммуникации, дисциплина, и всё что Вам ВАЖНО. Важно значит ВАЖНО, а не добавлено для галочки :))

Все вышеперечисленные пункты ИМХО важны, и все кроме второго можно сделать цифровыми, авторасчитываемыми и т.д.

Подскажите пожалуйста Наталья, как конвертировать в цифры субъективную оценку полученную в результате ревью?! как ковертировать оценку личной компетенции и понятности?!

....
Согласен, на объём не стоит мотивировать... это может привести к генерации кучи бесполезных кейсов, которые к тому же надо будет просмотреть для контроля...
Но ведь ревью - это субъективная оценка + ко всему это будет требовать очень много времени :(


Уместна ли оценка тест-кейсов по их актуальности, т.е. если занесён баг по тест-кейсу, но оказывается, что это вовсе не баг и найден в результате недоработок тест-кейса?!

На первых порах ревью необходимо, чтобы повысить качество тест дизайна... дальше уже "по накатанной"...
Не думаю, что уместна. Всё же основная оценка делается во время ревью... а то, что требует время, дык никто и не возражает, но если вы сами хотите делать аудит, то закладывайтесь на него "по полной".
Дальнейшая оценка возможно такая - за определённый период пользователи нашли N- ошибок, которые не были заложены в тест дизайне. Если N- величина меньше критической, то молодец тест дизайнер. Если больше, то не молодец :)
...
Учтите только такой момент, что ответственность аудиторы будут также разделять с тест дизайнером... Получается, что они не заметили явных проколов.

Дальнейшая оценка возможно такая - за определённый период пользователи нашли N- ошибок, которые не были заложены в тест дизайне. Если N- величина меньше критической, то молодец тест дизайнер. Если больше, то не молодец :)
...
Учтите только такой момент, что ответственность аудиторы будут также разделять с тест дизайнером... Получается, что они не заметили явных проколов.

Ну всё же с аудитом как с оценкой которая может повлиять на з/п никак не могу согласиться... ведь если например один человек будет проводить ревью, то оценка будет крайне субъективная.... и как же по ней з/п пересчитывать?!

Касательно найденных в продакшене ошибок, то тут достаточно трудно критические цифры обозначить ибо функционал растёт достаточно быстрыми темпами...

По поводу "отвественность аудиторов".. спасибо за замечание!

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

Уильям Эдвардс Деминг, "Новая экономика"

И ещё оттуда же.

Награда за хорошую производительность — то же самое, что награда синоптику за хорошую погоду. Поощрительная оплата труда сосредоточивает внимание на цифрах и отвлекает от цели.

....
Ну всё же с аудитом как с оценкой которая может повлиять на з/п никак не могу согласиться... ведь если например один человек будет проводить ревью, то оценка будет крайне субъективная.... и как же по ней з/п пересчитывать?!
...

А у нас ревью проводили не менее 2 человек . И потом - "субъективно". Тест дизайнер тоже присутствует при рефакторинге и согласование о том ошибка или нет делается совместно.

ИМХО, любая попытка оценить работу в "циферках" и привязать оные к ЗП, только демотивирует...

ИМХО, любая попытка оценить работу в "циферках" и привязать оные к ЗП, только демотивирует...

+1
Дипломатия более эффективна

Эта схема должна также мотивировать сотрудников работать качественно (расплывчатое понятие, но всё же) и эффективно...

Не будет работать. Дэн Пинк о мотивации.
И где-то есть перевод.

На портале есть: http://www.it4business.ru/video/2067/

ИМХО, любая попытка оценить работу в "циферках" и привязать оные к ЗП, только демотивирует...

+1
Дипломатия более эффективна

хорошо, немного усложню задачу...

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

по сути схема должна вынуждать работать, но при этом требуется сделать её более менее ориентированную на благо сотрудника... сейчас же работают по "сдельщине", так что демотивировать уже некуда...