Tester's KPI

Product Manager (РМ) команды разработки в ConquestSS многие годы опирался на количество задач при оценке уровня специалиста. Поэтому, когда команда разрослась, поручил мне еженедельно публиковать в чате отчёт об обработанных задачах в разрезе продуктов (от трёх до шести приложений) и о переписке тех.поддержки (сколько получено писем, сколько отправлено ответов, сколько застряло в обработке). В те недели, когда у меня были отпуска, количество обработанных задач резко падало, и это первым заметил PM. Сделав выборку значений и подставив периоды моего отсутствия, у меня получился нижеследующий график.

Схождение отпусков и провалов задач

Скачки снижения количества задач (голубая и рыжая кривые) в точности совпали помесячно с периодами моих отпусков (коричневая кривая, где 100 - наличие отпуска, 0 - рабочий период). Что в точности подтвердило гипотезу РМ.
Но мне стали интересны и другие мои идеи.
1. Как часто стоит менять курируемый продукт? Ежедневно, как это делал РМ на стендапах, или закрепить один продукт за каждым тестировщиком на весь период спринта?
2. Зависит ли производительность тестировщика от его гендерности?
3. Кто эффективнее обучает новичка?
Для этого была собрана нижеследующая таблица.

Данные о сроках и количестве задач в разрезе тестировщиков

Имя (пол)		Tester_1 (F)	Tester_2 (F)	Tester_3 (F)	Tester_4 (F)	Tester_5 (M)	Tester_6 (F)	Tester_7 (M)
Через N дней оформлен "свой" баг		1	13	4	15	11	9	23
Через N дней оформлена первая задача из техподдержки		16	46	3	15	11	9	23
Срок в команде (месяцы)		165	26	16	26	6	5	2
Обработано всего задач за весь период		32457	4510	2181	1632	548	427	157
Скорость (обработано задач в месяц)		196,7	173,5	136,3	62,8	91,3	85,4	78,5
Количество оформленных задач (найденные баги самостоятельно и предложения из техподдержки)	всего	17204	1697	814	1362	188	148	51
	в т.ч. своих	12187	994	497	707	91	65	35
	%	71	59	61	52	48	44	69
Курируемый продукт		All	P_1, P_2, P_3	P_1, P_4	All	P_1, P_3, P_4	P_2	P_1, P_4
Количество обработанных задач по Product_1	всего	4981	3042	1116	926	288	16	147
	в т.ч. новые	3779	1136	260	798	101	10	44
	закрытые	1202	1906	856	128	187	6	103
Количество обработанных задач по Product_2	всего	5920	923	86	324	16	400	0
	в т.ч. новые	3701	328	16	292	12	128	0
	закрытые	2219	595	70	32	4	272	0
Количество обработанных задач по Product_3	всего	21016	336	31	163	164	11	0
	в т.ч. новые	11388	174	6	152	42	10	0
	закрытые	9628	162	25	11	122	1	0
Количество обработанных задач по Product_4	всего	540	209	948	219	80	0	10
	в т.ч. новые	444	59	532	120	33	0	7
	закрытые	96	150	416	99	47	0	3
Кто обучал внутренним правилам		самостоятельно	Tester_1	Tester_1	PM	Tester_3	PM	Tester_5

Если рассмотреть цифры в строке "Скорость (обработано задач в месяц)" в зависимости от строки "Курируемый продукт", то можно предположить, что тестировщик - универсальный солдат, легко перескакивающий с одной темы на другую. Но если учесть "Срок в команде (месяцы)", то гипотеза становится сомнительной. Особенно после отчёта на одном из стендапов, когда Tester_6 отчиталась об оформлении одного бага, а от Tester_1 за этот же день было добавлено в BTS более 20-ти задач.
На второй мой вопрос о половой принадлежности цифры мало что могут ответить. Поскольку не было возможности разбить задачи по их тематичности, которая в большей степени влияет на эффективность распределения работ. Более подробно об этом читайте в моей статье "Гендерность на страже качества или Вам Девочку или Мальчика?".
А вот на третий вопрос об обучении цифры вполне подтвердили мою гипотезу, что передавать знания должен единый лидер. Скорость учеников прямопропорциональна скорости учителя. Взгляните на строки "Скорость (обработано задач в месяц)" и "Кто обучал внутренним правилам" в купе со значениями "Курируемый продукт".
По таблице может у вас возникнуть вопрос о наличии данных в продуктовых деталях у тестировщиков, занимавшихся не всеми продуктами. Это последствия частой смены кураторов, которую так усердно лоббировал РМ, желая превратить нас в универсальных солдатов. Как следствие, одна из тестировщиц на указания шефа стала отвечать смайликом "Yes, Sir!", но он воспринял это лишь шуткой, не придав значения хлипкости командного духа подчинённых.
Количеством закрытых в спринте задач любил бахвалиться РМ и перед вышестоящим руководством, не вдаваясь в подробности того, что половина из них были элементарным откатом к функционалу прошлых версий. На каждое изменение в продукте "деды" тестирования всегда оформят, как минимум, две задачи. А если тестировщик более внимательно слышит пользователя, нежели сборщик бэклога РМ, то процесс его пополнения будет бесконечным: РМ навязывает свой взгляд на решение, а тестировщик инвертирует к пожеланиям пользователей.