## 1. Введение ### Почему KPI-системы в разработке чаще всего не работают Позвольте начать с неудобной истины: большинство KPI-программ в инженерных командах не улучшают работу — они её разрушают. Медленно, незаметно, но системно. Паттерн везде одинаковый. Появляется новый руководитель с мандатом «сделать процессы прозрачными». Через 60 дней объявляется KPI-фреймворк. Команды начинают оптимизировать под метрики вместо того, чтобы делать хорошее ПО. Через полгода velocity растёт на бумаге, качество падает в реальности, а самые сильные инженеры начинают уходить, потому что чувствуют себя под микроскопом. Я видел это в банковских системах с 10 тысячами пользователей и в финтех-стартапах с 15 разработчиками. Механика одна и та же. Почему это происходит? Три фундаментальные ошибки: **Первая:** измерение активности вместо результатов. Количество закрытых тикетов, количество коммитов, velocity — всё это измеряет движение, а не прогресс. Команда может быть очень активной и при этом создавать продукт, который разрушает клиентский опыт. **Вторая:** измерение людей вместо системы. Это самая разрушительная ошибка. Деминг был прав: 85–95% проблем производительности — системные, а не индивидуальные. Инженер в сломанном процессе, с плохой кодовой базой, без нормальной среды разработки будет показывать плохие метрики вне зависимости от своей квалификации. Когда вы меряете людей вместо системы, вы наказываете симптомы и оставляете болезнь нетронутой. **Третья:** неправильный инструмент или неправильное использование правильного инструмента. Именно здесь Jira — одновременно и решение, и проблема. ### Jira как недооценённый инструмент управления Jira есть почти в каждой инженерной организации. И почти везде её используют примерно на 20% возможностей: создают тикеты, ведут спринты, иногда смотрят на бёрндаун. Всё. Между тем в Jira уже сейчас находятся данные для отслеживания Lead Time, Cycle Time, Bug Escape Rate, уровня переоткрытия багов, WIP, предсказуемости спринтов и многого другого. Эти данные не нужно собирать — они уже там. Нужно научиться их читать. Цель этой статьи — показать, как именно. Без общих слов, с конкретными JQL-запросами, конфигурацией дашбордов и примерами из реальной практики в fintech-окружении. --- ## 2. Нативные возможности Jira Прежде чем покупать плагины, нужно понять, что Jira уже умеет. Это важно по двум причинам: во-первых, многие необходимые метрики доступны бесплатно; во-вторых, без понимания нативных данных плагины будут бесполезны — garbage in, garbage out. ### Жизненный цикл задачи и переходы статусов Каждая задача в Jira хранит полную историю переходов между статусами с временными метками. Это фундамент для расчёта Cycle Time и обнаружения узких мест в процессе. Поля, доступные нативно: - `created` — дата создания задачи - `updated` — дата последнего изменения - `resolutiondate` — дата закрытия (Resolution) - `status` — текущий статус - `statusCategory` — категория статуса (To Do / In Progress / Done) Из этих полей строятся базовые формулы: - **Lead Time** = `resolutiondate` − `created` - **Cycle Time** ≈ `resolutiondate` − (дата первого перехода в статус «In Progress») Важный нюанс: нативная Jira не хранит историю переходов в удобном для запросов виде через JQL. Для точного Cycle Time потребуется либо плагин (Time in Status), либо экспорт во внешний инструмент. Но для приблизительных оценок нативных данных достаточно. ### Спринт-данные Если вы используете Scrum-доски, Jira хранит: - К какому спринту принадлежит задача - Была ли задача добавлена в спринт после его начала (sprint scope change) - Была ли задача завершена в спринте или перенесена - Velocity каждого спринта Это основа для метрик предсказуемости и стабильности команды. ### Компоненты, метки, версии Часто игнорируемые, но критически важные атрибуты: - **Components** — к какой части системы относится задача (например: `payment-processing`, `atm-xfs-layer`, `reporting`) - **Labels** — гибкие теги для кросс-функциональной классификации - **Fix Version** — к какому релизу относится задача - **Affects Version** — в какой версии найден баг Без правильного заполнения этих полей большинство полезных KPI невозможно. Это первое, что нужно стандартизировать при внедрении. ### Связи между задачами Jira поддерживает нативные связи: - `blocks / is blocked by` - `duplicates / is duplicated by` - `relates to` - `is caused by / causes` (можно добавить кастомно) Правильное использование связей позволяет строить граф: Story → Bug → Incident, что критично для качественных метрик. ### Нативные отчёты и гаджеты |Отчёт|Что показывает|Для чего полезен| |---|---|---| |Velocity Chart|Story points / issues за спринт|Тренд производительности команды| |Sprint Report|Завершённые vs. незавершённые задачи|Предсказуемость спринта| |Burndown Chart|Прогресс сгорания задач|Оперативный контроль спринта| |Control Chart|Cycle Time по задачам|Идентификация выбросов| |Cumulative Flow Diagram|Поток задач по статусам|Обнаружение WIP-проблем| |Release Burndown|Прогресс к релизу|Планирование поставки| |Created vs. Resolved|Входящий vs. исходящий поток задач|Баланс нагрузки команды| --- ## 3. Основные KPI на нативной Jira ### A. Метрики поставки #### Lead Time (Время от создания до закрытия) **Определение:** Полное время от создания задачи до её разрешения. Включает время ожидания в бэклоге. **Формула:** ``` Lead Time = resolutiondate - created ``` **JQL для анализа:** ```jql project = "PAYMENTS" AND issuetype = Story AND status = Done AND resolutiondate >= -30d ORDER BY resolutiondate DESC ``` Для расчёта Lead Time экспортируйте результат в CSV и рассчитайте разницу дат. В нативном Jira нет встроенного агрегата по времени — это одно из ключевых ограничений. **Гаджет:** Control Chart (настроенный на все статусы от «Open» до «Done»). **Интерпретация:** Если средний Lead Time превышает 6 недель для Story среднего размера — у вас системная проблема: либо слишком большая очередь, либо недостаточная мощность команды, либо задачи слишком крупные. Смотрите на тренд, а не на абсолютное значение. --- #### Cycle Time (Время активной разработки) **Определение:** Время от момента, когда задача взята в работу, до закрытия. То, на что инженерная команда имеет прямое влияние. **JQL для приближённого Cycle Time:** ```jql project = "PAYMENTS" AND issuetype in (Story, Bug) AND status changed to "In Progress" during (-60d, now()) AND status = Done ``` **Гаджет:** Control Chart — ключевой инструмент для Cycle Time. Показывает каждую задачу как точку на графике «время закрытия vs. длительность». Выбросы выше 85-го перцентиля — ваши проблемные задачи. **Интерпретация:** - Медиана Cycle Time растёт → накапливается технический долг или задачи становятся крупнее - Высокая вариативность (большой разброс точек) → непредсказуемый процесс, нестабильное определение done - Стабильная медиана + редкие выбросы → зрелый процесс --- #### Throughput (Пропускная способность) **Определение:** Количество задач, завершённых за период, нормализованное по типу задачи. **JQL:** ```jql project = "PAYMENTS" AND issuetype in (Story, Task) AND status changed to Done during (-14d, now()) AND issuetype != Sub-task ``` Для разбивки по типам задач: ```jql project = "PAYMENTS" AND issuetype = Bug AND status changed to Done during (-14d, now()) AND labels = "production-defect" ``` **Гаджет:** Created vs. Resolved Chart. Если линия Resolved стабильно ниже линии Created — у вас растёт бэклог. Это ранний сигнал перегрузки команды. **Интерпретация:** Не сравнивайте throughput между командами без нормализации по сложности. Команда, закрывающая 8 задач в неделю, может доставлять больше ценности, чем команда с 25 задачами, если первая работает с критической платёжной логикой, а вторая — с UI-компонентами. --- #### Sprint Completion Rate (Предсказуемость спринта) **Определение:** Процент задач, завершённых в спринте из тех, что были взяты в начале (без учёта задач, добавленных после старта). **JQL для задач, добавленных после старта спринта:** ```jql project = "PAYMENTS" AND sprint = "PAYMENTS Sprint 42" AND sprint not in openSprints() AND created >= "2025-01-15" ``` Где `2025-01-15` — дата старта спринта. **JQL для незакрытых задач спринта:** ```jql project = "PAYMENTS" AND sprint = "PAYMENTS Sprint 42" AND status != Done AND sprint not in openSprints() ``` **Гаджет:** Sprint Report (встроенный). Смотрите на раздел «Completed Issues» vs. «Issues Not Completed». **Целевое значение:** 80–85% стабильно. Ниже 70% — системная проблема с планированием. 100% стабильно — команда сознательно занижает обязательства (sandbagging). --- ### B. Метрики качества #### Bug Count Trend (Тренд количества багов) **JQL — открытые баги по компоненту:** ```jql project = "PAYMENTS" AND issuetype = Bug AND status not in (Done, Closed, "Won't Fix") AND component = "payment-processing" ORDER BY priority DESC ``` **JQL — баги, созданные за последние 30 дней:** ```jql project = "PAYMENTS" AND issuetype = Bug AND created >= -30d AND created <= now() ORDER BY created DESC ``` **Гаджет:** Two-Dimensional Filter Statistics — позволяет разбить баги по приоритету и компоненту одновременно. --- #### Bug Escape Rate (Уровень утечки багов) **Определение:** Доля багов, найденных в продовом окружении, от общего числа багов за период. **Требование к данным:** Необходимо кастомное поле `Found In Environment` со значениями: `Development`, `Testing/QA`, `Staging`, `Production`. **JQL — баги из прода:** ```jql project = "PAYMENTS" AND issuetype = Bug AND "Found In Environment" = Production AND created >= -30d ``` **JQL — все баги за период:** ```jql project = "PAYMENTS" AND issuetype = Bug AND created >= -30d ``` **Расчёт:** ``` Bug Escape Rate = (prod_bugs / total_bugs) × 100% ``` Экспортируйте оба запроса в CSV. Автоматизация расчёта требует eazyBI или внешнего BI-инструмента. **Целевое значение для fintech:** <10% для багов P1/P2. Выше 25% — ваш QA-процесс не работает. --- #### Reopen Rate (Уровень переоткрытия) **Определение:** Процент багов, которые были закрыты и затем переоткрыты из-за неадекватного исправления. **JQL — баги, переоткрытые за 30 дней:** ```jql project = "PAYMENTS" AND issuetype = Bug AND status changed to "Reopened" during (-30d, now()) ``` **Альтернативный вариант через историю статусов:** ```jql project = "PAYMENTS" AND issuetype = Bug AND status was "Done" before -7d AND status changed from Done during (-7d, now()) ``` **Интерпретация:** Reopen Rate >15% — сигнал о недостаточном покрытии тестами при исправлении или о давлении дедлайнов, заставляющем закрывать баги без надлежащей проверки. --- ### C. Метрики эффективности процесса #### WIP — Work in Progress **Определение:** Количество задач, находящихся в активной разработке в данный момент. **JQL — текущий WIP по команде:** ```jql project = "PAYMENTS" AND status in ("In Progress", "In Review", "In Testing") AND assignee in membersOf("payments-dev-team") AND sprint in openSprints() ``` **JQL — задачи без движения более 3 дней:** ```jql project = "PAYMENTS" AND status in ("In Progress", "In Review", "QA Testing") AND updated <= -3d AND sprint in openSprints() ``` **Гаджет:** Cumulative Flow Diagram (CFD). Если «полоса» статуса «In Progress» или «In Review» начинает расширяться — растёт WIP и возникают узкие места. **Целевое значение:** WIP на разработчика — не более 1–2 задач. Если у инженера 5+ задач «In Progress» — это признак дисфункционального процесса. --- #### Bottleneck Detection через Time in Status Нативно Jira не предоставляет прямой отчёт «время в статусе». Однако CFD показывает аккумулирование задач в конкретных статусах — это первый сигнал. **JQL — задачи, «застрявшие» в статусе более 5 дней:** ```jql project = "PAYMENTS" AND status = "In Review" AND status changed to "In Review" before -5d AND status != Done ``` Замените `"In Review"` на любой подозрительный статус: `"Awaiting Deployment"`, `"QA Testing"`, `"Waiting for Info"`. --- ### Сводная таблица KPI: JQL, гаджеты и интерпретация |KPI|JQL (упрощённый)|Гаджет / Отчёт|Целевое значение|Красный флаг| |---|---|---|---|---| |Lead Time|`status = Done AND resolutiondate >= -30d`|Control Chart|<4 нед. для Story|>8 недель| |Cycle Time|`status changed to "In Progress" during (-60d, now()) AND status = Done`|Control Chart|<5д p50|>14д p50| |Throughput|`status changed to Done during (-14d, now()) AND issuetype != Sub-task`|Created vs. Resolved|Стабильный тренд|Снижение 2+ нед. подряд| |Sprint Completion Rate|Sprint Report (встроенный)|Sprint Report|80–85%|<70%| |Bug Count Trend|`issuetype = Bug AND status not in (Done, Closed)`|Pie Chart / 2D Stats|Тренд ↓|Рост >20% за квартал| |Bug Escape Rate|`"Found In" = Production AND created >= -30d`|2D Filter Stats|<10%|>25%| |Reopen Rate|`status changed to "Reopened" during (-30d, now())`|Filter Stats|<10%|>20%| |WIP|`status in ("In Progress","In Review") AND sprint in openSprints()`|CFD|<1,5× размер команды|>2× размер команды| |Задачи-долгожители|`status = "In Progress" AND updated <= -7d`|Filter Results|0 задач >7д|>3 задачи| --- ## 4. Ограничения нативной Jira Честный разговор: нативная Jira хороша для базового отслеживания, но имеет принципиальные ограничения, которые делают её недостаточной для зрелой KPI-системы. ### Отсутствие точного Time in Status Это главное слабое место. Jira хранит историю переходов, но не предоставляет удобного способа запросить «сколько времени задача провела в статусе X» через JQL. Вы можете увидеть, когда статус изменился, но не агрегировать это по задачам и командам нативно. Следствие: истинный Cycle Time из «коробки» недостаточно точен. CFD показывает тренды, но не позволяет докопаться до конкретной задачи и сказать «она 12 дней ждала в QA». ### Отсутствие DORA-метрик из коробки Deployment Frequency, Change Failure Rate, MTTR — в нативной Jira этого нет. Jira не знает о деплоях, если вы не настроили интеграцию с CI/CD. Для получения этих метрик требуется либо плагин (Jira + GitLab integration), либо внешняя система (Grafana, Datadog). ### Слабая кросс-проектная аналитика В компаниях с несколькими проектами (типичная ситуация для банка с командами: Core Banking, ATM Software, Mobile, DevOps) нативные отчёты работают в рамках одного проекта. Получить сводный KPI «по всему инженерному подразделению» через нативный интерфейс крайне сложно. ### Ограниченная историческая аналитика Нативные отчёты Jira хорошо работают для текущего состояния и последних 30–90 дней. Исторический тренд за год+ — это уже территория BI-инструментов. Стандартные гаджеты не позволяют сравнить Q1 2024 с Q1 2025 в одном виде. ### Нет агрегации метрик по времени без ручного труда Среднее Lead Time за месяц, медианный Cycle Time за квартал, процентильные распределения — всё это требует экспорта в Excel или настройки eazyBI. В нативном Jira вы работаете со списками задач, а не с агрегированными метриками. ### Резюме ограничений |Потребность|Нативная Jira|Решение| |---|---|---| |Точный Time in Status|Нет|Time in Status plugin| |DORA-метрики|Нет|Jira + GitLab/Jenkins интеграция| |Кросс-проектная аналитика|Ограничено|eazyBI| |Историческая аналитика >90д|Ограничено|eazyBI / внешний BI| |Процентильные распределения|Нет|eazyBI / экспорт в BI| |Автоматический Bug Escape Rate|Нет|eazyBI + кастомные поля| |PR-метрики|Нет|Git-интеграции| |Дашборды для нетехнических стейкхолдеров|Базово|Rich Filters / eazyBI| --- ## 5. Расширенное отслеживание KPI с плагинами ### A. Time in Status **Что это:** Плагин для Jira (Atlassian Marketplace), добавляющий детальный анализ времени, проведённого задачей в каждом статусе. **Что даёт:** - Точный расчёт Cycle Time: от «In Progress» до «Done» с учётом реального времени, а не calendar time - Тепловая карта задержек по статусам — сразу видно, что 60% времени задачи проводят в «Awaiting QA» - Фильтрация по типу задачи, компоненту, assignee (для системной диагностики, не для оценки людей) - Перцентильные распределения: p50, p85, p95 **Пример использования в fintech:** Команда обработки платежей замечает, что средний Cycle Time вырос с 6 до 14 дней за квартал. Нативная Jira показывает только Control Chart с выбросами. Time in Status показывает: 8 из 14 дней задачи проводят в статусе «Security Review». Причина — один security-инженер стал бутылочным горлышком. Решение: добавить второго ревьюера и параллелизировать проверки. Без Time in Status вы бы месяцами гадали, почему вырос Cycle Time. **Конфигурация для fintech:** Создайте отчёт с разбивкой по статусам: ``` To Do → Refinement → In Progress → In Review → Security Review → QA → Staging → Done ``` Для каждого статуса: среднее время, медиана, p85, количество задач. Любой статус с медианой >2 рабочих дня для стандартных Story — кандидат на оптимизацию. --- ### B. eazyBI **Что это:** Мощный BI-инструмент, глубоко интегрированный с Jira. По сути — MDX/SQL-аналитика поверх данных Jira с красивыми дашбордами. **Что даёт:** - Кастомные вычисляемые метрики (среднее, медиана, перцентили, год-к-году сравнение) - Кросс-проектная аналитика в одном дашборде - Историческая аналитика без ограничений по глубине - MDX-выражения для нестандартных расчётов - Нативная интеграция с Git, Jenkins и другими источниками данных **Ключевые кейсы для fintech:** Bug Escape Rate автоматически через MDX: ```mdx [Measures].[Issues created] WHERE [Issue Type].[Bug] AND [Custom Field - Found In Environment].[Production] ``` Делите на общее количество багов за период — получаете автоматически обновляемый KPI без ручного Excel. Lead Time с перцентилями: eazyBI позволяет вычислить медианный Lead Time и p85 Lead Time за любой период, по любому проекту или компоненту. Это недостижимо нативными средствами Jira. Сравнение кварталов: дашборд «Q1 2025 vs. Q1 2024» — 15 минут настройки в eazyBI. В нативной Jira — несколько часов ручного экспорта и сравнения в Excel. **Стоимость и оправданность:** eazyBI — платный инструмент (~$200–500/мес для команды 20–50 человек на Cloud). Для fintech-команд с серьёзными требованиями к отчётности перед регуляторами или советом директоров — обязательная инвестиция. Для небольших команд (до 10 человек) можно обойтись нативными средствами + Excel. --- ### C. Rich Filters for Jira Dashboards **Что это:** Плагин, добавляющий интерактивные фильтры и улучшенные визуализации в стандартные Jira-дашборды. **Что даёт:** - Dropdown-фильтры прямо на дашборде (без перехода в JQL) - Интерактивные таблицы с сортировкой и группировкой - Экспорт в Excel одним кликом прямо с дашборда - Drill-down: клик на «15 багов» → видите список этих конкретных багов **Когда нужен:** Когда руководители (CTO, Head of Risk, банк-клиент) должны самостоятельно смотреть на дашборды без необходимости знать JQL. Rich Filters превращает Jira-дашборд из инструмента для разработчиков в инструмент для менеджмента. --- ### D. Git-интеграции: GitHub, GitLab, Bitbucket **Что это:** Atlassian предоставляет нативные интеграции (через Jira Software → Development Panel), а также сторонние плагины типа GitLab for Jira, GitHub for Jira. **Что даёт после привязки репозитория к Jira-проекту:** - Связанные ветки и коммиты (по упоминанию ключа задачи: `PAY-123`) - Pull Requests / Merge Requests: статус, кто ревьюит, когда создан - Pipeline статус: прошёл ли CI для данной задачи **Метрики, доступные через интеграцию:** - PR Cycle Time ≈ время от создания PR до мержа (видно в GitLab Analytics) - Deployment status ≈ дошла ли задача до конкретного окружения (если настроены Deployment events) - PR без связи с задачей — коммиты, не привязанные к Jira-тикету (признак нарушения процесса) **JQL с использованием Git-данных:** ```jql project = "PAYMENTS" AND development[pullrequests].open > 0 AND status = "In Progress" ``` Показывает задачи в разработке с открытыми PR — полезно для ежедневного стендапа. ```jql project = "PAYMENTS" AND development[branches].count > 0 AND status = "To Do" ``` Задачи, которые «ещё не взяты» по Jira, но уже имеют ветки — признак работы без тикетов. --- ## 6. DevOps-метрики в экосистеме Jira DORA-метрики — Deployment Frequency, Lead Time for Changes, Change Failure Rate, MTTR — стандарт для DevOps-организаций. Нативно Jira их не предоставляет, но их можно приблизить через комбинацию инструментов. ### Deployment Frequency (Частота деплоя) **Подход 1: Jira Release + Fix Version** Каждый деплой = релиз в Jira с тегом Fix Version. Фиксируйте дату каждого деплоя как Release Date. ```jql project = "PAYMENTS" AND fixVersion in releasedVersions() AND fixVersion in versionsReleasedBetween("2025-01-01", "2025-03-31") ``` Количество уникальных версий за период = приближение к Deployment Frequency. **Подход 2: Jira + GitLab/Jenkins через вебхуки** Настройте GitLab CI/CD или Jenkins так, чтобы при каждом деплое создавался Jira-тикет типа `Deployment` с полями: окружение, версия, статус деплоя, timestamp. ```jql project = "DEVOPS" AND issuetype = Deployment AND "Environment" = Production AND created >= -30d ``` --- ### Change Failure Rate (Уровень неудачных деплоев) Тип задачи `Deployment` дополняется полем `Deployment Status` (Success / Rollback Required / Hotfix Required). ```jql project = "DEVOPS" AND issuetype = Deployment AND "Deployment Status" in ("Rollback Required", "Hotfix Required") AND created >= -30d ``` Делите на общее количество деплоев за период. **Связь с инцидентами:** ```jql project = "DEVOPS" AND issuetype = Incident AND "Caused by Deployment" is not EMPTY AND created >= -30d ``` --- ### MTTR (Среднее время восстановления) Создайте тип задачи `Incident` с полями: - `Incident Detected` (datetime) — время обнаружения - `Incident Resolved` (datetime) — время восстановления - `Incident Severity` (P1/P2/P3/P4) - `Root Cause Category` (Software / Infrastructure / Deployment / External) **JQL — инциденты P1 за последние 90 дней:** ```jql project = "INCIDENTS" AND issuetype = Incident AND "Incident Severity" = P1 AND status = Resolved AND resolutiondate >= -90d ORDER BY resolutiondate DESC ``` MTTR = среднее(`Incident Resolved` − `Incident Detected`) по результатам запроса. Расчёт через eazyBI или экспорт в Excel. **Целевые значения для fintech ATM:** - P1 (банкомат недоступен): MTTR <30 мин (программный откат), <4ч (выезд) - P2 (частичная деградация): MTTR <2ч - P3 (не влияет на транзакции): MTTR <24ч ### Интеграционная схема: Jira + CI/CD + инциденты ``` GitLab CI/CD Pipeline │ ├── Деплой успешен → Jira: Deployment [Status: Success] ├── Деплой упал → Jira: Deployment [Status: Failed] │ └── автоматически создаёт Incident [P2] └── Rollback → Jira: Deployment [Status: Rollback] └── связывается с исходным Incident Jira Incident │ ├── Связан с: Deployment (caused by) ├── Связан с: Bug (root cause) └── Поля: Detected, Resolved, MTTR (авторасчёт через Automation) ``` Эта схема не требует внешних инструментов — достаточно GitLab Webhooks → Jira REST API → Jira Automation Rules. --- ## 7. Проектирование реального KPI-дашборда Пример полного дашборда для fintech инженерной команды из 15 человек (Dev + QA + DevOps). ### Принцип трёхуровневого дашборда - **Уровень 1 — Руководство (CTO/Head of Engineering):** стратегический взгляд, обновление еженедельно - **Уровень 2 — Менеджеры команд:** операционный взгляд, обновление ежедневно - **Уровень 3 — Команда:** тактический взгляд, реальное время --- ### Дашборд уровня 1: Инженерное руководство **Виджет 1: Throughput Trend (Created vs. Resolved — 12 недель)** - Тип: Line Chart (Created vs. Resolved gadget) - JQL Resolved: `project in (PAYMENTS, ATM, DEVOPS) AND status changed to Done during (-84d, now()) AND issuetype in (Story, Bug, Task)` - Цель: линия Resolved стабильно выше или равна Created **Виджет 2: Bug Escape Rate — таблица по месяцам** - Тип: Two Dimensional Filter Statistics - Ось X: месяц создания; Ось Y: Found In Environment - Обновление: автоматически через eazyBI **Виджет 3: Sprint Predictability — последние 6 спринтов** - Тип: Sprint Report или eazyBI - Показывает: % выполнения для каждого спринта в разрезе команд **Виджет 4: Open P1/P2 Bugs — текущее состояние** - JQL: `issuetype = Bug AND priority in (P1, P2) AND status not in (Done, "Won't Fix") AND project in (PAYMENTS, ATM)` - Нулевое значение = цель. Любой P1 старше 24 часов — немедленное действие **Виджет 5: Deployment Frequency** - JQL: `issuetype = Deployment AND "Environment" = Production AND created >= -30d` - Целевое значение: ≥4 деплоя в месяц --- ### Дашборд уровня 2: Engineering Manager **Виджет 6: Cumulative Flow Diagram — текущий спринт** - Расширение полос статусов = узкое место → действие менеджера **Виджет 7: Задачи без движения более 3 дней** - JQL: `project = PAYMENTS AND status in ("In Progress", "In Review", "In Testing") AND updated <= -3d AND sprint in openSprints()` **Виджет 8: WIP по статусам** - JQL: `project = PAYMENTS AND status in ("In Progress", "In Review", "QA Testing", "Awaiting Deployment") AND sprint in openSprints()` - Если «Awaiting Deployment» > 30% от WIP — пора автоматизировать деплой **Виджет 9: Bug Reopen Rate — текущий спринт** - JQL: `project = PAYMENTS AND issuetype = Bug AND status changed to "Reopened" during (startOfSprint(), now())` **Виджет 10: Задачи без assignee в активном спринте** - JQL: `project = PAYMENTS AND sprint in openSprints() AND assignee is EMPTY AND status != Done` --- ### Дашборд уровня 3: Команда (Operational) **Виджет 11: Мой текущий WIP** - JQL: `assignee = currentUser() AND status in ("In Progress", "In Review")` **Виджет 12: Мои задачи — ждут других** - JQL: `assignee = currentUser() AND status in ("Awaiting Approval", "Waiting for Info", "Blocked")` **Виджет 13: Open PRs >24ч (через Git-интеграцию)** - JQL: `project = PAYMENTS AND development[pullrequests].open > 0 AND status = "In Review" AND updated <= -1d` --- ### Полная таблица виджетов дашборда |№|Виджет|KPI|Уровень|Тип гаджета|Интерпретация| |---|---|---|---|---|---| |1|Throughput Trend|Пропускная способность|Руководство|Created vs. Resolved|Resolved > Created → здоровый поток| |2|Bug Escape Rate|Качество QA|Руководство|2D Filter Stats / eazyBI|>25% → системная проблема QA| |3|Sprint Predictability|Предсказуемость|Руководство|Sprint Report / eazyBI|<70% → проблема планирования| |4|Open P1/P2 Bugs|Критические дефекты|Руководство|Filter Results|Любой P1 >24ч → немедленное действие| |5|Deployment Frequency|Скорость поставки|Руководство|Filter Stats|<4/мес → тормозит бизнес| |6|CFD|WIP и узкие места|Менеджер|CFD (нативный)|Расширение полосы → bottleneck| |7|Задачи без движения|Блокировки|Менеджер|Filter Results|>3д без движения → блокировка| |8|WIP по статусам|Распределение нагрузки|Менеджер|Pie/Bar Chart|Неравномерность → дисбаланс| |9|Bug Reopen Rate|Качество исправлений|Менеджер|Filter Stats|>15% → слабое тестирование фиксов| |10|Задачи без assignee|Организация спринта|Менеджер|Filter Results|>0 → проблема планирования| |11|Мой WIP|Личный контроль|Команда|Filter Results|>2 → переключение контекста| |12|Мои заблокированные|Блокировки|Команда|Filter Results|>0 → нужна эскалация| |13|Open PRs >24ч|PR Review|Команда|Filter Results (Git)|>0 → бутылочное горлышко ревью| --- ## 8. Связывание задач, багов и инцидентов Это один из самых недооценённых аспектов KPI в Jira. Без правильных связей между сущностями невозможно ответить на ключевые вопросы: «Какой Story привёл к этому продовому багу?» или «Какой деплой вызвал этот инцидент?» ### Стратегия связей **Базовая цепочка:** ``` Epic → Story → Task/Sub-task └──→ Bug (found during development) Story → Bug (found in QA: "is caused by") Bug → Incident (found in Production: "caused by" / "relates to") Deployment → Incident ("caused by") ``` **Правила для команды:** 1. Каждый баг, найденный в QA, должен быть связан с Story, которая его вызвала (`Story PAY-100 causes Bug PAY-456`) 2. Каждый продовый инцидент должен быть связан с деплоем, который его вызвал 3. Каждый инцидент должен иметь связанный баг (root cause) ### Кастомные поля для качественных метрик **Обязательные кастомные поля для Bug:** |Поле|Тип|Значения|Зачем| |---|---|---|---| |`Found In Environment`|Select|Dev / QA / Staging / Production|Bug Escape Rate| |`Root Cause Category`|Select|Logic Error / Missing Test / Requirements Gap / Infra|Анализ причин| |`Introduced In Sprint`|Sprint Picker|(текущий спринт)|Связь с поставкой| |`Caused By Story`|Issue Link|(ссылка на Story)|Трассируемость| **Обязательные кастомные поля для Incident:** |Поле|Тип|Значения|Зачем| |---|---|---|---| |`Incident Severity`|Select|P1 / P2 / P3 / P4|Приоритизация, MTTR| |`Incident Detected`|DateTime|—|Расчёт MTTR| |`Incident Resolved`|DateTime|—|Расчёт MTTR| |`Caused By Deployment`|Issue Link|(ссылка на Deployment)|Change Failure Rate| |`Customer Impact`|Number|(количество затронутых клиентов)|Business Impact| ### Использование Labels и Components **Components** — архитектурные компоненты системы, устанавливаются администратором: ``` payment-processing / atm-xfs-layer / card-management / reporting / security / infrastructure ``` **Labels** — гибкие теги, которые команда добавляет по ситуации: ``` regression / performance / security-critical / customer-reported / tech-debt ``` **JQL с использованием Components для анализа качества:** ```jql project = PAYMENTS AND issuetype = Bug AND component = "payment-processing" AND "Found In Environment" = Production AND created >= -90d ORDER BY priority DESC ``` Этот запрос показывает продовые баги конкретного компонента за квартал. Если таких больше 10 — сигнал для рефакторинга или усиления тестового покрытия именно payment-processing. ### Автоматизация связей через Jira Automation Настройте правило: при создании задачи типа `Incident` с меткой `deployment-related` автоматически создавать ссылку на последний деплой в соответствующем проекте. ``` Trigger: Issue Created Condition: issuetype = Incident AND labels = "deployment-related" Action: Link Issue → [last Deployment in DEVOPS project] → "caused by" ``` Это устраняет человеческий фактор при заполнении связей под давлением инцидента. --- ## 9. План внедрения Реалистичный план для fintech-команды из 15–30 человек. Общий срок: **3 месяца**. ### Шаг 1: Аудит и стандартизация воркфлоу (Недели 1–2) Прежде чем строить KPI — убедитесь, что данные чистые и последовательные. **Что делать:** - Проведите аудит текущих статусов в каждом проекте. Типичная проблема: в одном проекте «In Development», в другом «In Progress», в третьем «Development» — это три разных статуса для одного состояния. - Стандартизируйте воркфлоу: один глобальный воркфлоу для всех Dev-проектов - Зафиксируйте Definition of Done для каждого статуса **Риск:** Команды сопротивляются изменению воркфлоу. **Митигация:** Объясняйте причину — не «потому что менеджмент хочет KPI», а «потому что мы не можем понять, где задача тормозит». --- ### Шаг 2: Чистка данных и ретроспективное заполнение (Недели 2–4) **Что делать:** - Добавьте обязательные кастомные поля (Environment, Severity, Components) — сначала для новых задач - Ретроактивно заполните `Found In Environment` для всех открытых багов - Настройте обязательность заполнения ключевых полей при переходе статусов (Jira Workflow Conditions) **JQL для аудита незаполненных полей:** ```jql project = PAYMENTS AND issuetype = Bug AND "Found In Environment" is EMPTY AND created >= -90d ``` Если этот запрос возвращает сотни задач — у вас проблема с дисциплиной данных. Это нормально на старте — главное зафиксировать и начать исправлять. --- ### Шаг 3: Добавление кастомных полей и конфигурация (Недели 3–5) **Что делать:** - Создайте все необходимые кастомные поля (см. раздел 8) - Настройте экраны задач: поле отображается там, где нужно - Создайте базовые JQL-фильтры и сохраните их — они станут основой дашбордов - Настройте Components для каждого проекта **Важно:** не перегружайте схемы задач десятками полей. Правило: если поле не используется в JQL или метрике — оно не нужно. --- ### Шаг 4: Построение JQL-фильтров (Недели 5–7) Создайте библиотеку сохранённых фильтров: ``` [PAYMENTS] Open P1/P2 Bugs [PAYMENTS] Bug Escape Rate - Last 30d [PAYMENTS] Tasks stuck > 3 days [PAYMENTS] Sprint Completion - Last 6 Sprints [DEVOPS] Deployment Log - Production [ALL PROJECTS] Open Incidents ``` Каждый фильтр: права на просмотр — всем в организации, права на редактирование — только владельцу. --- ### Шаг 5: Создание дашбордов (Недели 7–9) Создайте три дашборда (уровни 1–3 из раздела 7). Начните с Уровня 2 для Engineering Manager — он наиболее полезен и быстро даёт ценность. **Порядок создания виджетов:** 1. Сначала простые — Filter Results (список задач) 2. Затем агрегаты — Filter Statistics, Pie Charts 3. Последними — сложные: CFD, Control Chart, Created vs. Resolved --- ### Шаг 6: Введение KPI в жизнь команды (Недели 9–12) **Что делать:** - Презентуйте дашборды команде. Ключевое сообщение: «Эти метрики показывают, как работает система, а не как работаете вы лично» - Включите просмотр KPI в ритм: 5 минут на дашборд в начале каждого спринта, 10 минут на ретро - Первые 4–6 недель не делайте выводов — собирайте baseline - После получения baseline — установите первые целевые значения совместно с командой **Чего категорически не делать:** - Не публикуйте индивидуальные метрики (сколько задач закрыл инженер X) - Не вводите KPI-бонусы в первые 6 месяцев - Не используйте дашборды как инструмент давления на конкретных людей ### Временна́я шкала внедрения |Период|Фокус|Ожидаемый результат| |---|---|---| |Месяц 1, нед. 1–2|Аудит воркфлоу, стандартизация|Единый воркфлоу, документированный DoD| |Месяц 1, нед. 2–4|Чистка данных, ретроспективное заполнение|Baseline за 90 дней| |Месяц 2, нед. 5–7|Кастомные поля, JQL-фильтры|Библиотека из 10–15 сохранённых фильтров| |Месяц 2, нед. 7–9|Построение дашбордов|3 рабочих дашборда (Уровни 1–3)| |Месяц 3, нед. 9–12|Внедрение в ритм команды|KPI как часть спринт-ретро и планирования| |Месяц 3+|Baseline → Цели → Итерация|Первые измеримые улучшения| --- ## 10. Антипаттерны ### Антипаттерн 1: Измерение разработчиков по количеству закрытых тикетов **Как выглядит:** Менеджер создаёт виджет «Топ-10 разработчиков по закрытым задачам за месяц» и использует его при performance review. **Почему разрушительно:** - Инженеры начинают дробить задачи: одна реальная задача превращается в пять тикетов - Сложная работа (рефакторинг критической системы, менторинг, документирование архитектуры) не видна в счётчике и обесценивается - Самые опытные инженеры, делающие системную работу, выглядят «непродуктивными» — и уходят - В fintech: инженер, закрывший 3 тикета, но предотвративший инцидент стоимостью $500K, выглядит хуже инженера с 20 тривиальными UI-задачами **Правильно:** Измеряйте командный throughput. Индивидуально — только качественные показатели: участие в ревью, вклад в документацию, on-call реагирование. --- ### Антипаттерн 2: Velocity как KPI **Как выглядит:** «Наша velocity должна расти на 10% каждый квартал». Velocity попадает в OKR или ежемесячный отчёт для руководства. **Почему разрушительно:** - Команды раздувают story point estimates - При planning poker консенсус сдвигается вверх - Velocity перестаёт быть калибровочным инструментом и становится политическим - Реальная пропускная способность не меняется; меняются только цифры **Правильно:** Используйте velocity для внутреннего планирования спринтов. Никогда — для сравнения команд или как KPI для отчётности. --- ### Антипаттерн 3: Игнорирование контекста задач **Как выглядит:** Cycle Time вырос с 5 до 12 дней. Немедленный вывод: «команда работает медленнее». Немедленное давление на команду. **Почему разрушительно:** - Причин роста Cycle Time десятки: сложность задач выросла, появились зависимости, security-ревью стало обязательным, команда онбордит новых людей - Без анализа причин любое действие может ухудшить ситуацию - Команды начинают дробить задачи, чтобы показать «лучший» Cycle Time, не меняя реальный процесс **Правильно:** При росте Cycle Time спрашивайте «что изменилось?», а не «кто виноват?» --- ### Антипаттерн 4: Перегрузка дашборда **Как выглядит:** Дашборд с 25+ виджетами, который никто не смотрит. Или 15 метрик, из которых реально обсуждаются только 2. **Почему разрушительно:** - Информационный шум убивает фокус - Важные сигналы теряются среди несущественных - Команды перестают доверять дашборду **Правильно:** Руководство — максимум 5–7 метрик. Команда — максимум 10. Правило: если метрика не вызывала действия последние 3 месяца — удалите её. --- ### Антипаттерн 5: Jira как единственный источник правды о качестве **Как выглядит:** Bug count в Jira = оценка качества продукта. **Почему разрушительно:** - Количество багов в Jira зависит от дисциплины создания тикетов, а не от реального качества - Команды перестают создавать баги, чтобы «улучшить» метрику - Баги фиксируются в чате или на словах, минуя Jira **Правильно:** Сочетайте Jira-метрики с автоматическими источниками: error rate из Sentry/Grafana, результаты автотестов из CI, user-reported incidents из Service Desk. --- ## 11. Реальный кейс ### Фон: RegionalPay — финтех-компания, разрабатывающая ПО для банкоматов _RegionalPay — вымышленная, но репрезентативная компания. Ситуация отражает реальные паттерны из практики._ 45 человек, из них 28 в инженерии (разработка, QA, DevOps). Три команды: ATM Core, Payment Gateway, Back Office. Jira используется 3 года. --- ### До: хаотичное использование Jira - Три команды, три разных воркфлоу. В ATM Core — 12 статусов, в Payment Gateway — 5, в Back Office — 8. Переходы не коррелируют с реальным процессом. - В 60% багов поле `Environment` пусто. Bug Escape Rate невозможно рассчитать. - Velocity — главная и единственная метрика на weekly. - Нет связей между Story и Bug. Нельзя ответить: «какой Story вызвал этот инцидент?» - Инциденты в электронной почте и Excel. Без связи с Jira. - Дашборд: velocity chart и burndown — и больше ничего полезного. **Симптомы:** - CTO не может ответить банку-клиенту на вопрос: «Сколько критических багов в проде за 90 дней?» - Регуляторная проверка потребовала отчёт по инцидентам — сбор данных занял 5 рабочих дней вручную - Команда ATM Core жалуется на «постоянные переделки», но доказать это данными нечем --- ### Что было сделано (3 месяца) **Месяц 1:** Стандартизация воркфлоу до единого для всех команд. Добавлены кастомные поля: `Found In Environment`, `Root Cause Category`, `Incident Severity`, `Caused By Deployment`. Ретроспективно заполнены баги за 90 дней. **Месяц 2:** Настроены 14 JQL-фильтров. Построены дашборды уровней 1 и 2. Настроена интеграция GitLab → Jira (тип задачи `Deployment` создаётся автоматически). Инциденты перенесены из Excel в Jira. **Месяц 3:** Дашборды представлены командам. KPI-ревью добавлен в спринт-ретро (10 минут). Baseline зафиксирован. Первые целевые значения согласованы с командами. --- ### После: через 6 месяцев от начала |Метрика|До|После|Изменение| |---|---|---|---| |Bug Escape Rate|Неизвестно → Baseline 38%|17%|**–55%**| |Среднее время ответа на P1|~4ч (из email)|45 мин|**–81%**| |Время сбора отчёта для регулятора|5 рабочих дней|2 часа (JQL + экспорт)|**–95%**| |Sprint Completion Rate|Baseline 61%|78%|**+28%**| |Задачи-долгожители (>7д)|~12 задач постоянно|~2–3 задачи|**–75%**| |Связанность Story → Bug|0%|84%|**+84 п.п.**| **Что реально изменилось:** **Bug Escape Rate.** Baseline-измерение показало 38% продовых багов. Анализ по компонентам выявил: 71% из них — в модуле `payment-processing`, категория «Missing Test». QA-команда сфокусировалась на этом модуле. Через 6 месяцев — 17%. **Скорость реагирования.** Переход с email-Excel на Jira Incident с полями `Detected` и `Resolved` позволил за 2 недели понять: среднее время от обнаружения до эскалации — 47 минут (инцидент фиксировался в почте, пересылался, обсуждался). Автоматический Slack-алерт при создании P1 в Jira сократил время эскалации до <5 минут. **Sprint Completion Rate.** Дашборд показал: в 40% спринтов более 25% задач добавлялись после старта. Это было причиной непредсказуемости. Ввели правило: любое добавление требует явного согласования менеджера. Completion Rate вырос с 61% до 78% за три спринта. --- ## 12. Заключение ### Ключевые уроки **Первый:** Jira — это база данных о вашем инженерном процессе. Качество KPI определяется качеством данных. Прежде чем строить метрики — наведите порядок в воркфлоу, полях и дисциплине заполнения. Garbage in — garbage out. **Второй:** Начинайте с малого. Не пытайтесь внедрить все 20 метрик одновременно. Начните с трёх: Bug Escape Rate, Sprint Completion Rate, задачи без движения. Получите данные, убедитесь в их правдивости — потом расширяйте. **Третий:** KPI работают только тогда, когда команда понимает их смысл. Не объявляйте метрики — объясняйте, зачем они нужны и что изменится, когда они улучшатся. Покажите, как данные помогают убрать то, что раздражает самих инженеров: долгое ожидание ревью, непредсказуемые спринты, постоянные переделки. **Четвёртый:** Плагины нужны, но не срочно. Начните с нативной Jira — большинство базовых KPI доступны без дополнительных расходов. Time in Status и eazyBI покупайте тогда, когда точно знаете что они дадут и когда нативных средств уже не хватает. **Пятый:** Jira — это инструмент управления системой, а не людьми. Метрики должны отвечать на вопрос «где сломан процесс?», а не «кто плохо работает?». Эта разница — между KPI-системой, которая улучшает инженерную культуру, и той, которая её разрушает. В fintech и ATM-разработке цена ошибки несопоставимо выше, чем в потребительском ПО. Продовый баг в системе обработки платежей — это не «ухудшение пользовательского опыта», а финансовые потери и регуляторный риск. Это делает качественную систему метрик не просто «хорошей практикой», а операционной необходимостью. Правильно настроенная Jira — это не инструмент контроля. Это инструмент видимости. А видимость — первый шаг к управляемому улучшению. --- _Серия для инженерных лидеров · KPI в Jira · Fintech & Enterprise Software · 2025_