Как проверить качество digital-продукта: инструменты, метрики и стоимость обслуживания

Согласно стандарту ISO, качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя. То есть качество можно измерить объективными и субъективными метриками.

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

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

Контроль и инспекция качества

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

Контроль качества можно разделить на две части — технический надзор и продуктовый (бизнес) надзор.

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

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

Метрики и инструменты

Инструментами технического надзора могут выступать чек-листы, код-ревью, юнит-тесты и многое другое. Инструменты бизнес-надзора можно разделить на количественные (например, построение конверсионных воронок по целевым действиям пользователя) и качественные (например, качественные исследования: глубинные интервью, окулография (eye tracking), качественные опросы и т.д.).

Инспекция качества — это не только тестирование

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

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

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

• Чек-лист для каждого процесса на проекте — требование к паспорту проекта, формат документирования, требования к формату проведения спринтов и ретроспектив или же требования к формату обработки change request’ов и т. д.
• Чек-лист для каждого артефакта на проекте — требования к вёрстке, стандарты кодирования, гайдлайны для разработки дизайна и т. д.
• Процедуры функционального тестирования (ручное или автоматическое тестирование по определённым сценариям). На выходе обязательно надо составлять баг-репорт и подсчитывать количество отладок в рамках одного баг-листа. Самая лучшая метрика для измерения эффективности этого процесса — количество вернувшихся багов (после внутреннего теста, бизнес-тестирования и обязательно в промышленной эксплуатации).
• Процедуры общего тестирования инфраструктуры:

a) pagespeed или аналоги (желательно минимум два инструмента); б) нагрузочное тестирование приложения; в) статический анализ кода приложения; г) pen-тестирование (проверка на уязвимости).

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

• Измерение довольства пользователя на уровне приложения (Важно! не всего продукта или сервиса, об этом расскажем дальше). Например, оценки мобильного приложения в сторах, замеры количества фидбеков по формам обратной связи на веб-приложениях и т. д.
• Обязательное наличие документации по приложению: архитектура, функциональные требования, ПМИ, документирование кода и т. п.
• Авторский надзор со стороны системной аналитики/архитектора по реализации той или иной функциональности + код-ревью. Метрикой может являться отклонение от квотируемого бюджета на поддержку и развитие системы.

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

Инспекция качества продукта должна включать:

1. Измерение продуктовых метрик (конверсия пользователей по шагам воронки к целевому действию, сокращение стоимости того или иного процесса и т. д.).
2. Измерение того, насколько пользователь доволен продуктом и сервисом. Например, с помощью индекса потребительской лояльности (NPS) и индекса удовлетворенности клиентов (CSI).
3. Показатели веб-аналитики на всех шагах воронки (возможно, дашборды).
4. Процедура качественных исследований аудитории продукта и сервиса. Например, качественные опросы, глубинные интервью и т. д.
5. Замер количества новых пользователей (и их вклада в продукт) за отчётный период (неделя или месяц).
6. Количество «умерших» пользователей за отчётный период (обязательно выявлять критерии «умирания»).
7. Месячная активная аудитория/частота использования. Например: среднее количество активных действий за отчётный период;
8. LTV (Live Time Value) — деньги, которые пользователь тратит в вашем продукте за все время его использования.
9. CAC (Customer Acquisition Cost) — ваши затраты на привлечение пользователя.

Метрики продуктовой инспекции тоже можно дополнить. Например, хорошая практика при использовании продуктовой инспекции качества — сделать релиз новой функциональности на маленькую часть аудитории и провести сплит-тест.

Обеспечение качества (Quality assurance)

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

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

1. За процедуры технической инспекции выпускаемого продукта часто отвечает тимлид или архитектор).
2. За процедуры продуктовой инспекции сервиса — владелец продукта или продюсер).
3. За глобальный контроль всех процессов по принятым стандартам —независимый специалист надзора QA-службы или руководитель проекта.

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

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

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

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

При работе с подрядчиками используйте дополнительные меры контроля качества в своей команде:

1. Требуйте от подрядчиков выполнения жестких фиксированных стандартов качества. Кроме того, закрепите их внутри своей компании.
2. Формализуйте критерии приёмки (конкретные метрики успеха, конкретные тест-кейсы и т. д.), включая ограничения на итерации приёмки, входящие в оценку и передайте подряду.

Как правильно выстроить процесс контроля и инспекции качества в функциональных и продуктовых командах?

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

Однако тип команды влияет на некоторые нюансы в сути процесса. Например, есть более пяти типов продуктовых команд в зависимости от цели компании: одни ориентируются на пользовательские метрики, другие на дизайн (основное внимание уделяется wow-составляющей продукта), третьи на функции и т.д.

Работа функциональной команды должна содержать следующие этапы:

1. Предпроектное исследование (на выходе: ограничения и вижн-системы).
2. Проектирование архитектуры.
3. Чек-листы ко всем процессам и артефактам при разработке продукта.
4. Авторский надзор: отдельно технический и отдельно продуктовый на каждом этапе разработки.
5. Тестирование функциональности и инфраструктуры.

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

Стоимость

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

Стоимость технической инспекции составляет от 30 до 50% стоимости всей разработки.

При внедрении продуктовой инспекции рекомендуем измерять эффективность всех изменений и своевременно корректировать свои затраты. Стоимость такой инспекции зависит от типа продукта и многих других факторов. Мы тратим на инспекцию качества на постоянно растущих проектах примерно 750 тыс. руб. в месяц без учёта стоимости времени команды проекта. При этом статистически отток денег за 2018 и 2019 год составил 340 млн руб. После внедрения процедур инспекции качества значение оттока относительно всего годового оборота уменьшилось на 12%.

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

Больше материалов смотрите здесь.