У проджект-менеджера на робочому столі Excel із 15 метриками. Таблиця оновлюється щопонеділка, а дані вносять самі розробники. Проте ніхто не заглядає в неї між зустрічами. Коли проєкт зрештою затримується на два тижні, дивуватися нічому — графіки попереджали про це ще в другому спринті, коли CPI впав нижче 0,85. Проблема в тому, що команда цей сигнал проігнорувала, бо ніхто не розумів значення цієї метрики.
Ця стаття — для тих, хто хоче зрозуміти, які метрики обирати під свій проєкт, як їх читати і як налаштувати трекінг так, щоб цифри справді допомагали управляти.
Скільки метрик потрібно проєкту і як їх відбирати?
Для більшості проєктів вистачає 3-5 показників. Більше — зазвичай означає страх щось пропустити або бажання виглядати солідно у квартальному звіті. Такий підхід точно не орієнтований на результат.
Фільтр метрик досить простий, потрібно запитати себе: яке рішення ця метрика допоможе прийняти? Якщо відповіді немає — показник зайвий.
Ось реальна картина: команда відстежує кількість годин на задачу, середній час відповіді на листи і середню довжину коментаря в коді тощо. Але не концентруються на головному: чи вкладаються вони в бюджет і чи здадуть проєкт вчасно. Ці два питання закривають CPI і SPI. Решта метрик більше нагадує інформаційний шум.
Практичне правило: починайте з одного-двох показників, що відповідають на головне запитання проєкту. Новий показник додаєте лише тоді, коли є конкретне питання без відповіді.
За даними PMI, команди, що системно відстежують прогрес і звіряють його з цілями, отримують Net Project Success Score у +54 балів — проти +31 у тих, хто пропускає хоча б один із цих елементів. Різниця між «виміряли щось» і «виміряли те, що дійсно потрібно».
CPI і SPI: два показники, які закривають більшість потреб фіксованого контракту
Якщо у вас фіксований контракт і чітке ТЗ, два показники закривають більшість потреб: CPI і SPI. Обидва входять у методологію Earned Value Management — і обидва дуже прості в розрахунку.
CPI: як рахувати і де шукати причину перевитрати
Де найчастіше допускаються помилок. CPI опускається нижче 1,0 з двох причин: або завдання недооцінені на старті, або команда витрачає час на переробки та виправлення помилок. Перший крок — це з'ясувати, де саме перевитрата: в конкретних типах завдань чи рівномірно по всьому проєкту. Якщо рівномірно — проблема глобально в оцінюванні вартості проєкту. Якщо в одному блоці — шукайте технічний збій або нечіткі вимоги саме там.
SPI: як відрізнити проблему оцінювання від проблеми очікування
Де зазвичай проблема. SPI і CPI часто падають разом — тоді проблема в плануванні або оцінюванні проєкту на старті. Але якщо SPI падає, а CPI тримається — команда, скоріш за все, на щось чекає: на погодження від клієнта, доступ до систем, відповідь від суміжних команд. Це сигнал переглянути, де завдання стоять у черзі, а не виконуються.
Як часто перевіряти. Для проєктів тривалістю 3-6 місяців — раз на тиждень. Для довших — раз на два тижні як мінімум. CPI і SPI нижче 0,9 протягом двох тижнів поспіль — привід для серйозної розмови зі стейкхолдерами.
Agile-проєкт: три показники, які замінюють CPI і SPI — і одна типова помилка при їх читанні
У командах із гнучкою розробкою (agile-проєкти) CPI і SPI часто не підходять: набір завдань постійно коригується, а бюджет вимірюється в сторі-поїнтах. Там головні показники — velocity, Lead Time і Defect Rate.
Velocity: чому цей показник вводить в оману без Defect Rate
Velocity — кількість story points, закритих за спринт. Сама по собі ця цифра мало що говорить, адже важлива динаміка.
⚡ Приклад. За останні чотири спринти команда закрила відповідно 32, 35, 29 та 33 сторі-поінти. Середня швидкість — 32 поінти за спринт. Це реальний темп розробки. Якщо у беклозі залишається ще 160 поінтів, розраховуйте щонайменше на 5 спринтів. Дедлайн уже за 3? Тоді обговорюйте скорочення обсягу робіт прямо зараз, а не в останній момент.
❌ Поширена помилка. Коли Velocity йде вгору, але клієнт незадоволений якістю, це тривожний сигнал. Найімовірніше, команда або штучно занижує складність оцінок, або нехтує етапом тестування. Показник Velocity варто аналізувати лише в парі з Defect Rate — кількістю знайдених помилок у кожному релізі. Якщо обидві метрики зростають паралельно, таке «прискорення» є ілюзорним і шкодить проєкту.
Lead Time: де завдання стоять у черзі замість того, щоб виконуватися
Lead Time — час від моменту, коли завдання взяте в роботу, до його закриття.
⚡ Приклад. Задача відкрита 1 квітня, закрита 8 квітня — Lead Time 7 днів. Середній Lead Time за спринт — хороший індикатор передбачуваності: замовник розуміє, коли очікувати результат.
❌ Що часто роблять не так. Lead Time великий, але velocity нормальна. Класична ситуація: завдань закривається багато, але кожне йде довго. Вузьке місце зазвичай приховане там, де задачі простоюють у чергах, а не опрацьовуються: тривале очікування код-рев'ю або паузи перед фінальним демо.
Defect Rate і Rework Rate: норма до 10%, все вище — привід для ретроспективи
— Defect Rate — це кількість дефектів на реліз або на умовну одиницю продукту (модуль, функцію). Наприклад, коли в модулі авторизації виявлено 15 багів, а в каталозі лише 3, стає очевидним, який напрям потребує уваги.
— Rework Rate — це частка часу команди, що йде на виправлення помилок (переробку). Норма — до 5-10% від загального часу. Все, що вище — привід для ретроспективи. Переробки можуть коштувати до 20% бюджету контракту.
Як рахувати Rework Rate:
Якщо команда з п'яти людей у спринті витратила 30 годин із 200 на виправлення старих помилок — rework rate 15%. Варто поговорити, чому.
Як налаштувати трекінг: мінімальний стек для команди до 10 осіб
42% проєктних офісів витрачають щонайменше один повний день на місяць на ручне складання звітів. Тобто замість аналізу і рішень — збирання цифр.
Jira, ClickUp і Google Sheets: що потрібно команді до 10 людей на старті
Для невеликої команди (до 10 осіб) на старті вистачає мінімального стеку:
Цього вистачає для більшості проєктів до 6 місяців.
Power BI і ClickUp AI: коли ручний трекінг перестає справлятися
Jira дозволяє підключити Power BI або Tableau через API і автоматично рахувати показники. Для CPI і SPI є готові шаблони дашбордів у Power BI — налаштовуються за пів дня.
Щодо AI: ClickUp AI і Motion вже вміють підсвічувати ризики відхилення від плану на основі поточних даних. Ці інструменти корисні для раннього попередження про відхилення — менеджеру лишається прийняти рішення на основі цих сигналів.
Понад 194 тис. організацій у 2025 році використовували 151 технологію для управління проєктами. Логіка вибору проста: інструмент має відповідати на запитання, які команда ставить щодня. Якщо питання — «чи вкладаємося в терміни» — достатньо простого трекера. Якщо потрібна аналітика по кількох проєктах і командах — потрібно щось складніше.
Як перетворити дашборд на конкретні дії: формат 15-хвилинного огляду
Показати дашборд на зустрічі — недостатньо. Корисна практика: для кожного ключового відхилення одразу ставте питання «що ми робимо з цим до наступного перегляду?» і фіксуйте відповідального і термін. Тоді цифри перетворюються на конкретні дії. Без цього навіть найкращий дашборд перетворюється на інформаційний шум.
⚡ Приклад такого огляду. Понеділок, 10:15. Команда дивиться на три показники: CPI = 0,87 (нижче за минулий тиждень), Lead Time зріс з 4 до 7 днів, Defect Rate на останньому релізі — 12 дефектів проти 6 тижнем раніше. Питання до кожного показника: чому CPI падає, де зависають завдання, що змінилося в процесі тестування. Відповідальний і дія до п'ятниці по кожному пункту. І зустріч закрита за 15 хвилин.
Головна помилка при налаштуванні
Обрати інструмент і вважати задачу вирішеною. Перше, що треба зробити перед запуском трекінгу — зафіксувати базові значення. CPI і SPI починають давати сигнал лише в динаміці: сам по собі CPI = 0,9 нічого не означає, якщо ви не знаєте, чи це краще або гірше, ніж тиждень тому. Виміряйте показники на початку спринту або після першого місяця роботи — це ваш baseline. Від нього і відраховуйте.
Хороша система метрик складається з трьох-п'яти показників, за якими команда реально приймає рішення. Для фіксованих проєктів — CPI і SPI. Для agile — velocity, Lead Time і Defect Rate. Налаштуйте автоматичний збір там, де можна. Раз на тиждень — 15 хвилин на перегляд і конкретні дії.
Метрика, за якою ніхто не приймає рішень — це зайвий рядок у звіті. Починайте з малого, перевіряйте, чи впливають цифри на ваші рішення, і додавайте показники лише тоді, коли без них справді не обійтися. За даними PMI, лише половина проєктів завершується успішно — і одна з головних причин у тому, що команди не бачать проблему, поки вона не стала кризою. Правильно підібрані метрики вирішують саме це.
