В чем выражается надежность метрики
Наука о данных. Модуль 6
Как проверить качество модели с помощью метрик
В предыдущих модулях мы прошли все основные шаги от постановки цели до создания обучающей выборки и тренировки алгоритмов.
В этом модуле вы узнаете:
• как с помощью метрик понять, насколько хорошо работает модель;
• какие метрики подходят для задач регрессии и классификации и в чем основные плюсы и минусы каждой;
• как выбрать метрику для проекта.
Оглавление
Модуль 6. Как проверить качество модели с помощью метрик
Почему мы выбираем метрику на самом старте проекта
Ваше сотрудничество с дата-сайентистом — это вариант отношений «заказчик — подрядчик», а о ключевых вещах и показателях в этом случае принято договариваться «на берегу». Метрика — один из таких ключевых показателей: с ее помощью вы будете оценивать результат работы алгоритма. Поэтому в процессе первоначального обсуждения проекта вопрос о метрике всплывет обязательно.
Давайте вспомним общую схему, по которой можно вести диалог и формулировать запрос к специалисту, и уточним ее, добавив в конец еще один шаг — выбор метрики. Чтобы вам было проще, разберем все на примере:
1. Определите бизнес-задачу
Вы: Компании нужно поднять выручку на 5% до конца года и…
2. Расскажите о конкретных шагах по ее достижению
Вы: … и для достижения этой цели мы хотим допродавать существующим клиентам цифровые продукты, которые будут удачно сочетаться с теми, что они уже у нас покупают. Но чтобы вероятность дополнительной покупки была высокой, рекомендации продуктов должны быть по-настоящему релевантными и качественными (по прикидкам отдела маркетинга, чтобы достичь показателей, мы должны убедить каждого десятого клиента).
3. Определите, можно ли решить задачу с помощью машинного обучения
Дата-сайентист: Можно проанализировать текущую базу клиентов, выявить их поведенческие паттерны и объединить клиентов со схожими паттернами в отдельные сегменты. Затем для каждого сегмента подобрать наиболее релевантные услуги или товары.
4. Определите, что у вас с данными, целевой переменной, объектами и прочим
Вы: У нас есть CRM (англ. Customer Relationship Management, система управления взаимоотношений с клиентами) и другие источники данных о клиентах — мы знаем, что и с какой частотой они покупали ранее, откуда они, какими еще услугами и продуктами компании пользовались или пользуются в их домохозяйстве.
Дата-сайентист: По идее, мы можем набрать достаточно признаков, а модель сама определит их веса и сгруппирует клиентов. Здесь угадывается задача кластеризации.
5. Определите метрику качества
Дата-сайентист: Итак, решено: мы строим рекомендательную систему. Остается понять, как мы определим, что алгоритм подсказывает именно то, что нужно людям? По какой метрике будем оценивать качество?
Чтобы вы могли ответить на этот вопрос, в модуле мы изучим основные метрики машинного обучения.
Метрики для задач регрессии: какие бывают, плюсы и минусы
Любой прогноз может быть не на 100% точен, а вот какое отклонение допустимо, решаете вы, исходя из задач и целей бизнеса. В этом видео Элен расскажет о пяти популярных метриках для работы с числовыми прогнозами и о том, как они помогают выявлять расхождения между оценкой модели и реальностью и «штрафовать» алгоритм за слишком неточные предсказания. Как всегда — с примерами.
Метрики продукта.Внешние и внутренние особенности
В данной статье речь пойдет о ключевых метриках продукта. Для чего и кому нужны внутренние и внешние показатели. Как происходит подбор необходимых метрик для любого продукта.
Что такое метрики продукта?
Рассмотрим ключевые и универсальные метрики для любого продукта:
Рассмотрим несколько вариантов расчета LTV.
1. LTV1 =(Доход от клиента)- (затраты на привлечение и удержание)
2. LTV2 =(Средняя стоимость продажи)*(среднее число продаж в месяц)*(сколько месяцев удерживается клиент)
Retention rate отражает сколько клиентов за определенный период остались с продуктом.Измерять можно в коэффициенте удержания за неделю, месяц, год. Именно Retention rate определяет в бизнесе потенциал роста и влияет на метрики монетизации.
Рассчитывается по формуле (Джеффа Хэдена)
Метрика указывающая на коэффициент оттока клиентов. Разделяется в основном на Customer churn и Revenue churn.
Эта метрика показывает, сколько клиент проводит времени в продукте, отслеживая частоту посещений и качество целевых действий. Больше применима для мобильных приложений.
Что такое внутренние метрики?
Под внутренними (или операционными) метриками продукта подразумеваются показатели, которые помогают понять как повлияли те или иные изменения на пользователя (клиента). Оценить изнутри результат работы команды, опираясь на данные этих метрик. Вырабатывать и проверять новые гипотезы, для максимального улучшения качества продукта.
Что такое метрики роста (внешние)?
Необходимо учитывать тип продукта, так как даже одна и таже метрика будет иметь разное значение для разных продуктов.
Следуя данным рекомендация, вам не составит большого труда, определиться с метриками продукта, над которым вы работаете.
Модели качества и надежности в программной инженерии
10.1.2. Метрики качества программного обеспечения
В настоящее время в программной инженерии еще не сформировалась окончательно система метрик. Действуют разные подходы к определению их набора и методов измерения [10.11-10.13].
Система измерения включает метрики и модели измерений, которые используются для количественной оценки качества ПО.
При определении требований к ПО задаются соответствующие им внешние характеристики и их атрибуты (подхарактеристики), определяющие разные стороны управления продуктом в заданной среде. Для набора характеристик качества ПО, приведенных в требованиях, определяются соответствующие метрики, модели их оценки и диапазон значений мер для измерения отдельных атрибутов качества.
Согласно стандарту [1.16] метрики определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе тестирования или функционирования (внешние метрики) продукта.
Остановимся на классификации метрик ПО, правилах для проведения метрического анализа и процесса их измерения.
Существует три типа метрик:
Метрики программного продукта включают:
Внутренние метрики продукта включают:
Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.
Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования и управления достижением качества конечного программного продукта.
Стандарт ISO/IEC 9126-2 определяет следующие типы мер:
Специальной мерой может служить уровень использования повторных компонентов и измеряется как отношение размера продукта, изготовленного из готовых компонентов, к размеру системы в целом. Данная мера используется также при определении стоимости и качества ПО. Примеры метрик:
При оценке общего количества некоторых величин часто используются среднестатистические метрики (среднее число операций в классе, наследников класса или операций класса и др.).
Как правило, меры в значительной степени являются субъективными и зависят от знаний экспертов, производящих количественные оценки атрибутов компонентов программного продукта.
На основе этих атрибутов можно вычислить время программирования, уровень программы (структурированность и качество) и языка программирования (абстракции средств языка и ориентация на проблему) и др.
В качестве метрик процесса могут быть время разработки, число ошибок, найденных на этапе тестирования и др. Практически используются следующие метрики процесса:
10.1.3. Стандартная оценка значений показателей качества
Оценка качества ПО согласно четырехуровневой модели качества начинается с нижнего уровня иерархии, т.е. с самого элементарного свойства оцениваемого атрибута показателя качества согласно установленных мер. На этапе проектирования устанавливают значения оценочных элементов для каждого атрибута показателя анализируемого ПО, включенного в требования.
По определению стандарта ISO/IES 9126-2 метрика качества ПО представляет собой «модель измерения атрибута, связываемого с показателем его качества». При измерении показателей качества данный стандарт позволяет определять следующие типы мер:
Метрики качества используются при оценке степени тестируемости с помощью данных ( безотказная работа, выполнимость функций, удобство применения интерфейсов пользователей, БД и т.п.) после проведения испытаний ПО на множестве тестов.
Наработка на отказ как атрибут надежности определяет среднее время между появлением угроз, нарушающих безопасность, и обеспечивает трудноизмеримую оценку ущерба, которая наносится соответствующими угрозами.Очень часто оценка программы проводится по числу строк. При сопоставлении двух программ, реализующих одну прикладную задачу, предпочтение отдается короткой программе, так как её создает более квалифицированный персонал и в ней меньше скрытых ошибок и легче модифицировать. По стоимости она дороже, хотя времени на отладку и модификацию уходит больше. Т.е. длину программы можно использовать в качестве вспомогательного свойства для сравнения программ с учетом одинаковой квалификации разработчиков, единого стиля разработки и общей среды.
Если в требованиях к ПО было указано получить несколько показателей, то просчитанный после сбора данных показатель умножается на соответствующий весовой коэффициент, а затем суммируются все показатели для получения комплексной оценки уровня качества ПО.
На основе измерения количественных характеристик и проведения экспертизы качественных показателей с применением весовых коэффициентов, нивелирующих разные показатели, вычисляется итоговая оценка качества продукта путем суммирования результатов по отдельным показателям и сравнения их с эталонными показателями ПО (стоимость, время, ресурсы и др.).
Все метрики 
-атрибута суммируются и образуют 
-показатель качества. Когда все атрибуты оценены по каждому из показателей качества, производится суммарная оценка отдельного показателя, а потом и интегральная оценка качества с учетом весовых коэффициентов всех показателей ПО.
В конечном итоге результат оценки качества является критерием эффективности и целесообразности применения методов проектирования, инструментальных средств и методик оценивания результатов создания программного продукта на стадиях ЖЦ.
Для изложения оценки значений показателей качества используется стандарт [10.4], в котором представлены следующие методы: измерительный, регистрационный, расчетный и экспертный (а также комбинации этих методов). Измерительный метод базируется на использовании измерительных и специальных программных средств для получения информации о характеристиках ПО, например, определение объема, числа строк кода, операторов, количества ветвей в программе, число точек входа (выхода), реактивность и др.
Регистрационный метод используется при подсчете времени, числа сбоев или отказов, начала и конца работы ПО в процессе его выполнения.
Для оценки значений показателей качества в зависимости от особенностей используемых ими свойств, назначения, способов их определения используются:
Атрибуты программной системы, характеризующие ее качество, измеряются с использованием метрик качества. Метрика определяет меру атрибута, т.е. переменную, которой присваивается значение в результате измерения.Для правильного использования результатов измерений каждая мера идентифицируется шкалой измерений.
Стандарт ISO/IES 9126-2 рекомендует применять 5 видов шкал измерения значений, которые упорядочены от менее строгой к более строгой:
Метрики — индикаторы здоровья проекта
В IT здоровый проект — это система или сервис, который, с одной стороны, качественный, то есть соответствует требованиям и нравится пользователям. С другой стороны, приносит прибыль, потому что бизнес всегда на самом деле хочет зарабатывать деньги. Без связки качества и бизнеса ничего путного не выйдет.
Под катом Руслан Остропольский (RusOstropolsky) расскажет всё о метриках, которые являются индикаторами здоровья IT-систем. Разберет, какие бывают метрики, как они меняются по мере развития проекта, какие в каком проекте лучше применять. Объяснит, как качество и бизнес помогают друг другу с точки зрения метрик и зачем нужна эта коллаборация.
О спикере и компании: Руслан Остропольский в IT с 2010 года, главная сфера интересов — обеспечение качества. Последние 5 лет работает в компании DocDoc, которая разрабатывает медицинские интернет-сервисы. Основной продукт — это онлайн-запись к врачу, более 2 млн пациентов записались к врачу через DocDoc, также есть направление диагностики, телемедицины и ДМС-страхование.
Когда качество и бизнес не дружат
Без обеспечения качества бизнесу будет трудно зарабатывать в долгосрочной перспективе. Нужна связка качества и бизнеса. Если её нет, то возможны следующие ситуации.
Во-первых, бывает качество ради качества: когда все известные виды тестирования применяются в одном маленьком стартапе. Сразу думать об автоматизации и тестировании под нагрузками можно, но если переборщить, то продукт может так и не дойти до продакшна. Поэтому нужно:
NB: QA на самом деле — это не тестирование, а общий подход на уровне компании к тому, как вы делаете хорошие продукты.
Как понять разрабатываете вы качественно или нет?
Для объективной оценки нужны метрики, которые бы показывали:
Как выбирать метрики
Выбирать метрики можно по трем принципам.
Там, где болит. Если случается какой-то инцидент, его нужно разобрать, обвесить метриками и посмотреть на боль: как проходит лечение, какая динамика, исправляются ли баги.
При целевом подходе мы заведомо ориентируемся на цели, например, ускорение и автоматизацию. Раньше у нас автоматическое тестирование занимало два часа. Мы поставили цель в 10 минут и по метрикам смотрели, приближаемся ли к этому значению.
Но невозможно получить здоровый проект, если метрики не имеют никакой связи с бизнесом, они только технические, а бизнес не получает результатов. И наоборот, если багов нет, а бизнес при этом теряет деньги, значит, происходит что-то странное.
При этом важно помнить, что бывает разный бизнес и разные стадии проекта. Стартапу, растущей компании или проекту в стадии расширения нужны разные метрики. Это как с болезнью — если вы просто кашляете, можно померить температуру, выпить аскорбинку, и всё пройдет. Если же у вас подозрение на пневмонию, нужно сделать снимки, пойти на обследование и лечиться по-другому.
Метрики на разных стадиях проекта
Расскажу, какие метрики мы измеряли, когда были стартапом, а потом стали расти и расширяться.
Стартап
На этом этапе продукт только зарождается, вы проверяете какую-то гипотезу, исследуете, нужно ли это людям.
На этапе стартапа для бизнеса важно, чтобы идеи доставлялись до пользователя как можно быстрее, и можно было их проверить. То есть нужно измерять time-to-market — скорость доставки идеи до пользователей (именно до продакшна, а не просто до релиза) и количество клиентов.
В части QA у нас было всего 3-5 метрик:
Растём
На следующем этапе мы уже научились стоять на ногах, немножечко ходим.
Нужды бизнеса эволюционируют, становится важно измерять:
Появляется автоматизация. Monkey testing уже недостаточно, и есть смысл вкладываться в расширение. На этом этапе появляется автоматическое тестирование, которое должно помочь сделать регрессионное тестирование быстрее. Соответственно, измеряется скорость тестирования релиза: насколько автоматизация оправдана. Печально, когда на автоматизацию ушло полгода, а релизы почему-то не ускорились.
Также измеряется объем релиза, чтобы видеть, если, например, разработчиков вместо 5 стало 15, но почему-то объем релиза не вырос.
Для сбора метрик на этапе роста кроме рук и Excel появляются специализированные системы. Системы — это любые инструменты, которые помогают создавать продукт. Если раньше те же тест-кейсы писались в Google docs, здесь появляются:
Обрастаем жиром
Растем дальше, «обрастаем жиром» — не влезаем в офисы, в которых сидели, и начинаем периодически переезжать.
Что важно для бизнеса?
Трудности
Все гладко не бывает, и мы не исключение. Расскажу, с какими трудностями мы столкнулись, когда проект достаточно разросся.
Систем стало очень много, появилась необходимость ими как-то управлять. Смотреть в каждую систему — это, как минимум, много времени.
Выросло количество направлений, как продуктовых, так и технических. Причем каждое направление развивается по-разному, некоторые из них запускаются как стартап, и накладывать на них всю машину метрик и обеспечения качества будет неправильным.
Усложнились процессы: если раньше над проектом работало 5 человек, которым было нетрудно договориться и действовать соответственно, то теперь нужно следить за процессами. Например, новых людей нужно вводить постепенно, иначе им будет трудно разобраться в накопившемся числе систем.
Данные и отчеты уникальны в рамках сервиса. Это вытекает из того, что систем много, и нужно их все смотреть. Каждый сервис порождает свои отчеты, и нужно следить за ними всеми. Причем настроить их под себя становится тяжелее: нужно либо обращаться в техподдержку за новым отчетом, либо пытаться настроить его самостоятельно с помощью скриптов.
А если данных много, то Exсel уже не помогает. Особенно если десятки людей начинают работать над одним файлом, в котором все настроено на формулах — кто-то один что-то поменял, все сломалось — увидели через неделю.
Наверное, так в компаниях и появляются аналитики — специальные люди, которые собирают и поддерживают статистику и данные, потому что занимает слишком много времени, чтобы можно было совмещать.
И конечно, становится гораздо сложнее анализировать информацию из-за того, что опять же много систем, разных данных, которые хочется между собой связать.
Лечим грусть
Можно уехать на море, отдохнуть, вернуться и посмотреть на опыт других компаний.
Логичное решение — собрать всё вместе с точки зрения данных и преобразовать в метрики.
Мы сформулировали следующие критерии:
Дашборды
У нас множество дашбордов, только активных технических сейчас около 30, а общих около 100.
Данные для дашборда собираются вообще отовсюду. Получается большое полотно, из которого можно формировать нужные отчеты. Ниже несколько примеров.
Разбивка багов по критичности
Здесь мы измеряем и отображаем число багов за определенный период и то, насколько они были критичными. Данные вытаскиваются из Jira. Сама Jira, наверное, может построить такой отчет, но не в очень удобной форме.
Разбивка багов по собственным полям
В Jira можно упаковывать любые кастомные поля, и эти поля могут являться аналитикой, которая также загружается в общую систему. Например, ниже баги по компонентам.
Есть такой же срез по командам, людям, направлениям. Это позволяет смотреть самые разные срезы.
Соотношение новых и закрытых багов
Если мы создаем 20 багов, а закрываем только 5, то в какой-то момент погрязнем в них. Поэтому нужно следить за цифрами и стремиться, чтобы соотношение было равно 1.
Тренд по багам за период
Чем удобна система, которую мы ввели, так это тем, что мы выгрузили все исторические данные и можем видеть динамику.
В Jira это сделать сложновато. У нас же все работает автоматически, причем можно выбирать любой период и смотреть, удалось ли что-то улучшить, и сработали ли введенные процессы и идеи.
Этапы нахождения багов
Если раньше мы измеряли только баги в бою, то сейчас стремимся, чтобы багов в бою не было совсем, и строим срезы на разных этапах: бой, релиз, тестирование, автоматизация, ревью, требования.
Дашборд автоматизации
Для автоматического тестирования тоже есть свой дашборд. Он очень большой, поэтому ниже два отдельных фрагмента.
Здесь отражается количество пропущенных багов. Если у вас покрытие 90%, но на самом деле половина из багов просто закомментирована или пропущена, то это весьма критично, потому что в действительности верно работает только 50% функциональности.
То же самое по фейлам: сколько тестов падает. Мы обычно выделяем разные причины падений: системное падение, падение бага, изменилась функциональность. Отдельно разделяем падения, которые зависели от системы и от окружения, и которые были чисто по тестам. Первое — это работа команды эксплуатации, второе — автоматизации.
Также смотрим покрытие автоматизацией. Забираем из TestRial все сьюты, а еще можем погрузиться в блоки функциональности и определить, например, что поиск покрыт на 30%.
Кроме того здесь отражаются данные по срезу статусов:
Дашборд Performance
Этот дашборд мы строим в Grafana, причем подгружаем метрики отдельно по API, фронтенду, бэкенду и серверной части. Есть блок, который показывает текущий срез последнего релиза. Соответственно, можно провалиться в каждую из метрик и посмотреть в динамике.
Это все накладывается на различную функциональность, разные страницы сайта.
Летим дальше
Но по дороге встречаются новые проблемы. Графиков слишком много, и поэтому их реже смотрят. Когда графиков 5, их легко проверять каждый день. С увеличением их количества получается режим раз в неделю — тоже хорошо. А потом внезапно 3 дня назад случился факап, который никто не заметил. Отсюда же, реакция становится долгой, а метрики и дашборды успевают устареть. На это есть разные причины, с которыми тоже надо уметь бороться.
Нужно сделать агрегированные графики: из 10 делаем один, который будет показывать состояние этих 10. Причем основные показатели вытаскиваем наверх. Вы открываете дашборд и сразу видите нужные значения, а потом уже все остальное, подробнее раскрывающее метрики.
Мы разделяем: бизнес-метрики, метрики процессов, QA-метрики (Web / Mobile, Ручное / Автоматизация, Performance).
Так выглядит агрегированный график (NPS, CSAT).
Наверху значения и дельта по сравнению с предыдущим периодом. В данном случае, если стрелочка красная, то нужно что-то делать, как минимум подробнее смотреть графики. Если стрелочка зеленая — значит, все хорошо и можно не реагировать.
Также в графики встроена возможность провалиться на уровень ниже, никуда не переходя.
Баги связаны с людьми, их допустившими (тестировщиками или разработчиками). Если кликнуть отдельно на какого-нибудь тестировщика, по нему откроется отдельная таблица — срез по задачам.
Следующим действием решим проблему с тем, что графики редко контролируются. А именно, расширим схему работы с данными и с метриками: добавим оповещения на нужные метрики.
Оповещения
Мы используем достаточно много оповещений. Приведу примеры категорий и конкретных ситуаций:
Примеры оповещений
На задачи, которые подгорают, бот пишет номер задачи, статус, приоритет, сколько времени задача уже тестируется и кто ее тестирует.
Оповещение, оформленное в виде сводки, приходит отдельному человеку, который смотрит, какие у него есть проблемы. Вот пример оповещений для ревью-кейса, которые присылает TestRial.
Здесь указано, какие кейсы на кого назначены, с каким статусом и кому надо посмотреть.
Еще один пример — бот Ябеда, который следит за процессами.
Это было нужно, чтобы настроить процесс связывания бага и задачи. Разработчик, разбирая баг, должен найти задачу, в которой мы этот баг пропустили, для последующей аналитики, чтобы знать, почему мы пропустили баг. Это своего рода разбор инцидента, но с запозданием.
Сколько нужно оповещений и как часто?
Если оповещений будет очень много, то от них будет много стресса. Поэтому мы для себя вывели правила управления оповещениями.
Слишком много оповещений — перестаем реагировать. 500 оповещений в день вы совершенно точно перестанете успевать просматривать, а значит можете пропустить важное.
Слишком мало — не видим проблем. Если сообщений слишком мало, например, просто половину выкинуть, можно не увидеть какую-то проблему.
Нет проблем — сводка по фактам. В случае отсутствия проблем оповещения тоже нужно посылать, но в виде сводки: что произошло за день, что работало, какие были задачи, что случилось. Если не делать сводку, можно подумать, что просто все сломалось и надо искать, какие оповещения отвалились.
Обычно алертинг настраивается на пороговое значение метрики: если метрика перешла порог, прилетает оповещение. Но, как правило, в этот момент уже поздно что-то исправлять, системе уже плохо. Мы на этом обожглись, поэтому ввели метод светофора:
Метрики и дашборды устаревают
Метрики и дашборды устаревают по мере того как меняется продукт. Некоторые из них становятся неактуальными, и можно перестать их отслеживать. В то же время смещаются приоритеты. Например, в начале наш фокус был направлен на скорость автоматизации, и мы завели много соответствующих оповещений, то теперь нам важнее скорость сайта, и у нас появилось много новых алертов для этого. И, конечно, меняются цели: багов теперь практически нет, можно следить за ними менее пристально.
Чтобы следить за актуальностью метрик и дашбородов, полезно делать следующее:
Пример метрик в команде Online
Для этой команды не важна скорость поставки релиза. Им важно количество интеграций с клинками и текущее состояние инфраструктуры, то есть сколько времени тратится на поддержку. Полезен срез по людям, кто как отрабатывает внутри команды. Соответственно, дашборд этой команды очень отличается от других команд.
QA и бизнес
Наконец, рассмотрим на кейсах связку QA и бизнеса.
Упала конверсия
Эксперты говорят: это эффект сезонности, просто люди сейчас не болеют, поэтому не звонят.
Проверяем: на определенном сегменте с определенным решением пользователь видит белый экран, который ни мониторинг, ни тесты не смогли поймать.
Но при этом есть график связки релиза и конверсии:
Здесь узлы — это релизы, по оси X конверсия в запись (фиолетовая линия), в заявку (синяя) и в открытие формы (зеленая). Когда мы видим, что график где-то проседает, обращаемся к релизу (на него можно кликнуть) и видим связанную задачу: когда она была, кто накатывал. Можно быстро перейти и посмотреть, что же накатилось. Как минимум, можно развернуть эту ветку задач на окружение определенным тестом и посмотреть, это реальная причина проблем или нет. Такие срезы есть по устройствам, окружениям и другим параметрам, которые только есть.
Много багов в биллинге
Эксперты говорят: любой баг в биллинге — это блокер, его надо исправлять, и багов очень много (раз человек сам их нашел, ему кажется, что много).
Проверяем: баги были по «спящим клиентам». Это те клиенты, которые или не платили деньги, или не собираются платить, или платили, но очень мало. Это явно не было каким-то блокером. Соответственно не все из этих багов напрямую влияли на деньги.
Позже мы сделали срез, что влияет на деньги, а что нет. Оказалось, что влиял только один баг, а десяток не влияли. Соответственно исправлять их в режиме блокера не было никакого смысла.
Падение количества звонков в колл-центре
Эксперты говорят: доля онлайна растет, люди точно уже не звонят, а записываются через интернет. Плюс, молодое поколение не любит звонить в принципе.
Проверяем: был сбой у провайдера, который предоставляет нам телефонию, и после восстановления, часть телефонов не вернулась.
Это очень сложно заметить сходу, потому что у нас более 10 тысяч номеров, и если не вернулось 500, мы это вообще не увидим. Ночные тесты это поймают, но пройдут целые сутки.
Есть график по звонкам. Если видим падение, должен сработать алертинг, что звонков стало меньше обычного.
Суть этих примеров в том, что ответы не в ветвях, а у корней, поэтому нужно всегда проверять экспертов. Что бы ни казалось на интуитивном уровне, что бы эксперт не говорил, надо всегда докопаться до сути через метрики. Есть техника «5 почему», которая позволяет это сделать.
Если у вас есть технические метрики, подумайте, как их можно применить к вашему бизнесу, чтобы вы лучше чувствовали друг друга.
Итоги
Здоровый проект — это не система и не робот, а живой организм. В нем много составляющих, которые помогают ему повышать качество и быть здоровым. Вы не можете сделать систему, которая будет решать всё за вас. Люди, процессы, системы, информация — это организм, который надо улучшать.
Нет универсального набора метрик:
Метрики — это не решения. Это всего лишь показатели здоровья проекта, которые говорят о текущем состоянии и о его динамике. Оповещения как раз являются индикаторами, которые помогут не пропустить, если что-то случится.
Но в итоге принимают решения люди. Система за вас не скажет, что вам делать.
Что получилось у нас:
50 метрик QA и более 100 остальных.
Наша конференция, которая объединяет в себе все аспекты разработки качественных продуктов, в следующем году переродится, выпорхнет из-под крыла РИТ++ и станет самостоятельным масштабным мероприятием TechLead Conf. Дату и место скоро объявим в telegram-канале, но если вы на собственном опыте убедились, что процесс разработки – это не набор несвязанных между собой кирпичиков, и хотите поделиться решениями по выстраиванию инженерных процессов, подавайте заявку на доклад, не дожидаясь анонсов.