Основные ошибки при работе с метриками в ИТ-проектах и как их избежать

Метрики — важнейший инструмент управления ИТ-проектами, поскольку они позволяют оценивать прогресс, отслеживать отклонения и прогнозировать результат. Однако любые показатели могут оказаться бесполезны, если работать с ними поверхностно. Екатерина Синица, старший эксперт направления по развитию персонала Лиги Цифровой Экономики, рассказывает, какие типичные ошибки в работе с метриками часто допускают и опытные, и начинающие руководители.

Метрики — это не набор сухих чисел, а язык, на котором исполнитель и заказчик договариваются о том, что именно считать успехом. В ИТ-проектах метрики выполняют три базовые функции:

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

В процессе реализации проекта выбранные метрики являются базой для контроля и прогнозирования хода работ. Регулярное измерение факта и сравнение с планом по этим метрикам позволяет увидеть тренды и на их основе принимать грамотные управленческие решения. Сравнивая плановые и фактические значения по ключевым параметрам (скорость разработки, трудозатраты, себестоимость, удовлетворенность заказчика и т. п.), руководитель получает не абстрактное ощущение, что «все хорошо» или «все плохо», а полноценную картину состояния дел в проекте.

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

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

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

Руководители проектов часто стремятся достичь всех критериев успеха одновременно, без учета приоритетов заказчика: то есть сдать продукт в срок, остаться в рамках бюджета и полностью удовлетворить все требования к результату. На первый взгляд, естественное стремление — эти параметры традиционно считаются признаками успешного проекта. Однако попытка достичь всех целей одновременно и в равной степени, без компромиссов, может привести к обратному результату. Так, по статистике Standish Group, лишь около 25 % ИТ-проектов в мире завершаются по-настоящему успешно.

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

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

Другая крайность — попытка максимально формализовать критерии успешности. Руководитель выстраивает систему, где каждое отклонение фиксируется и тщательно контролируется. Юридически все идеально: проект завершен точно по ТЗ, без нарушений и сбоев.

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

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

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

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

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

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

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

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

Хорошая система контроля проекта отвечает следующим критериям:

1. Соответствие потребностям и приоритетам заказчика и спонсора.

2. Прозрачность для всех участников.

3. Гибкость и адекватность текущей ситуации (рабочая альтернатива абстрактному понятию «справедливости»).

4. Фокусировка на улучшении процессов и на извлечении уроков.

Такая система поможет успешно завершить ваш текущий проект и станет основой для новых профессиональных достижений!