Как выбрать метрики для продукта: разбираем на примерах

Метрики эффективности и добавочной ценности привязаны к задаче, а не продукту

Важная особенность метрик эффективности в том, что они привязаны к задаче, а не к продукту. Это значит, что метрику эффективности можно использовать для любого продукта, решающего соответствующую задачу.

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

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

Более глубоко вопрос измерения эффективности решения задачи и добавочной ценности мы обсудим в одном из следующих материалов.

Что такое KPI для целей разработки программного обеспечения

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

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

Ключевые показатели эффективности (KPI) — это величины, которые измеряют общую производительность компании. Они также используются при разработке программного обеспечения для согласования целей разработчиков с бизнес-целями.

Чаще всего ключевые показатели эффективности используются для измерения количества строк кода, коммитов и развертываний. Но они не очень точны и не отражают реальных целей команды. Поэтому одной из наиболее важных целей при формировании KPI в разработке программного обеспечения является качество целевых показателей.

Пять показателей тестирования программного обеспечения, которые необходимо отслеживать

Теперь давайте рассмотрим несколько конкретных примеров

Обратите внимание, что различные аспекты качества имеют разное значение в зависимости от обстоятельств

1. Удовлетворенность пользователей

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

2. Метрики процесса

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

Еще одна метрика, которую вы можете использовать, — это время цикла. Оно означает время на создание функции после получения разрешения на начало работы над ней. Наконец, вы можете отслеживать время, необходимое для решения трудностей. Это может означать скорость решения тикетов или ошибок после того, как о них было сообщено.

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

3. Метрики покрытия

Еще одним показателем качества тестирования является покрытие тестов. Оно информирует нас о количестве протестированного кода. Это способ убедиться в том, что ваши тесты проверяют код и насколько они работают. В этом случае лучше использовать стратегию «сверху вниз». Первым шагом является анализ покрытия модулей. Затем вы рассматриваете функциональность и, наконец, покрытие данных в каждой функциональности. Это означает, сколько различных комбинаций потенциальных входов данных вы покрываете тестами.

В эту группу входят такие метрики, как:

• Процент покрытия требований
• Покрытие модульных тестов
• Покрытие ручных или исследовательских тестов
• Тестовые случаи по категориям требований
• Покрытие тестов пользовательского интерфейса
• Покрытие интеграционных и API тестов

4. Метрики качества кода

Оценка качества кода означает разделение ценности кода на две категории: Хороший и плохой. Единого понятия качества не существует, потому что практически каждый разработчик сам определяет, что такое хороший код. Как вы можете оценить качество кода? Такие инструменты, как SonarQube, позволяют определить, сколько технического долга имеется в системе. Вам необходимо классифицировать проблемы и уязвимости, упорядочить их по приоритетности и выбрать, на чем вы собираетесь сосредоточиться.

5. Метрики ошибок или инцидентов

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

Что можно извлечь из отчетов о происшествиях? Эти результаты могут включать в себя:

• Общее количество ошибок
• Открытые дефекты
• Закрытые дефекты
• Время закрытия каждого отчета об инциденте
• Изменения с момента последнего релиза

Дополнительно

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

Двигатели роста

Метод может использоваться как в начинающих продуктах, так и в тех, которые уже не поддерживаются настолько, насколько это необходимо. Заключается в мониторинге трёх показателей.

Возвращаемость

Задача: поддерживать интерес пользователей.

Показатель успешности: новые пользователи приходят раньше, чем уходят старые.

Виральность

Задача: мотивировать пользователей рекомендовать нас.

Показатель успешности: на каждого платного пользователя есть более одного бесплатного.

Маржинальность

Задача: оптимизировать затраты на поиск клиентов.

Показатель успешности: LTV > CAC.

Usability-метрики

Продукт считается удобным и хорошо выполняющим свою задачу, если можно сказать, что пользователи: 

• эффективно справились со своей задачей;
• удовлетворены промежуточным процессом;
• достигли ожидаемого результата.

Для этого мы измеряем: 

• количество успешно завершённых задач;
• среднее время, которое требуется для решения;
• количество багов, ошибок, проблем на одного пользователя;
• субъективный индекс удовлетворённости.

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

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

Измерение работы в процессе ее выполнения

Скорость работы команды

Проекты обычно делятся на спринты, которые, как правило, направлены на выполнение конкретных задач. Каждый спринт имеет определенное количество таких задач, которые должны быть выполнены к концу рабочего дня. Во время спринта вы можете использовать показатели скорости разработки.

Существует множество способов измерения скорости, например, стори поинты. Один из них — измерение объема работы, который войдет в итоговый программный продукт.

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

Важные советы по измерению скорости работы сотрудников

Если скорость остается неизменной после нескольких спринтов, подумайте о включении в расчет других факторов.

Скорость может быть разной в зависимости от количества задач, на основе которых производился ее расчет.

Если вы хотите строить прогнозы на основе скорости разработки — среднего значения трех спринтов будет достаточно для прогнозирования будущих показателей.

Диаграмма сгорания задач (спринт Вurndown)

Итак, диаграмма сгорания задач — это визуальное представление рабочего процесса команды. Она показывает общий объем выполненной работы, а также то, сколько еще предстоит сделать. В идеале диаграмма должна быть усреднена, чтобы отражать минимально возможное количество задач или рабочих часов.

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

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

Сводная диаграмма сгорания задач похожа на сводную диаграмму спринта, поскольку она показывает статус проекта по отношению к дате его выпуска. Она может использоваться для информирования клиентов и сотрудников о задержках или ранних версиях проекта. Другими словами, она может помочь пользователям определить, будет ли проект выпущен в срок или команде следует двигаться дальше.

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

Example of release burndown chart.

Количественные метрики

Прежде всего, следует рассмотреть количественные характеристики исходного кода программ (в виду их простоты). Самой элементарной метрикой является количество строк кода (SLOC). Данная метрика была изначально разработана для оценки трудозатрат по проекту. Однако из-за того, что одна и та же функциональность может быть разбита на несколько строк или записана в одну строку, метрика стала практически неприменимой с появлением языков, в которых в одну строку может быть записано больше одной команды. Поэтому различают логические и физические строки кода. Логические строки кода — это количество команд программы. Данный вариант описания так же имеет свои недостатки, так как сильно зависит от используемого языка программирования и стиля программирования.

Кроме SLOC к количественным характеристикам относят также:

количество пустых строк,

количество комментариев,

процент комментариев (отношение числа строк, содержащих комментарии к общему количеству строк, выраженное в процентах),

среднее число строк для функций (классов, файлов),

среднее число строк, содержащих исходный код для функций (классов, файлов),

среднее число строк для модулей.

Иногда дополнительно различают оценку стилистики программы (F). Она заключается в разбиении программы на n равных фрагментов и вычислении оценки для каждого фрагмента по формуле Fi = SIGN (Nкомм.i / Ni — 0,1), где Nкомм.i — количество комментариев в i-м фрагменте, Ni — общее количество строк кода в i-м фрагменте. Тогда общая оценка для всей программы будет определяться следующим образом: F = СУММАFi.

Также к группе метрик, основанных на подсчете некоторых единиц в коде программы, относят метрики Холстеда []. Данные метрики основаны на следующих показателях:

n1 — число уникальных операторов программы, включая символы-

разделители, имена процедур и знаки операций (словарь операторов),

n2 — число уникальных операндов программы (словарь операндов),

N1 — общее число операторов в программе,

N2 — общее число операндов в программе,

n1′ — теоретическое число уникальных операторов,

n2′ — теоретическое число уникальных операндов.

Учитывая введенные обозначения, можно определить:

n=n1+n2 — словарь программы,

N=N1+N2 — длина программы,

n’=n1’+n2′ — теоретический словарь программы,

N’= n1*log2(n1) + n2*log2(n2) — теоретическая длина программы (для стилистически корректных программ отклонение N от N’ не превышает 10%)

V=N*log2n — объем программы,

V’=N’*log2n’ — теоретический объем программы, где n* — теоретический словарь программы.

L=V’/V — уровень качества программирования, для идеальной программы L=1

L’= (2 n2)/ (n1*N2) — уровень качества программирования, основанный лишь на параметрах реальной программы без учета теоретических параметров,

EC=V/(L’)2 — сложность понимания программы,

D=1/ L’ — трудоемкость кодирования программы,

y’ = V/ D2 — уровень языка выражения

I=V/D — информационное содержание программы, данная характеристика позволяет определить умственные затраты на создание программы

E=N’ * log2(n/L) — оценка необходимых интеллектуальных усилий при разработке программы, характеризующая число требуемых элементарных решений при написании программы

При применении метрик Холстеда частично компенсируются недостатки, связанные с возможностью записи одной и той же функциональности разным количеством строк и операторов.

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

Управление качеством данных: как его реализовать и как оно работает

Замкнутый круг управления качеством данных.

1. Определение влияния плохих данных на показатели при помощи оценки качества данных

сверху внизснизу вверхсверху внизснизу вверхпрофилирование данныхпрофилировании данных

• Исследование структуры (структурный анализ) используется для того, чтобы проверить, целостны ли данные и правильно ли они форматированы. Один из способов изучения структуры записей данных — сопоставление паттернов. Также для проверки валидности данных аналитики могут проверять статистику в данных, например, минимальные и максимальные значения, медианные и средние значения или стандартные отклонения.
• Исследование содержимого подразумевает изучение отдельных записей данных в базе данных для выявления нулевых или неверных (неверно форматированных) значений.
• Исследование взаимосвязей заключается в понимании взаимосвязей между массивами данных, записями данных, полями или ячейками баз данных. Исследование взаимосвязей начинается с изучения метаданных. Этот анализ позволяет выявлять и устранять такие проблемы, как дубликаты, которые могут возникать в несогласованных массивах данных.

2. Определение правил и метрик обеспечения качества данных

«Результаты эмпирического анализа выявляют типы измерений, которые можно использовать для оценки уровня качества данных в контексте конкретного бизнеса»The Practitioner’s Guide to Data Quality Improvementпороговые значения приемлемости

Стандарты данныхСтандарты управления метаданными.

• Бизнес-стандарты – использование бизнес-терминологии и определений в различных контекстах бизнеса, применение акронимов; параметры уровней безопасности данных и конфиденциальности.
• Технические стандарты – структура, формат и правила хранения данных (например, формат и размер для индексов, таблиц и столбцов в базах данных, моделях данных)
• Операционные стандарты – правила использования метаданных, описывающих события и объекты в процессе ETL (например, дата загрузки в ETL, дата обновления, показатель уровня достоверности)

Правила валидации данных.приводит рекомендации

5. Мониторинг и исправление данных

подготовки данных

• Анализ первопричин – выявление источника ошибочных данных, причин возникновения ошибок, изолирование факторов, влияющих на эту проблему, и поиск решения.
• Парсинг и стандартизация – сопоставление записей в таблицах баз данных с заданными паттернами, грамматикой и репрезентациями для выявления ошибочных значений данных или значений в ошибочных полях с последующим их форматированием. Например, аналитик качества данных может стандартизировать значения из разных систем измерения (фунты и килограммы), географические аббревиатуры записей (CA и US-CA).
• Сопоставление – выявление одинаковых или схожих сущностей в массиве данных и объединение их в одну. Сопоставление данных связано с решением проблемы подобия и связыванием записей. Можно использовать методику объединения массивов данных, после чего данные из нескольких источников интегрируются в одну конечную точку (процесс ETL). Решение проблемы подобия в массивах, содержащих записи об отдельных людях, позволяет создать единое описание клиента. При связывании записей обрабатываются записи, которые могут или не могут относиться к одному элементу (например, ключу базы данных, номеру социального страхования, URL) и которые могут отличаться из-за формата записей, места хранения, стиля или предпочтений куратора.
• Совершенствование – добавление новых данных из внутренних и внешних источников.
• Мониторинг – оценка данных с заданными интервалами для гарантии того, то они хорошо выполняют свои задачи.

Контрметрики

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

Чтобы этого не было, необходимо связать каждую метрику с соответствующей контрметрикой: количество платного и органического трафика, число регистраций и последующих активаций аккаунта, количество покупок и возвратов. Если вы видите, что заказов становится больше, не забывайте контролировать, чтобы количество оплат не снижалось, а возвраты не увеличивались. Тогда рост заказов действительно будет для вас сигналом о росте или даже кратном росте продукта — значит, вы нашли свою аудиторию.

Шаг 3: реализация. Внутренний инструмент Team meter

Этот шаг можно только условно назвать третьим, потому что продумывать реализацию и выбирать инструмент мы начали значительно раньше. Незадолго до нашей активности с дашбордом качества в Тинькофф реализовали внутренний инструмент Team meter.

Team meter — это self-service платформа, которая помогает командам работать с метриками. «Из коробки» позволяет получить настроенные дашборды и метрики по процессам поставки. Team meter идеально подходил под наши цели, потому что уже автоматически собирал все необходимые данные из Jira. Для визуализации настроили интеграцию с Metabase.

Metabase — инструмент для бизнес-аналитики с открытым исходным кодом. Пользователи задают вопросы о данных, а Metabase отображает ответы в осмысленных форматах, таких как гистограмма или таблица.

Создать дашборд команды можно в несколько шагов:

1. Выбрать дашборд, который хотите построить.

1. Ответить на несколько простых вопросов.

1. Нажать «Отправить».

2. Дашборд создан.

Сейчас команды могут создать два дашборда: 

• дашборд качества с большим количеством графиков про тест и прод;

• базовый дашборд качества — небольшой гигиенический дашборд, цель которого — показать все ли хорошо у команды на продакшене.

Вот так выглядят рабочие дашборды:

А зачем они нужны?

Я думаю многие из вас сталкивались с ситуациями когда:

• Проект отстаёт от графика, но всем всё равно
• Мы поздно понимаем, что нам не хватает времени на тестирование
• Непонятно, когда нужно остановить тестирование и готов ли продукт к релизу
• Непонятно стал ли лучше наш продукт, чем раньше
• Заказчику непонятна эффективность тестирования

и многое-многое другое.

Благодаря сбору и анализу метрик, мы можем управлять всеми этими вещами, оценивая различные показатели и то, как они меняются на протяжении времени. Если мы увидели, что какой-то показатель падает, то это может послужить тригером для команды к началу действий, которые будут направлены на улучшение качества.

Часто говорят, что тестировщик ответственнен за качество продукта. Но как он может за что-то отвечать если он ничего не может сделать с этим продуктом?

Задача тестировщика — предоставить информацию о качестве продукта и о других аспектах нашего проекта, которые могут влиять на качество.

Поэтому выбор и сбор правильных метрик является очень важным аспектом нашей работы.

В тестировании мы обычно наблюдаем за качество продукта, качеством различных процессов, производительностью людей и временными рамками проекта.

Определение метрик обычно происходит на этапе планирования тестирования и контроля.

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

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

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

1. Техподдержка

• дашборд качества

• поступающие задачи

2. QA

• покрытие

• тестовая документация

• покрытия автотестами

• результаты прогонов

• нагрузочное тестирование

• скорость написания автотестов

3. Безопасность

• загруженность отдела

• покрытие тестами безопасности

4. Процессные метрики

• загруженность производства

• сгорание задач

• срывы сроков задач

• сложность релизов

• приближение дедлайна

Метрики удовлетворённости учащихся

Удовлетворённость учёбой оценивать нужно обязательно, поскольку это напрямую влияет как на мотивацию студента, так и на качество обучения. Кроме того, именно от удовлетворённости зависит, вернутся ли студенты и купят ли новый курс.

Есть три основные метрики удовлетворённости.

CSAT (Customer Satisfaction Score)

CSAT (индекс удовлетворённости клиента) помогает понять, насколько студент доволен каким-то аспектом взаимодействия с образовательным продуктом. Например, качеством урока, домашних заданий или курса целиком, работой преподавателя или службы поддержки.

Вы сами можете определить, какие аспекты нужны для анализа вашего продукта.

Как рассчитать CSAT

Для расчёта CSAT используют обратную связь от учащихся. Студентов просят оценить продукт или его элемент от 1 до 5 (от «‎совсем недоволен» до «‎очень доволен»)‎. Это может выглядеть так: «Насколько вам понравился урок?» или «Оцените взаимодействие со службой поддержки».

А потом считают процент оценок «4» и «5» от общего количества оценок.

Изображение: Skillbox Media

Пример расчёта CSAT онлайн-курса

Представим, что курс по дизайну интерьеров состоит из размещённых в LMS видеоуроков. После каждого урока студент видит автоматическое сообщение «Оцените урок» и шкалу от 1 до 5.

За время курса студенты дали триста оценок разным урокам, из них 50 пятёрок и 200 четвёрок.

Изображение: Skillbox Media

Конечно, может возникнуть вопрос: какой показатель считать хорошим или плохим? Стандартов здесь нет, так что ответ на него могут определить только создатели или заказчики обучения. Главное, смотреть на показатель в динамике и стремиться к его росту.

CSI (Customer Satisfaction Index)

CSI — это тоже метрика удовлетворённости, которая говорит о том, доволен ли студент тем или иным аспектом обучения. Её рассчитывают иначе, чем CSAT, однако принципиальной разницы между ними нет.

Главное — сохранить преемственность по всем продуктам вашей школы, то есть выбрать только одну из метрик и отслеживать её регулярно, чтобы корректно сравнивать показатель одного курса с другими.

Как рассчитать CSI

Студентов тоже просят оценить тот или иной аспект взаимодействия, но в данном случае шкала — десятибалльная.

CSI считают как среднее арифметическое, то есть делят сумму всех оценок на их количество.

Изображение: Skillbox Media

Пример расчёта CSI онлайн-курса

Представим, что в том же видеокурсе по дизайну интерьеров разработчики решили измерить CSI. Они просили студентов оценивать уроки по десятибалльной шкале. Студенты дали те же 300 оценок, но в этот раз учитываются и суммируются все оценки от 1 до 10.

Допустим, что общая сумма оценок — 2650.

Изображение: Skillbox Media

Как и у CSAT, для CSI нет идеального бенчмарка — каждый сам решает, какой показатель считать приемлемым и к чему стремиться.

NPS (Net Promoter Score)

NPS — это индекс потребительской лояльности. Он показывает отношение студента к онлайн-школе в целом, его готовность рекомендовать друзьям и знакомым обучение именно у вас. А ещё говорит о том, какая у школы репутация среди учащихся и сколько из них готовы быть амбассадорами бренда.

Как рассчитать NPS

Сначала нужно задать студентам вопрос в духе «Готовы ли вы рекомендовать нашу онлайн-школу друзьям и знакомым?» и предложить шкалу с оценками от 0 до 10.

Затем пользователей группируют в зависимости от оценок:

• 0–6 — «критики», то есть те, кто не готовы рекомендовать вас или оставят отрицательный отзыв.
• 7–8 — «‎нейтральные потребители». Они не слишком заинтересованы, но, как правило, довольны.
• 9–10 — «‎сторонники», то есть лояльные и довольные клиенты, готовые продолжать учиться в вашей школе и рекомендовать образовательный продукт.

А расчёт проводят по формуле.

Изображение: Skillbox Media

Значение NPS может варьироваться от −100 до +100, в первом случае все ваши клиенты — критики, а во втором — сторонники.

Пример расчёта NPS онлайн-школы

Вы опросили одну тысячу студентов онлайн-школы английского языка, которые пользовались разными её продуктами:

• 50 человек дали NPS-оценки от 0 до 6;
• 150 человек — 7;
• 800 человек — 9 и 10.

В этом случае критики составляют 5% от общего числа, нейтральные пользователи — 15% и сторонники — 80%.

Иерархия метрик

Более сложная система работы с метриками, которая подойдёт, если вы — продакт большого продукта или экосистемы. Такая модель помогает упорядочить показатели, выявить зависимости и понять, работа с какой метрикой окажет наиболее существенный результат.

Иерархия метрик помогает разложить ключевой показатель успеха (чаще всего это прибыль) на более детальные метрики, а их — на ещё более мелкие. Благодаря этому: 

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

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

Метрики продукта

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

Характеристики того, как продукт превращает новых пользователей в другие материи — это метрики продукта.

• Retention показывает, как новые пользователи превращаются в активных;
• LTV показывает, как новые пользователи превращаются в прибыль за все время использования сервиса;
• Конверсия в первую покупку показывает, как продукт превращает новых пользователей в платящих.

↓ Подборки материалов о метриках:

→ Retention

→ LTV

Почему единые метрики качества — это важно

Прежде чем запустить новый бизнес, внедрить новые технологии или подходы, мы всегда задаемся вопросом: «Зачем?» Какую выгоду получим, как много денег сможем заработать или сэкономить.

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

Чтобы понять, насколько качественный продукт мы поставляем и как быстро это делаем, и нужны метрики. Не измеряя процессы и не зная, как у нас сейчас обстоят дела с качеством поставки, мы не можем улучшать процессы поставки. Да и понять, как с течением времени меняется наш продукт, в лучшую или худшую сторону, тоже не получится. Ведь без метрик это очень сложно.

Но при этом стоит помнить, что метрика — это помощник, а не панацея, которая разом избавит от всех проблем. Внедрение метрик только ради метрик отнимет время и не принесет результатов

Прежде всего важно понять, что и для чего хотим измерять, а потом подумать, как будем это делать. 

Чаще всего, в рамках одной организации работает много команд, процессы поставки в них различаются. При этом бизнес постоянно меняется, в компании появляются новые направления, а старые могут сойти на нет.

Без единого подхода к метрикам соотнести команды между собой очень сложно

Трудно понять, какая команда драйвит, постоянно работает над улучшением качества поставок, а какой команде стоит обратить внимание на качество своей разработки. При этом внедрить единые метрики сложно, потому что они не работают без единых подходов. 

Расскажу про четыре больших шага, которые мы прошли, чтобы внедрить единые метрики для всех.

Пирамида метрик

Иерархия метрик не всегда даёт однозначное понимание, какие из них являются более значимыми, какие — составными, а какие — промежуточными. Особенно сложно сориентироваться в самом начале. Чтобы избежать возможных ошибок, обратимся к пирамиде метрик.

Пирамида имеет пять уровней, расположенных по порядку от макроструктуры к микропроцессам. 

1. В основе находятся бизнес-метрики, которые показывают, зарабатываем ли мы и эффективна ли наша бизнес-модель (считаем общий профит).
2. Дальше идут метрики маржинальности, баланс которых напрямую влияет на профит. Следим за прибылью с каждого пользователя и каждой сделки, работаем над формулой LTV > CAC.
3. Ценность продукта. На этом этапе мы должны быть уверены, что продукт решает основную задачу пользователя, с которой он приходит к нам. Если она решается хорошо, это залог готовности платить больше и дольше, что напрямую влияет на второй этап. Здесь подойдут любые метрики лояльности. 
4. Метрики качества. Готовы ли мы гарантировать удобство и отказоустойчивость нашего сервиса? Чтобы измерить это, отслеживаем операционные процессы: оптимальность, безотказность, отсутствие багов и критических сценариев.
5. Маркетинговые метрики. Как работают отдельные каналы и сегменты, успешны ли наши рекламные коммуникации — всё это учитывается с помощью CTR, CPA и т. д. 

Кстати, достаточно сложная иерархия, представленная в виде древовидной структуры, является по сути пирамидой метрик.

Среднее время жизни дефекта

Общее время, в течение которого были открытыми дефекты, найденные в рамках итерации или релиза к сумме дефектов.

Назначение метрики: показать, сколько в среднем времени уходит на работу с одним дефектом: на его регистрацию, исправление и воспроизведение. Данный показатель позволит оценить время, необходимое на тестирование, выделить области ПО с которыми возникают наибольшие сложности.

• Обычно время жизни дефекта, это все время от его создания (статус Created) до закрытия (Closed) за вычетом всех возможных Postponed и Hold. Любой баг-трекер позволяет рассчитать и выгрузить данную информацию для отдельного спринта или релиза.
• Также среднее время жизни дефекта можно рассчитывать для различных модулей и функций ПО, или, что самое интересное, отдельно для каждого из тестировщиков и разработчиков из команды. Так есть шанс выявить особенно сложные модули или слабое звено в команде ПО.

Группа 4 — Качество работы команды тестирования

Задача этого набора метрик оценить насколько качественно тестировщики выполняют свои задачи, определить уровень компетенций и зрелости команды QA. Обладая таким набором показателей можно сравнивать команду с ней же самой в разные моменты времени или с другими, внешними группами тестирования.

Что такое качество данных? Размерности качества данных

размерностями качества данныхBeyond Accuracy: What Data Quality Means to Data Consumers
Beyond Accuracy: What Data Quality Means to Data ConsumersData Quality Assessment Framework (DQAF)размерностей качества данных

• Целостность – статистика собирается, обрабатывается и распространяется на основе принципа объективности.
• Методологическая надёжность – статистика создаётся на основе международных принятых руководств, стандартов и рекомендаций.
• Точность и надёжность – исходные данные, используемые для компилирования статистики, своевременны, взяты из исчерпывающих программ сбора данных, учитывающих специфические для страны условия.
• Удобство обслуживания – статистика согласована с массивом данных, по времени и с крупными массивами данных, а также регулярно подвергается ревизиям. Периодичность и своевременность статистики соответствуют общемировым стандартам распространения.
• Доступность – данные и метаданные представлены понятным образом, статистика актуальна и легкодоступна. Пользователи могут получать своевременную и компетентную помощь.

Критически важные размерности данных и признаки данных, соответствующие их критериямMeasuring Data Quality for Ongoing Improvement«Множество размерностей качества данных может использоваться для определения ожиданий (стандартов, относительно которых выполняются измерения) качества нужного массива данных, а также для измерения состояния имеющегося массива данных»

Заключение

Подводя итог, хотелось бы отметить, что ни одной универсальной метрики не существует. Любые контролируемые метрические характеристики программы должны контролироваться либо в зависимости друг от друга, либо в зависимости от конкретной задачи, кроме того, можно применять гибридные меры, однако они так же зависят от более простых метрик и также не могут быть универсальными. Строго говоря, любая метрика — это лишь показатель, который сильно зависит от языка и стиля программирования, поэтому ни одну меру нельзя возводить в абсолют и принимать какие-либо решения, основываясь только на ней.

Заключение

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

О том, как снимать метрики, можно написать целую статью. Экономя время, вкратце резюмирую:

• для того чтобы получить возможность крупного выигрыша в перспективе, необходимо внедрять снятие метрик в процессы уже сейчас, пожертвовав лишь небольшим количеством времени;

• неотъемлемой составляющей качества этих метрик будет служить контроль специалистов.