Метрики в управлении: прозрачность и высокий результат для проектов

Четкие измеримые показатели — ключевой инструмент для оценки успеха проекта. Метрики дают возможность объективно оценивать решения, выявлять проблемы и оперативно вносить корректировки в процесс работы. Например, в разработке программного обеспечения отсутствие метрик часто приводит к перерасходу бюджета и срывам сроков (из-за недооценки сложности задач). Поговорим о метриках, которые нужны при запуске проекта.

Измеримые показатели — это сроки, бюджет, качество, производительность и риски. Именно они помогают руководителю определять состояние проекта, выявлять отклонения и принимать нужные управленческие решения. Если для одного проекта критично важно отслеживать метрики по срокам и бюджету, то для другого важнее сместить фокус на конкретные процессы. Заранее определенные метрики дают возможность сравнить «до» и «после», отследить динамику. Метрики — это про стратегию.

Три главных критерия:

• объективная оценка проекта;
• принятие эффективных решений;
• прозрачность.

Когда все участники проекта имеют доступ к четким и понятным показателям, они могут предугадывать возможные риски и адаптироваться к изменениям. Например, в IT-проектах метрики позволяют избежать хаоса и синхронизировать работу всех участников.

Преимущества внедрения метрик в проекты

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

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

Улучшение коммуникации. Метрики покрывают полную картину состояния проекта. С их помощью можно избежать недопонимания между членами команды, заказчиком и руководством. К примеру, в Agile-проектах использование досок Kanban с метриками скорости исполнения задач поможет команде лучше планировать работу.

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

Наиболее распространенные метрики, которые применяются в сфере ИТ.

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

Продолжительность проекта = дата завершения — дата начала.

Например: проект рассчитан на 120 дней. Старт — 1 февраля, плановая дата релиза — 31 мая. Но фактически сдать кейс получилось только 15 июня. Формула показывает: фактическая продолжительность проекта составила 135 дней.

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

Отклонение от сроков = фактическая продолжительность — запланированная продолжительность.

Пример: 135 дней — 120 дней = 15 дней. В этом случае менеджеру следует пересмотреть подходы к управлению сроками, ресурсами и рисками.

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

Пример расчета метрики времени выводится в формулу:

Коэффициент своевременного завершения (КСЗ) =  (общее количество задач, сданных в срок / общее количество задач) × 100 %

Понятно, что цель любого менеджера проекта — достичь 100 % показателя или максимально приблизиться к этому результату. Но объективно процесс разработки может зависеть от многих факторов, поэтому этот порог можно регулировать. Но если КСЗ ниже 85 % — это сигнал: проект проседает и что-то пошло не по плану.

Метрики бюджета позволяют сравнить запланированные затраты с реальными. Формула определяет, как сильно фактическая стоимость проекта превысила плановую и наоборот:

Отклонение от стоимости проекта = (фактическая стоимость / плановая стоимость) × 100 %

Пример расчета метрики для определения отклонений от бюджета:

BV / CV = EV — AV, где BV — отклонение от бюджета, CV — отклонение от затрат, EV — заработанная стоимость, AV — фактическая стоимость.

Результаты расчета BV можно трактовать следующим образом:

• положительный результат — ниже бюджета;
• ноль — в рамках бюджета;
• отрицательный — превышает бюджет.

Расходы по категориям

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

Формула:

доля расходов на оплату труда — это разность фактических затрат на з/п и общего бюджета проекта × 100

Метрики качества

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

Формула:

удовлетворенность заказчика = сумма его оценок / общее количество оценок.

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

Количество дефектов и их исправление

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

Формула:

процент исправленных дефектов = количество исправленных дефектов / общее количество дефектов × 100.

К примеру, в проекте выявлено 50 дефектов разработки. На момент окончания проекта 45 из них были исправлены, при этом вы потратили на это 100 часов.

Считаем:

Процент исправленных дефектов = (45 / 50) × 100 % = 90 %.

Среднее время исправления = 100 / 45 = 22 часа.

Вывод: 90 % всех выявленных багов были исправлены.

Метрика выполнения стандартов качества

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

Формула:

процент выполнения стандартов качества = количество соответствующих требованиям элементов / общее количество проверенных элементов × 100 %

Например, в проекте 100 проверенных задач. Соответствуют стандартам 92. Чтобы получить процент выполнения стандартов качества, подставляем данные в формулу выше: (92 / 100) × 100 % = 92 %.

Результат дает нам понимание, что практически все задачи проекта соответствуют установленным требованиям. Но при этом 8 % из них не прошли проверку; это значит, что стоит оптимизировать некоторые процессы и усилить контроль за качеством.

В то же время метрики производительности команды считаются так: 

производительность команды = объем выполненной работы / затраченное время; а метрика скорости выполнения задач — это отношение количества выполненных задач к периоду времени, потраченному на них.

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

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

Пример: отказ серверного оборудования. Предположим, что по имеющимся данным за год работы над проектом произошло 3 сбоя в рамках 300 проверок оборудования. Тогда (3 / 300) × 100 = 1 %. Вероятность возникновения риска предельно низкая.

Вместе с тем можно просчитать и влияние рисков на проект:

индекс влияния риска = вероятность возникновения риска / степень воздействия.

Выше мы уже рассчитывали вероятность возникновения риска: 1 % или 0,01. Степень воздействия считается по шкале от 1 до 5. Тогда 0,01 / 5 = 0,002. Получается, показатель влияния риска на проект — незначительный.

Меры по смягчению рисков

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

Формула: 

Где Е — эффективность мер по смягчению, Iдо — влияние рисков до внедрения мер смягчения (в деньгах, днях или баллах), а Iпосле— влияние риска после применения мер смягчения. 

Разберем на примере проекта, где нужно настроить серверное оборудование. Предположим, что при планировании выявили риск сбоев в связи с отсутствием резервных серверов, оценили на 8 баллов. В качестве мер по снижению риска запланировали внедрение резервного оборудования; после этого уровень риска снизился до 3 баллов.

Делаем расчет метрики: (8−3)/8×100%=62,5%.

Итого, мы видим, что использование резервных серверов позволило снизить уровень риска на 62,5 %, что доказывает эффективность выбранных способов реагирования на риск.

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

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

Для того чтобы выстроить продуктивную систему контроля и мониторинга метрик, необходимо:

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

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

в) устанавливать целевые значения (внедрив метрику, важно определить пороговые значения, чтобы команда могла понимать, на что ориентироваться; например, отклонение от бюджета не должно быть выше 5%; при определении таких значений важно задавать реальные и достижимые данные);

г) отслеживать и обновлять данные по метрикам (работа по отслеживанию и обновлению метрик должна проводиться регулярно и с четкой периодичностью: проектный менеджер минимум раз в неделю должен мониторить отклонения по сроку и бюджету);

д) визуализировать данные и придерживаться прозрачности (графики, диаграммы и дашборды: следить за прогрессом удобно с помощью доски Kanban, а диаграмма Burndown Chart покажет, если проект вдруг пойдет не по плану);

е) доносить ценность метрик до команды и заказчика (прежде чем внедрить метрики, стоит убедиться, что команда и заказчик понимают их ценность и влияние на результат);

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