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

Приступим.

Метрики поддержки

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

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

• клиентская поддержка,

• SRE (управление надежностью).

Вопросы классической технической поддержки второго уровня я рассматривать не буду, потому что она явно проигрывает концепции SRE. Об этом подробно описано в статье «Токеон: почему SRE?»

Метрики клиентской поддержки

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

Метрика SLA-реакции рассчитывается как время первого ответа клиенту минус время, в которое обращение было создано. Проще говоря, метрика отвечает на вопрос – сколько пришлось ждать клиенту пока на его запрос обратят внимание?

Метрика SLA-решения рассчитывается как время перевода запроса в статус «решено» минус время, в которое обращение было создано. Метрика отвечает на вопрос – сколько пришлось ждать клиенту пока его запрос будет решен?

В типовой поддержке этими двумя метриками всё дело и заканчивается. Но можно использовать больше метрик:

• Метрика удовлетворенности клиента (субъективное мнение клиента о качестве обслуживания по шкале от 1 до 10)

• Количество повторных обращений в течение дня. Отвечает на вопрос – получил ли клиент исчерпывающий ответ на свой вопрос?

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

• Распределение обращений по времени суток. Из поля «время создания обращения» берем только время и смотрим распределение обращений от 0:00 до 24:00. Таким образом мы увидим, как распределяется активность пользователей в течение суток и сколько людей нам нужно выводить в конкретные часы, чтобы пользователям не приходилось слишком долго ждать ответ.

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

Метрики SRE

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

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

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

Подвох с доступностью заключается в том, что термин «доступность» требует четкого определения. К нему нужно подходить через верхнеуровневые бизнес-метрики. Например, для бизнеса важна не только доступность самого сайта и личного кабинета пользователя, но и функция размещения ЦФА, функционал вторичного рынка, начисление промежуточных выплат и прочие бизнес-функции. Иными словами, нам нужен продвинутый мониторинг, который будет регулярно проверять работоспособность важного, с точки зрения бизнеса, функционала, а не просто проверять код 200 в ответе от сайта на запрос логина.

Другие метрики, которые мы рассчитываем в Токеоне для определения качества работы SRE:

• SLA-реакции на инцидент: время перехода обращения в статус «в работе» минус время, в которое был создан инцидент. Метрика характеризует скорость реакции инженеров на возникновение инцидента. 

• SLA-решения инцидента: время перевода инцидента в статус «решен» минус время, в которое был создан инцидент. Метрика характеризует скорость решения проблемы/инцидента.

• Операционная нагрузка на SRE. Согласно рекомендациям Google, этот показатель не должен превышать 50%. Он рассчитывается как время, потраченное на инциденты и задачи от нетехнических коллег, разделенное на общую продолжительность периода (мы измеряем раз в месяц). Если ваши инженеры тратят более половины своего времени на «тушение пожаров», они не смогут заниматься проактивной работой и системными задачами по повышению надежности. Это важный параметр качества.

Метрики разработки

В разработке основные проблемы связаны с тем, что бизнесу нужен именно функционал. Задачи рефакторинга, проработки архитектуры, документирования редко бывают понятны бизнесу. Что же важно бизнесу?

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

Отсюда метрики:

• Cycle Time. Эта метрика – промежуток времени между тем, как задачу взяли в разработку и её появлением в проде. 

• Количество багов в проде. Очень просто вычисляется: считаем сколько у нас есть багов на определенную дату. Эту метрику можно усложнить, введя признак «баг есть в проде» и считая только такие баги. Баги полезно группировать по функциональности, чтобы определить наиболее проблемные участки. Абсолютные значения в метриках редко бывают полезны, но эта метрика исключение, потому что она вполне адекватно определяет риски, которые несет бизнес.

• Количество багов относительно общего количества/объёма задач. Эта метрика лучше характеризует качество работы команды разработки, чем предыдущая. Если команда делает много задач (или задачи более сложные), то и багов тоже может быть больше по объективным причинам. Способ расчёта: количество багов разделить на общее количество задач или количество багов разделить на оценку сложности задачи в стори-поинтах.

• Производительность команды. Считаем количество стори-поинтов (SP) за спринт. При этом количество SP может расти за счёт увеличения команды (но тут будут расти и расходы) и/или за счёт внедрения новых технологий (например, AI-ассистента) и/или за счёт оптимизации процессов (например, убираем с команды бюрократическую нагрузку и ненужные совещания)

• Фокус команды. Считаем сколько времени разработчик тратит на написание кода. Предлагаю считать, что если разработчик тратит меньше 80% своего времени на написание кода, то мы его используем не по назначению.

Выводы

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