Steve McConnelin kuvaama Cone of Uncertainty osoittaa sen, minkä jokainen kokenut ohjelmistoalan ammattilainen tietää. Mikä tarkoittaa, että minkään projektin alussa emme tiedä tarkalleen, kuinka kauan projekti kestää.
Syitä tähän on monia. Missään kahdessa koskaan toteutettavassa projektissa ei ole:
- samat vaatimukset.
- samat ihmiset.
- sama liiketoimintakonteksti.
- sama teknologia.
- samat prioriteetit &rajoitukset.
Jokainen on ainutlaatuinen. Jokainen koodirivi on käsityönä tehty. Ja tietämystyö, johon osallistuu älykkäitä luovia ihmisiä, ei sovellu tarkkuuteen samalla tavalla kuin ojankaivuu.
Mutta tarkkuutta pyydetään. Sponsorit haluavat tietää tarkalleen, milloin projekti valmistuu ja kuinka paljon se maksaa.
Tämän pulman ratkaiseminen on lähes yhtä vanhaa kuin itse aika. Seuraavassa on muutamia tapoja, joilla tiimit ja yritykset käsittelevät tätä epävarmuutta.
Kartion käsitteleminen
Täydennä arviota
Kun aliarviointi kirpaisee, yksi yleinen reaktio on kaksinkertaistaa tai kolminkertaistaa arvio seuraavalla kerralla. Tämä varmasti pienentää etukäteisriskiä, mutta lukujen pönkittäminen on vaikeampaa kuin miltä se kuulostaa.
Anna liian suuri luku, ja sponsorit epäröivät eivätkä hyväksy projektiasi. Jos annat liian pienen luvun, vaarana on, että rahat loppuvat kesken. Tästä tulee kaksin verroin hankalampaa, kun kilpailutat kiinteän tarjouksen sopimuksia, joissa on vielä enemmän paineita pitää luvut alhaisina.
Useimmat hankkeet lisäävät jonkinlaista pehmustetta lopullisiin lukuihin antaakseen itselleen riittävästi liikkumavaraa. Toinen asia, jonka tiimit voivat tehdä, on verrata tätä hanketta muihin.
Mitoita hanke suhteellisesti
Ihmiset ovat todella hyviä mitoittamaan asioita suhteellisesti. Emme voi kertoa tarkasti, kuinka suuri kivi on. Mutta voimme kertoa, kuinka suuri se on verrattuna johonkin muuhun. Voimme käyttää tätä myös mitoittaessamme projekteja.
Ole avoin ja rehellinen
Agilen oletusarvoinen toimintatapa on avoimuus ja näkyvyys. Ei siis liene yllätys, että ketterä tapa käsitellä kartiota on olla suorapuheinen ja rehellinen.
Katso. Emme tiedä, kuinka kauan tämä kestää. Tämä on paras arvauksemme. Mutta jos annat meille pari iteraatiota, voimme rakentaa jotain, mitata, kuinka kauan se kestää, ja sitten kertoa sinulle paljon paremman käsityksen siitä, kuinka suuri tämä asia on.
Toinen lähestymistapa, jota jotkut ketterät tiimit käyttävät epävarmuuden kommunikoimisen helpottamiseksi, on esittää arviot vaihteluvälinä.
Tämän etuna on, että sponsoreille näytetään näkyvästi projektiin liittyvä epävarmuus, ja sponsorit saavat sitten päättää, kuinka paljon riskiä heillä on varaa ottaa.
Rahoita inkrementaalisesti
Toinen lähestymistapa, jossa on paljon järkeä, mutta jota en valitettavasti näe sovellettavan tarpeeksi usein, on inkrementaalinen rahoitus.
Inkrementaalisella rahoituksella et pyydä koko rahasäkkiä etukäteen. Vain sen verran, että saadaan riittävästi rahaa työn läpiviemiseen, jotta voidaan raportoida parempi luku siitä, kuinka kauan siihen menee aikaa.
Se ei ole idioottivarma. Voit silti joutua vaikeuksiin myöhemmin. Mutta antamalla tiimeille 30-50 000 dollaria, antamalla heidän rakentaa jotakin ja katsomalla, kuinka kauan se kestää, voidaan vähentää huomattavasti tuon etukäteisluvun vaihtelua.
Voit lukea lisää tästä suunnittelutavasta ja sen tuomista eduista Jeremy Hopen kirjasta Beyond Budgeting
Juurisyy
Elämme vuosibudjettien maailmassa. Ja valitettavasti tämä aiheuttaa paljon jännitteitä ja draamaa työpaikoillamme. Jollain tavalla vuosibudjetit ovat luonnollisia (elämme ja seuraamme aikaa vuosisykleissä), mutta toisaalta ne ovat suunnittelun kannalta hirvittäviä, sillä vuosi on markkinoilla pitkä aika.
Jos huomaat kompastuvasi epävarmuuden kartioon, muista vain, että koko ohjelmistojen arvioinnin tarkoitus on määrittää, onko projekti edes mahdollinen.
Vai kuten Steve McConnell sanoo:
Ohjelmiston arvioinnin ensisijainen tarkoitus ei ole ennustaa projektin lopputulosta, vaan määrittää, ovatko projektin tavoitteet riittävän realistisia, jotta projektia voidaan ohjata niiden saavuttamiseksi.
-Steve McConnell, Software Estimation: Demystifying the Black Art