Побудова системи метрик для управління портфелем проєктів
Серед метрик можна виділити:
- Основні метрики Scrum:
- Акуратність оцінки;
- Burnout time – час згоряння;
- Velocity – швидкість команди;
- Estimated time of delivery – оціночний час поставки.
Основні метрики Kanban:
- Lead Time – час, який завдання проходить від моменту створення до релізу;
- Cycle Time – час, який завдання проходить від моменту старту робіт до релізу;
- WIP – кількість завдань/SP у роботі;
- Wasted Time – час, який завдання перебуває в очікуваннях;
- Effectiveness – час, який завдання перебуває в корисній роботі;
- Throughput – пропускна здатність команди.
Основні метрики PMBOK:
- Плановий обсяг бюджету;
- Засвоєний обсяг бюджету;
- Прогнозний обсяг бюджету;
- Відхилення за термінами;
- Відхилення за вартістю.
Основні продуктові метрики:
- ARPU – середній дохід на користувача;
- LTV – довічна цінність клієнта;
- Метрики залучення клієнтів;
- Метрики залученості клієнтів;
- Метрики утримання клієнтів;
- Метрики продуктивності та надійності.
Фреймворк HEART
H → Happiness – користь для клієнта;
E → Engagement – залученість ЦА;
A → Adoption – залучення клієнтів;
R → Retention – утримання клієнтів;
T → Task Success – успіх продукту.
Фреймворк PROJECT
P → People – команда проекту та її стан;
R → Reliability – надійність, якість;
O → Operations – операційні показники;
J → Job – стан скоупа;
E → Economy – фінансові показники;
C → Customer – задоволеність клієнта;
T → Timetable – розклад.
Мало збирати метрики, треба ще їх перевіряти. Причому, на постійній основі. Наприклад, раз на тиждень збиратися з тімлідами і дивитися, що з проектами відбувається.
Або доручити їм писати звіти кілька разів на тиждень з усіма показниками і поясненнями щодо відхилень. Гарною додатковою практикою тут може стати проєктний статус.
Це певна агрегована метрика стану проєкту – така собі єдина лампочка, за якою стає зрозуміло, чи добре все з проєктом, чи потрібно втрутитися. Проєктний статус, як правило, збирається за всіма метриками. І залежно від відхилень метрик від норми, буде виставлятися і сам статус проєкту.
Також варто враховувати кризи проєкту: конфлікти, звільнення, високий техборг – усе, що може вплинути на процес delivery. Краще, якщо для визначення проєктного статусу буде чіткий алгоритм, прям блок-схема, за якою всі будуть однаково розуміти, як його визначати й інтерпретувати.
Ну і кожен проєктний статус має передбачати певний алгоритм дій: надати план, інформувати, ескалувати тощо.
