От данных к решениям: как эффективно использовать метрики управления проектами

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

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

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

Какие бы метрики вы ни применяли, помните закон Гудхарта: "Когда мера становится целью, она перестает быть хорошей мерой". Вместо того чтобы использовать многочисленные цифры о проекте или команде как основание для решений, воспринимайте их как сигналы, указывающие на потенциальные проблемы. Рассмотрим пример:

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

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

Результат:
Время перехода задач из одного статуса в другой сокращается, что на бумаге выглядит отлично. Однако теперь команды тратят меньше времени на тесты и ревью. Фичи выходят быстрее, но с проблемами — пользователи недовольны.

Решение Б: Менеджер обращается к командам и объясняет цель. Команды дают контекст своей работы, показывая, что определенные этапы требуют больше времени для обеспечения более высокого качества.

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

В обоих случаях менеджер имел перед собой метрики управления проектами. В решении A он проигнорировал сигналы этих метрик и подошел к проблеме без учета контекста. Решение B демонстрирует, как стратегически мыслящий менеджер может использовать метрики производительности конструктивно: не нанося ущерба качеству и способствуя улучшению отношений между менеджментом и инженерами. Теперь рассмотрим сами метрики и сигналы, которые они подают.

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

Эти метрики показывают время, затраченное на различные аспекты проекта, связанные с разработкой.

Время цикла (cycle time). Измеряет, насколько быстро команда выполняет задачи. Отслеживает время перехода задачи от начального статуса (например, "To do") до финального (например, "Done") и рассчитывает среднюю продолжительность этого перехода. Эта метрика может сигнализировать о необходимости скорректировать воркфлоу или процесс согласования.

Пример: команда разработки выполняет пользовательские истории в рамках Agile-процесса с общим временем производства 10 рабочих дней (80 часов). Команда выполняет 20 пользовательских историй, затрачивая на каждую 4 часа. Это означает, что в среднем выполнение одной истории от начала до конца занимает 4 часа.

Время выполнения (lead time). Измеряет общее время от создания задачи до достижения финального статуса. Помогает оценить общую эффективность обработки задач от постановки до завершения. Эта метрика служит сигналом для руководства о том, как команды справляются с задачами в совокупности.

Пример: команда создает новую фичу, проходя через несколько фаз: подача запроса, сбор требований, фаза проектирования, фаза разработки, фаза тестирования, день деплоя, ревью и обратная связь, финальные правки. Процесс занял 30 дней — с первого по тридцатый, то есть общий lead time составляет 30 дней.

Время выхода на рынок (time to market). Оценивает, насколько быстро крупные задачи, например эпики, продвигаются от создания до поставки. Дает представление и сигналы о том, насколько оперативно команда может доставлять значимые компоненты проекта.

Пример: у команды разработки из примера выше показатель time to market составляет 26 дней и включает подачу запроса, сбор требований, фазу проектирования, фазу разработки, фазу тестирования и день деплоя.

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

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

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

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

В примере ниже показана стоимость каждой задачи и общая сумма по каждому сотруднику за август:

Высококачественный код ведет к улучшению продуктов и повышению удовлетворенности клиентов. Измерять качество кода позволяют правильные метрики. Вот четыре примера.

Изменчивость кода (code churn). Измеряет изменения, внесенные в код за определенный период, включая добавления и удаления. Может сигнализировать о трудностях инженеров с написанием кода, который не требует многочисленных правок. Отображается в процентах или абсолютных значениях.

Плотность дефектов (defect density). Показывает количество подтвержденных дефектов относительно размера кода. Сигнализирует о трудностях в тестировании и ревью кода. Отображается как количество дефектов на KLOC (тысячу строк кода).

Среднее время обнаружения (mean time to detect, MTTD). Показывает среднее время, необходимое для выявления дефекта или сбоя. Этот сигнал может указывать на отличную или слабую коммуникацию в зависимости от данных. Отображается в единицах времени (часы/дни).

Частота сбоев (rate of crash). Показывает частоту сбоев за определенный период. Может сигнализировать о том, что код работает нестабильно и требует проверки, а также о том, насколько адекватно команды реагируют на устранение первопричин. Отображается как частота (например, сбоев в час или за сессию).

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

Ожидаемые часы. В таких инструментах, как Enji, можно указать количество часов, которые сотрудник должен работать над проектом в месяц. Это сигнализирует руководителям о том, тратит ли кто-то больше или меньше времени на проект, чем ожидается, — и дает повод разобраться в причинах.

Ежедневные часы. Также полезно устанавливать количество часов, которое сотрудник должен работать в день. Это может соответствовать условиям его контракта и общей рабочей нагрузке компании. Служит сигналом как для сотрудника, так и для руководства о способности правильно расставлять приоритеты между проектом и другими обязанностями.

Допустимое отклонение. На основе ожидаемых и ежедневных часов полезно указать, на сколько часов в день сотрудник может превышать лимит ежедневных часов.

Оплачиваемые часы. Количество ежемесячных часов, которые будут выставлены клиенту к оплате. Например, ожидаемые часы могут составлять 160 в месяц, а оплачиваемые — 80, если по соглашению с клиентом он оплачивает только 80 часов работы в месяц.

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

• Вероятность срыва сроков. Оценивает вероятность того, что проект не уложится в установленные дедлайны. Метрика использует исторические данные и анализирует такие факторы, как процент выполненных задач, управление зависимостями и распределение ресурсов.
  
  Пример: программный проект, в котором возникли задержки на фазах проектирования и интеграции, может получить 40% вероятность срыва сроков.

• Вероятность превышения бюджета. Измеряет вероятность того, что проект выйдет за рамки выделенного бюджета. Метрика учитывает текущие темпы расходования средств, изменения скоупа, стоимость ресурсов и непредвиденные расходы на основе отклонения стоимости (CV), скорость сгорания денежных средств и исторических данных о производительности.
  
  Пример: если проект на середине разработки показывает перерасход в 20%, он может быть отмечен как имеющий 70% вероятность превышения бюджета — если не принять корректирующие меры.

• Количество уязвимостей высокой степени серьезности. Отслеживает количество критических уязвимостей безопасности, выявленных в ходе разработки, тестирования или после деплоя. Это проблемы, представляющие значительный риск для безопасности и функциональности системы.
  
  Пример: система с 15 уязвимостями высокой степени серьезности может потребовать немедленных мер по снижению рисков, тогда как система с 1-2 такими уязвимостями с большей вероятностью поддается управлению.

• Сложность интеграции с существующими системами. Оценивает, насколько сложно интегрировать новое программное обеспечение с легаси-системами или сторонними приложениями. Высокая сложность интеграции увеличивает риск задержек, багов и сбоев системы.
  
  Пример: проект с несколькими легаси-системами, требующими разработки кастомных API и миграции данных, может быть оценен как имеющий высокую сложность интеграции — что увеличивает риск задержек и ошибок.

• Текучесть кадров в команде. Измеряет частоту, с которой участники команды покидают проект или организацию, в процентах за определенный период. Высокая текучесть может привести к потере продуктивности, снижению экспертизы и увеличению риска провала проекта или задержек.
  
  Пример: проект, в котором за шесть месяцев уходят 3 из 10 участников команды, считается высокорисковым из-за 30% текучести — это может привести к срыву дедлайнов или снижению качества кода по мере того, как новые участники входят в работу.

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

Данные и метрики дают руководителям важный взгляд на производительность проекта, команды и отдельных сотрудников. Тем не менее они являются лишь частью контекста, и команда Enji подчеркивает необходимость ответственного принятия решений на основе данных. Просто иметь данные недостаточно. Используйте метрики как сигналы для экономии времени при изучении проблем через позитивный контроль. Enji объединяет эти метрики в сводках и отчетах, которые руководители могут сформировать за несколько минут в едином дашборде.