Уже больше 6 лет я работаю проектной менеджеркой в IT. На моем счету очень сложные и нестандартные проекты, стартапы в разных бизнес-доменах. У меня были клиенты, которые считали буквально каждую копейку. Во всех этих случаях точные расчеты проектных KPI помогали моей команде успешно работать с заказчиками.
Мы все одинаково понимали реальное положение дел на проекте и видели, в каком направлении развивается продукт. Думаю, к этому стремится каждый менеджер. Сегодня вы узнаете, как добиться понимания в команде и с клиентом благодаря правильно определенным KPI.
В этой статье я опишу пользу от KPI для проектных менеджеров, а также почему эти показатели важны для клиентов. Мы подробно разберем расчеты основных видов KPI. Я приведу несколько примеров из своей практики с разной стратегией проектного менеджмента.
Key Performance Indicator — это метрика, которая показывает успешность достижения поставленных целей и задач конкретным специалистом или проектом.
Менеджерам KPI помогают решать несколько задач:
Вы можете понять как общую картину, так и выделить направления для улучшения определенных процессов. С правильными KPI даже посторонний для проекта PM сможет разобраться, на чем сконцентрировать основной фокус работы.
За счет постоянного контроля KPI вы можете увидеть достижения команды или проседания работы в целом, или на отдельных этапах.
На более ранних этапах проекта правильно определенные KPI позволяют увидеть, где у вас возникло проседание по графику. Поэтому вы оперативнее можете принять соответствующие меры.
KPI помогают как решать проблемы на проекте, так и видеть перспективы его развития. Точные расчеты позволяют определить, что нового и полезного можно воплотить и как это отразится на проекте в будущем.
Таким паттерном может быть, например, фокус-фактор. Этот KPI указывает, какой процент времени команда тратит на выполнение проектных задач. Скажем, разработку или тестирование. Митинги сюда не входят. Они считаются клиентами не совсем «полезной» работой. Можно рассчитать, что в период планирования релиза фокус-фактор ниже, чем в фазе Construction. Ведь команда сосредоточена на обсуждении, а не кодинге, и это нормально.
Я разделяю все проектные KPI на четыре основных типа:
У каждого из них есть свои разновидности. Их множество, и рассказать обо всех в одной статье невозможно. Поэтому я приведу наиболее популярные и полезные примеры каждой категории.
Этот показатель показывает способность выполнять взятые на себя обязательства. Он помогает с более точным планированием в будущем. Для расчета 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 спринтов будет вашим таргетом.
Это один из моих любимых 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 разделяете количество фактически потраченных на релиз рабочих дней на количество запланированных на релиз и затем умножаете это на 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%. То есть команда была более эффективной, чем планировалось. Несвоевременность снабжения оправдана объемом работ.
С помощью этого KPI вы поймете, движется ли проект по согласованному графику. Для расчета разделите освоенный объем работ на запланированный:
SPI = EV (Earned Value) / PV (Planed Value)
По сути это определение value: если индекс больше единицы, то вы опережаете график, если ниже — отстаете. Этот KPI в большей степени необходим для проектных менеджеров и часто используется в проектах с фиксированной стоимостью.
Наверное, у кого-то может возникнуть вопрос, как рассчитывать метрики Earned Value и Actual Spent в двух вышеприведенных KPI. Ответ прост — все это в динамике после каждой итерации.
Показывает фактическую эффективность проекта и стоимость выполненных задач в рамках утвержденного бюджета. Этот показатель иногда называют «освоенным объемом». Для его расчета умножьте процент выполненного скоупа на весь бюджет, выделенный на релиз:
EV = PC (Percent of actual Completed work) * BAC (Budget At Completion)
То есть вы умножаете то, что потратили, на то, что еще собираетесь потратить.
Цель этого KPI — показать, находится ли проект «здесь и сейчас» с учетом текущего бюджета. Для этого из Earned Value, который вы посчитали в предыдущем пункте, вычтите актуальный кост:
CV = EV (Earned value) – AC (Actual Cost)
Если Cost Variance больше или равно нулю, вы вписываетесь в бюджет. Если же меньше нуля, то уже вышли за пределы.
Как правило, этот KPI применяется для проектов с фиксированным бюджетом, где уже на старте есть понимание количества необходимых часов. В Agile-проекте скоуп добавляется в процессе работы с релизом, так как появляются чейндж-реквесты, баги из продакшена и т.д. Все это влияет на запланированную capacity команды. И даже если проект ведется по комбинированному со SCRUM подходом, то на этапе планирования релиза вы поймете количество нужных часов. В чистом SCRUM оценку в часах не определяют.
Показатель говорит о способности находить и устранять дефекты до попадания релиза в продакшен. Для расчета этого KPI общее количество найденных в разработке дефектов нужно разделить на суммарное количество дефектов, обнаруженных в девелопменте и на продакшене, и умножить это все на 100%:
DRE = DD (Defects in Development) / (DD + DP (Defects in Production) ) * 100%
Обратите внимание: если речь идет о первом релизе, сосчитать такой KPI не удастся. У вас еще нет продакшена.
Для оценки качества работы мы можем собирать разные тренды дефектов. Это могут быть дефекты по severity. Для этого нужно следить за количеством критических или блокирующих дефектов за последние 5-10 спринтов. Также можно мониторить тренды по корневым причинам возникновения багов.
Перечислите все возможные причины и покажите разработчикам. Они выберут нужную при исправлении бага. Далее вам остается только сделать выборку для определения количества дефектов, допустим, из-за некачественного тестирования или неполного описания требований. Это отличный KPI для оценки качества процесса разработки как такового.
В описании каждого из проектных KPI я говорила об их значении, что очень важно в общении с клиентами. Ведь недостаточно показывать формулу расчета KPI и давать результаты.
Гораздо лучше, если вы объясняете заказчику, почему вы считаете именно этот параметр, чем он важен и ценен для команды, и для его бизнеса.
Тогда клиент начинает лучше понимать ситуацию на проекте, видит ваши достижения и заранее узнает причины возможных проблем. В конце концов, заказчики платят за ваше время на сбор и обработку информации, за все подсчеты. Поэтому им следует знать, для чего вам все эти KPI. Вполне возможно, что некоторые из них на конкретном проекте окажутся ненужными.
Чтобы ваша работа была оправдана, всегда задавайте себе следующие вопросы:
Перейдем к реальным примерам KPI.
В этом проекте за релиз отвечал клиент и его 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 так резко упал в динамике. С постепенным исследованием нового функционала характеристики команды выровнялись с ранее заложенными.
Здесь главными были упомянутые выше On Time Release Delivery и In Full Release Delivery. Таргет обоих случаях обозначили 100%. Но если в первой категории мы не добрали 8% (то есть поставки были позже запланированной даты), то во второй превысили таргет на 40% (объем поставки с головой перекрыл наше опоздание).
Когда клиент выразил недовольство по поводу опоздания по графику, мы определили проблему и сразу показали, что это компенсируется большей эффективностью: «Да получилось несвоевременно. Но посмотрите, на сколько больше мы сделали в итоге!»
Также на этом проекте мы отслеживали Team Focus Factor. Его таргет определили на уровне 75–80%. В каждом спринте отмечено небольшое превышение этой отметки. Это говорит о достаточной эффективности командного фокус-фактора.
На этом проекте я следила за 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 действительно приносят большую пользу и менеджерам, и команде. И, конечно, оказывают влияние на развитие продукта в целом. Но все это действует при правильно подобранных метриках в соответствии с особенностями конкретного проекта. В таком случае время для расчетов полностью оправдывает себя.
If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…