Метрики

1. Метрики

Как их выбирать, собирать и хранить

2. ЧТО ТАКОЕ МЕТРИКИ?

• Метрика в организационном управлении — численный
показатель качества, эффективности процесса, обладающий
свойствами функции расстояния.
• Метрика программного обеспечения — численное значение
некоторого свойства разрабатываемого программного
обеспечения для управления процессом создания.

3. ЧТО ТАКОЕ KPI?

Key Performance Indicators, KPI) — числовые показатели
деятельности подразделения (предприятия), которые помогают
организации в достижении целей или оптимальности процесса, а
именно: результативности и эффективности.

4. ЧТО ТАКОЕ BSC?

Сбалансированная система показателей (ССП, англ. balanced
scorecard, BSC) — инструмент стратегического управления
результативностью, частично стандартизированная форма
отчётности, позволяющая менеджерам отслеживать исполнение
заданий сотрудниками, а также последствия исполнения или
неисполнения.

5. ЧТО ТАКОЕ SLA?

Соглашение об уровне предоставления услуги (англ. Service Level
Agreement, SLA) — термин методологии ITIL, обозначающий
формальный договор между заказчиком услуги и её поставщиком,
содержащий описание услуги, права и обязанности сторон и, самое
главное, согласованный уровень качества предоставления данной
услуги.

6. Не торопись!

А ТЫ ПОВЕРИЛ?
А ТЫ НАШЁЛ КОРНИ?
А ТЫ УВЕРЕН ЧТО ВЫ ОЗВУЧИЛИ ВСЁ?
А КАК ТЫ ОЦЕНИШЬ РЕЗУЛЬТАТ?

7. КОГДА МОЖНО БЕЗ МЕТРИК?

• Проблемы очевидны
• Проблемы наглядны
• Проект скоро закроется

8. ЧТО ДАДУТ МЕТРИКИ

1. Анализ, копнуть глубже
• Подтвердить или опровергнуть
• Оценить масштабы бедствия
2. Перепроверить субъективные оценки
• Плохое точно плохо?
• Хорошее точно хорошо?
3. Продажа, убедить в решениях
• До
• после
4. Отслеживать, что вы всё делаете правильно
5. Оценить прогресс

9. «ЗА» И «ПРОТИВ»

Результаты
• Ты видишь те проблемы, которые никто не заметил
• Ты можешь копнуть глубже и решить корень вместо симптомов
• У тебя есть числовые аргументы
• Ты можешь отслеживать прогресс и вызнавать проблемы на
ранних этапах
Затраты
• 1 неделя внедрения метрик

10. Категоризируем метрики

ПО ЮЗ КЕЙСУ
• ПО ЦЕЛЕВОЙ АУДИТОРИИ
ПО ВРЕМЕНИ СБОРА
• Найти неизвестные
проблемы
• Бизнес
• Финальные
• Проектная команда
• Итерационные
• Технари
• Процессные
• Диагностировать известные
проблемы
• Принимать взвешенные
решения
• Ресурс менеджеры
• Контролировать динамику
ПО ОБЪЕКТУ
• ПО ГРУППЕ
• Продукт
• Process
• Проект
• Результат
• Команда
• Человек
• Отдельно выбранное
решение

11. ЗАДАЁМ СЕБЕ ВОПРОСЫ ПО ПОРЯДКУ

КАК СОБРАТЬ
Где нам взять для этого
данные?
Каким образом собирать и
рассчитывать?
КАК СЧИТАТЬ
Какие расчёты помогут собрать эти
оценки?
Какие для этого нужны данные,
формулы?
КАК ОЦЕНИТЬ
Как это можно измерить?
Какие цифры будут показательны?
ЧТО ТАК/ НЕ ТАК?
Что плохого мы хотим исправить?
Что хорошего мы хотим сохранить?

12. СНАЧАЛА БЫЛА ЦЕЛЬ

• (Не)подтверждение проблемы
• Диагностика и уточнение проблемы
• Стремление к целям
• Мониторинг хорошего
• Аргументация мнений
• Фундамент для принятия решений
• Выявление сбоев

13. Разбираем «матрёшку»

Вы заводите баги слишком
поздно
Окей, значит нам надо
посчитать время,
прошедшее между
выпуском сборки на
тестирование, и
заведением критикалов...
Как это проявляется?
Dev
Lead QA
Я успеваю забыть, что я написал
Прости, мы не можем подтвердить эту
проблему. Между появлением сборки на
тестирование и заведением критичных
ошибок проходит в среднем 4 часа.
Океееей

14. Разбираем «матрёшку» 2

Оценка проблемы
Окей, значит нам надо
посмотреть, по какому %
дефектов запрашиваются
уточнения... 26%!
Ваши баги непонятные
Как это проявляется?
Dev
Lead QA
Всё время приходится
запрашивать уточнения и доп.
информацию
Никита, по 26% из наших багов вам
приходится запрашивать уточнения. Это явно
слишком много! Мы возьмём эту проблему в
работу, пожалуйста, помогите?
Оooooокееееей.

15. Разбираем «матрёшку» 2

Анализ проблемы
Ага-ага, доктор,
вылечите мне
температуру ))
26% наших дефектов требуют уточнения. Давай
это исправим и научим ребят правильнее писать
баги! Нужен новый формат!
Team
Manager
Lead QA
Категории уточнений
■ непонятно описано — 8%
■ не то окружение — 3%
■ не добавили требуемые файлы — 12%
■ не локализовали проблему — 77%

16. Разбираем «матрёшку» 2

Отклонение
проблемы на этапе
анализа
Вы заводите кривые баги
Да, мы подтвердили проблему, 18%
наших багов отклоняются, т.к. не
являются дефектами
Dev
Lead QA
Стоп! Я тут собрал статистику по
причинам реджектов...
Team
Manager

17. ИЗМЕРЯЕМ КАЧЕСТВО

Нам нужно оценивать качество ПО,
причём, на максимально ранних
этапах!
Значит, первым делом нам надо
понять, что такое качество, а потом
уже его измерять.
Team
Manager
Я подготовила метрики качества, исходя
из набора жалоб клиентов:
% успешно пройденных сценариев
% соблюдённых требований
Число открытых жалоб
пользователей
Скорость отклика страниц
Успешное выполнение сценариев в
UX-экспертизе
Оценка достоверности расчётов
N обращений по каждому новому
улучшению
Lead QA

18. Дашборд по качеству

Показатель
ЦЕЛЬ
Релиз 1
Релиз 2
Релиз 3
Релиз 4
% успешно пройденных сценариев
100%
98%
94%
96%
93%
Число открытых жалоб пользователей
0
13
11
14
12
% реализованных требований
100%
78%
81%
81%
86%
Скорость отклика страниц
<2с
6с
6с
6,5с
3с
Успешное выполнение сценариев в UXэкспертизе
95%
64%
72%
67%
86%
Оценка достоверности расчётов
100%
85%
85%
96%
96%
N обращений по каждому новому
улучшению
<2
4
3,2
4,1
3,6

19. ВНЕДРЯЕМ SLA

Team
Manager
Интересно, правда ли это, и
надолго ли ))
В целом команда довольна тем, как
быстро мы работаем и как
взаимодействуем с другими
участниками проекта
Значит, нам надо оценить
показатели скорости и
взаимодействия, чтобы
• убедиться, что всё хорошо
• отслеживать, чтобы ничего не
сломалось
Lead QA

20. SLA НА ТЕСТИРОВАНИЕ

Показатель работы команды
ЦЕЛЬ
Январь
Февраль
Март
Апрель
Затраты на тестирование сборки
До 160 чч
148
166
180
144
Скорость тестирование сборки
До 2 дней
2
2
2,5
2
Скорость обработки инцидентов
До 1 р.д.
0,85
0,88
0,65
0,63
Скорость ответа на обращение пользователя
До 4 р.ч.
5,5
5,8
7,2
6,9
Пройдено тестов с приоритетом 1
100%
97
100
92
100
Пройдено тестов в затронутых областях
100%
100
n/a
100
100
Пройдено от общего числа тестов
80%+
84
86
81
84
Автоматизировано регресса
60%+
63
65
70
69

21. Алгоритм

22. ЧЕК-ЛИСТ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ

• Проблемы подтверждены или опровергнуты цифрами
• Проведён анализ, найдены корешки
• Все показатели собираются, понятны и наглядны
• Мы можем аргументировать что угодно кому угодно, опираясь на
объективную информацию

23. Источники — везде!

Метрики можно собирать из множества источников:
• Таск-трекеры (Jira, YouTrack, Redmine и др.)
• Тайм-трекеры (Timesheet, Jira Time Tracking)
• Электронная почта
• Базы данных
• Серверный мониторинг (Zabbix, Bamboo)
• Везде! — если есть данные, их можно использовать.

24. Как собирать метрики?

Варианты сбора:
• Встроенные средства («из коробки») — фильтры, отчеты,
дашборды
• Расширения и плагины — например, Time In Status, Timesheet
Reports
• Дополнительные инструменты — Excel, Power BI, Tableau
• Вручную — при отсутствии автоматизации
• Опросы — субъективные оценки (например, от 1 до 5)
• Спросить у коллег — не все метрики в вашем ведении

25. Где хранить метрики?

• Табличные дашборды — Excel, Google Sheets
• Графические дашборды — Power BI, Tableau, Data Studio
• Отдельные файлы с анализом — для детального разбора
• Встроенные дашборды — в Jira, YouTrack

26. Зачем нужны дашборды?

• Наглядность — видеть комплекс показателей
• Динамика — отслеживать изменения во времени
• Демонстрация бизнесу — визуализация результатов

27. Алгоритмы действий

• 1. Всё есть (данные + инструменты)
• → Используем встроенные средства → собираем показатель →
храним
• 2. Данные есть, инструментов нет
• → Ищем плагины → или выгружаем в Excel → считаем
формулами → храним
• 3. Ничего нет
• → Убеждаемся, что метрика нужна → определяем показатели →
настраиваем поля/плагины → собираем → храним

28. Критерии хорошей метрики

• Измеряет именно то, что важно
• За каждой цифрой — аргументированные исходные данные
• Формулы расчетов верны
• Есть возможность видеть динамику
• Затраты на сбор адекватны

29. Важно помнить

• Не все показатели в вашем ведении — спросите у коллег
• Технические средства — не единственный способ
• Для важных замеров можно создавать неудобства — если это
оправдано
• Главное — цель → данные → инструменты