Вже понад 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 спринтів. Також можна моніторити тренди з кореневих причин виникнення багів.
Перерахуйте всі можливі причини та покажіть розробникам. Вони оберуть потрібну під час виправлення бага. Далі вам лишається тільки зробити вибірку для визначення кількості дефектів, припустимо, через неякісне dev-тестування або неповний опис вимог. Це чудовий KPI для оцінки якості процесу розробки як такого.
В описі кожного з проєктних KPI я говорила про їх значення, що неабияк важливо у спілкуванні з клієнтами. Адже недостатньо показувати формулу розрахунку KPI та давати результати.
Набагато краще, якщо ви пояснюєте замовнику, чому рахуєте саме цей параметр, чим він важливий та цінний для команди і власне для його бізнесу.
Тоді клієнт починає краще розуміти ситуацію на проєкті, бачить ваші досягнення і заздалегідь знатиме причини можливих проблем. Зрештою замовники платять за ваш час на збирання й обробку інформації, за всі підрахунки. Тому їм варто знати, для чого вам усі ці KPI. Цілком можливо, що деякі з них на конкретному проєкті виявляться непотрібними.
Щоб ваша робота була виправданою, завжди ставте собі наступні питання:
Перейдемо до реальних прикладів KPIs.
У цьому проєкті за реліз відповідав клієнт та його 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 дійсно приносять неабияку користь і менеджерам, і команді. І, звісно, впливають на розвиток продукту в цілому. Та все це діє за умови правильно підібраних метрик відповідно до особливостей конкретного проєкту. В такому разі час для розрахунків цілком виправдовує себе.
Днями я завзято нила про щось ChatGPT (експериментую між сеансами з живим терапевтом). І от…
«Крутіть колесо, щоб отримати знижку до 50%!» «Натисніть тут, щоб відкрити таємничу пропозицію!» «Зареєструйтесь зараз,…
Дуже хочеться робити якісь десктопні апки. Сумую за часами коли всі програми були offline-first, і…
Надсилаючи криптовалюту, багато новачків ставлять запитання: як працюють комісії та чому вони відрізняються в різних…
Нова афера набирає обертів — ось детальний розбір того, як фальшиві потенційні роботодавці намагаються вкрасти…
Соцмережа з можливістю вбудовувати повноцінні додатки прямо в пости — звучить як фантастика, але Farcaster…