Health check IT‑проекта — это быстрая диагностика по 7 метрикам (сроки, деньги, поток задач, качество, предсказуемость, люди, стейкхолдеры), которая помогает не «верить в план», а видеть риск срыва заранее; ключевой риск — смотреть на красивые цифры вместо причин, особенно когда все героически «успевают» за счёт выгорания.

Есть два типа проектов: те, где метрики IT‑проекта действительно подсвечивают проблему, и те, где метрики рисуют для успокоения начальства. Во втором случае у вас не project management, а кружок художественной гимнастики с диаграммами.

В российской реальности health check осложняется двумя вещами: импортозамещение (Jira уехала, остались Yandex Tracker, Kaiten, Битрикс24 и друзья) и культ «героизма» (переработки перед релизом называют “рывком”). Поэтому вопрос «как отслеживать метрики» — это не про формулы из PMBOK, а про то, чтобы поставить дашборд и перестать врать самим себе.

Что именно проверяем в health check (и почему 7 метрик — не магия, а минимум)

1) Отклонение по срокам (Schedule Variance / SV): когда план уже умер, но вы ещё не знаете

Тезис: SV показывает разницу между планом и фактом по срокам/объёму. Если SV уходит в минус — проект скатывается в “успеем потом”.

Как применяют в РФ: обычно в связке с диаграммой Ганта (в корпорациях) или Burndown Chart (в Agile-командах).

Практический вывод: SV нужен, чтобы вовремя признать: “мы не успеваем”, а не чтобы красиво объяснить, почему “почти успели”.

Подводный камень: SV можно «улучшить», просто выкинув кусок scope. Технически цифра станет лучше, бизнес — нет.

2) CPI (Cost Performance Index): бюджетный детектор фантазий

Тезис: CPI = освоенный объём / фактические затраты. Если CPI < 1, вы тратите больше, чем «стоите» по плану.

Почему критично: для аутсорса и заказной разработки с фиксированным бюджетом CPI — это не “финансовая метрика”, а вопрос выживания маржи.

Практический вывод: хотите health check — держите CPI в еженедельном отчёте вместе со сроками. Деньги без сроков — бесполезно, сроки без денег — самообман.

Подводный камень: CPI часто считают раз в месяц “по бухгалтерии”. Поздно. Проект умирает быстрее отчётного периода.

3) Lead Time и Cycle Time: где вы теряете время — в очереди или в работе

Тезис:

• Lead Time — от появления идеи/тикета до релиза.
• Cycle Time — сколько задача реально была “в работе”.

В образовании: это база Kanban и Lean: метрики потока, поиск узких мест, снижение “ожидания”.

Практический вывод: если Lead Time растёт, а Cycle Time нет — у вас пробка в очереди (приоритизация, согласования, зависимость от одного человека).

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

4) Defect Density (плотность дефектов): сколько багов вы покупаете каждым релизом

Тезис: дефекты на KLOC (тысячу строк кода) или на модуль. Высокая плотность дефектов = качество падает, техдолг растёт.

Практический вывод: метрика нужна не для наказаний, а для решения: инвестируем в рефакторинг, тесты, code review, стабилизацию.

Подводный камень: сравнивать команды по плотности дефектов — сомнительно. Разный домен, код, легаси. Сравнивайте проект с самим собой во времени.

5) Velocity: предсказуемость команды, а не повод меряться “скоростью”

Тезис: сколько Story Points команда закрывает за спринт.

Практический вывод: velocity помогает прогнозировать объём, если вы не меняете команду каждые две недели и нормально калибруете оценки.

Подводный камень (классика): сравнивать разные команды по Velocity — ошибка уровня “сравним килограммы с метрами”. На нормальных курсах по Scrum это проговаривают отдельно.

6) Team Happiness / Niko-Niko: экономика настроения (да, серьёзно)

Тезис: пульс команды (самооценка настроения) предсказывает текучесть раньше, чем заявление “по собственному”.

Российская специфика: при кадровом голоде найм дорогой и долгий. Поэтому падение Team Happiness — это будущая стоимость замены людей, простаивания и онбординга.

Практический вывод: включайте well-being в health check официально: выгорание — производственная проблема, а не “HR потом разберётся”.

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

7) NPS/CSI стейкхолдеров: вы делаете правильно — или просто делаете

Тезис: удовлетворённость заказчика/бизнеса показывает, совпал ли результат с ожиданиями, а не с формальным ТЗ.

Практический вывод: если сроки и качество норм, но NPS падает — у вас проблема в коммуникации/ожиданиях/ценности. По данным PMI и российских аналитиков, до 70% провалов — это именно про коммуникацию и отсутствие прозрачных метрик на ранних этапах.

Подводный камень: спрашивать “вы довольны?” раз в квартал. Квартал — это вечность для продукта и два релиза для команды.

Какие инструменты использовать в РФ: импортозамещение без страданий

Если вы реально хотите понять, как отслеживать метрики, забудьте ручной Excel-сбор. Он легко съедает до 20% времени менеджера — слишком дорогая привычка.

Сколько стоит научиться метрикам (и почему это вообще ROI-история)

В РФ курсы “Project Manager в IT”/“Product Manager”, где учат метрики проекта и метрики IT‑проекта, стоят:

• 100 000 – 160 000 ₽ за профессию “с нуля”
• 30 000 – 60 000 ₽ за короткие интенсивы по hard skills/метрикам
• 6–12 месяцев по времени на полное погружение

По данным HeadHunter и Хабр Карьеры спрос на менеджеров, которые умеют аналитику и инструменты (Jira/Kaiten/SQL), вырос на 15–20% за год. И да, теперь в вакансиях всё чаще требуют именно Yandex Tracker или Kaiten: более 40% компаний уже переехали на отечественные таск‑трекеры.

Экспертный вердикт: мини-инструмент для health check без фанатизма

Вот короткий чек‑лист, который использую, когда нужно отличить “метрики для управления” от “метрик для отчёта”.

1. Одна страница: SV + CPI + Lead/Cycle + Defect Density + Velocity + Team Happiness + NPS/CSI. Если не помещается — вы пишете книгу, а не управляете.
2. Динамика важнее цифры: любые метрики проекта смотрим трендом 4–8 недель.
3. У каждой метрики есть действие: “если X — делаем Y”. Нет действия — вы собираете коллекцию графиков.
4. Запрет на метрики тщеславия: “закрыли 300 задач” ничего не значит без Cycle Time и ценности.
5. Светофор для стейкхолдеров: зелёный/жёлтый/красный + план. Без плана жёлтый = красный (просто стесняетесь признаться).

И да: если переработки стали нормой, проект “здоров” только в презентации. В реальности он просто доедает команду. Точнее… уже доел, просто эффект будет через пару месяцев.

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