Метрики успеха IT-проектов: как измерять и анализировать результаты
Как измерять прогресс IT-проекта с помощью понятных метрик? Разбираем в статье с проектным менеджером
Что такое метрики и для чего они нужны
Я Арина Барлова, сертифицированный проектный менеджер. И в этой статье я расскажу о том, какие метрики помогают оценить успех IT-проекта и понять, насколько всё идет по плану в процессе работы.
С точки зрения менеджмента, метрики — это измеримые показатели, которые используются для оценки эффективности, прогресса и результативности работы. Они помогают менеджерам принимать обоснованные решения, отслеживать достижения целей, выявлять проблемы и оптимизировать ресурсы.
В этой статье мы рассмотрим:
- в чем заключаются задачи менеджера при работе с метриками;
- как подобрать метрики под проект с учетом особенностей метрик IT-разработки;
- какие основные метрики IT-проектов существуют;
- какие инструменты могут помочь в сборе и анализе показателей;
- как оценить эффективность метрик и что это дает.
Как использовать метрики в проектном треугольнике
Когда мы говорим про управление IT-проектами, мы объединяем проектное управление и контроль продуктовой разработки.
Проектный треугольник содержит:
- сроки;
- бюджет;
- скоуп — объем работ для достижения результата проекта и его качества.
В управление разработкой входят:
- исполнители задач, чью работу нужно организовать;
- продукт, который нужно доставить конечному потребителю.
При этом у разработки может и не быть конечного срока, но мы должны контролировать бюджет и качество создания продукта.
Задача менеджера «свести» проектное управление и продуктовую разработку с помощью метрик, чтобы оценить реальный прогресс и результативность команды.
Подбирать метрики проще и легче, зная их специфику в сфере. В IT это:
- фокус на технических параметрах: качество кода, время отклика системы, уровень доступности, интегрируемость с другими системами, минимально необходимые серверы для развертывания продукта;
- фокус на оценке пользователя: Customer Satisfaction и Net Promoter Score (NPS) помогают оценить, насколько конечный продукт отвечает ожиданиям пользователей. Реакция рынка во многом определяет стратегию развития, выживаемость продукта;
- фокус на гибких подходах к управлению разработкой: метрики можно легко и быстро оценивать, изменять и отбрасывать те, которые не дают ответов на поставленные вопросы.
Основные метрики IT-проектов
Разберем метрики трех разных направленностей:
- технической,
- продуктовой,
- управленческой.
Технические метрики могут многое сказать о «здоровье» и качестве продукта с точки зрения кода, технологии разработки, соответствия современным техническим стандартам на рынке. К ним относятся:
- Uptime (Время безотказной работы) — процент времени, в течение которого система или приложение доступно пользователям без перебоев.
- Crash Rate (Уровень сбоев) — процент сессий взаимодействия между пользователем и приложением, которые завершились сбоем.
- Response Time (Время отклика системы) — время, необходимое для обработки запроса.
- Latency (Задержка, Время ожидания) — время задержки между запросом пользователя и ответом системы. В широком смысле, это любая задержка во время выполнения запросов.
Еще можно выделить Code Quality (Качество кода) — это не метрика, а совокупность значений разных характеристик кода. Она измеряется:
- числом багов;
- тестовым покрытием (coverage) — числом тестов на «сантиметр» кода;
- оценкой технического долга — объемом невыполненных задач.
Для каждого проекта будет свой набор технических метрик в зависимости от сложности и типа продукта. Например, при разработке высоконагруженной системы, которая обрабатывает большое количество данных и запросов, нужно учитывать пропускную способность, длину очередей запросов и среднюю нагрузку системы в единицу времени. Эти метрики могут помочь сформировать конкурентное преимущество — ваша система быстрее оппонентов поставляет ценность клиенту.
Продуктовые метрики помогают оценить, насколько клиентам нравится продукт. Также они включают в себя соотношение ожиданий предприятия и конечного результата.
- Customer Satisfaction (Удовлетворенность пользователей) — оценка взаимодействия клиентов с продуктом через опросы, отзывы и рейтинги.
- Retention Rate (Уровень удержания пользователей) — процент пользователей, продолжающих использовать продукт после первого взаимодействия через какой-то отрезок времени. Например, через 30 дней после скачивания приложения 75% пользователей продолжают регулярно заходить в приложение.
- Conversion Rate (Конверсия) — процент пользователей, совершивших целевое действие в веб- или мобильном приложении: регистрацию, покупку, подписку.
- Active Users (Активные пользователи, DAU/MAU) — количество уникальных активных пользователей за день (DAU) или за месяц (MAU).
- Time to Market (Время выхода на рынок) — время, которое потребовалось для разработки и вывода продукта или новой функции на рынок.
В зависимости от того, какой у вас продукт, можно детализировать эти метрики. Например, если вы выпустили мобильное приложение в дополнение к сайту, то сравните количество покупок на сайте и покупок внутри приложения (In-App Purchases).
Также для оценки конкретной функции можно использовать количественные и качественные исследования в маркетинге и продуктовом менеджменте.
Управленческие метрики — помогают оценивать «нестабильные» элементы: людей, затраченный бюджет и время.
- Velocity (Скорость разработки) — количество задач или пользовательских историй, которые команда завершает за один спринт или один цикл разработки.
- Budget Variance (Отклонение бюджета) — разница между запланированным и фактическим бюджетом проекта. Она помогает напомнить, что, например, изменение списка разработки обойдется в Х больше денег, чем было запланировано изначально. Также в отклонении можно внести причины его возникновения. Это поможет сделать процессы прозрачными.
- Lead Time (Время выполнения задачи) — время от появления задачи в бэклоге до ее завершения.
- Cycle Time (Время цикла) — время, необходимое для выполнения задачи.
- Team Satisfaction (Удовлетворенность команды) — показатель, насколько команда довольна проектом, процессами и условиями работы. Измеряется через опросы и обратную связь.
- ROI (Возврат инвестиций) — оценка доходности проекта относительно вложенных в него ресурсов, позволяет измерить финансовую эффективность продукта.
Среди управленческих метрик можно использовать другие показатели: финансовые, кадровые, ресурсные. Также вы можете отслеживать и прогнозировать риски — оценивать, скольких удалось избежать, а какие из них наступили и повлекли за собой непредвиденные расходы.
Главное — контролировать те метрики, которые действительно помогают принимать управленческие решения, а не уходят «в стол».
Как менеджеру работать с метриками в IT-проекте
Любой проект состоит из цикла, который включает в себя этапы инициации, планирования, реализации, контроля, завершения.
У менеджера на всех стадиях разработки есть определенные задачи по управлению процессом и результатом, поэтому работа с метриками ведется на каждом этапе создания продукта.
- На этапе инициации менеджер определяет базовые метрики, которые помогут отслеживать ключевые риски и результаты конкретного проекта. Это могут быть ожидания от проекта, сформулированные в его резюме. Например, для мобильного приложения — это количество скачиваний. Еще ожидания включают прогнозы ROI (возврат инвестиций), который будет, например, не менее 20% исходя из статистики отрасли.
- На этапе планирования менеджер, аналитик или продукт-менеджер подбирает и детализирует метрики для каждой команды или этапа проекта, выставляет ожидаемые метрики. Например, для команды разработчиков важны метрики Code Quality и Velocity, для маркетинговой команды — метрики привлечения пользователей. Эти показатели и нужно заложить в ожидания.
- В процессе реализации контроль и мониторинг происходит в режиме реального времени. Если команда работает по Agile, каждую итерацию нужно проверять и пересматривать метрики, чтобы оперативно вносить изменения в процесс.
- На этапе завершения менеджер смотрит на поставленные ожидания и сравнивает их с фактическими полученными значениями. Метрики ROI, удовлетворенность пользователей или количество исправленных багов помогают оценить общий успех проекта.
Важно: завершение может означать окончание работ над какой-либо функцией проекта, а не в целом его закрытие. Разработка основного продукта — это не конец. После его выхода на рынок команда дорабатывает его и обновляет, а менеджер продолжает контролировать метрики проекта.
Разберем, какие задачи менеджер решает с помощью метрик в ходе работы:
- оценка прогресса. Метрики позволяют отслеживать, насколько быстро продвигается проект по сравнению с планом. Например, с помощью показателя Velocity (скорость разработки) менеджер может понять, справляется ли команда с задачами на спринт;
- идентификация проблем. Метрики помогают выявлять узкие места в проекте: недостатки в коде, нехватку ресурсов или задержки. Например, метрики качества кода (такие как Code Coverage) показывают, насколько проект уязвим к багам;
- прогнозирование. Менеджер с помощью метрик может предсказывать будущие риски и проблемы. Например, если на протяжении нескольких спринтов Velocity снижается, это может быть сигналом перегруженности команды или проблем в процесса;.
- принятие решений. На основе метрик менеджер принимает стратегические решения: перераспределяет ресурсы, изменяет сроки или меняет приоритеты.
Как подобрать метрики под проект с учетом особенностей IT
Подбор метрик для IT-проекта зависит от его специфики и контекста. Вот несколько ключевых критериев для выбора:
- Метрики соответствуют типу проекта:
- для веб-проектов важны такие метрики, как время загрузки страниц, коэффициент отказов и конверсии;
- в мобильных приложениях фокус смещается на удержание пользователей, частоту сбоев и производительность приложения;
- для корпоративных систем важны показатели, связанные с уровнем доступности (SLA), безопасностью и интеграцией с другими системами.
- Метрики должны отражать ключевые цели проекта. Например, если целью является быстрая доставка продукта на рынок, важной метрикой будет Time to Market — время от начала разработки до выхода продукта. Если цель — заработать определенный объем денег на подписках, то мы оцениваем конверсии в покупку и LTV (Lifetime Value) — общий доход за время использования приложения одним пользователем.
- Метрики должны учитывать доступные ресурсы. Если у команды ограниченные ресурсы, фокусируйтесь на метриках, которые помогают выявлять узкие места и оптимизировать процессы. Это такие метрики, как 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-проект, не существует. В зависимости от типа проекта необходимо подбирать свои показатели, оценка которых будет приносить пользу, а не лишнюю бюрократию.