Тестировщик и kpi

Добрый день уважаемые форумчане!

Хотел бы спросить, есть кто работает по kpi?

Если да, то какие проблемы/преимущества этого метода оценки работы?

И если не сложно, приведите пример вашей kpi.

Буду очень благодарен, заранее спасибо.

С уважением, Антон.

Можешь посмотреть доклад Галиева Рашида  из Performance Lab с Quality Assurance Day:

KPI для определения эффективности отдела тестирования

Тезисы:

1. Понятие эффективности отдела
2. Критерии определяющие эффективность отдела тестирования
3. Расчет и валидация KPI
4. Использование KPI для совершенствования работы

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

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

Это я все понимаю, в идеале KPI нужно для самого отдела и его развития а не для: "Я менеджер и буду вас измерять" =)

Главное, это донести до руководства.

Больше всего беспокоит то, что начнут "читерить" при привязке KPI к премии.

Как KPI поможет развитию отдела? И почему он вам нужен?

Решение какой проблемы вы хотите с помощью него достигнуть?

Не получится ли, что при увеличении работы после внедрения KPI выхлоп отдела снизится, особенно, если благодаря нему будет считаться премия?

Инициаторами этого являются: "Я менеджер и буду вас измерять" =)

Я прекрасно понимаю что это не самый лучший вариант, но руководство уже так решило.

Так что приходиться самому создать такой kpi который хотя бы не испортит все.

Процент переоткрытых задач — которые тестировщик проверил, но, как оказалось, не до конца.

Процент ошибок, найденных на PROD окружении

1. Для разработки KPI необходимо прежде всего определить цель сбора метрик.

2. Метрики должны быть сбалансированными. Это значит, что если вы, например, измеряете скорость тестирования (кол-во пройденных тест кейсов), то обязательно надо измерять и качество (кол-во претензий от пользователей). Иначе будут большие перекосы. 

3. KPI должны отражать разные аспекты деятельности.

Мы, например, используем следующую модель. Разделяем kpi на 3 категории:

1) Надежность ПО

Сюда входят показатели, относящиеся к непосредственно к характеристикам ПО (дефекты разной степени тяжести, успешные/неуспешные тесты, плотность дефектов и т.д.)

2) Сложность/Покрытие (кол-во функций, кол-во тестов на функцию и т.д.) 

3) Финансы (условная стоимость прогона одного теста, бага, кол-во выполненных тестов в час и т.д.)

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

Или, например, время прогона тестов увеличилось на 20%, при этом сложность выросла на 50% - вывод очевиден.

По метрикам рекомедную прочитать книгу  Каплана и Нортона "Система сбалансированных показателей" .