EVM dla projektów IT i Oprogramowania
Stosowanie Zarządzania Wartością Wypracowaną (EVM) w projektach informatycznych i programistycznych jest zarówno trudniejsze, jak i bardziej zniuansowane niż w budownictwie. Praca nad oprogramowaniem jest abstrakcyjna, wymagania mogą się zmieniać w trakcie projektu, a mierzenie "procentu ukończenia" funkcji jest z natury subiektywne. Jednakże, dzięki odpowiednim dostosowaniom, EVM dostarcza ogromną wartość w zarządzaniu programami IT oraz w komunikowaniu stanu budżetu i harmonogramu do nietechnicznych interesariuszy.
Główne wyzwanie: Pomiar Wartości Wypracowanej w oprogramowaniu
W budownictwie można mierzyć fizyczny postęp (wylane metry sześcienne, ułożone metry). W tworzeniu oprogramowania, mierzy się pracę niewidoczną. Trzy najpopularniejsze podejścia to:
1. Punkty historyjek (Story Points - Agile EVM)
W środowiskach Scrum lub Kanban zespoły szacują pracę w punktach historyjek. Możesz na tym zbudować EVM:
- BAC = Całkowita liczba punktów historyjek × średni koszt za punkt
- PV = Punkty zaplanowane do ukończenia do tego sprintu
- EV = Punkty faktycznie ukończone × średni koszt za punkt
- AC = Faktyczne koszty zespołu (wynagrodzenia, infrastruktura, licencje) w tym okresie
Takie podejście zalicza "zrobienie" tylko dla historyjek, które spełniają zespołową Definition of Done — zapobiega to pułapce "gotowe na 90%".
2. EVM oparty na kamieniach milowych (Waterfall)
W przypadku projektów Waterfall przypisz wagi budżetowe do kamieni milowych (np. Wymagania = 15%, Projektowanie = 20%, Tworzenie = 40%, Testowanie = 20%, Wdrożenie = 5%). Wartość wypracowana jest przyznawana tylko wtedy, gdy każdy kamień milowy jest w pełni zrealizowany i zaakceptowany.
3. Ważone pakiety robocze
Podziel oprogramowanie na moduły funkcjonalne (uwierzytelnianie, raportowanie, API, UI). Oszacuj koszt i czas trwania każdego z nich. Śledź postępy na poziomie poszczególnych modułów. To najbardziej tradycyjne podejście do EVM, odpowiednie dla kontraktów IT ze stałą ceną.
Przykład obliczeniowy: Projekt rozwoju oprogramowania
Niestandardowy projekt CRM: BAC = 400 000 $, 8 sprintów (16 tygodni). W 4 sprincie (8 tydzień):
- Całkowita liczba punktów historyjek: 800. Średni koszt za punkt: 500 $.
- Planowane punkty do 4 sprintu: 400. PV = 400 × 500 $ = 200 000 $
- Ukończone punkty historyjek: 320. EV = 320 × 500 $ = 160 000 $
- Koszt rzeczywisty (pensje zespołu + infrastruktura): AC = 195 000 $
SPI = EV ÷ PV = 160 000 ÷ 200 000 = 0,800 (opóźnienie o 20%)
EAC = BAC ÷ CPI = 400 000 ÷ 0,821 = 487 211 $
VAC = 400 000 − 487 211 = −87 211 $
EVM i Agile: Powszechne zarzuty
| Zarzut | Odpowiedź |
|---|---|
| "Agile nie ma stałego zakresu" | EVM działa z priorytetowym backlogiem — BAC to uzgodniony zakres wydania, a nie cały backlog produktu |
| "Wymagania zmieniają się co sprint" | Wykorzystaj proces kontroli zmian. Zatwierdzone zmiany zakresu aktualizują BAC. Niezaplanowane zmiany to odchylenia do zbadania. |
| "Szybkość (velocity) sprintów jest bardziej użyteczna" | Prędkość zespołu (velocity) jest świetna dla deweloperów; EVM zapewnia obraz finansowy potrzebny sponsorom i kadrze kierowniczej. |
| "Nie szacujemy nic z góry" | EVM wymaga linii bazowej (baseline). Nawet historyjki wycenione relatywnie mogą stanowić jej podstawę, o ile są szacowane spójnie. |
Praktyczne wskazówki dla kierowników projektów IT
- Ustal BAC przed sprintem, a nie po nim: Plan bazowy musi być stabilny, by EVM miało sens.
- Traktuj historyjki jako 0% lub 100% gotowe: Unikaj częściowych zaliczeń; zawyża to EV i maskuje ryzyko.
- Śledź trendy CPI co tydzień: Projekty oprogramowania posuwają się szybko do przodu. Raporty miesięczne EVM mogą wykrywać problemy zbyt późno.
- Oddziel BAC dla infrastruktury/operacji od rozwoju: Koszty infrastruktury mają inne mechanizmy kosztowe i powinny być śledzone oddzielnie.
- Korzystaj z EVM na poziomie programu: Gdy posiadasz wiele zespołów Agile, agreguj ich dane EV/AC na poziomie całego programu w celu raportowania dla kierownictwa.