Якщо проаналізувати ТОП-20 причин провалу стартапів, то стає зрозумілою загальна тенденція для всіх проєктів. А саме – слабка організація процесів, помножена на неправильні пріоритети.
Однак це скоріше наслідки того, що компанія неправильно оперує метриками. Або ж взагалі не має налагоджених процесів моніторингу здоров’я проєктів.
Власне, сьогодні і сфокусуємось на цій проблемі та розглянемо ряд критичних моментів, зокрема це:
- Чому метрики важливі для проєкту?
- Типи метрик проєкту.
- Визначення ефективності метрик.
- Стратегії збору та аналізу даних.
- Практичні приклади та кейси.
Дочитайте матеріал до кінця, щоб поглибити знання з формування та контролю метрик здоров’я проєкту, його ефективності. І почнемо як завжди – з основ.
Визначення Project Metrics
Якщо пошукаємо класифікацію Project Metrics в PMI, то отримаємо наступне визначення:
«Показники проєкту – це конкретні показники, які використовуються для кількісного визначення та оцінки продуктивності та прогресу проєкту.»
Якщо трохи розширити визначення, то можемо сказати, що метрики є об’єктивними оцінковими параметрами для встановлення:
- Поточного рівня готовності проєкту.
- Стану здоров’я як проєкту, так і його учасників, тобто команди, стейкхолдерів.
- Актуальної продуктивності та ефективності запланованих процесів.
- Подальших пріоритетів та точок фокусування.
- Відповідність прогресу запланованій меті.
Однак, це лише короткий опис, який дозволяє приблизно уявити основну цінність метрик. В PMI же присутній цілий розділ цьому поняттю, який у всіх відтінках пояснює особливості та призначення метрик. Тому рекомендуємо ознайомитись з посібником PMBOK останньої ітерації.
Навіщо потрібні метрики проєкту?
Будь-який проєкт має певну мету та цілі, яких його власники досягають різними способами. Зокрема це відповідність вимогам, терміни розробки, якість продукту тощо.
Саме метрики дозволяють проєктним менеджерам оцінювати актуальний стан проєкту та відповідним чином реагувати на виклики, які завжди присутні при розробці.
Однак, сукупна кількість цілей метрик виходить далеко за межі цього визначення. Тому розгляньмо коротко всі ключові аспекти, для яких вони призначені.
Окреслити та продемонструвати статус проєкту
Перша і найголовніша мета метрик – дати розуміння того, на якій стадії знаходиться проєкт, який його стан, кількість проблем в ньому. Це дозволяє чітко побачити картину та ухвалити план подальших дій.
Також це можливість виявити поточні виклики і оперативно відреагувати на них, наприклад, змінивши підхід до реалізації проєкту, або ввівши додаткові практики.
Забезпечити прозорість зацікавленим сторонам
Стейкхолдери (інвестори, власники продукту, потенційна аудиторія) завжди очікують від проєкту певних результатів. Чіткі метрики – це спосіб надати певну інформацію зацікавленим сторонам у зрозумілому форматі.
Наприклад, візуалізуючи показники та певні поточні цифри у вигляді інфографіки, яка пояснює походження і причини тих чи інших особливостей стану проєкту.
Дозволити менеджерам приймати рішення на основі об’єктивних даних
Метрики не просто є набором цифр, це статистичні дані, які можуть слугувати платформою для ухвалення певних рішень. Наприклад, для переспрямування частини ресурсів для розв’язання актуальних проблем.
Загалом інформація, що отримана з метрик, є важливою для правильної організації процесів на проєкті, ідентифікації проблем та встановлення пріоритетів, обґрунтованих наявними та дослідженими факторами.
Переглянути тенденції в проєкті
Без актуальних метрик у менеджера може не бути повної інформації про стан проєкту, його здоров’я чи навіть тенденцій, які потенційно можуть впливати на підсумкову успішність розробки.
Наприклад, якщо не відстежувати хоча б ключові метрики, то можна втратити фокус, або ж взагалі пропустити момент, коли на проєкті змінився вектор і він почав розвиватися у дещо іншому напрямку ніж було заплановано.
Зробити проєкт передбачуванішим
Якщо ви маєте актуальні алгоритми збору та аналізу даних проєкту, бажано б ще й автоматизовані, то ви майже в режимі онлайн можете слідкувати за станом продукту.
Це означає, що ви маєте можливість завчасно попереджати різноманітні ризики та реагувати на них. Відповідно, ця контрольованість допоможе ефективно та без зайвих проблем працювати над проєктом.
Робити прогнози та передбачення на основ і показників
Коли перед менеджером та бізнес-аналітиком постійно знаходяться дані з метрик, вони мають можливість будувати прогнози, підкріплені фактичними показниками.
Відповідно, це дозволить тримати фокус на основних цілях проєкту та попереджати фактично будь-які можливі виклики. В підсумку це зменшить кількість проблем проєкту та збільшить його шанси на успіх.
Визначати та зменшувати бізнес-ризики
Залежно від типу метрик, їх можна використовувати і для пошуку та нівелювання потенційних ризиків для бізнесу. Зокрема тих, що пов’язані з фінансовою частиною проєкту.
Наприклад, спостерігати за витратами бюджету на реалізацію окремих функцій та зменшувати їх за потреби. Або ж прораховувати потенційні збитки від несвоєчасного релізу, багів на виході тощо.
Оцінювати новий обсяг (наприклад, вихідні дані для аналізу)
Якщо в проєкт вносяться зміни, то лише наявні метрики дозволять порівняти новий обсяг роботи, цілі тощо з попередніми планами. Таким чином можна заздалегідь прорахувати потенційний вплив змін та підготуватися до викликів.
Зокрема це стосується випадків, коли відбувається переформатування частин проєкту, що мають масштабний вплив на графік реалізації та якість продукту.
Зверніть увагу, описані метрики стосуються лише проєктів. На глобальнішому рівні існують ще й організаційні показники, які охоплюють більшу частину даних. Однак сьогодні мова саме про спеціалізовані метрики, які дозволяють не втрачати фокус під час роботи над певним проєктом, або ж навіть продуктом.
Критерії метрик
Якщо коротко, то загальна суть всіх метрик зводиться до одного: вони мають нести певну цінність для проєкту. Наприклад:
- показувати вигоди, або збитки від певних рішень;
- давати точне і вимірюване значення стану проєкту;
- демонструвати залежності між рішеннями та наслідками.
Однак це можуть робити лише якісно побудовані метрики, що базуються на релевантних та достовірних даних. А ще такі, що відповідають трьом ключовим критеріям.
Проста і зрозуміла для керівництва проєкту, членів команди, клієнтів та керівництва організації
Метрика має бути легкою для сприйняття всіма зацікавленими сторонами. Тобто вона має чітко вказувати саме на ту інформацію, яку ми намагаємось донести стейкхолдерам, або ж іншій аудиторії.
Наприклад, коли ми визначаємо цінність певної фічі, то можемо апелювати до статистичних даних, що демонструють нам прибутки чи збитки у цифрових значеннях від її реалізації.
Вимірюються чітко, чесно для всіх і без двозначності
Якими б не були дані, метрики мають демонструвати їх без прикрас. Інакше вони просто втрачають свою цінність. Умовно, якщо в проєкті присутні проблеми, то їх слід відображати на папері, щоб уникнути подальших помилкових рішень.
Так, цілком можливо спробувати догодити стейкхолдерам, однак з хибними метриками та даними ви лише зашкодите проєкту, що в майбутньому призведе до масштабування проблем.
Підтримуються та відстежуються реальними даними
Ніяких придуманих даних. Метрики проєкту мають будуватись лише на фактичній інформації, як то дані про витрати, актуальний стан, потенційні збитки тощо.
Інакше ви ризикуєте власноруч створити ілюзію, яка сформує або ж завищені очікування, або ж просто призведе до невизначеності, яка згубить проєкт.
Все зазначене є не просто критеріями ефективних та якісних метрик, а і тригером, який дозволяє запобігати ряду ризиків та викликів для проєкту. Хоча саме проблематики метрик він не виключає. І саме про неї поговоримо далі.
Виклики, пов’язані з метриками у проєктах
Самі собою метрики не є панацеєю, оскільки їхня ефективність залежить зокрема і від того, як саме вони побудовані та на що вказують.
Таким чином, якщо ваші метрики не відповідають певним критеріям та стандартам, то вони потенційно можуть шкодити проєкту. Особливо, якщо на основі отриманої з них інформації ухвалюватимуться важливі рішення тими ж менеджерами, або стейкхолдерами.
Тож давайте поглянемо на ключові виклики, з якими стикається абсолютна більшість проєктних менеджерів та інших ролей, залучених до процесу формування метрик.
Універсальна помилка
Метрика заради метрики. Уявіть ситуацію, коли вам приходить завдання від стейкхолдера виміряти показники проєкту. Просто, без деталізації з ціллю охопити все і вся.
Постає питання про доцільність такої дії. Зокрема, а як ви плануєте вимірювати все і одразу? Комплексним алгоритмом? Чи великою кількістю різних тестів? Перша ідея взагалі не несе ніякої цінності, тоді як друга лише додає клопотів проєкту.
Не існує універсального алгоритму побудови метрик для проєкту, як і не існує потреби вимірювати все і вся.
Метрика заради метрики – це одна з найгірших та ресурсно недоцільних концепцій, яка найчастіше зустрічається на проєктах різних типів.
Визначення показників, які приносять цінність для зацікавлених сторін
Будь-яка метрика, яку ви збираєтесь додати до проєкту має нести певну цінність. Так, в теорії можна прикрутити тисячі метрик, зібрати відповідні дані і гордо демонструвати їх стейкхолдерам. Однак вас просто не зрозуміють.
Розгляньмо приклад.
Ви приходите в проєкт, скажімо, де розробляється певна фіча для продукту. Перед вами постає завдання визначити ефективність процесів і оцінити загальний стан цього проєкту, включно з продуктивністю, дотриманням дедлайнів тощо. Якщо в цьому контексті ви візьметесь за підрахунок якихось другорядних моментів, наприклад, виміряєте кількість рядків коду що створюються за день, то вас просто не зрозуміють.
Першочергово вам потрібно врахувати ряд факторів, зокрема:
- Розмір та культуру організації.
- Розмір та культуру проєкту.
- Робоче оточення.
- Логіку клієнта.
- Вимоги продукту.
- Кількість та склад команд.
- Системи, що використовуються на проєкті.
Можливо, вам достатньо ввести всього кілька базових метрик, щоб забезпечити ефективне вимірювання кількісних та якісних показників проєкту. Принаймні, ви можете виділити лише кілька основних з них та отримувати дійсно цінну інформацію замість набору даних, які не мають користі ані для проєкту, ані для його стейкхолдерів.
Але є і зворотний бік медалі. Коли ви, умовно, працюючи на масштабному проєкті, намагаєтесь обійтися звичним мінімумом метрик. Тоді збільшується ризик того, що ви не зможете покрити метриками всі критичні аспекти проєкту.
Якщо підсумувати, то просто намагайтесь тримати в фокусі ключові потреби проєкту та його масштаб, а також адаптувати стратегію вимірювання показників до цих факторів.
Типи метрик по PMI
Те, що вимірюється, а також параметри та метод вимірювання залежать від цілей проєкту, очікуваних результатів і середовища, в якому розгорнутий проєкт.
За стандартами PMBOK класифікують такі типи метрик:
- Deliverable metrics.
- Delivery.
- Baseline performance.
- Resources.
- Business value.
- Stakeholders.
- Forecasts.
Це все ключові метрики, точніше групи, за якими розбивається значна кількість алгоритмів вимірювання основних типів показників проєкту. Саме за ними формується бачення та фокус розробки, визначаються цілі, мета, кількість залучених ресурсів, продуктивність, задоволеність стейкхолдерів тощо.
Додаткові класифікації метрик
Якщо основних груп метрик замало для вашого проєкту, то можна скористатись розширеним переліком, який групується за областями застосування алгоритмів вимірювання показників.
Що цікаво, загалом фокус цих додаткових метрик майже аналогічний ключовим типам, але сам набір метрик є значно гнучкішим, що дозволяє обрати саме ті варіанти, які потрібні вашому проєкту.
Однак, це все теорія, тому пропонуємо перейти до практичних моментів, а саме до огляду прикладів побудови метрик у реальних проєктах.
5 кейсів з побудови метрик
Проєктний менеджмент охоплює одразу велику кількість компонентів самого проєкту. Як організаційні моменти, так і суто практичні, як от контроль швидкості та якості роботи команди, її професійного та емоційного здоров’я, якість коду, своєчасність тощо.
Для кожного з цих параметрів існують свої набори метрик та алгоритмів їхнього вимірювання. Тож далі ми продемонструємо вам 5 різних кейсів того, як на практиці будуються метрики для розв’язання різного роду задач та збору цінних даних.
1. Де ми знаходимося як команда?
Подібні метрики потрібні одразу для кількох цілей, а саме:
- Тримати фокус команди та її тонус.
- Контролювати стан проєкту та актуальні досягнення.
- Будувати песимістичні та оптимістичні прогнози.
- Надавати прогнози щодо дедлайнів стейкхолдерам.
- Виявляти проблеми продуктивності команди.
Тут може бути досить велика кількість чартів, вибір яких залежить саме від того, що саме є актуальним для вас, команди та стейкхолдерів на певному етапі розвитку цього проєкту.
2. Якість нашого коду погана
Щоб визначити наскільки на вашому проєкті все добре чи погано саме в технічному плані, вам знадобляться наступного типу чарти та графіки:
- Контроль частоти та серйозності дефектів.
- Аналіз співвідношення створених та виправлених багів.
- Області автоматизації тестування.
- Метрики за показниками з CI/CD на кшталт Jira/Jenkins.
- Зведена інфографіка щодо загальної кількості проблем, їхньої періодичності тощо.
Це допоможе поглянути на проєкт крізь призму критики та оцінити його поточний технічний стан, визначити пріоритети виправлення багів та виявити залежності між кількістю створених та розв’язаних проблем.
3. Нездоровий беклог
Формально ця метрика демонструє фактичний стан проєкту в порівнянні з запланованими задачами. Зокрема тут можна використовувати такі показники для аналізу:
- To Do.
- Analysis.
- Planning.
- Development.
- Review.
- Piloting.
- Education.
- Roll-out.
- Done.
Останній параметр, накладений на решту і візуалізує скільки умовних відсотків від запланованого вже готові. І цей індикатор є важливим для проєкту, оскільки показує його фактичний стан та виділяє моменти, на які не вистачає ресурсів.
4. Нам потрібно покращити час виходу на ринок
Щоб виміряти, чи є час виходу продукту на ринок оптимальним можна використовувати метрики з того ж Kanban, зокрема Lead Time. Умовна інфографіка демонструє проміжок часу від отримання ТЗ клієнта до його фактичного виконання та розгортання у вигляді певної фічі для продукту.
Корисна ця метрика зокрема у випадках, коли ваші стейкхолдери висувають претензії щодо періодичності та своєчасності розгортання оновлень, щодо відставання від конкурентів тощо.
5. Низька продуктивність команди
Аналогічний попередньому графік можна реалізувати і для тестування продуктивності команди. Але вже за іншим набором параметрів, ніж це було у випадку з аналізом проблем своєчасності розгортання ітерацій продукту.
Підсумуємо
Незалежно від типу вашого проєкту та його масштабу, вам потрібно контролювати його та проводити постійну аналітику. Зокрема і через впровадження метрик, збір та аналіз показників, моделювання на їх основі спеціальної інфографіки, таблиць та інших візуальних моделей.
Ключові функції метрики – донести цінність того чи іншого рішення до стейкхолдерів, схарактеризувати та продемонструвати поточний стан продукту, виявити проблеми, ризики проєкту.
Однак не варто застосовувати всі відомі вам алгоритми та будувати метрики просто для «галочки». Сфокусуйтесь на потребах та масштабах проєкту та вимірюйте лише цінні показники, з якими ви матимете можливість покращити проєкт, продуктивність команди, оперувати очікуваннями стейкхолдерів тощо.
Для цього орієнтуйтесь на PMI та алгоритми PMBOK. Або ж отримайте експертну консультацію у фахівців платформи E5, які допоможуть вам краще налагодити процеси проєктного менеджменту в компанії.
