Miksi softaprojekti voi kestää 2–3 kertaa pidempään kuin suunniteltiin?
Tässäpä vapaasti lyhenneltynä ja mukailtuna oiva Quora-vastaus kysymykseen, joka koskee ohjelmistokehitysalalla niin tuttua tilannetta: miksi alkuperäisarvio projektin kestosta niin usein tuplaantuu tai triplaantuu?
Lyhyt vastaus on “Miksi koira nuolee pallejaan? Koska se pystyy siihen” -tyyppinen.
Useimmat softaprojektit ovat – ja pystyvät olemaan – paljon puutteellisemmin ymmärrettyjä projektiin lähdettäessä kuin fyysisen maailman vastaavat hankkeet, vaikkapa sillanrakennus tai kerrostalon pystyttäminen.
Ohjelmisto on täysin virtuaalinen, ei-kosketeltava: sen tekemiseen ei yleensä vaadita painavia työkoneita tai lupaprosessejakaan.
Yksikin lahjakas devaaja saattaa tuottaa suuren määrän tasokasta koodia lyhyessä ajassa – hän saattaa pystyä jopa koodaamaan koko tuotteen alusta loppuun yksin. Eipä onnistu millään rakennustyömaalla moinen. Softan virtuaalinen olemus muuttaa kokonaan käsityksen siitä, millä tahdilla ja resursseilla projekteja voidaan viedä läpi.
Mutta…
Koska softaa voidaan koodata ilman mittavaa etukäteissuunnittelua tai edes täydellistä ymmärrystä itse ratkaistavan ongelman laadusta, tämä on juuri se tapa, millä softat yleensä halutaan tehtävän.
Toisin sanoen: kukaan ei pyydä pientä rakennusliikettä pystyttämään jättimäistä rakennushanketta puolessa vuodessa, mutta ohjelmistoyrityksiltä vaaditaan aivan rutiininomaisesti jättimäisiin rakennushankkeisiin verrattavia koodituotoksia.
Softaprojekti on "opitaan sitä mukaa kuin valmista syntyy" -prosessi
Tämän seurauksena softaprojekti on tyypillisesti oivallusprosessi: Projektin edetessä devaaja näkee ja oppii mitä pitää kehittää ja mihin suuntaan. Mikä hankalampaa, asiakas usein muuttaa mieltään projektin kuluessa, ja tämän on hankala nähdä miten laajoja vaikutuksia esimerkiksi valikkorakenteen muutoksella lennossa voi olla. Niinpä projektin laajuus muuttuu ajassa, ja välietapit siirtyvät kauemmas.
Ketterät ohjelmistokehitysmetodit ovat vastaus tähän haasteeseen. Iteratiivisuus taklaa "opitaan sitä mukaa kuin valmista syntyy" -tyyppisen prosessin ongelmia, mutta eivät ne sillä kokonaan poistu. Diagnostis-henkisen lähestymistavan avulla on silti helpompaa ennustaa, kun projektin ”etenemispylväs” on koko ajan suurennuslasin alla, ja kurssia pyritään jatkuvasti korjaamaan sen mukaan, miten ymmärrys tarpeesta kehittyy.
Kokemuksella ja taidolla nopeammin maaliin
Takaisin alkuperäiseen kysymykseen: on paljon todennäköisempää, että projektin lopullinen kesto tuplaantuu tai triplaantuu tai vaikkapa kymmenkertaistuu arvioidusta, kun projektiin lähdettäessä on epävarmaa, mitä pitää tehdä, ja tämä selviää vasta palautesyklin kautta softaa kehitettäessä.
Jos taas mahdolliset virheet ovat niin kriittisiä että ne on ehdottomasti vältettävä, projekti vaatii valtavan määrän suunnittelua, ja sehän maksaa. Useimmat softaprojektit eivät ole sellaisia. Siksi esimerkiksi varastonhallintajärjestelmiä tai mobiili-dashboardeja koodataan iteratiivisesti.
Toki kannattaa miettiä myös, voiko iteraatiokierrosten määrää vähentää käyttämällä erityisen hyviä devaajia. Vastaus on kyllä!
Lue myös: