English version [[KPIs in Software Engineering. A Practitioner's Guide for ATM & Fintech Systems]] ## 1. Введение: почему программы KPI терпят неудачу Начну с признания: я видел больше KPI-инициатив, которые разрушали инженерные команды, чем тех, которые их укрепляли. Не потому что KPI сами по себе плохи, — а потому что большинство организаций внедряют их неправильно: сверху вниз, с фокусом на метрики, оторванные от инженерной реальности. В типичной финтех-компании или компании, разрабатывающей ПО для банкоматов, картина выглядит так: приходит новый CTO или VP Engineering, испытывает давление со стороны совета директоров и в течение 90 дней объявляет о «KPI-фреймворке». Через 6 месяцев инженеры накручивают velocity в спринтах, каждый баг помечается как P3 чтобы не портить статистику дефектов, а команда на бумаге работает быстрее, накапливая технический долг, который обойдётся в три раза дороже. ### Три типичные ошибки **Ошибка 1: Измерение людей вместо систем.** Это самая разрушительная ошибка. Когда вы привязываете performance-ревью инженера к его личному количеству коммитов или закрытых story points, вы создаёте враждебную систему. Вы получите коммиты — многие из них бессмысленные. Получите story points — раздробленные на фрагменты ради накрутки velocity. Хорошего программного обеспечения вы не получите. **Ошибка 2: Путаница между output и outcome.** Velocity — не равно доставка ценности. Девяносто закрытых историй за спринт ничего не значат, если продукт ненадёжен, если интеграционные тесты пропускаются ради дедлайна или если фичи выходят, которыми никто не пользуется. Output-метрики привлекательны, потому что их легко собирать и они всегда растут. Outcome-метрики сложнее определить и зачастую обнажают неудобную правду. **Ошибка 3: Злоупотребление velocity как инструментом планирования.** Velocity была разработана в рамках Extreme Programming как внутренний инструмент калибровки команды — грубая оценка для понимания собственной пропускной способности. Она никогда не задумывалась как показатель производительности. В момент, когда velocity становится целевым показателем в performance-ревью, она перестаёт быть полезным измерением. Закон Гудхарта: _«Когда мера становится целью, она перестаёт быть хорошей мерой»._ ### Контекст финтеха и ATM принципиально отличается Стандартные инженерные KPI, разработанные для веб-приложений или SaaS-платформ, в большинстве своём неадекватны для мира финтеха и банкоматов. Вот почему: - **Связка железа и软ware.** Сбой ПО банкомата — это не просто тикет. Это физическое устройство, которое становится недоступным для клиентов в отделении банка. Модель стоимости отказа принципиально отличается от веб-аутейджа. - **Регуляторное соответствие.** Деплоименты — это не только инженерные решения. Они должны пройти проверку по PCI DSS, быть залогированы для аудита и иногда требуют формального согласования с compliance-командой. KPI по частоте деплоя должны это учитывать. - **Сложность интеграций.** ATM-системы, как правило, интегрированы с АБС (автоматизированными банковскими системами), платёжными свичами (Visa, Mastercard), HSM-устройствами, принтерами чеков, карридерами и модулями выдачи наличных — каждый со своими режимами отказов, вендорскими SLA и протоколами (XFS/CEN, ISO 8583). - **Нулевая терпимость к финансовым ошибкам.** Баг в процедуре выдачи наличных банкомата — это не страница с ошибкой для пользователя. Это финансовые потери — для клиента или для банка. Стоимость дефектов на порядки выше, чем в потребительском ПО. - **Управление флотом в масштабе.** Крупный банк может иметь 5 000–50 000 банкоматов по всей стране. Обновление ПО для такого флота требует поэтапного выкатывания, возможности отката и телеметрии на уровне устройства — того, что большинство стандартных DevOps-пайплайнов просто не предусматривают. > ⚠️ **Важный контекст:** Любой KPI-фреймворк для ПО банкоматов или финтеха должен строиться с пониманием: цена отказа измеряется не деградацией пользовательского опыта, а регуляторными штрафами, финансовыми потерями и репутационным ущербом перед центральными банками и институциональными клиентами. Проектируйте метрики соответственно. --- ## 2. Философия KPI Прежде чем определить хотя бы одну метрику, нужно чётко понимать, что и зачем вы измеряете. Это звучит очевидно. Почти ни одна организация не делает это правильно. ### Измеряйте системы, а не людей У. Эдвардс Деминг, статистик, перестроивший японское производство после Второй мировой войны, был однозначен в этом вопросе: 85–95% проблем с производительностью — следствие системы, а не конкретного человека. Инженер, работающий в раздробленном монорепо без среды интеграции, с четырёхчасовым CI-пайплайном и процессом код-ревью, занимающим три дня, будет показывать ужасные метрики поставки. Это не проблема конкретного человека. Это системная проблема, и правильная реакция — исправить систему. Это означает, что KPI должны прежде всего отвечать на вопрос: _Как работает наша инженерная система?_ — а не _Как работает инженер X?_ Второй вопрос уместен в периодических performance-ревью, но он никогда не должен управляться теми же дашбордами, которые вы используете для мониторинга здоровья инженерного подразделения. ### Output-метрики vs. Outcome-метрики |Тип|Что измеряет|Риск| |---|---|---| |**Output-метрики**|Активность: story points, коммиты, смерженные PR, выпущенные фичи|Проще измерить. Проще фальсифицировать. Часто вводят в заблуждение.| |**Outcome-метрики**|Результат: снижение даунтайма, более быстрые транзакции, меньше compliance-инцидентов|Сложнее измерить. Намного сложнее подделать.| Цель — не полностью отказаться от output-метрик: они полезны как диагностические сигналы. Но они всегда должны быть подчинены outcome-метрикам. Если частота деплоя растёт, а uptime банкоматов падает, метрика частоты деплоя ничего не значит. ### Опережающие vs. запаздывающие индикаторы **Запаздывающий индикатор** рассказывает о том, что уже произошло: uptime банкоматов в прошлом месяце составил 99,2%. **Опережающий индикатор** намекает на то, что будет: покрытие тестами модуля обработки платежей упало с 78% до 61% за последние два спринта. Зрелые инженерные организации поддерживают оба вида, но вкладываются больше в опережающие индикаторы. К тому времени, когда ваша статистика MTTR сигнализирует о проблеме надёжности, вы уже заплатили цену. Растущий возраст открытых багов, снижение участия в код-ревью или увеличение частоты сбоев CI — это сигналы, на которые можно реагировать до того, как пострадает прод. ### Закон Гудхарта и проблема извращённых стимулов > _«Когда мера становится целью, она перестаёт быть хорошей мерой»._ — Чарльз Гудхарт Это не теоретическое предупреждение. Каждый KPI, который вы вводите, меняет поведение инженеров. Реальные примеры из финтех-среды: - **KPI: Story points за спринт** → Инженеры агрессивно дробят задачи. Velocity растёт. Реальная пропускная способность не меняется. - **KPI: Количество деплоев** → Команды разбивают релизы на тривиальные инкременты. Частота деплоя утраивается. Темп реальной доставки фич остаётся прежним. - **KPI: Скорость код-ревью** → Ревьюеры формально одобряют PR ради соблюдения SLA. Качество кода падает. Плотность дефектов растёт через три месяца. - **KPI: Количество багов** → Инженеры помечают баги как «by design» или «won't fix». Дашборд выглядит здоровым. Программное обеспечение — нет. Защита от закона Гудхарта: никогда не измеряйте одну метрику в изоляции, регулярно обновляйте набор KPI и сохраняйте прямое человеческое наблюдение как проверку здравым смыслом. Никакой дашборд не заменит инженерного лидера, задающего неудобные вопросы. --- ## 3. Основные категории KPI ### A. Метрики поставки _Насколько быстро и предсказуемо работа проходит через систему?_ #### Lead Time (Время от заявки до поставки) **Определение:** Elapsed time от создания задачи до её поставки в прод. **Почему важно:** Lead Time — самый честный показатель того, насколько отзывчива ваша инженерная организация к потребностям бизнеса. В ПО для банкоматов Lead Time особенно критичен для патчей безопасности: критическая уязвимость XFS должна попасть на устройства за часы-дни, а не за недели. **Как измерять:** Отслеживайте дату создания тикета vs. дату деплоя в прод в трекере задач (Jira, Linear). **Антипаттерны:** Измерять Lead Time только для фич, игнорируя баги и операционные задачи. Измерять «lead time спринта», не учитывая время ожидания в очереди до начала спринта. **Целевые значения:** P1/P2 патчи безопасности: <48ч до staging, <5 рабочих дней до полного флота. Запросы на фичи: <4 недели средний Lead Time для задач средней сложности. #### Cycle Time (Время цикла) **Определение:** Время от момента, когда работа _активно начата_, до её выхода в прод — та часть Lead Time, которая находится под прямым контролем инженеров. **Почему важно:** Cycle Time обнажает узкие места процесса. Если Cycle Time короткий, а Lead Time длинный — проблема в очереди. Если сам Cycle Time длинный — задача заблокирована в процессе: ждёт ревью, среды, QA. **Как измерять:** Переходы статусов тикетов в Jira/Linear. Визуализируйте как диаграмму рассеяния (Control Chart), чтобы видеть вариативность, а не только среднее. **Антипаттерны:** Усреднять Cycle Time, не смотря на распределение. Медиана в 3 дня ничего не значит, если 20% тикетов занимают 3 недели из-за проблем интеграции с АБС. #### Throughput (Пропускная способность) **Определение:** Количество задач, завершённых за единицу времени (за спринт или за неделю), нормализованное по типу задач. **Почему важно:** Снижение тренда throughput на протяжении 6 недель зачастую сигнализирует о росте технического долга, выгорании команды или проблемах инфраструктуры — раньше, чем это становится заметно клиентам. **Антипаттерны:** Использовать сырой throughput без нормализации по сложности. Считать только фичи, исключая исправление багов и работу с техдолгом. #### Sprint Predictability (Предсказуемость спринта) **Определение:** Отношение выполненного объёма к запланированному. `completed_points / committed_points × 100%` **Почему важно:** В регулируемом финтехе предсказуемость критически важна для планирования соответствия требованиям, графиков аудитов и договорных обязательств перед банковскими клиентами. **Целевые значения:** 80–85% стабильно — отлично. 100% стабильно — красный флаг: команда занижает обязательства. Ниже 70% стабильно — системные проблемы с планированием или зависимостями. --- ### B. Метрики качества _Каково качество ПО, выходящего из вашего пайплайна?_ #### Bug Escape Rate (Уровень утечки багов) **Определение:** Баги, найденные в проде, vs. общее количество найденных багов (прод + pre-prod). `prod_bugs / (prod_bugs + pre_prod_bugs) × 100%` **Почему важно:** В ПО для банкоматов производственный дефект может вызвать проблемы с финансовой сверкой, жалобы клиентов в центральный банк или регуляторные расследования. Стоимость каждого производственного дефекта в 5–100 раз выше, чем дефекта, пойманного на тестировании. **Целевое значение:** <10% уровень утечки для багов P1/P2. #### Defect Density (Плотность дефектов) **Определение:** Количество подтверждённых дефектов на 1000 строк кода (KLOC) на модуль, за скользящий период. **Почему важно:** Определяет, какие модули наиболее хрупкие. В ПО для банкоматов слой XFS-сервисов и модуль обработки сообщений ISO 8583 традиционно имеют наибольшую плотность дефектов. **Антипаттерны:** Использовать плотность дефектов для сравнения разных команд без учёта различий в сложности. Легаси-код всегда будет показывать бо́льшую плотность — это ожидаемо, а не провал. #### Reopen Rate (Уровень переоткрытия) **Определение:** Процент закрытых багов, которые были переоткрыты из-за недостаточного исправления. **Почему важно:** Уровень переоткрытия выше 15% сигнализирует о недостаточном покрытии тестами для исправлений, слабом код-ревью или о том, что разработчики закрывают баги «для галочки» под давлением velocity. В деплоях для банкоматов переоткрытый критический баг может потребовать экстренного отката на тысячах устройств. **Целевое значение:** <10% в целом. Любой баг P1 с переоткрытием требует формального RCA. #### Покрытие тестами (и его ограничения) **Определение:** Процент строк, ветвей или функций исходного кода, покрытых автоматизированными тестами. > ⚠️ **Критическое предупреждение:** Покрытие тестами — одна из наиболее злоупотребляемых метрик в инженерии. 80% покрытие ничего не значит, если эти 80% — тривиальный getter/setter-код, а не покрытая логика выдачи наличных. Покрытие — _необходимое, но не достаточное_ условие качества. **Как использовать правильно:** Отслеживайте покрытие по модулям, уделяя особое внимание бизнес-критичным путям. Требуйте >90% покрытия ветвей в коде обработки платежей. Запускайте мутационное тестирование (Pitest для Java, mutmut для Python), чтобы проверять качество тестов, а не только их количество. Измеряйте баланс тестовой пирамиды: unit/integration/e2e в соотношении примерно 70/20/10. --- ### C. DevOps / DORA-метрики _Четыре ключевые метрики Accelerate — откалиброванные для регулируемого финтеха_ DORA-метрики (из книги _Accelerate_ Форсгрен, Хамбла и Кима) — наиболее строго валидированные индикаторы инженерной производительности из существующих. Однако они требуют существенной адаптации для ATM и финтех-сред, где ограничения регуляторного управления изменениями делают наивное применение опасным. #### Deployment Frequency (Частота деплоя) **Определение:** Как часто команда деплоит в прод. **Адаптация для финтеха:** Для ПО флота банкоматов «elite» — это не несколько деплоев в день. Поэтапный выкат на 10 000 банкоматов принципиально медленнее, чем деплой кода на веб-сервис. Реалистичная цель для зрелой ATM-команды — еженедельные минорные обновления с ежемесячными/ежеквартальными мажорными релизами, подкреплёнными автоматическим canary-выкатом на тестовый флот (5–10% устройств) перед полным деплоем. **Антипаттерны:** Считать деплои на staging и отчитываться ими как о деплоях в прод. Деплоить тривиально мелкие изменения для накрутки частоты. #### Lead Time for Changes (Время от коммита до прода) **Определение:** Время от коммита кода до его работы в проде. **Целевые значения для ATM-ПО:** Коммит → автотесты → staging: <2 часа. Staging → прод (после compliance-проверки): <5 рабочих дней для обычных изменений, <4 часа для патчей безопасности с экстренным согласованием CAB. #### Change Failure Rate (Уровень неудачных изменений) **Определение:** Процент продовых деплоев, которые приводят к деградации сервиса, инциденту или требуют отката. `failed_deployments / total_deployments × 100%` **Почему важно:** Неудачный деплой на флот банкоматов может вывести из строя 500 устройств в пиковые часы транзакций. Элитный бенчмарк DORA — <5% CFR. Для ПО банкоматов цель: <3%. #### Mean Time to Restore — MTTR (Среднее время восстановления) **Определение:** Среднее время от обнаружения инцидента до полного восстановления сервиса. **ATM-специфичная сложность:** MTTR имеет несколько измерений. Программный откат может восстановить приложение за минуты. Но программно вызванная аппаратная неисправность может потребовать физического визита инженера к банкомату — добавляя часы. Ваша метрика MTTR должна различать инциденты, устранимые программно, и инциденты, требующие выезда на место. **Целевые значения:** Инциденты с программным откатом: <30 минут. Сетевые/интеграционные инциденты: <2 часа. Требующие выезда: <4 рабочих часа. #### Таблица 1 — DORA-метрики: стандартные vs. ATM/финтех целевые значения |Метрика|DORA Elite (общее)|ATM/Финтех Elite|Минимально допустимо|Красный флаг| |---|---|---|---|---| |Частота деплоя|Несколько раз в день|Еженедельно (минор) / Ежемесячно (мажор)|Ежемесячно|Ежеквартально или реже| |Lead Time for Changes|<1 часа|<2ч до staging; <5д до прода|<2 недели до прода|>1 месяца до прода| |Change Failure Rate|<5%|<3%|<8%|>15%| |MTTR (программный)|<1 часа|<30 мин|<4 часов|>24 часов| |MTTR (с выездом)|N/A|<4 рабочих часа|<в тот же рабочий день|>следующий рабочий день| --- ### D. Производительность инженеров _Показатели эффективности процессов на уровне команды_ #### PR Cycle Time (Время цикла pull request) **Определение:** Время от создания PR до его мержа — разбивается на: время до первого ревью, время в ревью и время до мержа после аппрувала. **Почему важно:** Долгое время цикла PR — одна из главных причин фрустрации разработчиков и нарушения потока. Когда PR ждут 2–3 дня, инженеры переключаются на другие задачи, что существенно затрудняет возврат к исходной работе. **Целевые значения:** Время до первого ревью: <4 часа в рабочее время. Общее время цикла PR: <24 часа для рутинных изменений, <4 часа для патчей безопасности. #### PR Size (Размер pull request) **Определение:** Строки кода, изменённые в одном PR (добавления + удаления). **Почему важно:** Исследования стабильно показывают: PR объёмом более 400 строк получают качественно более слабое ревью. В ATM-ПО, где ошибка на единицу в алгоритме пересчёта наличных может привести к сбоям сверки на тысячах устройств, большие PR — реальный финансовый риск. **Целевые значения:** <300 строк для кода со сложной логикой. Отслеживайте 90-й перцентиль, а не среднее: экстремальные выбросы искажают картину. #### Work in Progress — WIP (Незавершённая работа) **Определение:** Количество задач, находящихся в активной разработке (не в очереди, не заблокированных) на одного разработчика или на команду. **Почему важно:** Теория ограничений и десятилетия данных бережливого производства доказывают: ограничение WIP резко улучшает эффективность потока. Каждая дополнительная задача в WIP увеличивает накладные расходы на переключение контекста и удлиняет Cycle Time для всех активных задач. Идеальный WIP для разработчика — 1–2 задачи одновременно. **Антипаттерны:** WIP-лимиты, которые установлены, но не соблюдаются. Задачи «в процессе» более 2 недель без движения (это заблокированные задачи, маскирующиеся под активную работу). #### Переключение контекста **Определение:** Среднее количество различных задач или проектов, которых касается член команды за день/неделю. **Почему важно:** Исследование Глории Марк (Калифорнийский университет, Ирвайн) показывает: в среднем требуется 23 минуты, чтобы вернуться к полной концентрации после прерывания. В финтех-командах, где разработчиков регулярно отвлекают на реагирование на инциденты, compliance-документацию и кросс-командные встречи, реальное время написания кода может составлять всего 2–3 часа в день. --- ### E. Здоровье инженерной команды _Индикаторы устойчивости, которые большинство дашбордов игнорирует_ #### Коэффициент технического долга **Определение:** Отношение оценочных затрат на устранение к общей стоимости разработки системы. Инструменты вроде SonarQube вычисляют это автоматически. **Почему важно:** В ATM-ПО технический долг — не метафора, а прямой операционный риск. Легаси-код интеграции XFS на C++, написанный в 2003 году и непонятный ни одному члену текущей команды, — это одновременно проблема bus factor, риск безопасности и кошмар поддержки. **Целевые значения:** Коэффициент техдолга <5%. Выделяйте 15–20% каждого спринта на устранение технического долга — не как одолжение инженерам, а как требование непрерывности бизнеса. #### Bus Factor (Автобусный фактор) **Определение:** Минимальное количество членов команды, которые должны покинуть её, чтобы критический компонент стал неподдерживаемым. **Почему важно:** Во многих ATM-командах есть компоненты, в которых полную картину знает ровно один инженер. Когда этот человек уходит, способность команды поддерживать компонент рушится. Bus factor = 1 на любом продовом компоненте — серьёзный организационный риск. **Как измерять:** Сопоставьте критические компоненты системы с инженерами, обладающими глубокими знаниями. Подсчитайте носителей знаний на компонент. Визуализируйте как тепловую карту. **Целевые значения:** Ни один продовый компонент не должен иметь bus factor ниже 2. Для наиболее критичных систем (обработка платежей, выдача наличных, безопасность/управление ключами) стремитесь к 3. #### Удовлетворённость команды и индикаторы выгорания **Определение:** Регулярные (раз в две недели — ежемесячные) анонимные опросы, измеряющие: эффективность инженерной работы, психологическую безопасность, устойчивость нагрузки, поддержку руководства и возможности роста. **Почему важно:** Удовлетворённость инженеров — опережающий индикатор удержания, которое, в свою очередь, — опережающий индикатор деградации bus factor и потери институциональных знаний. В ATM-ПО замена ушедшего инженера занимает 3–6 месяцев рекрутинга и 6–12 месяцев ввода в должность. **Сигналы выгорания для мониторинга:** - Рост активности коммитов в нерабочее время (не «преданность» — это предупреждающий знак) - Снижение участия в код-ревью - Рост количества больничных дней - Рост уровня эскалации инцидентов на инженера - Самооценка «трудности с концентрацией» в опросах --- ### F. Бизнес-метрики _Метрики, которые обосновывают инвестиции в инженерию перед стейкхолдерами_ #### Time to Market (Время выхода на рынок) **Определение:** Прошедшее время от утверждения бизнес-требования до первого продового деплоя для живых клиентов или устройств. **Почему важно:** В конкурентном финтехе Time to Market для новых возможностей банкоматов напрямую влияет на привлечение банков-клиентов и продление контрактов. Конкурент, способный доставить новую функцию банкомата за 6 недель, пока вы тратите 6 месяцев, выигрывает сделку — вне зависимости от технического качества. #### Feature Adoption Rate (Уровень принятия фич) **Определение:** Процент подходящих банкоматов или пользователей, активно использующих новую фичу в течение 30/60/90 дней после выкатки. **Почему важно:** Фичи, которыми не пользуются, — это потери. Метрики принятия вынуждают неудобные разговоры между инженерами и продуктом, которые улучшают будущие решения дорожной карты. #### Customer Impact Score (Оценка влияния на клиентов) **Определение:** Составная метрика — количество клиентов, затронутых инцидентами, взвешенное по серьёзности и длительности. `Σ(затронутых_клиентов × длительность_часов × вес_серьёзности)` **Почему важно:** Переводит инженерную производительность на язык бизнеса. Четырёхчасовой аутейдж, затронувший 50 банкоматов в крупном городе, — это потенциально 20 000 неудавшихся транзакций клиентов, каждая из которых — момент разочарования и репутационный ущерб для банка. --- ## 4. KPI специфичные для ATM и финтеха Метрики в этом разделе не имеют аналогов в стандартной веб-разработке. Они существуют потому, что ATM и платёжная инфраструктура находятся на пересечении физического железа, регулируемых финансовых процессов и обработки транзакций в реальном времени. ### Доступность ПО банкоматов (Fleet Uptime) **Определение:** Процент времени, в течение которого банкоматы находятся в полностью работоспособном состоянии и способны проводить транзакции. Измеряется на уровне устройства и агрегируется на уровне флота. **Категории доступности:** - **IN SERVICE:** Устройство работоспособно и обслуживает клиентов - **OUT OF SERVICE — Software:** Сбой приложения, проблема ОС, сетевой сбой - **OUT OF SERVICE — Hardware:** Замятие купюр, неисправность карридера, сетевое оборудование - **OUT OF SERVICE — Operational:** Закончились наличные, бумага для чеков, плановое обслуживание Инженерный отдел отвечает — и должен измеряться только — по недоступности, вызванной программным обеспечением. Включение аппаратных сбоев в KPI аптайма ПО вводит в заблуждение и создаёт ложную ответственность. **Целевое значение:** Недоступность из-за ПО <0,5% общих fleet-hours в месяц. В масштабе (10 000 банкоматов) это означает не более 50 device-days программной недоступности в месяц. ### Уровень инцидентов на устройство в месяц **Определение:** Среднее количество программно вызванных инцидентов (требующих вмешательства) на банкомат в месяц. **Целевое значение:** <0,5 инцидента на устройство в месяц для программных причин. Выше 1,0 на устройство в месяц — системные проблемы качества, требующие немедленного архитектурного анализа. ### Среднее время устранения программных сбоев банкоматов Декомпозируйте на три фазы: |Фаза|Определение|Цель| |---|---|---| |**Время обнаружения**|От возникновения сбоя до алерта мониторинга|<2 минуты при активных health-checks| |**Время триажа**|Время на определение первопричины и плана действий|<15 минут для известных сигнатур ошибок| |**Время устранения**|Время на восстановление устройства|Удалённый перезапуск/откат: <10 мин; выезд: <4 часов| ### Compliance и регуляторные метрики **Коэффициент покрытия контролей PCI DSS:** Процент компонентов ATM-ПО, прошедших последнюю проверку требований PCI DSS. Цель: 100% перед любым продовым деплоем. Нулевая терпимость. **Lead Time патча безопасности:** Время от публикации CVE до деплоя патча на 100% флота банкоматов. PCI DSS требует применения критических патчей в течение 30 дней; зрелые организации нацелены на <10 рабочих дней для критических уязвимостей в коде обработки платежей. **Количество замечаний аудита на релиз:** Число compliance-замечаний, поднятых в ходе внутренних или внешних аудитов на каждый мажорный релиз ПО. Тренд в сторону нуля — цель. Более 3 замечаний на релизный цикл свидетельствует о сбоях процессного контроля. **Коэффициент соответствия управлению изменениями:** Процент продовых изменений с полностью задокументированными и согласованными записями об изменениях до деплоя. Должен быть 100%. Любые незадокументированные изменения — compliance-риск, не только технический. ### Метрики надёжности интеграций #### Таблица 2 — KPI надёжности интеграций по типам систем |Точка интеграции|Ключевая метрика|Целевой SLA|Порог алерта|Последствия сбоя| |---|---|---|---|---| |АБС (Core Banking)|Процент успешных авторизаций транзакций|>99,95%|<99,9%|Отклонённые карточные транзакции| |Платёжный свич (Visa/MC)|Время ответа на сообщение (ISO 8583)|<800мс p95|>1200мс p95|Таймауты транзакций, отклонённые карты| |HSM (управление ключами)|Доступность шифрования PIN|99,999%|<99,99%|Банкомат не может проводить PIN-транзакции| |Мониторинг ATM (EJ)|Процент успешной загрузки журналов|>99,9%|<99,5%|Пробелы в audit trail, compliance-риск| |Сетевое подключение|Время установки сессии|<5с на соединение|>15с|Устройство выглядит офлайн для мониторинга| |Канал обновления ПО|Процент успешного обновления флота|>98% в окне|<90%|Разнородный флот по версиям, уязвимость безопасности| > 🏦 **Регуляторная заметка:** В регулируемых средах ЕС (PSD2, руководства EBA) аптайм банкоматов и процент успешных транзакций могут быть метриками, обязательными к отчётности перед национальным компетентным органом или в рамках отчётности об операционной устойчивости по DORA (Регламент ЕС о цифровой операционной устойчивости). Ваши инженерные KPI напрямую связаны с регуляторным соответствием. --- ## 5. Проектирование системы KPI ### Модель 70/30: командные vs. индивидуальные KPI Единственное наиболее важное структурное решение в вашей KPI-системе — соотношение командных и индивидуальных метрик. **Настойчивая рекомендация: 70% на уровне команды/системы, 30% на индивидуальном уровне.** 70% командных метрик измеряют здоровье системы: частоту деплоя, Change Failure Rate, аптайм флота, надёжность интеграций, Cycle Time. Они принадлежат инженерному лидеру и используются для организационных улучшений, а не для оценки отдельных инженеров. 30% индивидуальных метрик должны фокусироваться на качестве вклада, а не на его количестве: - Уровень участия в код-ревью - Вклад в документацию - Менторская активность (если применимо к уровню) - Прохождение тренингов по безопасности - Качество реагирования на on-call инциденты (оцениваемое коллегами, а не только скоростью) ### Почему индивидуальные метрики производительности опасны Измерение инженеров по коммитам в неделю, story points за спринт или строкам кода даёт предсказуемые и вредные результаты. Инженер, пишущий 200 сосредоточенных, хорошо протестированных строк критического кода обработки платежей, создаёт больше ценности, чем инженер, вносящий 1200 строк скаффолдинга. В ATM финтех-командах наиболее ценная работа зачастую невидима на стандартных дашбордах производительности: инженер, потративший неделю на анализ XFS-интеграционного слоя и написавший исчерпывающий технический документ о режимах его отказов, потенциально предотвратил дорогостоящий продовый инцидент стоимостью $100 000 в экстренном устранении. Эта работа выглядит как «низкая выработка» на commit-based метриках. ### Таблица 3 — Полный справочник KPI: категория, метрика, цель, метод, владелец |Категория|Метрика|Целевое значение|Метод измерения|Владелец| |---|---|---|---|---| |**Поставка**|Feature Lead Time|<4 недели в среднем|Временны́е метки тикетов Jira|Engineering Manager| ||Cycle Time|<5д p50; <14д p90|Лог переходов статусов, Control Chart|Engineering Manager| ||Предсказуемость спринта|80–90%|Данные Sprint Review, velocity chart|Scrum Master / Команда| |**Качество**|Bug Escape Rate|<10% (P1/P2)|Трекинг дефектов Jira, тегирование окружений|QA Lead| ||Плотность дефектов|<2 ошибки/KLOC/квартал|Интеграция SonarQube + Jira|QA Lead| ||Reopen Rate|<10%|Аналитика воркфлоу Jira|QA Lead| ||Покрытие критических путей|>90% branch coverage|JaCoCo / Istanbul / pytest-cov|Dev Team Lead| |**DORA**|Частота деплоя|Еженедельно (минор), Ежемесячно (мажор)|События CI/CD пайплайна, ArgoCD|DevOps Lead| ||Lead Time for Changes|<2ч до staging; <5д до прода|Git commit → delta события деплоя|DevOps Lead| ||Change Failure Rate|<3%|Тегирование деплоев: успех/откат|DevOps Lead| ||MTTR (программный)|<30 мин|Трекинг инцидентов, PagerDuty/OpsGenie|DevOps Lead / SRE| |**Производительность**|PR Cycle Time|<24ч для рутинных изменений|Аналитика PR в GitHub/GitLab|Team Lead| ||Размер PR (p90)|<400 строк p90|GitHub/Gitea API, еженедельный отчёт|Team Lead| ||Активный WIP на разработчика|<2 задачи одновременно|Доска Jira, фильтр In Progress|Engineering Manager| |**Здоровье**|Коэффициент техдолга|<5%|Quality gate SonarQube|Head of Engineering| ||Bus Factor (критические модули)|≥2 на модуль|Карта знаний, ежеквартальный ревью|Head of Engineering| ||eNPS (удовлетворённость команды)|>30|Анонимный pulse-опрос раз в 2 недели|Head of Engineering| |**ATM / Финтех**|Простой ATM из-за ПО|<0,5% fleet-hours/мес|ATM-платформа мониторинга|DevOps Lead / SRE| ||Инцидентов на устройство/мес|<0,5|Управление инцидентами + реестр устройств|SRE / Field Operations| ||Lead Time патча безопасности|<10 рабочих дней (критичные)|CVE-трекер + деплой-пайплайн|Security Lead / DevOps| ||Процент успешных транзакций|>99,95%|Отчёты сверки по свичу/EJ|Payment Ops / SRE| ||Соответствие управлению изменениями|100%|ServiceNow / инструмент Change Management|Release Manager| |**Бизнес**|Time to Market (фичи)|<8 недель для стандартных фич|Дата бизнес-требования → дата прода|Head of Engineering + PM| ||Customer Impact Score|Тренд ↓ квартал к кварталу|Данные инцидентов + реестр клиентов|Head of Engineering| --- ## 6. Дизайн KPI-дашборда Дашборд, показывающий всё, по сути не показывает ничего. Цель — не отобразить каждую собранную метрику, а донести правильные сигналы до правильной аудитории в правильное время. ### Слой 1: Дашборд для руководства (60 секунд) Для CTO, CRO или банковских клиентов. Отвечает на один вопрос: _Работает ли инженерия надёжно и безопасно?_ Показывайте пять чисел со статусом RAG (красный/жёлтый/зелёный): - Доступность флота банкоматов (%) - Процент успешных транзакций (%) - Количество инцидентов за последние 30 дней - Текущий Change Failure Rate - Количество открытых критических проблем безопасности ### Слой 2: Дашборд инженерного руководства (15 минут) Для Head of Engineering, DevOps Lead, Engineering Managers. Управляет еженедельными операционными решениями. - **Поток поставки:** Диаграмма накопительного потока (CFD), тренд Lead Time за 8 недель, предсказуемость спринта за последние 6 спринтов - **Сигналы качества:** Тренд Bug Escape Rate, тепловая карта покрытия тестами по модулям, возраст открытых багов P1/P2 - **DORA-метрики:** Все четыре метрики с трендами за 12 недель - **Здоровье ATM-флота:** Доступность по регионам/банкам-клиентам, тепловая карта программных инцидентов на устройство, статус интеграционных SLA по каждой системе ### Слой 3: Командный дашборд (операционный, реальное время) Принадлежит команде, а не навязан менеджментом. - Здоровье CI/CD пайплайна (процент успешных сборок за последние 24ч, p95 длительности пайплайна) - Количество открытых PR и распределение по возрасту (выделяются PR старше 48ч) - Текущий WIP на разработчика (канбан-визуализация) - Очередь on-call инцидентов и текущий статус PagerDuty - Статус устройств ATM по регионам с лентой алертов в реальном времени ### Реализация в Grafana / Prometheus ```yaml # Пример: метрика доступности флота ATM (формат Prometheus) # Экспортируется интеграционным экспортером мониторинга ATM atm_device_status_total{status="in_service", region="north", bank="acme"} 342 atm_device_status_total{status="oos_software", region="north", bank="acme"} 2 atm_device_status_total{status="oos_hardware", region="north", bank="acme"} 5 # software_availability = in_service / (in_service + oos_software) # Намеренно исключает аппаратные сбои из KPI ПО ``` ```yaml # Recording rule для DORA Change Failure Rate - record: engineering:change_failure_rate:7d expr: | sum(increase(deployments_total{result="rollback"}[7d])) / sum(increase(deployments_total[7d])) ``` > ✅ **Принцип дашборда:** Каждая метрика на дашборде должна иметь владельца, способного принять меры при её деградации. Если нет чёткого владельца и чёткого действия — удалите метрику. Дашборды, полные метрик тщеславия, которые никто не использует, — это шум, а не актив. --- ## 7. План внедрения Реалистичный план с учётом рисков для финтех/ATM-организации. Общий срок: **5 месяцев**. ### Шаг 1: Определение метрик совместно с инженерами (Месяц 1, Недели 1–4) Не разрабатывайте KPI-фреймворк в переговорной и не объявляйте его инженерам. Проведите двухдневный воркшоп с инженерными лидами, старшим разработчиком от каждой команды и QA Lead. Проработайте вопрос: _«Что говорило бы нам о здоровье инженерной системы, а что — о её деградации?»_ **Результат:** Ранжированный шорт-лист из 15–20 метрик-кандидатов. Применяйте фильтр отбора: - Измеримо ли это текущими инструментами? - Измеряет ли это outcomes, а не просто активность? - Можно ли это накрутить, не улучшая реально систему? Если да — удалите или сопроводите контрметрикой. **Риск:** Руководство захочет пропустить этот шаг. **Митигация:** Представьте воркшоп как самый быстрый путь к обоснованному KPI-фреймворку. Пропуск обойдётся дороже на этапе управления изменениями позже. ### Шаг 2: Сбор базовых данных (Месяц 1–2, Недели 3–6) Прежде чем устанавливать любые целевые значения — соберите 4–6 недель базовых данных по каждой выбранной метрике. Это не обсуждается. Организации, устанавливающие цели без базовых данных, делают это либо произвольно (демотивирует), либо оптимистично (бессмысленно). Базовые данные обнажат неудобную правду. Ваш Bug Escape Rate может оказаться 35%. Среднее время цикла PR — 4 дня. Фиксируйте это без осуждения — это отправная точка. **Необходимые инструменты:** Prometheus/Grafana или Datadog для инфраструктурных метрик. Дашборды Jira для метрик поставки и качества. Интеграция событий деплой-пайплайна. Подключение ATM-платформы мониторинга к стеку метрик. **Риск:** Неполное покрытие данными. **Митигация:** Принимайте несовершенные базовые данные. Неполные данные лучше, чем их отсутствие. Фиксируйте пробелы явно. ### Шаг 3: Установка реалистичных целей (Месяц 2–3, Недели 7–10) Установка целей — это переговоры, а не диктовка. Представьте базовые данные команде и спросите: _«Какое улучшение реалистично за следующие 6 месяцев, если устранить наиболее важные ограничения?»_ Используйте **правило 20% улучшения** как отправную точку: если базовый Cycle Time — 10 дней, цель — 8 дней за 6 месяцев. Если Bug Escape Rate — 35%, цель — 25%. **Процесс согласования:** Цели по бизнес-критичным метрикам (аптайм ATM, процент успешных транзакций, Lead Time патча безопасности) должны быть проверены и одобрены CTO, Head of Risk и, возможно, Chief Compliance Officer. Это не просто инженерные цели — это договорные и регуляторные обязательства. ### Шаг 4: Коммуникация с командами (Месяц 3, Недели 11–12) Проведите общекорпоративный инженерный all-hands. Нарратив имеет огромное значение. - **Избегайте:** _«Мы внедряем KPI для повышения ответственности»._ - **Используйте:** _«Мы создали систему, которая делает нашу инженерную производительность видимой, чтобы выявлять и устранять то, что нас тормозит»._ Обратитесь к «слону в комнате» напрямую: _«Эти метрики измеряют систему, а не людей. Ни один инженер не будет оцениваться или получать компенсацию на основе velocity спринта или количества коммитов»._ Если это неправда в вашей организации — сначала исправьте это. Публикуйте все дашборды внутри компании и делайте их доступными для всех инженеров, а не только для менеджеров. Прозрачность — антидот подозрительности. ### Шаг 5: Ревью, обучение, итерация (Месяцы 4–5, постоянно) Проводите формальный ревью KPI каждые 4 недели: - 10 минут — обзор трендов метрик - 20 минут — метрики, которые деградировали (что случилось? что изменилось?) - 20 минут — действия по улучшению с владельцами и дедлайнами Выводите из использования метрики, выполнившие свою цель или ставшие предметом накруток. Добавляйте новые по мере возникновения новых вызовов. KPI-система — живой инструмент, а не постоянная инсталляция. **Через 6 месяцев:** Проведите полную ретроспективу самой KPI-системы. Что она реально изменила? На какое поведение положительно повлияла? Какие непреднамеренные последствия создала? > ⚠️ **Риск сроков:** Самый распространённый сценарий неудачи — попытка внедрить все метрики одновременно во всех командах. Начните с одной команды-пилота. Проведите 6–8 недель, узнайте что работает, затем масштабируйте. --- ## 8. Антипаттерны и типичные ошибки ### Антипаттерн 1: Измерение разработчиков по количеству коммитов Это выглядит очевидно неправильным, но продолжает встречаться во многих организациях — зачастую замаскированное под «метрики вклада» или «activity dashboards» в GitLab или GitHub Insights. Возьмём двух инженеров в команде интеграции ATM с банковским ядром. Инженер А делает 15 коммитов в неделю — в основном мелкие CSS-правки, конфигурационные твики и незначительные UI-исправления. Инженер Б делает 3 коммита в неделю — но в этих коммитах тщательно отрефакторенный ISO 8583 message parser, снижающий интеграционные ошибки на 60% и подкреплённый 200 новыми тест-кейсами. На дашборде по количеству коммитов Инженер Б выглядит малопродуктивным. В реальности Инженер Б доставляет в 20 раз больше бизнес-ценности. **Результат:** Инженеры дробят работу на тривиальные коммиты, чтобы выглядеть занятыми. Качество код-ревью падает. Старшие инженеры, делающие самую сложную и важную работу, оказываются недооценёнными и уходят. ### Антипаттерн 2: Weaponization velocity Когда менеджер говорит «нашей velocity нужно вырасти на 20% в следующем квартале» — он фундаментально неправильно понял, что такое velocity. Velocity — инструмент планирования для внутренней калибровки конкретной команды. Она не сравнима между командами, не сравнима между кварталами после изменения состава команды и не является объективной мерой производительности. В момент, когда вы устанавливаете целевые значения velocity в performance-ревью, команды достигают их за счёт: раздувания оценок story points, дробления историй на микрозадачи, засчитывания историй как выполненных до надлежащего тестирования и создания технического долга для очистки доски спринта. ### Антипаттерн 3: Накрутка KPI в отчётности по инцидентам ATM Когда уровень инцидентов привязан к performance-ревью команды, классификация инцидентов становится политической. Аутейджи банкоматов классифицируются как «аппаратные сбои» (которые не засчитываются против команды ПО), а не «программно вызванные аппаратные сбои». Сетевые проблемы сваливаются на инфраструктурную команду, а не на логику повторных попыток прикладного уровня. Результат: метрики инцидентов выглядят здоровыми, пока реальная система деградирует. **Решение:** Классификацию инцидентов должна проводить независимая сторона — принципиальный инженер или отдельная reliability-команда, — а не команда, которую измеряют. ### Антипаттерн 4: Перегрузка метриками Организации с 40+ KPI в 12 категориях создают дашборды, на которые инженеры смотрят один раз, чувствуют себя overwhelmed и больше никогда не открывают. Человеческий мозг способен отслеживать и действовать на основании примерно 5–7 ключевых метрик на данном уровне фокуса. Больше — диффузия внимания и паралич принятия решений. Дисциплина проектирования KPI-системы — это не _больше измерений_, а безжалостный отбор минимального количества метрик, дающих наиболее чёткую картину. Если ваши топ-KPI не помещаются на одном экране без скролла — у вас их слишком много. ### Антипаттерн 5: Иллюзия «зелёного дашборда» Дашборд, где все метрики зелёные, — не достижение. Это предупреждение. Либо ваши цели слишком низкие, либо измерение сломано, либо ваша команда научилась оптимизировать под метрики, а не под outcomes, которые метрики должны представлять. Здоровая KPI-система всегда должна показывать какие-то жёлтые метрики — области известных проблем, над которыми команда активно работает. Если всё неизменно зелёное — повышайте цели или проводите аудит измерений. --- ## 9. Реальный кейс > 📋 **NovaCash Systems: от хаоса к управляемой поставке** > > _NovaCash Systems — вымышленный, но репрезентативный составной образ реальных компаний, разрабатывающих ПО для банкоматов в Восточной Европе и СНГ. Описанная ситуация отражает паттерны, встречавшиеся автору в нескольких реальных проектах._ ### Отправная точка: организованный хаос #### До — Год 0 |Область|Состояние| |---|---| |KPI-система|Отсутствует — поставка измеряется фразой «вышел ли релиз?»| |Средний Lead Time фичи|11 недель от запроса до деплоя на банкомат| |Bug Escape Rate|42% — почти половина всех багов находится в проде| |Простой ATM из-за ПО|1,8% fleet-hours в месяц| |Предсказуемость спринта|58% — почти половина взятых обязательств не выполняется| |MTTR|4,2 часа в среднем для программных инцидентов| |Управление изменениями|Нет формального процесса — 3 незадокументированных экстренных патча за квартал| |Bus Factor|1 на модуле обработки ISO 8583| |eNPS команды|–12 (детракторов значительно больше, чем промоутеров)| |Коэффициент техдолга|14% — почти в 3 раза выше целевого| #### После — Месяц 12 |Область|Состояние| |---|---| |KPI-система|Полный фреймворк активен в 3 инженерных командах| |Средний Lead Time фичи|5,5 недели **(–50%)**| |Bug Escape Rate|14% **(–67%)**| |Простой ATM из-за ПО|0,41% **(–77%)**| |Предсказуемость спринта|83% (стабильно, без занижения обязательств)| |MTTR|22 минуты для программных инцидентов **(–91%)**| |Управление изменениями|100% соответствие 2 квартала подряд| |Bus Factor|3 на модуле ISO 8583 (обучены двое дополнительных инженеров)| |eNPS команды|+28 (значительный разворот от –12)| |Коэффициент техдолга|7,2% **(–49%, улучшение продолжается)**| ### Что реально изменилось Измеримые улучшения стали результатом небольшого числа целевых изменений — KPI показали, куда инвестировать. **Главная победа — снижение простоя ATM (–77%):** Базовые измерения выявили, что 60% программных инцидентов банкоматов имели единственную первопричину: приложение банкомата некорректно обрабатывало ошибки таймаутов в пуле соединений с АБС, заставляя XFS-сервис переходить в невосстановимое состояние, требующее перезапуска устройства. Об этом знали неофициально годами, но никогда не приоритизировали, потому что это не измерялось. После появления измерений это стало инициативой P0. Три недели рефакторинга полностью устранили паттерн. **Снижение Lead Time (–50%):** Анализ CFD выявил, что задачи проводили в среднем 17 дней в статусе «ожидание QA» — не потому что QA работал медленно, а потому что QA-окружение было общим для трёх команд и постоянно недоступным. Выделение отдельного QA-окружения для каждой команды (2 недели инфраструктурной работы) сократило время ожидания QA до менее 3 дней. **Улучшение Bug Escape Rate (–67%):** Анализ код-ревью показал, что 70% ускользнувших багов прошли через PR, смерженные менее чем за 2 часа — быстрее, чем обычно возможно для осмысленного ревью. Введение мягкого минимума в 4 часа для PR на платёжно-критичный код улучшило глубину ревью. Дополнительно — интеграция обязательного сканирования безопасности (Semgrep, dependency audit) в CI-пайплайн поймала целый класс ускользавших уязвимостей. **Снижение MTTR (–91%):** Предыдущий процесс реагирования на инциденты требовал ручного SSH на системы мониторинга, запроса логов и корреляции данных из 4 разных инструментов до постановки диагноза. Развёртывание единого observability-стека (Prometheus + Loki + Grafana с преднастроенными дашбордами реагирования на инциденты) сократило среднее время триажа с 45 минут до менее 5 минут для 80% типов инцидентов. **Восстановление eNPS (+40 пунктов):** Инженеры почувствовали, что их работа теперь видима и ценится. Снижение продовых инцидентов уменьшило on-call нагрузку, которая выжигала людей. Явное выделение 20% спринта на технический долг дало команде разрешение работать с проблемами, которые они накапливали годами. ### Итоговые результаты |Метрика|Улучшение| |---|---| |Feature Lead Time|–50%| |Bug Escape Rate|–67%| |Простой ATM из-за ПО|–77%| |Mean Time to Restore|–91%| |eNPS команды|+40 пунктов (–12 → +28)| |Незадокументированные продовые изменения (H2)|**0**| --- ## 10. Заключение После 20+ лет в mission-critical финтехе и разработке ПО для банкоматов — вот что я узнал о KPI, чего не скажет ни один фреймворк: **KPI не создают лучшую инженерию. Лучшая инженерия создаёт лучшие KPI.** KPI-система — диагностический инструмент, а не управленческая техника. Метрики обнажают, где сломана система. Задача инженерного руководства — исправить то, что обнажают метрики. Если вы не вносите структурных изменений на основе того, что показывают KPI, — вы просто создаёте дорогостоящий отчётный механизм. **Наиболее важные метрики — те, которые труднее всего накрутить.** Доступность флота ATM, процент успешных транзакций, Bug Escape Rate, MTTR — их сложно фальсифицировать, потому что они укоренены в реальном мире. Банкомат, который не работает, — не работает, вне зависимости от того, что показывает дашборд velocity команды. **Доверие инженеров — не KPI, но оно определяет, работают ли ваши KPI.** Если инженеры считают, что KPI-система — инструмент слежки, они будут обходить её. Если они считают её системой для выявления и устранения препятствий для их лучшей работы — они примут её. То, во что они верят, почти полностью определяется тем, как руководство внедряет и использует метрики. **В регулируемом финтехе цена игнорирования измерений катастрофична.** Проверка центрального банка, аудит PCI DSS Level 1 или оценка вендорских рисков банком-клиентом зададут вопросы о ваших инженерных метриках. «Мы формально не отслеживаем уровень неудачных деплоев» — неприемлемый ответ регулятору, оценивающему вашу операционную устойчивость. **Наконец: начинайте с малого, начинайте честно и сохраняйте последовательность.** Пять метрик, измеряемых тщательно в течение 12 месяцев, расскажут о вашей инженерной системе больше, чем 40 метрик, отслеживаемых небрежно в течение 3 месяцев. Ваши банкоматы работают с реальными деньгами реальных клиентов. Ваш код обработки платежей работает в одной из наиболее регулируемых и высокорисковых сред коммерческого ПО. Профессионализм вашей системы инженерных измерений должен это отражать. > _«Нельзя управлять тем, что не измеряешь — но измерять неправильные вещи хуже, чем не измерять вовсе»._ — по мотивам Питера Друкера ### Ключевые выводы - Измеряйте системы, а не людей — 70% командных KPI, 30% индивидуального качества вклада - Адаптируйте DORA-метрики к регулируемой реальности ATM/финтеха — бенчмарки частоты деплоя не переносятся напрямую из SaaS - ATM-специфичные метрики (аптайм флота, инциденты/устройство, интеграционные SLA) — бизнес-критичны, а не метрики тщеславия - Закон Гудхарта разрушит каждую метрику, которую вы превратите в цель производительности — используйте контрметрики и регулярно обновляйте набор KPI - Срок внедрения 5 месяцев — реалистичен; всё более быстрое жертвует инженерной поддержкой, которая делает систему работающей - Начинайте со сбора базовых данных — цели без базовых данных — это организационный театр - Удовлетворённость инженеров (eNPS) — опережающий индикатор всех остальных метрик. Берегите её соответственно --- _Серия для инженерных лидеров · KPI для mission-critical финтеха и ATM-систем · 2025_