Метрики IT‑проекта — это измеримые показатели IT‑проекта (индикаторы проекта IT), которые показывают: мы вообще движемся к цели или просто красиво «заняты» — по срокам, деньгам, качеству, ценности для бизнеса и здоровью команды. Измеряются они через данные из таск‑трекера, репозиториев, мониторинга и финансов.

Самая частая картина в российских компаниях: отчёты есть, графики есть, «статусы» по пятницам есть — а понимания, почему релиз сорвался и где утек бюджет, нет. Метрики IT‑проекта либо «для галочки», либо потому что кто-то увидел в Telegram модную аббревиатуру DORA и решил: вот оно, спасение.

Проблема не в метриках. Проблема в том, что метрика без решения — это просто число. А метрика, которая заставляет людей играть в KPI-театр (накручивать story points, закрывать задачи «на отвали», резать тесты) — ещё и вредная.

Как выбрать метрики IT‑проекта: от цели, а не от инструмента

Тезис: правильные показатели IT‑проекта завязаны на управленческие решения. Если по метрике нельзя понять «что делать в понедельник», это не метрика, а украшение дашборда.

Практический вывод: сначала формулируем цель (что считаем успехом), потом — индикаторы проекта IT, потом — где брать данные и как часто смотреть.

• Цель бизнеса: рост выручки, снижение издержек, выполнение требований регулятора.
• Цель продукта: активация, удержание, конверсия, NPS/CSI, доля фичи в сценариях.
• Цель проекта: уложиться в срок/бюджет/объём, не сломать прод, не выжечь команду.

Подводный камень: «успех» подменяют «успели выкатить». В России это особенно популярно в интеграциях с 1С, Госуслугами, ЕМИАС/МИС и прочими системами, где “релиз” без стабильности и поддержки просто переносит боль на операционку.

Классификация: 6 корзин, в которые удобно раскладывать показатели IT‑проекта

1) Сроки и предсказуемость (Delivery)

Тезис: проект ценен не скоростью, а предсказуемостью. Бизнесу важнее «выйдем 20-го ±2 дня», чем «когда-нибудь быстро».

• Lead Time — время от идеи/заведения задачи до продакшена.
• Cycle Time — время от «в работе» до «готово».
• План-факт по релизам — % релизов, вышедших в обещанный срок.
• Throughput — сколько задач/историй реально завершаете за период.

Как измерять: Jira/YouTrack (российский фаворит), Kaiten, GitLab Issues. Важно: единые статусы и договорённость, что такое «Done».

Подводный камень: сравнивать команды по throughput без учёта размера задач. Начинается «режем на микро‑таски» ради красоты графика.

2) Деньги и экономика (Cost)

Тезис: бюджет в IT — это не только зарплаты. Стоимость владения (TCO) и цена задержки (Cost of Delay) обычно сильнее, чем «перерасход на подрядчика».

• Burn Rate — скорость сжигания бюджета (₽/неделя или ₽/месяц).
• Cost of Delay — сколько стоит каждый месяц задержки (упущенная выручка/штрафы/ручные операции).
• TCO — стоимость владения за год: поддержка, лицензии, инфраструктура, доработки.

Как измерять: финучёт + timesheets (если есть), затраты на облако/железо, лицензии (например, 1С, Postgres Pro, КриптоПро), поддержка (SLA/аутсорс).

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

3) Качество и стабильность (Quality / Reliability)

Тезис: качество — это не «мало багов», а «система держится и меняется без истерики».

• Defect Leakage — доля дефектов, ушедших в прод.
• MTTR — среднее время восстановления после инцидента.
• Change Failure Rate — доля изменений, приведших к инцидентам/откатам.
• SLA/SLO — доступность, латентность, ошибки (для сервисов).

Как измерять: мониторинг (Prometheus/Grafana, Zabbix), логирование (ELK/OpenSearch), инциденты в Service Desk (например, Naumen, ITSM-системы). Баги — из трекера + postmortem.

Подводный камень: считать «количество багов» мерилом качества. Чем лучше тестирование, тем больше багов вы найдёте — и это хорошо.

4) Объём и управление содержанием (Scope)

Тезис: проект тонет не от сложных задач, а от бесконтрольного scope creep — «а давайте ещё вот это, маленькое».

• Scope Change Rate — сколько требований меняется по ходу.
• Requirement Volatility — пересборка требований (частота и масштаб изменений).
• Rework — доля времени на переделки.

Как измерять: история изменений в Confluence/Р7-Офис/корпоративных вики, версии ТЗ, количество возвратов задачи из QA в Dev, причины переоткрытий.

Подводный камень: пытаться «зацементировать» требования там, где нужен discovery. Для продукта — норм, что требования меняются; ненорм — что вы это не контролируете.

5) Ценность для пользователя и бизнеса (Value)

Тезис: можно сделать проект в срок и в бюджет — и выпустить никому не нужную штуку. Классика жанра.

• Adoption — доля пользователей, использующих новую функцию.
• Activation Rate — конверсия в целевое действие.
• Retention — удержание (D7/D30, если применимо).
• Экономия времени — сколько человеко-часов убрали автоматизацией.

Как измерять: продуктовая аналитика (AppMetrica, Яндекс.Метрика, self-hosted), логирование событий, опросы, данные CRM (Битрикс24 и аналоги).

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

6) Здоровье команды (Team / Process)

Тезис: если команда выжжена, метрики проекта быстро превращаются в «кривую приближения к увольнению».

• WIP — сколько задач одновременно в работе.
• Bus Factor — сколько людей, без которых всё встанет.
• Текучесть — оборот команды за квартал/год.
• Овертаймы — не героизм, а сигнал проблем планирования.

Как измерять: WIP — из канбан-доски, текучесть — HR-данные, bus factor — ревизия знаний/ревью-картина по репозиторию.

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

Мини-набор «если вы новичок и не хотите утонуть»: 12 ключевых метрик

Как именно измерять: источники данных и частота

Тезис: метрики IT‑проекта должны быть дешевле, чем решения, которые они запускают. Если на сбор метрик уходит 2 дня в неделю аналитика — вы строите храм, а не управленческий инструмент.

1. Таск‑трекер (YouTrack/Jira/Kaiten): lead/cycle time, WIP, throughput, rework. Частота: еженедельно.
2. Git (GitLab/Gitea): частота деплоя, код‑ревью, размер PR, ownership. Частота: еженедельно/ежемесячно.
3. Мониторинг (Zabbix, Prometheus): доступность, MTTR, инциденты. Частота: ежедневно + разборы инцидентов.
4. Финансы: burn rate, TCO, cost of delay. Частота: ежемесячно.
5. Продуктовая аналитика: adoption/retention/конверсия. Частота: еженедельно (для продукта) или по релизам.

Подводный камень: собирать «среднее по больнице». Для lead time берите медиану и перцентили (например, P85), иначе пару «долгостроев» испортят картину или наоборот спрячут проблему.

Коммерческие факторы: что метрики экономят в рублях (и где скрытая цена)

Здесь без магии. Типовые потери в IT‑проектах обычно сидят в трёх местах: простои (инциденты), переделки (rework) и задержки (cost of delay). И да, это всё деньги.

• Инциденты: если ваш сервис приносит 300 000 ₽ выручки в день, то падение на 2 часа — это не «ну бывает», а примерно 25 000 ₽ упущенной выручки плюс репутационные потери. MTTR помогает уменьшить это окно.
• Переделки: 15–30% времени на rework в проектах с плохой постановкой — не редкость. При команде 6 человек это легко превращается в «минус один разработчик» по полезной мощности.
• Задержки: если регуляторный дедлайн (например, отчётность/маркировка/интеграции) сорван — штрафы и экстренные подрядчики обычно дороже нормальной разработки.

Скрытая цена метрик: BI‑дашборды, которые поддерживать дороже, чем сам проект; KPI, которые разрушают культуру; и время людей на «ручной сбор». Поэтому автоматизация и простота важнее красоты.

Экспертный вердикт и инструмент: чек‑лист метрик, которые реально управляют проектом

Если вы меняете профессию на IT или вы джун с 1–3 годами опыта, не пытайтесь «переметричить» всё. Возьмите 8–12 индикаторов проекта IT и привяжите каждый к решению.

• 1) Какая цель? (Срок, деньги, качество, бизнес-результат.)
• 2) Какое решение я приму, если метрика стала хуже? (Урезать WIP, добавить тесты, переоткалибровать скоуп, поднять приоритет.)
• 3) Где источник данных? (YouTrack/GitLab/Zabbix/финансы.)
• 4) Кто владелец метрики? (Не «все», а конкретный человек/роль.)
• 5) Какой порог тревоги? (Например, P85 lead time > 14 дней.)
• 6) Как часто смотрим? (Еженедельно/ежемесячно, не «когда вспомним».)
• 7) Как защищаемся от накрутки? (Определение Done, выбор медианы, связки метрик.)

И да: «скорость разработки» без метрик качества — это как «быстро еду» без тормозов. Впечатляет ровно до первого поворота.

Частые вопросы