EVM для ИТ и Программных Проектов
Применение Управления Освоенным Объемом к ИТ и программным проектам сложнее и тоньше, чем к строительству. Программная работа абстрактна, требования могут меняться по ходу проекта, а измерение "процента завершения" функции по своей сути субъективно. Тем не менее, при правильной адаптации, EVM представляет огромную ценность для управления ИТ-программами и для информирования нетехнических стейкхолдеров о статусе бюджета и графика.
Основная Проблема: Измерение Освоенного Объема в ПО
В строительстве вы можете измерить физический прогресс (залитые кубометры, проложенные метры). В разработке ПО вы измеряете невидимую работу. Три наиболее распространенных подхода:
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%). Освоенный объем засчитывается только тогда, когда каждая веха полностью завершена и принята.
3. Взвешенные Пакеты Работ
Разбейте ПО на функциональные модули (аутентификация, отчетность, API, UI). Оцените стоимость и продолжительность для каждого. Отслеживайте завершение на уровне модуля. Это наиболее традиционный подход EVM, подходящий для ИТ-контрактов с фиксированной ценой (Fixed Price).
Пример: Проект Разработки ПО
Проект разработки пользовательской 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 (скорость) полезнее" | Скорость (Velocity) отлично подходит для команды; EVM предоставляет финансовое представление, необходимое спонсорам и руководству. |
| "Мы не оцениваем заранее" | EVM требует базового плана. Даже истории относительного размера могут стать основой, если они последовательно оценены. |
Практические Советы для ИТ Менеджеров Проектов
- Устанавливайте BAC до начала спринта, а не после: Базовый план должен быть стабильным, чтобы EVM имел смысл.
- Считайте только 0% или 100% для историй в работе: Избегайте частичного зачисления; это раздувает EV и маскирует риски графика.
- Отслеживайте тренды CPI еженедельно: Программные проекты движутся быстро. Ежемесячная отчетность EVM может выявить проблемы слишком поздно.
- Разделяйте BAC для инфраструктуры/Ops и разработки: Инфраструктурные расходы имеют разные драйверы затрат и должны отслеживаться отдельно.
- Используйте EVM на уровне программы: Если у вас несколько Agile-команд, агрегируйте их данные EV/AC на уровне программы для отчетов руководству.