EVM для ІТ та програмних проєктів
Застосування Earned Value Management до ІТ та програмних проєктів є більш складним та нюансним, ніж у будівництві. Програмна робота є абстрактною, вимоги можуть змінюватися посеред проєкту, а вимірювання "відсотка виконання" функції є за своєю суттю суб'єктивним. Проте, за умови правильної адаптації, EVM забезпечує величезну цінність для управління ІТ-програмами та для інформування нетехнічних зацікавлених сторін про стан бюджету та графіка.
Основна проблема: вимірювання Earned Value у програмному забезпеченні
У будівництві ви можете виміряти фізичний прогрес. У програмному забезпеченні ви вимірюєте невидиму роботу. Три найпоширеніші підходи:
1. Story Points (Agile EVM)
У середовищах Scrum або Kanban команди оцінюють роботу в story points (пунктах історій). Ви можете побудувати EVM на основі цього:
- BAC = Загальна кількість story points × середня вартість одного story point
- PV = Story points, заплановані для завершення до цього спринту
- EV = Фактично завершені story points × середня вартість одного story point
- AC = Фактичні витрати команди (зарплати, інфраструктура, ліцензії) за період
Цей підхід враховує історію як "виконану" лише тоді, коли вона відповідає командному Definition of Done — що запобігає пастці "90% виконання".
2. EVM на основі віх (Waterfall)
Для проєктів Waterfall або фазових проєктів призначайте бюджетні ваги віхам (наприклад, Вимоги = 15%, Дизайн = 20%, Розробка = 40%, Тестування = 20%, Впровадження = 5%). Earned Value зараховується лише тоді, коли кожна віха повністю завершена та прийнята.
3. Зважені пакети робіт
Розбийте програмне забезпечення на функціональні модулі (автентифікація, звітність, API, UI). Оцініть вартість і тривалість для кожного. Відстежуйте завершення на рівні модуля. Це найбільш традиційний підхід EVM, який підходить для ІТ-контрактів з фіксованою ціною.
Практичний приклад: Проєкт розробки ПЗ
Проєкт розробки користувацької CRM: BAC = $400,000, 8 спринтів (16 тижнів). На спринті 4 (тиждень 8):
- Загальна кількість story points: 800. Середня вартість одного story point: $500.
- Story points, заплановані до спринту 4: 400. PV = 400 × $500 = $200,000
- Фактично завершені story points: 320. EV = 320 × $500 = $160,000
- Фактичні витрати (зарплати команди + інфраструктура): AC = $195,000
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800 (відставання від плану на 20%)
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = $487,211
VAC = 400,000 − 487,211 = −$87,211
EVM та Agile: Поширені заперечення
| Заперечення | Відповідь |
|---|---|
| "Agile не має фіксованого обсягу" | EVM працює з пріоритезованим беклогом — BAC представляє погоджений обсяг релізу, а не весь беклог продукту |
| "Вимоги змінюються кожного спринту" | Використовуйте процес контролю змін. Затверджені зміни обсягу оновлюють BAC. Незаплановані зміни — це відхилення, які потрібно дослідити. |
| "Швидкість (Velocity) story points є більш корисною" | Velocity чудово підходить для команди; EVM забезпечує фінансовий огляд, необхідний спонсорам та керівникам. |
| "Ми не робимо оцінок заздалегідь" | EVM вимагає базового плану (baseline). Навіть історії відносного розміру можуть стати основою, якщо вони послідовно оцінені. |
Практичні поради для ІТ-менеджерів проєктів
- Встановлюйте BAC перед спринтом, а не після: Базовий план має бути стабільним, щоб EVM мав сенс.
- Враховуйте лише 0% або 100% для історій в процесі: Уникайте часткового кредиту; це завищує EV та маскує ризики графіка.
- Відстежуйте тренди CPI щотижня: Програмні проєкти рухаються швидко. Щомісячна звітність EVM може виявити проблеми занадто пізно.
- Окремий BAC для інфраструктури/операцій та розробки: Витрати на інфраструктуру мають інші драйвери витрат і повинні відстежуватися окремо.
- Використовуйте EVM на рівні програми: Якщо у вас є кілька Agile-команд, агрегуйте їхні дані EV/AC на рівні програми для звітності керівництву.