Что такое KPI и как его считать: виды, формулы и примеры моих проектов

Уже больше 6 лет я работаю проектной менеджеркой в ​​IT. На моем счету очень сложные и нестандартные проекты, стартапы в разных бизнес-доменах. У меня были клиенты, которые считали буквально каждую копейку. Во всех этих случаях точные расчеты проектных KPI помогали моей команде успешно работать с заказчиками.

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

В этой статье я опишу пользу от KPI для проектных менеджеров, а также почему эти показатели важны для клиентов. Мы подробно разберем расчеты основных видов KPI. Я приведу несколько примеров из своей практики с разной стратегией проектного менеджмента.

Что такое KPI и зачем он нужен

Key Performance Indicator — это метрика, которая показывает успешность достижения поставленных целей и задач конкретным специалистом или проектом.

Менеджерам KPI помогают решать несколько задач:

• Мониторить Project Health — текущее состояние проекта

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

• Отслеживать прогресс проекта

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

• Вовремя вносить изменения

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

• Использовать новые возможности

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

• Анализировать паттерны во времени
Професійний курс від mate.academy: Java.
Погрузьтеся у світ програмування.
Отримати інформацію про курс

Таким паттерном может быть, например, фокус-фактор. Этот KPI указывает, какой процент времени команда тратит на выполнение проектных задач. Скажем, разработку или тестирование. Митинги сюда не входят. Они считаются клиентами не совсем «полезной» работой. Можно рассчитать, что в период планирования релиза фокус-фактор ниже, чем в фазе Construction. Ведь команда сосредоточена на обсуждении, а не кодинге, и это нормально.

Разновидности проектных KPI

Я разделяю все проектные KPI на четыре основных типа:

• KPI эффективности;
• KPI по терминам;
• KPI бюджета;
• KPI качества.

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

KPI эффективности

Estimate Accuracy

Этот показатель показывает способность выполнять взятые на себя обязательства. Он помогает с более точным планированием в ​​будущем. Для расчета Estimate Accuracy мы делим затраченное время на скоуп и умножаем результат на 100:

EA = SH (Spent Hours for delivered scope) / PH (Planned hours for delivered scope) * 100

Если этот KPI больше 100%, то у нас есть проблемы с выполнением комитментов. Если меньше 100%, то все хорошо.

Также я бы выделила ballpark-оценки и оценки, которые мы обычно даем перед стартом. При работе по методологии SCRUM ballpark-оценки формируются на этапе планирования релиза — когда невозможно дать качественный прогноз. В таком случае таргет обычно у ballpark не более 60%. При точных оценках, когда имеется достаточное количество инвестиций, детальное описание требований и технические дизайны, таргет будет заметно выше.

Что касается определения норм этих KPI, мы делаем это фактически сами. С точки зрения попадания в эстимейты таргет должно быть, по-моему, 100%. Поскольку значительный объем работы по определению конкретных действий команды в рамках спринта уже выполнен.

У вас есть описание требований к продукту и его техническая реализация, поэтому оценка достаточно точная. Что касается 60% таргета при ballpark, то это средний показатель. Так показывает моя многолетняя практика и опыт коллег.

Попадание в этот порог я бы назвала хорошим результатом — эта оценка дается при наличии большой зоны неизвестности. Представьте высокоуровневый скоуп, который вы еще не декомпозировали. Максимум на этапе планирования — это технический дизайн, архитектура той части, которая будет создаваться в рамках релиза. В таком случае таргет 60-65% будет крутым достижением.

Если вы никогда не рассчитывали фокус-фактор, то для первого таргета предлагаю собрать исторические данные вашего проекта. Подсчитайте фокус-фактор, например, за последние 5 спринтов, и исследуйте динамику.

Фокус-фактор — сугубо индивидуальный параметр. У одних клиентов он включает митинги, а у других даже написание тест-кейсов. Соответственно и таргет может быть очень разным. Именно поэтому нужно смотреть на динамику. Она позволяет увидеть зоны для улучшения. Если сейчас это невозможно, и клиент с этим согласен, то средний фокус-фактор за 5 спринтов будет вашим таргетом.

Weighted Velocity

Это один из моих любимых KPI в работе со стори поинтами. Он помогает быстро спланировать огромный скоуп даже на год вперед. Weighted Velocity показывает связь производительности команды с ее возможностями. Для расчета этого KPI нужно количество полностью закрытых в пределах спринта стори поинтов разделить на фактически отработанное количество FTE:

WV = EV (Earned Value in Story Points) / WFTE (actual worked out FTEs)

Здесь не учитываются люди, которые не работали. Предположим, у вас спринт на 2 недели без праздников. То есть 80 рабочих часов — это и есть 1 FTE. В нашем случае при команде у 9 человек на фулл-тайме выходит 9 FTE (720 часов). Но если кто-то заболел, ушел в отпуск или взял на полдня дей-офф, то реальный показатель будет ниже. Тогда количество израсходованных за спринт часов нужно разделить на 80, чтобы получить нужный для расчета Weighted Velocity показатель FTE.

KPI по терминам

On Time Release Delivery

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

OTRD = ASWD (Actual spent working days for release) / PSWD (Planned spent working days release) * 100%

Благодаря On Time Release Delivery вы увидите возможные отклонения в процентах. К примеру, вы запланировали потратить на спринт 180 дней, а уложились в 160 — то есть шли с опережением графика примерно на 11%. Или наоборот: хотели все выполнить за 160 днем, а закончили за 180. Тогда отставание по графику составляет 12,5%.

С этим показателем можно посчитать другой KPI — In Full Release Delivery. Он показывает фактически поставленный скоуп против запланированного.

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

OTRD — это отличная метрика для демонстрации клиенту visibility. Представьте, что вы полностью отвечаете за поставку стабильного билда на стейдж-энвайроменте. Сначала вам нужно было сделать поставку 29 сентября, но она состоялась 15 октября. По On Time Release Delivery отклонение составляет, допустим, 20%. Вполне ожидаемо, что клиент будет недоволен. В этом случае вы можете рассчитать In Full Release Delivery и узнать, что скоуп составил, скажем, 150%. То есть команда была более эффективной, чем планировалось. Несвоевременность снабжения оправдана объемом работ.

Schedule Performance Index

С помощью этого KPI вы поймете, движется ли проект по согласованному графику. Для расчета разделите освоенный объем работ на запланированный:

SPI = EV (Earned Value) / PV (Planed Value)

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

Наверное, у кого-то может возникнуть вопрос, как рассчитывать метрики Earned Value и Actual Spent в двух вышеприведенных KPI. Ответ прост — все это в динамике после каждой итерации.

KPI бюджета

Earned Value

Показывает фактическую эффективность проекта и стоимость выполненных задач в рамках утвержденного бюджета. Этот показатель иногда называют «освоенным объемом». Для его расчета умножьте процент выполненного скоупа на весь бюджет, выделенный на релиз:

EV = PC (Percent of actual Completed work) * BAC (Budget At Completion)

То есть вы умножаете то, что потратили, на то, что еще собираетесь потратить.

Cost Variance

Цель этого KPI — показать, находится ли проект «здесь и сейчас» с учетом текущего бюджета. Для этого из Earned Value, который вы посчитали в предыдущем пункте, вычтите актуальный кост:

CV = EV (Earned value) – AC (Actual Cost)

Если Cost Variance больше или равно нулю, вы вписываетесь в бюджет. Если же меньше нуля, то уже вышли за пределы.

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

KPI качества

Defect Removal Efficiency

Показатель говорит о способности находить и устранять дефекты до попадания релиза в продакшен. Для расчета этого KPI общее количество найденных в разработке дефектов нужно разделить на суммарное количество дефектов, обнаруженных в девелопменте и на продакшене, и умножить это все на 100%:

DRE = DD (Defects in Development) / (DD + DP (Defects in Production) ) * 100%

Обратите внимание: если речь идет о первом релизе, сосчитать такой KPI не удастся. У вас еще нет продакшена.

Defects trends

Для оценки качества работы мы можем собирать разные тренды дефектов. Это могут быть дефекты по severity. Для этого нужно следить за количеством критических или блокирующих дефектов за последние 5-10 спринтов. Также можно мониторить тренды по корневым причинам возникновения багов.

Перечислите все возможные причины и покажите разработчикам. Они выберут нужную при исправлении бага. Далее вам остается только сделать выборку для определения количества дефектов, допустим, из-за некачественного тестирования или неполного описания требований. Это отличный KPI для оценки качества процесса разработки как такового.

Всегда указывайте KPIs value

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

Гораздо лучше, если вы объясняете заказчику, почему вы считаете именно этот параметр, чем он важен и ценен для команды, и для его бизнеса.

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

На что обращать внимание при определении KPI

Чтобы ваша работа была оправдана, всегда задавайте себе следующие вопросы:

• Цель. Прежде всего вам нужно определить целесообразность расчетов того или иного KPI. Всегда спрашивайте себя, нужен ли вам действительно Estimate Accuracy, настолько ли важен Cost Variance и далее по списку.
• Измерение. Как вы планируете измерять нужный вам KPI? Где вы будете собирать данные? По какой формуле рассчитывать метрики? Как быть, если данных нет? Последнее не такая уж редкость. Например, на некоторых проектах команда может не логировать время в соответствующие таски. Поэтому стоит продумать, как лучше внедрить этот процесс.
• Производительность. Здесь все просто: измеряют ли выбранные вами KPI что-то важное, действительно ли они улучшают производительность?
• Стратегия. В зависимости от типа проекта и задач, стоящих перед вами, существуют разные стратегии работы. И они оказывают непосредственное влияние на выбор KPI. Например, если менеджеры отвечают за команду, важны метрики эффективности ее работы: Estimate Accuracy, Team Satisfaction, Customer Satisfaction и т.д. Если PM отвечает за релиз, и проект строится по принципу фиксированного бюджета, то необходимы Earned Value и индексы CPI.
• Оптимизация. При расчете KPI вы должны представлять, что будете делать с полученными результатами. Четко определите, что будут показывать ваши метрики. Подумайте, можно ли исправить проблемы с процессами и перфомансом при их обнаружении, и как это можно сделать.
• Оценка. Следует определиться, как часто будете считать выбранные KPI, когда это имеет смысл. К примеру, Estimate Accuracy собирают каждый спринт. On Time Release Delivery можно рассчитывать раз в полгода.

Работа с KPI на практике. Три истории — три проектные стратегии

Перейдем к реальным примерам KPI.

Проект №1

В этом проекте за релиз отвечал клиент и его PM. Я фокусировалась на эффективности работы нашей команды. Поэтому считала такие KPI как количество Failed Stories на спринт (т.е. качество имплементации наших разработчиков). Под этим термином мы договорились понимать Stories, в которых при переходе от разработчика к тестировщику не выполнялся хотя бы один Accepted Criteria.

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

Также в этом проекте я анализировала корневые причины. На базе данных из Jira я отсеивала из всех Failed Stories замеченные именно моей командой и на ретроспективе или ее продолжении разбирала каждую страницу с разработчиками. Никто, кроме них, точно не скажет причину возникновения проблемы. На такие обсуждения уходило не более получаса после каждого спринта, который длился 4 недели.

В результате я структурировала причины и выстроила диаграммы (на иллюстрации ниже). Как видите, основная причина процесса, AC were not met, была второй по частоте. Хотя были и другие. Например, «Accepted Criteria исполнены, но найдены баги». Это свидетельство того, что работа выполняется не в соответствии с согласованным процессом. Были и архитектурные issues, и неопределенные Accepted Criteria и т.д.

Имея список корневых причин, можно предложить клиенту улучшение процесса. К примеру, в случае 35% с багами сказать, что такие Stories не нужно фейлить, поскольку это нарушает сам процесс. Также сбой процесса очевиден и по неопределенным Accepted Stories, где нужно отдельно разбирать корневые причины. Предположим, это произошло из-за неправильного планирования или сюда могли попасть приоритетные истории, в которых не прописаны AC.

Возможно, вы сталкивались с тем, что разработчики не всегда понимают ценность KPI. И вообще, зачем нужны дополнительные митинги? Это обычная ситуация.

При внесении изменений в привычные сценарии возможен отпор со стороны команды. Когда я на этом проекте сказала о сборе метрик, один из членов команды с иронией спросил: «Мы что, будем работать ради цифр?» Я привела ему такую ​​аналогию. Если нужно измерить температуру, вы можете приложить руку ко лбу, хотя и можете использовать градусник. В первом случае вы подумаете, что температура наверняка повышена. Во втором точно узнаете, что у вас 37,5°С. Так что цифры всегда показывают, насколько проблема серьезна и существует ли вообще.

Также здесь я считала Estimate Accuracy. Мы поставили ближайший таргет 90%, чтобы быть на старте в «зеленой зоне». Потом собирались постепенно поднять эту отметку. На последнем спринте благодаря определенным улучшениям, которые мы обсуждали с клиентом, удалось добиться показателя в 93%.

Отдельно объясню о падении от 114 до 77%. До этого команда работала только с определенной функциональной областью проекта. Позже разработчиков перевели на незнакомую им область. И даже демо не провели…

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

Проект №2

Здесь главными были упомянутые выше On Time Release Delivery и In Full Release Delivery. Таргет обоих случаях обозначили 100%. Но если в первой категории мы не добрали 8% (то есть поставки были позже запланированной даты), то во второй превысили таргет на 40% (объем поставки с головой перекрыл наше опоздание).

Когда клиент выразил недовольство по поводу опоздания по графику, мы определили проблему и сразу показали, что это компенсируется большей эффективностью: «Да получилось несвоевременно. Но посмотрите, на сколько больше мы сделали в итоге!»

Также на этом проекте мы отслеживали Team Focus Factor. Его таргет определили на уровне 75–80%. В каждом спринте отмечено небольшое превышение этой отметки. Это говорит о достаточной эффективности командного фокус-фактора.

Проект №3

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

Сначала проект был завязан на часы, но затем перешел на стори поинты. При этом в тот момент еще поменялось 80% команды. Поэтому на первом спринте мы не до конца понимали Velocity и не знали, как работают новые разработчики (еще и не очень хорошо осведомлены в продукте).

Но в течение 5 спринтов постепенно улучшалась скорость снабжения. Как видите ниже, за это время команда выросла с 2,4 стори поинтов на 1 FTE до почти 4 единиц — и стабильно держит этот показатель.

Weighted Velocity помог спланировать следующий спринт. Для этого я взяла средний показатель за 5 спринтов, длившихся по 2 недели, и посмотрела на загрузку команды. На тот момент у нас было 9 специалистов, но один должен был уйти в отпуск в неделю. Таким образом FTE будет 8,5 единицы. Далее я умножила средний Weighted Velocity на заданный FTE и понимала, сколько поинтов стоит взять в ближайший спринт.

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