Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

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

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

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

4 <h2>Контроль и инспекция качества</h2>

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

6 <p>Контроль качества можно разделить на две части - технический надзор и продуктовый (бизнес) надзор.</p>

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

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

9 <h2>Метрики и инструменты</h2>

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

11 <h4>Инспекция качества - это не только тестирование</h4>

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

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

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

15 <ul><li>Чек-лист для каждого процесса на проекте - требование к паспорту проекта, формат документирования, требования к формату проведения спринтов и ретроспектив или же требования к формату обработки change request’ов и т. д.</li>

16 <li>Чек-лист для каждого артефакта на проекте - требования к вёрстке, стандарты кодирования, гайдлайны для разработки дизайна и т. д.</li>

17 <li>Процедуры функционального тестирования (ручное или автоматическое тестирование по определённым сценариям). На выходе обязательно надо составлять баг-репорт и подсчитывать количество отладок в рамках одного баг-листа. Самая лучшая метрика для измерения эффективности этого процесса - количество вернувшихся багов (после внутреннего теста, бизнес-тестирования и обязательно в промышленной эксплуатации).</li>

18 <li>Процедуры общего тестирования инфраструктуры:</li>

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

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

21 <ul><li>Измерение довольства пользователя на уровне приложения (Важно! не всего продукта или сервиса, об этом расскажем дальше). Например, оценки мобильного приложения в сторах, замеры количества фидбеков по формам обратной связи на веб-приложениях и т. д.</li>

22 <li>Обязательное наличие документации по приложению: архитектура, функциональные требования, ПМИ, документирование кода и т. п.</li>

23 <li>Авторский надзор со стороны системной аналитики/архитектора по реализации той или иной функциональности + код-ревью. Метрикой может являться отклонение от квотируемого бюджета на поддержку и развитие системы.</li>

24 </ul><p>По мере необходимости список можно дополнять инструментами и метриками. Например, инспекцией по полноте и срокам доставки в промышленную эксплуатацию тех или иных новых "фич".</p>

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

26 <ol><li>Измерение продуктовых метрик (конверсия пользователей по шагам воронки к целевому действию, сокращение стоимости того или иного процесса и т. д.).</li>

27 <li>Измерение того, насколько пользователь доволен продуктом и сервисом. Например, с помощью индекса потребительской лояльности (NPS) и индекса удовлетворенности клиентов (CSI).</li>

28 <li>Показатели веб-аналитики на всех шагах воронки (возможно, дашборды).</li>

29 <li>Процедура качественных исследований аудитории продукта и сервиса. Например, качественные опросы, глубинные интервью и т. д.</li>

30 <li>Замер количества новых пользователей (и их вклада в продукт) за отчётный период (неделя или месяц).</li>

31 <li>Количество "умерших" пользователей за отчётный период (обязательно выявлять критерии "умирания").</li>

32 <li>Месячная активная аудитория/частота использования. Например: среднее количество активных действий за отчётный период;</li>

33 <li>LTV (Live Time Value) - деньги, которые пользователь тратит в вашем продукте за все время его использования.</li>

34 <li>CAC (Customer Acquisition Cost) - ваши затраты на привлечение пользователя.</li>

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

36 <h2>Обеспечение качества (Quality assurance)</h2>

37 <p>Обеспечение качества - часть менеджмента качества, направленная на создание уверенности в том, что требования к качеству будут выполнены.</p>

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

39 <ol><li>За процедуры технической инспекции выпускаемого продукта часто отвечает тимлид или архитектор).</li>

40 <li>За процедуры продуктовой инспекции сервиса - владелец продукта или продюсер).</li>

41 <li>За глобальный контроль всех процессов по принятым стандартам -независимый специалист надзора QA-службы или руководитель проекта.</li>

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

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

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

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

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

47 <ol><li>Требуйте от подрядчиков выполнения жестких фиксированных стандартов качества. Кроме того, закрепите их внутри своей компании.</li>

48 <li>Формализуйте критерии приёмки (конкретные метрики успеха, конкретные тест-кейсы и т. д.), включая ограничения на итерации приёмки, входящие в оценку и передайте подряду.</li>

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

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

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

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

53 <ol><li>Предпроектное исследование (на выходе: ограничения и вижн-системы).</li>

54 <li>Проектирование архитектуры.</li>

55 <li>Чек-листы ко всем процессам и артефактам при разработке продукта.</li>

56 <li>Авторский надзор: отдельно технический и отдельно продуктовый на каждом этапе разработки.</li>

57 <li>Тестирование функциональности и инфраструктуры.</li>

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

59 <h2>Стоимость</h2>

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

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

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

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

64 <p><em>Больше материалов смотрите<a>здесь</a>.</em></p>