«РМ та замовник біжать у різні боки». Як багато болю у цій фразі, адже вона означає, що команда витрачає ресурси даремно. Але цього можна уникнути.
Павло Харіков — Head of IoT в VEON Group (Kyivstar, Beeline). Він має понад 10 років досвіду проєктного та портфельного менеджменту в міжнародних компаніях. Павло працював над масштабними проєктами з бюджетом до $150 млн, а в Laba він веде курс «Проджект-менеджмент 2.0».
Нам Павло розповів, як визначати ключові метрики успішності та готувати фінансовий звіт про проєкт.
Які існують метрики успішності
Універсальні для РМ — терміни, бюджет та охоплення. Але зупинятися на них — велика помилка. Ключовими метриками повинні бути ті, що оцінюють відповідність цілям замовника. Їх потрібно визначати на ранніх етапах проєкту, тому що від них залежить реалізація. Коли РМ розуміє, що для клієнта важливо та цінно, він ухвалюватиме відповідні рішення.
Наприклад, в IT специфічні метрики поділяються на два види:
- ті, що показують прибутковість реалізованого рішення
- ті, що показують, якою мірою це рішення популярне і наскільки виходить утримати аудиторію
Є метрики, які стосуються не лише IT, а й інших сфер, у тому числі банків та телекому.
- ARPU (Average Revenue Per User) — середній чек на користувача чи клієнта. Це важливий показник, адже, коли замовник планує реалізацію якогось функціоналу, він розраховує на певні доходи.
- Також прийнято рахувати Paying Users, адже можуть бути і користувачі лише безплатної частини функціоналу. Ця метрика показує життєздатність товару і дорівнює кількості юзерів, які платять за період. Тривожним дзвінком може бути ситуація, якщо більшу частину доходу приносять лише декілька користувачів. Втрата кожного з них здатна зробити проєкт збитковим.
- LTV (lifetime value — пожиттєва цінність) — це передбачуваний чистий дохід від усіх взаємодій клієнта з продуктом за весь час його використання. Визначає доцільність товару.
Є метрики, які допомагають зрозуміти, наскільки проєкту вдається мотивувати аудиторію залишитися:
- Retention rate (утримання користувачів) — здатність компанії утримувати своїх споживачів протягом певного часу.
- Churn rate (показник відтоку користувачів) — відсоток юзерів, які відмовилися використовувати в майбутньому запропонований сервіс.
Наприклад, KPI конкретного проєкту для великого системного бізнесу може бути зниження Churn rate лише на 1,5%, що дуже суттєво для фінансових показників компанії.
Як визначити метрики в ІТ-сфері: приклад
Допустимо, ви взяли проєкт зі створення додатку для виклику таксі. Тут у вас точно буде два типи користувачів: пасажири та водії. Програма повинна задовольняти їхні потреби, а метрики — враховувати цілі за кожною з категорій користувачів.
Отже, можна орієнтуватися на такий набір метрик:
Проєктні:
- термін реалізації (допустимі відхилення від базового плану)
- виконання бюджету (допустимі відхилення)
Дохідні:
- Revenue — загальний дохід від сервісу.
- ARPU пасажирів, щоби розуміти, скільки кожен користувач приносить в середньому.
- Paying Users, щоб бачити, який відсоток користувачів користується платними активностями.
- Lifetime value (LTV) покаже дохід від клієнта за час користування додатком. Побічно цей параметр визначає максимальні витрати на залучення нових юзерів.
- CAC (Customer Acquisition Cost) — вартість залучення одного користувача. Необхідно порівняти з LTV: 1/1 (або нижче) — потрібно терміново робити щось, інакше компанія збанкрутує, 2/1 — вже непогано, 3/1 (і вище) — можна інвестувати більше в залучення нових користувачів і проєкт здатний собі це дозволити.
Активна база / утримання:
- MAU-P (Monthly Active Users-Passengers) — кількість активних користувачів-пасажирів. Можна аналізувати за різні періоди (день/тиждень/3 місяці).
- MAU-D (Monthly Active Users-Drivers) — кількість активних користувачів-водіїв. Якщо критично знизиться — не буде кому возити людей.
- Churn rate — Passengers — скільки пасажирів перестало користуватися додатком. Зростання цього показника свідчить, що необхідно змінити ціну, функціонал, дизайн, комунікації тощо.
- Churn rate — Drivers — скільки водіїв перестало користуватися додатком. Зростання цього показника сигналізує про те, що необхідно переглянути умови партнерства.
- Average trip evaluation (середня оцінка поїздки) — штучна метрика під конкретний приклад. Вона показує, наскільки якісно водії дотримуються правил обслуговування клієнтів (водіння за ПДР, чистота авто, маска, справність ременів безпеки).
Не менш важливо вимірювати NPS (Net Promoter Score — Індекс підтримки споживача). Він говорить про те, наскільки люди готові рекомендувати вашу програму своїм знайомим. Від NPS залежить лояльність клієнтів. Сюди входить і комфортність використання нашого додатка, і співвідношення «ціна — якість».
Що буде, якщо РМ не зафіксує результатів
Сформулювавши цілі проєкту за допомогою KPI та метрик, проджект-менеджер (PM) повинен узгодити їх із ключовими стейкхолдерами та замовником. Це важливо зробити саме на старті проєкту, перш ніж команда почне витрачати ресурси. Без загального розуміння РМ та замовник бігтимуть у різні боки.
Як показує практика, якщо РМ не зафіксує результати проєкту, то стейкхолдери та клієнт зроблять це суб'єктивно. Тож краще очолити цю історію, щоб не поставити під удар кар'єру проджект-менеджера та всієї команди.
Усі процеси з проєктного управління — живі. Вони відбуваються не у вакуумі, а в організації з певною оргструктурою та взаємодією між людьми. Якщо ці процеси не коригувати, то розвитку не буде. Фінальний звіт (ФЗ) — якраз спосіб визначити проблеми та запропонувати рішення.
Весь бізнес-контент у зручному форматі
Навіщо фіксувати результати проєкту: 3 найважливіші фактори
#1. Ретроспектива та рефлексія. Для РМ це можливість розібратися, що він робить неправильно і як можна працювати ефективніше.
#2. Накопичення досвіду організації. Проджект-менеджер повинен мати можливість не починати з нуля, а використовувати напрацювання попередніх РМ компанії. Це глобальна мета фінального звіту про проєкту.
#3. Фіксація результатів конкретного проєкту, щоб уникнути можливості трактувати їх по-різному.
Як створити ефективний фінальний звіт
У ФЗ обов'язково фіксуйте, що планувалося, та що вийшло у підсумку. Де-факто ФЗ — це ретроспектива (або post-mortem analysis — він працює за принципом «розтин покаже»), в якій ми описуємо:
- плановий та фактичний термін реалізації
- причини зсувів у часі. Важливо: якщо проєкт вівся коректно, то будь-яке зміщення терміну реалізації мало фіксуватися запитом на зміну. Подібних рішень РМ не ухвалює — він може тільки все підготувати, запропонувати опції подальших дій, але останнє слово залишається за спонсором
- звіт про витрати (скільки планували і скільки зрештою витратили)
- ризики (потрібно вказати, які контрзаходи були ефективними, а які — ні). Важливо також наголосити на ризиках, які не були ідентифіковані, але сталися в процесі. Допомагає всім наступним РМ у роботі з іншими проєктами
- команду (які скіли та досвід отримали, яка плинність, чи були проблеми з наймом)
- досвід закупівель (яких підрядників залучали і як з ними працювалося)
- досвід комунікації (наскільки замовник та команда могли ефективно взаємодіяти)
- рефлексію РМ щодо своєї роботи
Ось 4 ключові запитання, на які РМ повинен відповісти після закінчення проєкту:
1. Що б він робив по-іншому?
2. Що б він перестав робити?
3. Що б він робив більше?
4. Що б він робив менше?
Musthave інструменти для РМ
З мого досвіду роботи в телекомунікації та банківській сфері, дуже гнучкі звіти дозволяє будувати продукт Power BI від Microsoft. Для отримання фінансових метрик попередньо необхідно опрацювати з бухгалтерією, які дані та з яких звітів потрібні.
Щоб складати ФЗ було нескладно, важливо вести проєкт правильно з самого початку. Адже, окрім рефлексії РМ з виконаної роботи, у ФЗ входить зібрана в один документ історія трансформацій. Якщо щось у ході проєкту змінювалося (терміни, бюджет), такі моменти мають фіксуватись.
Всі ці дані проджект-менеджеру потрібно тримати під рукою у вигляді простої таблиці в Excel з інформацією:
- дата погодження змін
- опис та причини, через які виникла необхідність їх вносити
- терміни/бюджет реалізації проєкту до змін
- терміни/бюджет реалізації проєкту внаслідок змін
- хто погодив зміни
- файл із протоколом наради, де було ухвалено рішення, або лист із підтвердженням або посилання на документ у системі електронного документообігу. Тут підходить будь-який прийнятий в організації спосіб фіксувати домовленості
Проджект-менеджеру буде складно пояснити, чому проєкт затягнутий, бюджет перевищили, зроблено лише частину функціоналу, а запитів на зміну не було.
Інструменти, за допомогою яких складається ФЗ, залежать від організації: це може бути Word, презентація або інший зручний формат. Але важливо мати базу всіх документів, які збиралися під час проєкту. Багатьом зручно вести все в Confluence або Jira, тоді вся інформація накопичується в базі знань проєкту. Звідти легко за категоріями взяти дані та зібрати у ФЗ.
Бажаєте отримувати дайджест статей?
