Метрики/KPI в тестировании: как узнать кто хороший мальчик?

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

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

За время работы в качестве QA инженера, лида и менеджера, я сформулировал для себя собственные практики оценки QA специалистов, которые, конечно же, субъективны, но все-таки хочу ими с вами поделиться.



Правила внедрения KPI:
1) Лучше если KPI будет несколько (публичный и приватный)
2) Публичный KPI создается для того, чтобы заставить замотивировать ваших сотрудников добиться какой-то цели. Например, с помощью публичного KPI разработчиков или автоматизаторов могут стимулировать писать больше кода/тестов за единицу времени (пример из жизни - надо написать минимум 6 авто-тестов в неделю (написать и добиться чтобы они прошли ревью)).
3) Приватный KPI - это метрики, которые руководитель создает сам для себя, чтобы как-то ранжировать сотрудников, принимать решения о повышениях или переводе на другой проект. Эти KPI не показываются сотрудникам, иначе их смысл пропадает. Смысл таких KPI - иметь "карточку" для каждого сотрудника, где прописаны сильные и слабые стороны каждого инженера, измеренные в числовом эквиваленте. Многие менеджеры пренебрегают этим и действуют на основе "интуиции" (на самом деле делая примерно то же самое, но в голове и без формализации).

Важный момент - сотрудники хорошего руководителя всегда четко знают как их оценивают и за что любой сотрудник может получить бонус или выговор/замечание. Это очень важный и полезный инструмент руководителя - четко определить правила и никогда их не нарушать, и эти правила сами будут способствовать тому, что люди будут стараться добиться важного для вас и для компании результата. То есть ваши сотрудники должны понимать как работает публичный KPI, как понять свой "текущий балл" и что надо сделать, чтобы его повысить.

С приватным KPI все немного сложнее, под каждую команду и проект он подготавливается чаще всего индивидуально, и во многом зависит от soft skills ваших сотрудников, а так же от ваших собственных soft skills. Как применял такой приватный KPI я:
1) Для решения кого можно поставить на новый проект, а кому отдать сложный баг для разгребания логов и документации
2) Для решения о том, что пора кого-то повысить, а кому-то еще рано
3) Для решения кого с кем поставить в одну команду
4) Для доказательства своему руководству моих "интуитивных" менеджерских решений и наблюдений

Правила формулировки и сбора данных для KPI:
1) Для всех сотрудников отдела KPI должны быть одинаковыми (то есть построенными на тех же самых метриках, а не для каждого "свои")
2) Достижение KPI каждым сотрудником должно приводить команду к выполнению поставленной цели (для команды и компании)
3) Должна быть возможность быстро собрать данные по каждому человеку, и измерять KPI автоматически (получать эти данные вы должны уметь меньше чем за 10 минут)
4) Должна быть табличка / вики-страничка, где сотрудники могут изучить все имеющиеся KPI, а так же посмотреть свой текущий балл.
5) KPI должен предполагать, что кроме достижения общих KPI, у каждого сотрудника есть еще другие обязанности и задачи, которые тоже надо выполнять.
6) Достижение нужного уровня KPI должно вознаграждаться (хотя бы в формате "у тех, кто выполнил KPI, больше шансов получить повышение").


Пример реального "скрытого" KPI, который я использовал в своей команде:

Из баг трекера выгребаются все баг-репорты за последние пол года, каждому багу назначаются "баллы", например, если баг находится в статусе Invalid/NotReproduced - 0 баллов, Confirmed+MediumPriority - 1 балл,  Fixed+Critical - 5 баллов, Verified+Critical - 6 баллов (градаций было больше, тут просто пример).

Для каждого инженера подсчитывается число багов, которые были им зарепорчены, а так же суммарное число баллов за все найденные и описанные им баги.

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

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

Забавно, что через несколько лет после того, как я придумал и написал этот скрипт, идея оценки багов баллами переросла в отдельный игровой проект для QA инженеров - https://qa-battle.com