​#мнение
KPI не про эффективность

Привет, друзья!

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

Что такое KPI?
KPI — это пороговые значения метрик, которые используются для оценки состояния процессов. Применять KPI имеет смысл только к стабилизированным и устойчивым процессам. Применение KPI к новым процессам или в условиях хаоса — это бессмысленно.

Как выбирать метрики?
Выбор метрик должен быть осмысленным и связанным с конкретными целями и состоянием вашего процесса. KPI помогают оценить производительность и качество работы. Один из полезных инструментов для выбора метрик — Fit for Purpose Indicators Wheel.

Подробнее об этой модели:

Defining KPIs to Drive Fitness for Purpose: https://medium.com/@agilemanager/defining-kpis-to-drive-fitness-for-purpose-c3ad2af46738
Как определить KPI продукта: https://filipyev.ru/2022/08/30/kak-opredelit-kpi-produkta/
Набор метрик из Fit for Purpose Indicators Wheel:
Для оценки эффективности команды можно использовать следующие метрики:

Health Indicators (индикаторы здоровья) — показатели текущего состояния и работоспособности системы.
Value Drivers (драйверы ценности) — метрики, которые способствуют увеличению ценности продукта или услуги.
Quality of Service (качество обслуживания) — показатели, характеризующие удовлетворенность клиентов и качество предоставляемых услуг.
Vanity Metrics (метрики тщеславия) — показатели, которые могут выглядеть привлекательно, но не обязательно указывают на реальные улучшения или эффективность.

Технический пример: Ошибки 500
Есть тривиальный KPI, дефолтно использующийся во многих командах разработки. Такой же как uptime. Возьмем как пример 500 ошибки.

Как это работает с технической точки зрения:
Сбор данных:

Логи ошибок собираются из разных сервисов. Эти логи обычно включают информацию о времени ошибки, URL, который вызвал ошибку, и стэк-трейс для детального анализа.
Логи отправляются в систему мониторинга, такую как Grafana, через логгер, встроенный в код приложения, или через систему сбора логов, такую как Prometheus.
Мониторинг:

Grafana используется для визуализации и мониторинга данных. Метрики из логов отправляются в Grafana через Prometheus, который собирает и агрегирует данные.
Настраиваются дашборды, которые показывают количество 500 ошибок по различным параметрам, например, по времени или по микросервисам.
Анализ и реагирование:

Настраиваются алерты для критических 500 ошибок. Например, если количество ошибок превышает определенный порог, срабатывает алерт, который отправляется в Slack или PagerDuty для оперативного реагирования.
Вводятся дежурства и отчётность для разборов инцидентов. Это помогает быстрее находить и устранять причины ошибок.

Разнообразие мнений в сообществе
Когда дело доходит до KPI, в сообществе IT нет единой точки зрения. Нет методички, и это делает процесс выбора и внедрения KPI таким сложным. Каждый случай уникален, и неправильное использование KPI может легко навредить, как если забивать гвозди микроскопом. Я проанализировал все 48 статей на Хабре про KPI и выделил 4 наиболее примечательных. Во всех 48 +- одни и те же противоречащие выводы, про которые все и так в курсе. Давайте взглянем на некоторые мнения и подходы, чтобы лучше понять эту тему.

Топ-4 статьи о KPI на Habr
"KPI разработчика: какие метрики можно использовать и эффективно ли их внедрение"
Почему стоит обратить внимание: Статья подробно разбирает различные метрики для оценки разработчиков, акцентируя внимание на балансе между количественными и качественными показателями. Интересные идеи включают метрики безаварийности и попадания в оценку.

"Как построить систему KPI для команды разработки"
Почему стоит обратить внимание: Подробный гид по созданию системы KPI для разработки с примерами и шагами внедрения. Важные идеи включают регулярный пересмотр метрик и индивидуальный подход.