Метрики в IT-проектах: как выбрать, внедрить и отследить

IT-проект – сложный «механизм», который требует организации и контроля. В этой статье backend-разработчик SimbirSoft Ринат рассматривает метрики как один из способов наблюдения за состоянием проекта, приводит примеры метрик и области их применения на проектах. Материал будет полезен менеджерам проектов, в которых еще не внедрены метрики, и начинающим разработчикам, которые задумываются об улучшениях в работе.

Зачем нужны метрики и как их выбрать

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

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

Если ваш проект – небольшой стартап, который не имеет достаточно ресурсов и находится на стадии создания, многие из метрик будут только мешать. На старте, когда все силы брошены на максимально быстрое создание продукта, нет смысла тратить время на ведение большого количества метрик, достаточно 3-5. Они могут быть не только неэффективными, но и давать отрицательный результат.

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

Метрики в проблемных местах

Метрики могут появляться на месте уже найденных проблем. Чаще всего команда занимается только бизнес-задачами и не уделяет достаточно времени багам. Через какое-то время может обнаружиться слишком много дефектов, в результате – пользоваться системой будет сложно. Чтобы избежать такой ситуации, можно добавить дашборд с количеством заведенных и решенных за неделю багов. Это помогает отслеживать динамику роста ошибок и вовремя исправлять ситуацию, не допуская ее повторения. Если проблема не решается долго и продолжает периодически всплывать, стоит изучить возможность её покрытия метриками. Они помогут рассмотреть проблему в динамике и выбрать оптимальный способ решения.

Также метрики помогают исследовать слабые места в проекте. Когда мы знаем слабые места, можно добавить показатели и отслеживать их изменение. Если таких мест нет, возможно, стоит посмотреть внимательнее и обнаружить их с помощью метрик, которые были введены в проект ранее.

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

Метрики в системе управления проектом

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

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

Пример дашборда соотношения открытых багов к закрытым за неделю

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

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

Пример дашбордов в Allure

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

Метрики для мониторинга проекта

Одним из наиболее популярных инструментов для мониторинга данных является Grafana. С помощью различных временных рядов он помогает мониторить, визуализировать и анализировать данные. Пользователь может создать необходимые дашборды с различными метриками. Например, можно мониторить состояние базы данных, брокера сообщений, серверной части и т.п.

Пример дашбордов в Grafana

Изображен пример стандартных графиков для Grafana: количество авторизаций и запросов к серверу, отслеживание CPU, памяти и трафика, а также время полной загрузки страницы на стороне клиента

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

5 популярных инструментов для работы с метриками

При создании метрик и работе с ними проектные команды чаще всего используют следующие инструменты:

  • Jira: позволяет создавать графики и дашборды для отслеживания результатов и прогресса команды.
  • Grafana — инструмент для визуализации, мониторинга и анализа данных. Выше о нем уже упоминали. Он обладает гибкой настройкой и включает в себя большое количество плагинов. Часто используется в паре с Prometheus.
  • Prometheus — приложение, которое основано на базе данных временных рядов и используется для мониторинга событий. Этот инструмент удобен для настройки оповещения. Он имеет свою базу данных и собирает в неё сведения, а Grafana их визуализирует.
  • Allure — инструмент для создания отчетов по результатам тестов и построения различных графиков, которые можно использовать для отслеживания прогресса проекта. Подробнее о нашем опыте можете почитать здесь.
  • Excel: для небольших проектов может быть более эффективно собирать данные вручную и строить графики в Excel, чем подключать различные инструменты.

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

Задача метрик – помочь продукту, а не затормозить реализацию проекта, поэтому к их выбору стоит подходить с особой тщательностью и не перестараться. Советуем отталкиваться от стадии проекта, проблемных мест, выстроенных процессов или потребностей на проекте. В завершение приведем пример, как одна наша команда выстраивала процессы и внедряла метрики на проекте. Их путь занял 5 спринтов, но результаты того стоили.
Надеемся, этот опыт будет вам полезен.

Больше кейсов и полезных материалов в наших каналах:

  • ВК и Telegram для разработчиков
  • ВК и Telegram для владельцев продуктов и IT-управленцев.
0
1 комментарий
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
-2 комментариев
Раскрывать всегда