Метрики здоровья вашего IT продукта

1️⃣ Глава: «Вступление»

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

Но самое интересное, что 7 из 10 основателей стартапов почему не задумается от показателях его будущей компании от слова "совсем"...

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

Для объективной оценки проекта как раз и нужны метрики, которые бы показывали:

• Факт проблем. Что у вас в принципе есть проблемы, а если проблем нет, надо их поискать более тщательно. Скорее всего, они где-то есть, просто вы их еще не видите.
• Факт результатов. Проекты создаются, чтобы заработать денег, выйти на рынок, увеличить конверсию. Эти результаты нужно отслеживать.
• Текущее состояние. Где вы находитесь на пути к поставленным целям, сколько у вас в текущий момент багов, успеваете ли вы в спринт, с какой скоростью двигаетесь.

Выбирать метрики нужно по трем принципам.

1) Там, где болит. Если случается какой-то инцидент, его нужно разобрать, обвесить метриками и посмотреть на боль: как проходит лечение, какая динамика, исправляются ли баги.

2) При целевом подходе мы заведомо ориентируемся на цели, например, ускорение и автоматизацию. Раньше у нас автоматическое тестирование занимало два часа. Мы поставили цель в 10 минут и по метрикам смотрели, приближаемся ли к этому значению.

3) В Связке с бизнесом. Но невозможно получить здоровый проект, если метрики не имеют никакой связи с бизнесом, они только технические, а бизнес не получает результатов. И наоборот, если багов нет, а бизнес при этом теряет деньги, значит, происходит что-то странное.

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

2️⃣ Глава: «Метрики разных стадий проекта»

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

2.1 Стартап

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

На этапе стартапа для компании важно, чтобы идеи доставлялись до пользователя как можно быстрее, и быстро можно было их проверить. То есть нужно измерять time-to-market — скорость доставки идеи до пользователей (именно до продакшна, а не просто до релиза) и количество клиентов.

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

2.2 Растём

На следующем этапе компания уже научились стоять на ногах, немножечко ходить и чуть бежать).

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

• Трафик — когда стало понятно, что продукт нужен пользователям, генерируется как можно больше трафика, например, появляются партнерские программы.
• Масштабирование — насколько возможно вырасти как со стороны продукта, так и со стороны разработки.

Объем метрик уже становится больше: 10-15 метрик. Если в стартапе мы создавали продукт по нашим ощущениям, например, основатель говорил: «Хочу синюю кнопку», и все делали ее, то теперь есть первая статистика. Можно пропускать фичи через A/B-тесты и не забывать измерять результаты.

Появляется автоматизация. Monkey testing уже недостаточно, и есть смысл вкладываться в расширение. На этом этапе появляется автоматическое тестирование, которое должно помочь сделать регрессионное тестирование быстрее. Соответственно, измеряется скорость тестирования релиза: насколько автоматизация оправдана. Печально, когда на автоматизацию ушло полгода, а релизы почему-то не ускорились.

Также измеряется объем релиза, чтобы видеть, если, например, разработчиков вместо 5 стало 15, но почему-то объем релиза не вырос.

Для сбора метрик на этапе роста кроме рук и Excel появляются специализированные системы. Системы — это любые инструменты, которые помогают создавать продукт. Если раньше те же тест-кейсы писались в Google docs, здесь появляются:

• менеджер-системы, например, TestRail;
• Google Analytics для сбора данных о пользователях;
• Report portal, Allure для автоматизации.

Система строит внутри себя еще дополнительные метрики и отчеты.

2.3 Обрастаем жиром

Растем дальше, «обрастаем жиром» — не влезаем в офисы, в которых сидели, и начинаем периодически переезжать.

Что важно для бизнеса на этом этапе?

• LTV — Нужно удерживать клиентов. Если раньше клиент записывался один раз и уходил, то сейчас, очевидно, что нужно его удерживать, строить пользовательский сервис.
• Бренд / Репутация — Если раньше люди обращаясь в DocDoc, могли думать, что это клиника, теперь они знают, что попали именно в сервис, который им помогает.
• SLA — Так как люди начинают пользоваться сервисом постоянно, доступность сервиса становится критичной, потому что любой простой напрямую влияет на деньги.
• Данные — Появляются первые данные, причем как продуктовые, так и технические и пользовательские, которые нужно уметь обрабатывать и хранить. Встает вопрос безопасности.
• Конверсия — На этапе масштабирования не создается принципиально новый продукт, а улучшается созданный.

В обойму компании уже входит примерно 30-50 метрик. Мы измеряем:

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

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

2.4 Трудности

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

a) Систем стало очень много, появилась необходимость ими как-то управлять. Смотреть в каждую систему — это, как минимум, много времени.

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

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

d) Данные и отчеты уникальны в рамках сервиса.
Это вытекает из того, что систем много, и нужно их все смотреть. Каждый сервис порождает свои отчеты, и нужно следить за ними всеми. Причем настроить их под себя становится тяжелее: нужно либо обращаться в техподдержку за новым отчетом, либо пытаться его самостоятельно с помощью скриптов.

e) Exсel уже не помогает, когда данных и метрик великое множество.
Особенно если десятки людей начинают работать над одним файлом, в котором все настроено на формулах — кто-то один что-то поменял, все сломалось — увидели через неделю.

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

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

2.5 Лечим грусть

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

Логичное решение — собрать всё вместе с точки зрения данных и преобразовать в метрики.

2.6 Дашборды

В такой компании уже обычно множество дашбордов, только активных технических может быть около 30, а общих около 100 в сумме.

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

a) Разбивка багов по критичности

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

b) Разбивка багов по собственным полям

В Jira можно упаковывать любые кастомные поля, и эти поля могут являться аналитикой, которая также загружается в общую систему. Например, ниже баги по компонентам.

Есть такой же срез по командам, людям, направлениям. Это позволяет смотреть самые разные срезы.

c) Соотношение новых и закрытых багов

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

d) Тренд по багам за период

Чем удобна система, которую вводим, так это тем, что мы выгружаем все исторические данные и можем видеть динамику...

В Jira это сделать сложновато. У нас же все работает автоматически, причем можно выбирать любой период и смотреть, удалось ли что-то улучшить, и сработали ли введенные процессы и идеи.

e) Этапы нахождения багов

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

f) Дашборд автоматизации

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

Здесь отражается количество пропущенных багов. Если у вас покрытие 90%, но на самом деле половина из багов просто закомментирована или пропущена, то это весьма критично, потому что в действительности верно работает только 50% функциональности.

То же самое по фейлам: сколько тестов падает. Мы обычно выделяем разные причины падений: системное падение, падение бага, изменилась функциональность. Отдельно разделяем падения, которые зависели от системы и от окружения, и которые были чисто по тестам. Первое — это работа команды эксплуатации, второе — автоматизации.

Также смотрим покрытие автоматизацией. Забираем из TestRial все сьюты, а еще можем погрузиться в блоки функциональности и определить, например, что поиск покрыт на 30%.

Кроме того здесь отражаются данные по срезу статусов:

• New — новая функциональность;
• Need correction — нужно апдейтить кейс;
• Not need — не хотим покрывать автоматизацией;
• Done — покрыто.

На критичность тоже есть свой срез.

g) Дашборд Performance

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

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

3️⃣ Глава: «Летим дальше»

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

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

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

Например разделяем: бизнес-метрики, метрики процессов, QA-метрики (Web / Mobile, Ручное / Автоматизация, Performance).

Так выглядит агрегированный график (NPS, CSAT) ⤵️

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

Также в графики встроена возможность провалиться на уровень ниже, никуда не переходя.

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

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

4️⃣ Глава: «Оповещения»

Стоит использовать достаточно много оповещений на практике.
Приведем примеры категорий и конкретных ситуаций:

• Performance;
• Автотесты -> например, если слишком повышается процент пропущенных багов или если слишком много новой функциональности не покрыто тестами;
• Входящие баги -> в компании любой человек может завести баг в тикет-системе. Это могло сопровождатся сообщением в личку, а теперь есть канал оповещений о новых багах, мало того, баги автоматически назначаются на исполнителя по очереди. Назначенный человек должен разобрать баг, иначе бот будет каждые 15 минут ему напоминать;
• Скорость тестирования/ожидания тестирования -> если видно, что человек закопался в задачу — неважно, он ее кодировал, делал ревью, тестировал — должно прилететь оповещение: «Ты уже три дня занимаешься одной задачей, возможно, ты закопался, попроси помощи»;
• Дефекты на задачу/команду;
• Ревью тест-кейсов -> это просто автоматизация процесса, чтобы не делать это руками.

4.1 Примеры оповещений

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

Оповещение, оформленное в виде сводки, приходит отдельному человеку, который смотрит, какие у него есть проблемы. Вот пример оповещений для ревью-кейса, которые присылает TestRial.

Здесь указано, какие кейсы на кого назначены, с каким статусом и кому надо посмотреть.

Еще один пример — бот Ябеда, который следит за процессами.

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

4.2 Сколько нужно оповещений и как часто?

Если оповещений будет очень много, то от них будет много стресса.
Поэтому вывели правила управления оповещениями...

a) Слишком много оповещений — перестаем реагировать
500 оповещений в день вы совершенно точно перестанете успевать просматривать, а значит можете пропустить важное;

b) Слишком мало — не видим проблем Если сообщений слишком мало, например, просто половину выкинуть, можно не увидеть какую-то проблему.

c) Нет проблем — сводка по фактам В случае отсутствия проблем оповещения, тоже нужно посылать, но в виде сводки: что произошло за день, что работало, какие были задачи, что случилось. Если не делать сводку, можно подумать, что просто все сломалось и надо искать, какие оповещения отвалились.

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

• Зеленый сигнал — релиз проходит, оповещение не нужно.
• Желтый сигнал — прилетит алерт, но смотреть его не нужно, если он разовый. Если повторяется, вы в жёлтой зоне и пора посмотреть, что же происходит. При этом релиз желтой зоны все равно проходит.
• Красный сигнал — все должно само останавливаться с обязательным разбором, почему так случилось, в том числе, почему дело дошло до красной зоны, и проблема не была выявлена раньше.

Кроме того, ввели уровни оповещений:

• Исполнитель — первый, кого будет бить бот, если задача горит.
• Команда / общий чат. Если исполнитель не реагирует, подключается команда или чат, в котором собраны люди по релизам или по перформансу.
• Лид. Если исполнитель или команда не реагируют, сообщение получит лид.
• Руководитель. Если и лид не среагировал, сообщение прилетит уже к руководителю. Плюс, обычно мы отправляем руководителю ставим сводку. Он не видит обычных оповещений, но получает результат, как идут дела.

5️⃣ Глава: «Метрики и дашборды устаревают»

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

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

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

• Регулярное ревью и пересмотр метрик
  Примерно раз в месяц пробегаемся по дашбордам, смотрим, какие метрики нужны, какие не нужны. Где все стало совсем хорошо можно отключить оповещения.
• Убираем ненужное
  Например, на начальном этапе у нас была автоматизация, в которой мы замеряли, сколько сценариев покрыто тестами и общий процент покрытия. Но общий процент ничего не дает, когда у вас 10 разных продуктов — точно нужны срезы.
• Делегировать
  Причем делегировать надо умно, через цели и инструменты.

Дать инструмент, научить им пользоваться, а дальше отпустить в самостоятельное плавание.

Это даст несколько преимуществ:
🔺 Во-первых, команда изнутри, скорее всего, видит больше, чем вы сверху, особенно если у вас 15 команд, и вы пытаетесь всеми ими управлять.

🔺 Во-вторых, команда может определить метрики, которые для них важны. Не надо строить универсальную систему и предлагать всем командам работать именно так.

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

5.1 Пример метрик в команде Online

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

6️⃣ Глава: «QA и бизнес»

Наконец, рассмотрим на кейсах связку QA и бизнеса...

6.1 Упала конверсия

Эксперты говорят: это эффект сезонности, просто люди сейчас не болеют, поэтому не звонят.

Проверяем: на определенном сегменте с определенным решением пользователь видит белый экран, который ни мониторинг, ни тесты не смогли поймать.

Но при этом есть график связки релиза и конверсии:

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

6.2 Много багов в биллинге

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

Проверяем: баги были по «спящим клиентам». Это те клиенты, которые или не платили деньги, или не собираются платить, или платили, но очень мало. Это явно не было каким-то блокером. Соответственно не все из этих багов напрямую влияли на деньги.

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

6.3 Падение количества звонков в колл-центре

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

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

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

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

Суть этих примеров в том, что ответы не в ветвях, а у корней, поэтому нужно всегда проверять экспертов. Что бы ни казалось на интуитивном уровне, что бы эксперт не говорил, надо всегда докопаться до сути через метрики. Есть техника «5 почему», которая позволяет это сделать.

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

📌 Резюмируем:

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

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

Нет универсального набора метрик:

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

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

Метрики — это не решения. Это всего лишь показатели здоровья проекта, которые говорят о текущем состоянии и о его динамике. Оповещения как раз являются индикаторами, которые помогут не пропустить, если что-то случится.

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

Какие выводы получились в общем остатке:

• ~ 50 метрик QA и более 100 остальных;
• ~ 30 активных дашбордов;
• Разные уровни погружения — можно быстро посмотреть, где проблема;
• Обязательные оповещения на метрики;
• Создание и поддержку - отдаем в сами команды;
• Связка QA и бизнеса must have.