EVM IT ir programinės įrangos projektams
Taikyti Earned Value Management (EVM) IT ir programinės įrangos projektams yra sudėtingiau nei statybose. Programinės įrangos darbas yra abstraktus, reikalavimai gali keistis projekto viduryje, o funkcijos „baigtumo procento“ matavimas iš prigimties yra subjektyvus. Tačiau pasirinkus tinkamus pritaikymus, EVM suteikia didžiulę vertę IT programų valdymui ir biudžeto bei tvarkaraščio būsenos komunikacijai su netechniniais suinteresuotaisiais asmenimis.
Pagrindinis iššūkis: EV (Earned Value) matavimas programinėje įrangoje
Statybose galite išmatuoti fizinę pažangą (išlieti kubiniai metrai, pakloti metrai). Programinėje įrangoje matuojate nematomą darbą. Trys dažniausiai naudojami metodai:
1. Istorijų taškai (Agile EVM)
Scrum arba Kanban aplinkose komandos vertina darbą istorijų taškais (story points). EVM galite kurti remdamiesi tuo:
- BAC = Visi istorijų taškai × vidutinė vieno istorijos taško kaina
- PV = Istorijų taškai, kuriuos planuojama užbaigti iki šio sprinto
- EV = Faktiškai baigti istorijų taškai × vidutinė vieno istorijos taško kaina
- AC = Faktinės komandos išlaidos (atlyginimai, infrastruktūra, licencijos) atitinkamam laikotarpiui
Šis požiūris istorijoms priskiria vertę tik tada, kai jos atitinka komandos „Baigimo apibrėžimą“ (Definition of Done) — taip išvengiama spąstų „90% baigta“.
2. Etapais pagrįstas EVM (Waterfall)
„Krioklio“ (waterfall) projektams priskirkite biudžeto svorius etapams (pvz., Reikalavimai = 15%, Dizainas = 20%, Kūrimas = 40%, Testavimas = 20%, Diegimas = 5%). Uždirbta vertė (EV) suteikiama tik tada, kai kiekvienas etapas yra visiškai baigtas ir priimtas.
3. Svertiniai darbo paketai
Suskirstykite programinę įrangą į funkcinius modulius (autentifikavimas, ataskaitos, API, vartotojo sąsaja). Įvertinkite kiekvieno jų kainą ir trukmę. Stebėkite baigtumą modulio lygiu. Tai pats tradiciškiausias EVM metodas, tinkamas fiksuotos kainos IT sutartims.
Praktinis pavyzdys: Programinės įrangos kūrimo projektas
Individualios CRM sistemos kūrimo projektas: BAC = 400 000 $, 8 sprintai (16 savaičių). Būsena 4-ame sprinte (8-a savaitė):
- Visi istorijų taškai: 800. Vidutinė vieno taško kaina: 500 $.
- Planuojami istorijų taškai iki 4-o sprinto: 400. PV = 400 × 500 = 200 000 $
- Faktiškai baigti istorijų taškai: 320. EV = 320 × 500 = 160 000 $
- Faktinės išlaidos (komandos atlyginimai + infrastruktūra): AC = 195 000 $
SPI = EV ÷ PV = 160 000 ÷ 200 000 = 0,800 (20% atsiliekama nuo plano)
EAC = BAC ÷ CPI = 400 000 ÷ 0,821 = 487 211 $
VAC = 400 000 − 487 211 = −87 211 $
EVM ir Agile: Dažni prieštaravimai
| Prieštaravimas | Atsakymas |
|---|---|
| „Agile neturi fiksuotos apimties“ | EVM veikia su prioritetizuotu užduočių sąrašu (backlog) — BAC atstovauja sutartai laidos (release) apimčiai, o ne visam produkto sąrašui. |
| „Reikalavimai keičiasi kiekviename sprinte“ | Naudokite pokyčių valdymo procesą. Patvirtinti apimties pokyčiai atnaujina BAC. Neplanuoti pokyčiai yra nuokrypiai, kuriuos reikia ištirti. |
| „Istorijų taškų greitis (velocity) yra naudingesnis“ | Greitis puikiai tinka komandai; EVM suteikia finansinį vaizdą, kurio reikia rėmėjams ir vadovams. |
| „Mes nevertiname iš anksto“ | EVM reikalingas bazinis planas (baseline). Net santykinai įvertintos istorijos gali būti pagrindas, jei vertinama nuosekliai. |
Praktiniai patarimai IT projektų vadovams
- Nustatykite BAC prieš sprintą, o ne po jo: Bazinis planas turi būti stabilus, kad EVM būtų prasmingas.
- Naudokite tik 0% arba 100% taisyklę nebaigtoms istorijoms: Venkite dalinio vertinimo; tai dirbtinai padidina EV ir maskuoja tvarkaraščio riziką.
- Stebėkite CPI tendencijas kas savaitę: Programinės įrangos projektai juda greitai. Mėnesinės EVM ataskaitos gali per vėlai pastebėti problemas.
- Atskirkite infrastruktūros/operacijų BAC nuo kūrimo BAC: Infrastruktūros išlaidos turi kitokius veiksnius ir turėtų būti stebimos atskirai.
- Naudokite EVM programos lygiu: Jei turite kelias Agile komandas, apjunkite jų EV/AC duomenis programos lygiu, kad galėtumėte teikti ataskaitas vadovams.