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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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