Що таке KPI та як його рахувати: види, формули та приклади моїх проєктів

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

Ми всі однаково розуміли реальний стан справ на проєкті і чітко бачили, в якому напрямку розвивається продукт. Гадаю, цього прагне кожен менеджер. Тож сьогодні ви дізнаєтесь, як досягти порозуміння в команді та з клієнтом завдяки правильно визначеним KPI.

У цій статті я опишу користь від KPI для проєктних менеджерів, а також чому ці показники важливі клієнтам. Ми детально розберемо розрахунки основних видів KPI. Я наведу декілька прикладів зі своєї практики з різною стратегією проєктного менеджменту.

Що таке KPI і навіщо він потрібен

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

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

• Моніторити Project Health — поточний стан проєкту

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

• Відстежувати прогрес проєкту

За рахунок постійного контролю KPI ви можете побачити досягнення команди або ж просідання роботи загалом чи та окремих етапах.

• Вчасно вносити зміни

На більш ранніх етапах проєкту правильно визначені KPI дозволяють побачити, де у вас виникло просідання за графіком. Тож ви оперативніше можете вжити відповідних заходів.

• Використовувати нові можливості

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

• Аналізувати патерни у часі

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

Різновиди проєктних KPI

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

• KPI ефективності;
• KPI за термінами;
• KPI бюджету;
• KPI якості.
Онлайн-курс "Чистий код та патерни проєктування" від robot_dreams.
Прискорюйте й спрощуйте процес розробки.Під менторством лектора з 15-річним досвідом ви навчитеся застосовувати 20+ шаблонів, опануєте рефакторинг і принципи чистого коду.
Детальніше

Кожен із них має свої різновиди. Їх безліч, і згадати все в одній статті неможливо. Тому я наведу найбільш популярні та корисні приклади для кожної категорії.

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 спринтів. Також можна моніторити тренди з кореневих причин виникнення багів.

Перерахуйте всі можливі причини та покажіть розробникам. Вони оберуть потрібну під час виправлення бага. Далі вам лишається тільки зробити вибірку для визначення кількості дефектів, припустимо, через неякісне dev-тестування або неповний опис вимог. Це чудовий 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 ви маєте уявляти, що робитимете з отриманими результатами. Чітко визначте, що будуть показувати ваші метрики. Подумайте, чи можна буде виправити проблеми з процесами та перфомансом при їх виявленні, та як це можливо зробити.
Курс-професія "Копірайтер" від Skvot.
40 занять — і ти з упевненістю, скілами та портфоліо зможеш тиснути Apply на вакансії копірайтера.Досвідом і ключами поділяться 2 лекторки та запрошені спікери.
Детальніше про курс
• Оцінка. Варто визначитись, як часто рахуватимете обрані KPI, коли це має сенс. Наприклад, Estimate Accuracy збирають кожен спринт. On Time Release Delivery можна розраховувати раз на півроку.

Робота з KPI на практиці. Три історії — три проєктні стратегії

Перейдемо до реальних прикладів KPIs.

Проєкт №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 дійсно приносять неабияку користь і менеджерам, і команді. І, звісно, впливають на розвиток продукту в цілому. Та все це діє за умови правильно підібраних метрик відповідно до особливостей конкретного проєкту. В такому разі час для розрахунків цілком виправдовує себе.