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

[Tishka]

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

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

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

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

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

 

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

[lurk]

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

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

Тезисы:

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

[clipsa]

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

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

[Tishka]

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

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

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

[lurk]

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

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

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

[Tishka]

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

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

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

[Molechka]

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

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

[krukovskiy]

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

 

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

 

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

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

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

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

 

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

 

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

 

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

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

 

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