Метрики успеха IT-проектов: как измерять и анализировать результаты

Что такое метрики и для чего они нужны

С точки зрения менеджмента, метрики — это измеримые показатели, которые используются для оценки эффективности, прогресса и результативности работы. Они помогают менеджерам принимать обоснованные решения, отслеживать достижения целей, выявлять проблемы и оптимизировать ресурсы.

В этой статье мы рассмотрим:

• в чем заключаются задачи менеджера при работе с метриками;
• как подобрать метрики под проект с учетом особенностей метрик IT-разработки;
• какие основные метрики IT-проектов существуют;
• какие инструменты могут помочь в сборе и анализе показателей;
• как оценить эффективность метрик и что это дает.

Как использовать метрики в проектном треугольнике 

Когда мы говорим про управление IT-проектами, мы объединяем проектное управление и контроль продуктовой разработки. 

Проектный треугольник содержит:

• сроки;
• бюджет;
• скоуп — объем работ для достижения результата проекта и его качества.

В управление разработкой входят:

• исполнители задач, чью работу нужно организовать; 
• продукт, который нужно доставить конечному потребителю.

При этом у разработки может и не быть конечного срока, но мы должны контролировать бюджет и качество создания продукта. 

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

Подбирать метрики проще и легче, зная их специфику в сфере. В IT это:

• фокус на технических параметрах: качество кода, время отклика системы, уровень доступности, интегрируемость с другими системами, минимально необходимые серверы для развертывания продукта;
• фокус на оценке пользователя: Customer Satisfaction и Net Promoter Score (NPS) помогают оценить, насколько конечный продукт отвечает ожиданиям пользователей. Реакция рынка во многом определяет стратегию развития, выживаемость продукта;
• фокус на гибких подходах к управлению разработкой: метрики можно легко и быстро оценивать, изменять и отбрасывать те, которые не дают ответов на поставленные вопросы.

Основные метрики IT-проектов

Разберем метрики трех разных направленностей:

• технической,
• продуктовой,
• управленческой.

Технические метрики могут многое сказать о «здоровье» и качестве продукта с точки зрения кода, технологии разработки, соответствия современным техническим стандартам на рынке. К ним относятся:

1. Uptime (Время безотказной работы) — процент времени, в течение которого система или приложение доступно пользователям без перебоев.
2. Crash Rate (Уровень сбоев) — процент сессий взаимодействия между пользователем и приложением, которые завершились сбоем.
3. Response Time (Время отклика системы) — время, необходимое для обработки запроса.
4. Latency (Задержка, Время ожидания) — время задержки между запросом пользователя и ответом системы. В широком смысле, это любая задержка во время выполнения запросов.

Еще можно выделить Code Quality (Качество кода) — это не метрика, а совокупность значений разных характеристик кода. Она измеряется:

• числом багов. Это найденные в коде баги до и после релиза. То есть те, что нашли тестировщики на этапе разработки и те, про которые написали пользователи; 
• тестовым покрытием (coverage) — какая доля кода обеспечена тестами —ручным или автоматизированным тестированием. Эта характеристика помогает убедиться, что критические участки кода были протестированы;
• оценкой технического долга — объемом задач, на которых команда решила «сэкономить» время в процессе разработки. Обычно это быстрое архитектурное решение, которое потом, после релиза, команда дорабатывает и заменяет на более фундаментальное.

Для каждого проекта будет свой набор технических метрик в зависимости от сложности и типа продукта. Например, при разработке высоконагруженной системы, которая обрабатывает большое количество данных и запросов, нужно учитывать пропускную способность, длину очередей запросов и среднюю нагрузку системы в единицу времени. Эти метрики могут помочь сформировать конкурентное преимущество — ваша система быстрее оппонентов поставляет ценность клиенту.

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

1. Customer Satisfaction (Удовлетворенность пользователей) — оценка взаимодействия клиентов с продуктом через опросы, отзывы и рейтинги. 
2. Retention Rate (Уровень удержания пользователей) — процент пользователей, продолжающих использовать продукт после первого взаимодействия через какой-то отрезок времени. Например, через 30 дней после скачивания приложения 75% пользователей продолжают регулярно заходить в приложение.
3. Conversion Rate (Конверсия) — процент пользователей, совершивших целевое действие в веб- или мобильном приложении: регистрацию, покупку, подписку.
4. Active Users (Активные пользователи, DAU/MAU) — количество уникальных активных пользователей за день (DAU) или за месяц (MAU).
5. Time to Market (Время выхода на рынок) — время, которое потребовалось для разработки и вывода продукта или новой функции на рынок.

В зависимости от того, какой у вас продукт, можно детализировать эти метрики. Например, если вы выпустили мобильное приложение в дополнение к сайту, то сравните количество покупок на сайте и покупок внутри приложения (In-App Purchases). 

Также для оценки конкретной функции можно использовать количественные и качественные исследования в маркетинге и продуктовом менеджменте.

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

1. Velocity (Скорость разработки) — количество задач или пользовательских историй, которые команда завершает за один спринт или один цикл разработки.
2. Budget Variance (Отклонение бюджета) — разница между запланированным и фактическим бюджетом проекта. Она помогает напомнить, что, например, изменение списка разработки обойдется в Х больше денег, чем было запланировано изначально. Также в отклонении можно внести причины его возникновения. Это поможет сделать процессы прозрачными.
3. Lead Time (Время выполнения задачи) — время от появления задачи в бэклоге до ее завершения.
4. Cycle Time (Время цикла) — время, необходимое для выполнения задачи.
5. Team Satisfaction (Удовлетворенность команды) —  показатель, насколько команда довольна проектом, процессами и условиями работы. Измеряется через опросы и обратную связь.
6. ROI (Возврат инвестиций) — оценка доходности проекта относительно вложенных в него ресурсов, позволяет измерить финансовую эффективность продукта.

Среди управленческих метрик можно использовать другие показатели: финансовые, кадровые, ресурсные. Также вы можете отслеживать и прогнозировать риски — оценивать, скольких удалось избежать, а какие из них наступили и повлекли за собой непредвиденные расходы.

Главное — контролировать те метрики, которые действительно помогают принимать управленческие решения, а не уходят «в стол».

Как менеджеру работать с метриками в IT-проекте

Любой проект состоит из цикла, который включает в себя этапы инициации, планирования, реализации, контроля, завершения.

У менеджера на всех стадиях разработки есть определенные задачи по управлению процессом и результатом, поэтому работа с метриками ведется на каждом этапе создания продукта.

• На этапе инициации менеджер определяет базовые метрики, которые помогут отслеживать ключевые риски и результаты конкретного проекта. Это могут быть ожидания от проекта, сформулированные в его резюме. Например, для мобильного приложения — это количество скачиваний. Еще ожидания включают прогнозы ROI (возврат инвестиций), который будет, например, не менее 20% исходя из статистики отрасли.
• На этапе планирования менеджер, аналитик или продукт-менеджер подбирает и детализирует метрики для каждой команды или этапа проекта, выставляет ожидаемые метрики. Например, для команды разработчиков важны метрики Code Quality и Velocity, для маркетинговой команды — метрики привлечения пользователей. Эти показатели и нужно заложить в ожидания.
• В процессе реализации контроль и мониторинг происходит в режиме реального времени. Если команда работает по Agile, каждую итерацию нужно проверять и пересматривать метрики, чтобы оперативно вносить изменения в процесс. 
• На этапе завершения менеджер смотрит на поставленные ожидания и сравнивает их с фактическими полученными значениями. Метрики ROI, удовлетворенность пользователей или количество исправленных багов помогают оценить общий успех проекта.

Важно: завершение может означать окончание работ над какой-либо функцией проекта, а не в целом его закрытие. Разработка основного продукта — это не конец. После его выхода на рынок команда дорабатывает его и обновляет, а менеджер продолжает контролировать метрики проекта. 

Разберем, какие задачи менеджер решает с помощью метрик в ходе работы:

• оценка прогресса. Метрики позволяют отслеживать, насколько быстро продвигается проект по сравнению с планом. Например, с помощью показателя Velocity (скорость разработки) менеджер может понять, справляется ли команда с задачами на спринт;
• идентификация проблем. Метрики помогают выявлять узкие места в проекте: недостатки в коде, нехватку ресурсов или задержки. Например, метрики качества кода (такие как Code Coverage) показывают, насколько проект уязвим к багам;
• прогнозирование. Менеджер с помощью метрик может предсказывать будущие риски и проблемы. Например, если на протяжении нескольких спринтов Velocity снижается, это может быть сигналом перегруженности команды или проблем в процесса;.
• принятие решений. На основе метрик менеджер принимает стратегические решения: перераспределяет ресурсы, изменяет сроки или меняет приоритеты.

Как подобрать метрики под проект с учетом особенностей IT

Подбор метрик для IT-проекта зависит от его специфики и контекста. Вот несколько ключевых критериев для выбора:

1. Метрики соответствуют типу проекта:
   • для веб-проектов важны такие метрики, как время загрузки страниц, коэффициент отказов и конверсии;
   • в мобильных приложениях фокус смещается на удержание пользователей, частоту сбоев и производительность приложения;
   • для корпоративных систем важны показатели, связанные с уровнем доступности (SLA), безопасностью и интеграцией с другими системами.
2. Метрики должны отражать ключевые цели проекта. Например, если целью является быстрая доставка продукта на рынок, важной метрикой будет Time to Market — время от начала разработки до выхода продукта. Если цель — заработать определенный объем денег на подписках, то мы оцениваем конверсии в покупку и LTV (Lifetime Value) — общий доход за время использования приложения одним пользователем.
3. Метрики должны учитывать доступные ресурсы. Если у команды ограниченные ресурсы, фокусируйтесь на метриках, которые помогают выявлять узкие места и оптимизировать процессы. Это такие метрики, как Cycle Time (Время цикла — сколько времени от создания до реализации заняла задача) и  Defect Rate (Частота дефектов — количество ошибок, найденных после релиза, чтобы экономить силы на пострелизном обслуживании продукта).

Какие инструменты могут помочь в сборе и анализе метрик

Есть 2 подхода в сборе данных по метрикам:

• real-time;
• в документе, который мы добросовестно выполняем.

Real-time метрики информативнее и прозрачнее, чем созданные на основе них документы-артефакты для контроля и мониторинга проекта.

Например, в практике менеджмента проектов есть рекомендация вносить данные в Test Coverage Document на этапе контроля. Это документ, который описывает объем и качество тестирования продукта. Он включает в себя информацию о тестовых сценариях, данных, методах и покрытии тестирования. Но в современной разработке у большинства QA-команд есть системы управления тестами, которая помогает считать метрику Test Coverage автоматически. При этом тестовые сценарии и тестовые данные вносятся в код, который работает как документация. В таком случае сам документ не нужен. Его создание займет время, но никто никогда его не откроет. 

В качестве инструмента можно использовать системы  для управления разработкой — Kaiten, Jira, Google Analytics, GitLab. И уже из них за выбранный период выносить нужные метрики в дашборд. 

Предварительно вместе с командной определите, за какими метриками необходимо наблюдать. И в динамике выводите на дашборд нужные показатели за определенный период. На основе данных можно сделать выводы, принять решения о развитии проекта. Лучше всего синхронизироваться с циклом разработки и сверять метрики от цикла к циклу — от спринта к спринту. Так вы успеете «подтянуть» низкие показатели к новому спринту. 

Сейчас бОльшая часть управленческих метрик самостоятельно считается в таск-трекерах, откуда можно подтягивать информацию в дашборды и таблицы. И системы управления проектами — такие как Kaiten — предоставляют множество отчетов о работе команды. 

В итоге можно выделить 3 основных инструмента для сбора метрик:

• таск-трекер для отслеживания показателей в реальном времени,
• дашборд для их отображения,
• отчеты для аналитики. 

Примеры полезных отчетов для снятия IT-метрик 

Разберем несколько отчетов, которые будут полезны для анализа эффективности работы IT-компании. Все изображения взяты из таск-менеджера Kaiten. 

Cumulative Flow Diagram

Это график, который позволяет видеть, как меняется количество работы на каждом этапе с течением времени. 

Если вкратце, то диаграмма позволяет отследить:

• объем выполненных задач на каждом этапе,
• темп работы,
• сколько задач еще нужно выполнить,
• на каких этапах продвижения задач есть проблемы. 

Cycle time

Как говорили выше, Cycle time — это цикл выполнения задачи от «Очереди» до «Готово». На графике в Kaiten вы можете посмотреть, сколько задача находилась на каждом из этапов. 

Velocity

График для отображения скорости выполнения задач. Отлично подходит для контроля продолжительности спринтов Scrum-команды. 

Чтобы измерить количество работы используют условную переменную Story point, которая может означать сложность или объем задачи. Значение переменной команда присваивает самостоятельно перед стартом спринта. 

С помощью такого отчета можно быстро:

• спрогнозировать дальнейшую скорость работы команды,
• посмотреть скорость работы каждого участника,
• оценить изменения в процессах. 

Control chart

Control chart — это точечный график, который показывает сколько задач было выполнено за определенный период времени и сколько часов потребовалось на каждую из них. Чем выше находится точка, тем дольше задача была в работе. 

Здесь же есть SLA (Service Level Agreement) — линия, которая показывает договоренности между заказчиком и исполнителями о том, за сколько времени должны быть выполнены задачи. Если вы не устанавливаете ее сами, то алгоритм Kaiten предлагает среднее время выполнения за прошлый период. 

Метрики IT-проекта: коротко о важном

IT-метрики делятся на три направления:

• технические,
• продуктовые,
• управленческие. 

В технические метрики входят:

• Uptime — время безотказной работы;.
• Crash Rate — уровень сбоев;
• Response Time — время отклика системы;
• Latency — время задержки.

Список возможных продуктовых метрик:

• Customer Satisfaction — удовлетворенность пользователей;
• Retention Rate — уровень удержания пользователей;
• Conversion Rate — процент целевых действий;
• Active Users — активные пользователи;
• Time to Market — время выхода на рынок. 

Управленческие показатели:

• Velocity — скорость разработки;
• Budget Variance — отклонение бюджета;
• Lead Time — время выполнения задачи с момента взятия обязательств;
• Cycle Time — время выполнения задачи с момента старта работы;
• Team Satisfaction — удовлетворенность команды;.
• ROI — возврат инвестиций. 

Для того чтобы оценить метрики, используйте отчетность и просматривайте движение задач по этапам в таск-трекере. Это поможет оценить, как быстро и в каком объеме они движутся по стадиям разработки и тестирования.  

Универсального набора метрик, который будет подходить под каждый IT-проект, не существует. В зависимости от типа проекта необходимо подбирать свои показатели, оценка которых будет приносить пользу, а не лишнюю бюрократию.