mttr что это такое
Как вычисляется среднее время до отказа и вероятность безотказной работы?
Понятиям MTTF (Mean Time To Failure — среднее время до отказа) и другим терминам теории надежности посвящено большое количество статей, в том числе на Хабре (см., например, тут). Вместе с тем, редкие публикации «для широкого круга читателей» затрагивают вопросы математической статистики, и уж тем более они не дают ответа на вопрос о принципах расчета надежности электронной аппаратуры по известным характеристикам ее составных элементов.
В последнее время мне довольно много приходится работать с расчетами надежности и рисков, и в этой статье я постараюсь восполнить этот пробел, отталкиваясь от своего предыдущего материала (из цикла о машинном обучении) о пуассоновском случайном процессе и подкрепляя текст вычислениями в Mathcad Express, повторить которые вы сможете скачав этот редактор (подробно о нем тут, обратите внимание, что нужна последняя версия 3.1, как и для цикла по machine learning). Сами маткадовские расчеты лежат здесь (вместе с XPS- копией).
1. Теория: основные характеристики отказоустойчивости
Вроде бы, из самого определения (Mean Time To Failure) понятен его смысл: сколько (конечно, в среднем, поскольку подход вероятностный) прослужит изделие. Но на практике такой параметр не очень полезен. Действительно, информация о том, что среднее время до отказа жесткого диска составляет полмиллиона часов, может поставить в тупик. Гораздо информативнее другой параметр: вероятность поломки или вероятность безотказной работы (ВБР) за определенный период (например, за год).
Для того чтобы разобраться в том, как связаны эти параметры, и как, зная MTTF, вычислить ВБР и вероятности отказа, вспомним некоторые сведения из математической статистики.
Ключевое понятие теории надежности — это понятие отказа, измеряемое, соответственно, интервальным показателем
Q(t) = вероятность того, что изделие откажет к моменту времени t.
Соотвественно, вероятность безотказной работы (ВБР, в английской терминологии «reliability»):
P(t) = вероятность того, что изделие проработает без отказа от момента t0=0 до момента времени t.
По определению, в момент t0=0 изделие находится в работоспособном состоянии, т.е. Q(0)=0, а P(0)=1.
Оба параметра — это интервальные характеристики отказоустойчивости, т.к. речь идет о вероятности отказа (или наоборот, безотказной работы) на интервале (0,t). Если отказ рассматривать, как случайное событие, то, очевидно, что Q(t) — это, по определению, его функция распределения. А точечную характеристику можно определить, как
p(t)=dQ(t)/dt = плотность вероятности, т.е. значение p(t)dt равно вероятности, что отказ произойдет в малой окрестности dt момента времени t.
И, наконец, самая важная (с практической точки зрения) характеристика: λ(t)=p(t)/P(t)=интенсивность отказов.
Это (внимание!) условная плотность вероятности, т.е. плотность вероятности возникновения отказа в момент времени t при условии, что до этого рассматриваемого момента времени t изделие работало безотказно.
Измерить параметр λ(t) экспериментально можно путём испытания партии изделий. Если к моменту времени t работоспособность сохранило N изделий, то за оценку λ(t) можно принять процент отказов в единицу времени, происходящих в окрестности t. Точнее, если в период от t до t+dt откажет n изделий, то интенсивность отказов будет примерно равна
λ(t)=n/(N*dt).
Именно эта λ-характеристика (в пренебрежении ее зависимостью от времени) и приводится чаще всего в паспортных данных различных электронных компонент и самых разных изделий. Только сразу возникает вопрос: а как вычислить вероятность безотказной работы и при чем здесь среднее время до отказа (MTTF).
2. Экспоненциальное распределение
В терминологии, которую мы только что использовали, пока не было никаких предположений о свойствах случайной величины — момента времени, в который происходит отказ изделия. Давайте теперь конкретизируем функцию распределения значения отказа, выбрав в качестве нее экспоненциальную функцию с единственным параметром λ=const (смысл которого будет ясен через несколько предложений).
Дифференцируя Q(t), получим выражение для плотности вероятности экспоненциального распределения: ,
а из него – функцию интенсивности отказов: λ(t)=p(t)/P(t)=const=λ.
Что мы получили? Что для экспоненциального распределения интенсивность отказов – есть величина постоянная, причем совпадающая с параметром распределения. Этот параметр и является главным показателем отказоустойчивости и его часто так и называют λ-характеристикой.
Мало того, если теперь посчитать среднее время до первого отказа – тот самый параметр MTTF (Mean Time To Failure), то мы получим, что он равен MTTF=1/ λ.
Но это еще не все, потому, что для экспоненциального распределения особенно легко делать расчет систем, состоящих из множества элементов. Но об этом – в следующей статье (продолжение следует).
Надежность, отказоустойчивость, доступность. Синонимы или.
Заказчики часто весьма туманно формулируют свои требования к дата-центрам. Их нужно переформулировать в терминах, которые можно зафиксировать в техническом задании.
Бывает, что требования излагаются примерно в таком виде: «Наш банк работает с очень серьезными клиентами, поэтому ЦОД должен работать всегда». Ну что делать? Мы принимаем эти требования и начинаем переводить их на язык техзадания, попутно объясняя, что понадобится внести серьезные изменения в предварительные проектные решения по инженерным системам.
Дадим некоторые пояснения к терминам, которыми мы пользуемся для достижения проектных показателей надежности, отказоустойчивости и доступности дата-центров. Речь пойдет об инженерных системах ЦОДа, хотя в принципе то же самое относится и к ИТ-оборудованию. Только полный анализ показателей всей инфраструктуры дата-центра может дать адекватную картину уровня доступности объекта.
Братья, почти близнецы MTBF, MTTF и MTTR
Два ключевых показателя в инженерных системах – это среднее время между отказами (Mean Time Between Failures, MTBF) и среднее время ремонта (Mean Time To Repair, MTTR):
MTBF = Общее время непрерывной работы
MTTR = Общее время простоя
Среднее время ремонта – среднее время, необходимое для ремонта устройства после отказа.
Денис СИВЦОВ, менеджер проектов подразделения IT Business, Schneider Electric
Большинству заказчиков, в особенности владельцам корпоративных ЦОДов, довольно затруднительно самостоятельно сформулировать четкие требования к отказоустойчивости создаваемых ими дата-центров. Как правило, это обусловлено тем, что не всегда есть ясное понимание того, насколько бизнес зависит от конкретных ИТ-сервисов и какие потери будет нести компания в периоды, когда тот или иной сервис не работает. В результате в процессе проектирования могут возникнуть сложности с определением необходимого уровня доступности ИТ-оборудования, на котором функционируют соответствующие сервисы. Это приводит к тому, что зачастую невозможно корректно задать требования к отказоустойчивости инженерной инфраструктуры ЦОДа, которая должна обеспечить работоспособность данного оборудования. В такой ситуации для разработки детального ТЗ заказчик может выбрать один из следующих вариантов:
1) привлечь консультантов (только для разработки ТЗ или для чтобы они полностью контролировали данный проект, как на этапе проектирования, и так и на этапе строительства, осуществляя всесторонний технический надзор и не допуская расхождений между требованиями и результатом);
2) разработать ТЗ самостоятельно, опираясь на требования к строительству дата-центров, содержащиеся в международных стандартах или, например, в рекомендациях такой известной экспертной организации, как Uptime Institute (правда, и в этом случае для чтобы обеспечить превращение рекомендаций в четкие требования для проектировщиков, без консультантов не обойтись).
Стоит отметить, что рекомендации Uptime Institute не привязаны ни к стране, ни к климату, ни к каким-либо другим характеристикам окружающей среды, в которой работает ЦОД. Они формулируются исходя из требований бизнеса к надежности инженерной инфраструктуры или к ЦОДу. Причем необходимо уделять внимание отказоустойчивости не только ЦОДа, но и ИТ-инфраструктуры в целом, поскольку нет смысла в суперотказоустойчивом ЦОДе при неработающей ЛВС или каналах связи и т.п. Рекомендации Uptime Institute универсальны, и их требования иногда могут оказаться избыточными. Поэтому в некоторых случаях частью требований можно пренебречь без ущерба для отказоустойчивости ЦОДа (и тем самым немало сэкономить), так как вероятность некоторых отказов в конкретном дата-центре может быть крайне мала. Но чтобы определить возможность такого отступления от требований, безусловно, необходимо привлекать консультанта, который хорошо разбирается в рекомендациях Uptime Institute и обладает опытом строительства ЦОДов с похожими характеристиками и в условиях, аналогичных тем, в которых будет создаваться новый дата-центр.
Стоит также отметить, что разные типы заказчиков обычно предъявляют разные требования к надежности своих ЦОДов (корпоративным и коммерческим дата-центрам). В коммерческих ЦОДах отказоустойчивость напрямую влияет на доходы заказчика, поэтому требования к ней значительно выше, чем в корпоративных ЦОДах. Хотя иногда высокий уровень надежности требуется и от некоторых корпоративных дата-центров (например, от ЦОДов банков, бирж и т.п.).
В любом случае, когда при создании ЦОДа хочется найти компромисс между затратами и отказоустойчивостью, следует привлекать опытных консультантов, которые в каждой ситуации могут подобрать наиболее эффективное решение для конкретного заказчика. 
Для тех объектов, которые не могут быть отремонтированы и просто заменяются новыми, применяется термин «средняя наработка до отказа» (Mean Time To Failure, MTTF). По сути, это среднее время, которое проработает устройство до того момента, как сломается. Для ремонтопригодных устройств среднее время между отказами можно определить как сумму MTTF и MTTR (см. рисунок). Другими словами, средняя наработка на отказ – это среднее время от начала одного сбоя до начала другого. Это различие между терминами важно, если время ремонта составляет значительную часть общего времени работы устройства.
Например, для лампочки в светильнике наиболее подходящий показатель – MTTF, так как она ремонту не подлежит. Для светильника же будет применяться MTBF, поскольку замену лампочки можно считать ремонтом светильника. Но MTBF светильника почти равен MTTF лампочки, поскольку ее замена производится всего 0,0167 ч, а ее ресурс – целых 10 000 ч. Таким образом, MTBF = MTTF (10 000 ч) + MTTR (0,0167 ч) = 10 000,0167 ч. Как видите, разница незначительна.
Другой пример: без замены масла в двигателе автомобиля поломка может произойти после 500 ч езды по шоссе – это MTTF. Если предположить, что на замену двигателя потребуется 12 ч (MTTR), то среднее время между отказами автомобиля из-за поломки двигателя (MTBF) составит 512 ч.
Большая часть технологического оборудования, подобно автомобилям, в случае поломки будет отремонтирована, а не заменена, поэтому в контексте надежности оборудования ЦОДа показатель «среднее время между отказами» больше всего подходит для измерений.
Что такое отказ?
Термин «отказ» может употребляться в нескольких значениях.
Например, источник бесперебойного питания выполняет пять функций в двух состояниях. Когда основное питание доступно, он 1) позволяет защитить питание от основного источника к машине; 2) стабилизирует питание путем ограничения скачков или колебаний; 3) запасает энергию в аккумуляторе до полного заряда батареи. Когда основное питание прерывается, ИБП 4) защищает поставку непрерывной мощности к машине; 5) подает сигнал, указывающий, что основное питание выключено.
Нет никаких сомнений, что происходит отказ, если ИБП прекращает защиту основного питания машины (функция 1). Отказы для функций 2, 3 или 5 могут быть неочевидными, так как «защищенная» машина по-прежнему работает на основном питании или питании от батареи. Даже если эти сбои заметили, меры по их устранению могут не быть приняты незамедлительно, так как «защищенная» машина все еще работает и ее работа может быть важнее, чем ремонт или замена ИБП.
Что такое доступность?
Доступность устройства для запланированного рабочего времени математически выражается отношением общего времени, когда оборудование находится в работоспособном состоянии, к общему времени эксплуатации.
Автомобиль в приведенном выше примере имеет доступность 500 / (500 + 12) = 97,66% времени. Ремонт является внеплановым простоем. С плановой получасовой заменой масла каждые 250 ч, когда индикатор на приборной панели предупреждает водителя, доступность увеличится до 250 / (250 + 0,5) = 99,8%. Если замена масла производится по расписанию как мероприятие по техническому обслуживанию, да еще с предоставлением подменного автомобиля, то доступность передвижения на автомобиле достигнет 100%.
Почему это важно? Доступность – это ключевой показатель производственного процесса; он является частью метрики «общая эффективность оборудования» (OEE). Производственное расписание, которое включает в себя время простоя для профилактического обслуживания, может точно предсказать общий объем производства. Графики, которые игнорируют среднюю наработку на отказ и среднее время ремонта, – это просто будущие бедствия, ожидающие ликвидации.
Как рассчитать фактическое среднее время между отказами? Фактическая или историческая средняя наработка на отказ рассчитывается с помощью наблюдений в реальной ситуации (существует отдельная дисциплина для разработчиков оборудования, базирующаяся на компонентах и предполагаемом уровне нагрузки). Расчет фактического среднего времени между отказами требует множества наблюдений, для каждого из которых должны определяться:
Uptime moment (u)– момент времени начала работы оборудования (изначально или после ремонта);
Downtime moment (d) – момент времени, в который оборудование сломалось после начала работы.
Время между отказами (TBF) – это, соответственно, разность d – u.
Для расчетов необходима совокупность пар моментов ui и di (i изменяется от 1 до n, где n – количество наблюдений). Среднее время между отказами рассчитывается по формуле:
Вспомним теперь, из чего состоит инженерная инфраструктура дата-центра: многочисленные системы питания, системы охлаждения/кондиционирования, системы дренажа, системы освещения и т.д. Каждая система, в свою очередь, состоит из множества элементов, которые имеют свои показатели времени наработки на отказ. Таким образом, чем сложнее инженерная инфраструктура дата-центра, тем больше в ней будет возникать отказов. Именно поэтому надо стремиться к разумному упрощению систем.
Что же такое надежность?
Надежность – это свойство оборудования (системы) сохранять значения установленных параметров функционирования в определенных пределах, соответствующих заданным режимам. Надежность – комплексный параметр, который в зависимости от назначения системы и условий ее эксплуатации может включать в себя безотказность, долговечность, ремонтопригодность и доступность как в отдельности, так и в разных сочетаниях. Работоспособность – это состояние системы, при котором она соответствует всем требованиям, предъявляемым к ее основным параметрам. Показатели могут со временем меняться. Изменение, выходящее за допустимые границы, приводит к возникновению отказа. Долгое время надежность не измерялась количественно, что сильно затрудняло ее объективную оценку. Для оценки использовались качественные определения – «высокая», «низкая» и др. Установление количественных показателей и способов их измерения и расчета положило начало научным методам в исследовании надежности.
Количественные показатели надежности определяются путем расчетов, проведением испытаний, статистической обработкой данных эксплуатации и математическим моделированием. Расчеты надежности производятся главным образом на этапе проектирования с целью прогнозирования ожидаемой надежности данной системы. Это позволяет выбрать наиболее подходящий вариант технического решения и методы обеспечения надежности, выявить слабые места, обоснованно назначить рабочие режимы, форму и порядок обслуживания системы.
Надежность можно повышать разными способами:
Необходимость и избыточность
Все вышеописанные расчеты подробно рассматриваются в двух десятках ГОСТов серии 27 «Надежность в технике». Как мы с вами понимаем, такие расчеты по надежности ЦОДа чрезвычайно трудоемки, поскольку компонентов в системе жизнеобеспечения ЦОДа много, а добыть информацию о MTBF, MTTR и MTTF для каждого элемента почти невозможно.
Авторам доводилось бывать на немецком заводе холодильного оборудования. И на вопрос о MTBF холодильной машины им ответили, что такой параметр известен только для одного из компонентов машины.
Поскольку мы инженеры, нам часто приходится действовать как в анекдоте про физика, математика и инженера, которым поручили найти объем красных резиновых шаров, и физик объем измерил, математик вычислил, а инженер посмотрел в таблице. Применительно к ЦОДам есть свои «таблицы объема красных резиновых шаров» – это стандарты обеспечения доступности и отказоустойчивости. Наиболее известны документы Uptime Institute Tier Standard: Topology и Operational Sustainability. Первый документ говорит о проектировании ЦОДа, второй – о его обслуживании. Кроме того, существуют и другие системы классификации ЦОДов по уровню надежности.
Некоторые системные интеграторы мирового масштаба не поддержали концепции и критерии Tier Standard: Topology. Они сочли, во-первых, что критерии Uptime Institute зачастую слишком категоричны и не учитывают многих факторов, специфичных для конкретного ЦОДа, и во-вторых, что наработки и информацию, накопленные ими за долгое время, следует хранить внутри компании, так как это ее интеллектуальная собственность. Этот довод понятен; посмотрим, какие же факторы должны браться в расчет при определении требуемого уровня надежности.
Прежде всего – бизнес-задачи заказчика. У разных заказчиков задачи различаются, как различаются требования к ЦОДу провайдера, ЦОДу поисковой системы, коммерческому ЦОДу, ЦОДу банка, суперкомпьютера и т.д. К примеру, для ЦОДа поисковой системы главное – доступность информации. Крупный поисковик при нештатной ситуации в одном ЦОДе может распределить запросы на другие работающие ЦОДы, при этом конечный пользователь разницы в качестве предоставления услуги не заметит. Другая ситуация может возникнуть в ЦОДе суперкомпьютера, где в зависимости от ситуации может появиться возможность снизить мощность ИТ-оборудования без прерывания технологического процесса. То есть необходимо разбираться, где конкретно должна быть обеспечена надежность – на уровне инженерных систем, на уровне ИТ-оборудования, на уровне информации или на каком-либо ином уровне.
Второй фактор – локализация заказчика. В зависимости от местных норм и правил требования к системам ЦОДа могут меняться. Так, пытаясь выполнить и локальные нормы, и требования Uptime Institute, можно получить ЦОД с двумя независимыми городскими вводами и резервированием 2N по дизель-генераторным установкам, что, на наш взгляд, избыточно.
Как видим, достаточная надежность может быть обеспечена разными способами и подходами, не всегда традиционными и лежащими в рамках стандартов, но менее затратными и не такими сложными. И из всего вышесказанного можно сделать достаточно банальный, но трудный в реализации вывод. Если вы собираетесь построить оптимальный по надежности и стоимости ЦОД, наиболее рациональным подходом будет максимальное упрощение инженерной инфраструктуры и уменьшение количества элементов в каждой системе.
9 метрик, которые могут иметь значение для современных команд по разработке ПО
Перевод статьи подготовлен в преддверии старта курса «Team Lead 2.0».
Как я отмечал в статье «Why metrics don’t matter in software development unless you pair them with business goals», выбор метрик нужно продумывать очень тщательно, чтобы дать ответы на вопросы, которые ставит перед собой бизнес. Вот эта критическая точка: измерения должны быть спроектированы так, чтобы отвечать на вопросы бизнеса. И эти вопросы никогда не будут звучать как «Сколько у нас сейчас тысяч строк кода в проекте?»
В этой статье продолжается тема, начатая в предыдущей. Сначала мы поговорим о конкретных метриках, которые должна использовать каждая команда, или по крайней мере планирует использовать для того, чтобы заметно улучшить производительность. Обратите внимание, что название этой статьи начинается как «9 метрик, которые МОГУТ иметь значение…», потому что важно именно то, как эти метрики повышают ценность бизнеса. Как вы их будете использовать зависит только от вас. Завершим мы статью рассказом о том, как осмысленно сочетать эти метрики между собой, а также сформулируем и проверим гипотезу о ценности бизнеса.
Начните с измерения правильных вещей
Здесь представлены 9 объективных показателей (или метрик), которые необходимо постоянно отслеживать, чтобы инкрементально улучшать процессы и производственную среду. Улучшение этих показателей не гарантирует, что уровень удовлетворенности ваших клиентов будет расти не по дням, а по часам. Однако, это те показатели, которые действительно нужно мониторить. В одном из последующих разделов «Собираем все вместе», вы узнаете почему.
Метрики Agile-процесса
Для agile и lean-процессов основными метриками будут leadtime, cycle time, velocity команды, и open/close коэффициент. Эти показатели помогают в планировании и принятии решений по улучшению процессов. Несмотря на то, что они не измеряют успешность или добавочную ценность, не имеют ничего общего с объективным качеством программного обеспечения, вам все равно нужно их отслеживать. Ниже я объясню почему.
Вы не можете точно знать или хотя бы предполагать откуда берутся те или иные цифры, но эти метрики дадут вам понимание того, где и на какие процессы стоит обратить внимание. Например, высокий показатель open и низкий close в течение нескольких итераций может означать, что issue продакшена сейчас имеют более низкий приоритет, чем новые функции, или, возможно команда сосредоточена на сокращении технического долга и исправления целых классов проблем, или же, что единственный человек, который знал, как их исправить уволился или с ним что-то случилось. Из чисел вы первопричину точно не узнаете.
Аналитика продакшена
Частота сбоев приложения – количество раз, которое приложение «падает», деленное на количество использований. Этот показатель напрямую связан с MTBF и MTTR.
Обратите внимание, что ни одна из этих трех метрик не даст вам представление об отдельных функциях или задействованных пользователях. И все же, чем меньше значения показателей, тем лучше. Современные системы мониторинга приложений позволяют с легкостью собирать эти метрики по программам и транзакциям, но чтобы настроить правильные диапазоны для отправки предупреждений или триггеры для масштабирования (применительно к облачным системам), нужно время и тщательное осмысление.
Конечно, хотелось бы, чтобы наше ПО никогда не отказывало, но статистически это маловероятно. Хотелось бы, чтобы никакие важные данные не терялись и приложение восстанавливалось мгновенно, когда оно падает, но достичь этого бывает чрезвычайно сложно. Однако, если ваше программное обеспечение – это ваш источник дохода, то усилия того стоят.
Помимо MTBF и MTTR, более точные метрики основаны на отдельных транзакциях, приложениях и т.д., и они отражают доставленную бизнес-ценность, а также стоимость устранения сбоев. Если ваше приложение для обработки транзакций падает один раз из ста, но при этом поднимается через 1-2 секунды без критических потерь информации, то и с частотой сбоев в 1% можно жить. Но если с такой частотой падает приложение, которое обрабатывает 100 000 транзакций в день, теряет по 100$ за сбой и восстановление стоит 50$, то исправление этого 1% будет в приоритете. И такое исправление в итоге сильно повлияет на итоговую ситуацию.
Метрики безопасности
Безопасность – важный аспект качества программного обеспечения, который на поздних этапах разработки (или последующих этапах жизненного цикла) часто упускается. Инструменты анализа безопасности могут использоваться в процессе сборки вместе с более специализированными методами оценки и стресс-тестами. Требования к безопасности согласуются со здравым смыслом, но команда разработчиков должна всегда о них помнить, ровно как и о метриках от них происходящих.
Полный спектр методов обеспечения безопасности и связанных с ними метрик выходит за рамки этой статьи, но, как и в случае с метриками agile-процессов и метриками продакшена, существует несколько вполне конкретных показателей, которые будут иметь большое значение для удовлетворения потребностей ваших клиентов.
Вы найдете больше способов применения метрик безопасности в разработке программного обеспечения в статьях Application Security for Agile Projects и Security Threat Models: An Agile Introduction.
Заметка о метриках исходного кода
На сегодняшний день подключить сканнер исходников к пайплайну сборки и получить ворох объективных метрик достаточно легко. Существуют эмпирические средние значения, предлагаемые диапазоны и логические аргументы в пользу относительной важности этих показателей. Однако на практике эти инструменты более полезны для обеспечения соблюдения определенного стиля написания кода, выделения определённых антипаттернов и выявления аномалий и закономерностей.
Не стоит зацикливаться на цифрах. Приведу пример, чтобы вы поняли, к чему я клоню.
Допустим, вы обнаружили в классе метод с нелепым значением показателя сложности NPATH в 52 миллиона. То есть потребуется 52 миллиона тест-кейсов, чтобы протестировать каждый вариант выполнения метода. Вы можете отрефакторить код и получить более простую структуру, но прежде, чем это сделать, подумайте о том, как это отразится на бизнес-логике. Скорее всего этот старый страшный код работает достаточно хорошо (несмотря на то, что он может быть не полностью покрыт тестами). Ценным будет показать этот антипаттерн своей команде, чтобы они так больше не делали, поскольку фикс этого метода в целом не изменит ни одну стоящую бизнес-метрику.
Лучше всего, если команда согласится с уровнем требований и правилами, которым отвечает их код, но имейте в виду, что изучение аномалий и беспокойство на тему появления каких-либо закономерностей может отнимать время.
Соберем все вместе: Успех – универсальная метрика
Главный плюс использования автоматизированных инструментов для отслеживания и измерения показателей качества и анализа поведения пользователей кроется в том, что они освобождают время для работы над действительно важными показателями – показателями успеха.
Как использовать метрики для достижения успеха
У бизнеса есть цели. В целях кроются вопросы, например: «Как выглядит успех?» или «Как продукт повлияет на поведение клиентов?». Правильно сформулированные вопросы таят в себе метрики.
Другими словами, метрики должны использоваться только для ответов на поставленные вопросы, для проверки гипотез, сформулированных относительно конкретной бизнес-цели. Отвечать на эти вопросы следует до тех пор, пока ответы приводят к положительным изменениям.
Разве не все у всех проектов есть некоторый набор инвариантных целей, вопросов и гипотез, а следовательно, и метрик?
Да, но только с точки зрения бизнеса. Метрики уровня бизнеса, такие как вовлеченность пользователей, коэффициент закрытия сделок, генерирование доходов и т.д., дают фидбэк о том, как влияет бизнес на реальный мир. Изменения в ПО, которые повлияют на бизнес, также повлияют и на эти метрики.
На более тонком уровне разрешения каждая функция и User Story могут иметь свой собственный показатель успеха – предпочтительнее, чтобы он был единственным и был связан непосредственно с ценностью, которая доставляется клиенту. Закрытие 9 из 10 историй за спринт для функций, которые остаются недоставленными – это не успех, а поражение. Доставка историй, которые клиентам не нужны, и они их не используют – не успех, а пустая трата времени и сил. Создание историй, которые делают пользователя немного счастливее – вот это успех. Создание истории, которая не улучшила взаимодействие с пользователями, тоже своего рода успех, поскольку теперь вы знаете, что эта бизнес-гипотеза не работает, и можете освободить ресурсы для поиска других идей.
Как сформулировать ценностную гипотезу
Ценностная гипотеза – это утверждение о том, что, по вашему мнению, произойдет в результате добавления определенной функции. Взаимосвязь между программным обеспечением, желаемым результатом и метриками формирует ценностную гипотезу для функции (или системы, истории, обновления и т.д.). Гипотеза должна выражать ожидаемое изменение целевой метрики в течение определённого промежутка времени, а также понятие о ее эффективности. Вам нужно будет поговорить с командой и с Product Owner-ом, чтобы как минимум выяснить, что именно это функция или история может создать или улучшить применительно к бизнесу, чтобы сформулировать относительно нее ценностную гипотезу. Возможно, задать вопрос «почему» вам придется несколько раз (как ребенку), чтобы избавиться от невысказанных предположений, поэтому будьте терпеливы. Когда вы поймете, какой должна быть ценность для бизнеса, вы можете начать задавать вопросы, которые приведут вас к метрикам, дающим на них ответы.
Например, «техническая» история о повышении скорости оформления заказа в интернет-магазине может иметь под собой идею о том, что ускорение продаж приведет к росту их количества. Но почему мы так думаем? Много ли людей оставляют корзины с товарами во время процесса оформления заказа? Если вы пришли к консенсусу (подкрепили свои предположения данными), то ценностная гипотеза может быть звучать так: «Мы считаем, что ускорение процесса оформления заказа приведет к снижению коэффициента «отказа от корзины». В свою очередь это приведет к увеличению продаж и улучшению пользовательского опыта.»
Вероятно, вы предполагаете, что пользователям понравится ускорение оформления заказа, но не будет лишним спросить, заметили ли они это вообще. Коэффициент отказа от корзины и продажи можно замерить в течение определенного времени до внедрения нового процесса и после. Если коэффициент отказа от корзины падает, а продажи увеличиваются (с учетом статистических колебаний), то доказательства подтверждают гипотезу, и вы можете задаться вопросом, оправдано ли дальнейшее увеличение скорости оформления покупки. Если нет, то пускай эта метрика отойдет на задний план (или вообще исключите ее, чтобы не отвлекала), и переключите свое внимание на следующую гипотезу. Если коэффициент отказа от корзины уменьшается, а продажи остаются неизменными, проводите измерения дольше или попробуйте переосмыслить предполагаемую связь между отказом от корзины и продажами. Другими словами, используйте метрики, которые приносят значимые улучшения для того, чтобы учиться.
В некоторых случаях, гипотеза оказывается ошибочной, и мы отбрасываем метрики (и откатываемся к старой версии программного обеспечения) спустя несколько дней. В других случаях гипотеза может быть верной, поэтому мы продолжаем улучшать показатели в этой области в течение долгих лет.
Шесть эвристик для эффективного использования метрик
Мы увидели, как субъективные метрики делали больший вклад в успех бизнеса, чем старые добрые объективные показатели качества. Полученные знания и возможности для обучения преобладают над усилиями, необходимыми для поиска и измерения соответствующих бизнес-показателей функций. Условия бизнеса и возможности меняются постоянно, поэтому вместо того, чтобы выводить хрупкую формулу, которой можно было бы следовать, я дам шесть эмпирических правил, или эвристик, которые помогут сохранить сосредоточенность и гибкость. Пусть они помогут вам на вашем пути к качественному программному обеспечению и успеху!