Ohjelmistoprojektin alusta loppuun vienti on haastava ja harvoin lineaarinen tie. Laajaa keskustelua on käyty erilaisista malleista, kuten vesiputousmallista ja ketterästä ohjelmistokehittämisestä. Lisäksi niissä käytettävä hinnoittelumalli on monelle mielenkiintoinen asia. 

Moni ohjelmistohankkeen tilaaja olisi varmasti kiinnostunut kiinteästä hankehinnasta. Tässä kirjoituksessa käsittelen näitä malleja ja hinnoittelua.

Vesiputousmalli

Ohjelmistokehityksessä vesiputoukseksi kutsutaan sellaista projektimallia, jossa ratkaistava ongelma ensin määritellään, sitten suunnitellaan, ja lopulta toteutetaan ja testataan. Vesiputousmallissa määrittely ja suunnittelutyö ovat suhteellisen raskaita toimia ja vaativat runsaasti dokumentaatiota ja mahdollisesti useita kommentointikierroksia. 

Termi vesiputous viittaa siihen, että vaiheet etenevät järjestyksessä. Tämä sopi erityisesti valmistavan teollisuuden tarpeisiin vielä Internetin alkuaikoina. IT-ratkaisut olivat tuolloin vielä vahvasti sidoksissa fyysisiin tuotteisiin, ja verkon yli tehtävät päivitykset eivät olleet vielä tavallisia.

Ketterät menetelmät

2000-luvun alkupuolella Internetiin alkoi ilmestymään ensimmäisiä web-sovelluksia ja puhelimiin tuli datayhteydet. Tällöin alkoi nousta uusia menetelmiä, jotka poikkesivat olennaisesti vesiputousmallista. Niistä alettiin käyttää nimitystä ketterät menetelmät. 

Menetelmiä oli useita erilaisia, mutta kaikkia niitä yhdisti ajatus siitä, että ratkaisua ei  tarvinnut suunnitella etukäteen kokonaisuudessaan, vaan niissä keskityttiin luomaan arvoa ja saamaan palautetta nopealla syklillä. Menetelmistä tunnetuin on todennäköisesti Scrum-viitekehys, jossa kehitystyötä tehdään muutaman viikon pituisissa jaksoissa, eli sprinteissä. Menetelmän tavoite on saada inkrementaalinen parannus edelliseen versioon.

Eri tarpeisiin eri menetelmät

Vesiputousmalli soveltuu sellaisiin tilanteisiin, jossa tavoite on selkeä ja teknologia ymmärretään syvällisesti. Lisäksi malli hyödyttää eniten sellaisia tilanteita, joissa projektin laajuus ja tiimi ovat kooltaan pieniä ja projektin riskit ovat erittäin minimaalisia. 

Kuten arvata saattaa, tällaisia tilanteita on ohjelmistoprojekteissa vain harvoin ja siksi ketterät menetelmät ovat huomattavasti yleisempiä. 

Meille kuitenkin on tärkeintä se, että valittu projektimalli on selkeä sinun yrityksellesi, asiantuntijoille ja tilanteeseen sopiva.

Budjetointi

Ohjelmistokehitysprojektit ovat herkempiä monenlaisille epävarmuuksille ja budjettiriskille moneen muuhun toimialaan verrattuna. Koska ohjelmistoprojekti on investointi, sen kannattavuus on arvioitava ennen projektiin ryhtymistä. 

Miten sitten kannattaa laatia budjetti ohjelmistoprojektille, jos vesiputousmallissa tehtävä määrittely on työläs ja ketterässä menetelmässä kokonaisuutta ei suunnitella etukäteen? Onko asiakas-arvoa edes mahdollista arvioida näkemättä lopullista palvelua?

Yksi tapa arvioida projektin lopputulosta ja siitä saavutettavaa arvoa on luoda konsepti tai prototyyppi idean perusteella. Tämä tuo idealle lisää konkretiaa ja luo paremmat edellytykset budjetin arvioimiselle. 

Olemme auttaneet asiakkaitamme tämän kaltaisissa asioissa. Olemme järjestäneet työpajoja ja käyttäjähaastatteluita, joiden avulla ideasta on mahdollista jalostaa ihmisläheinen ja miellyttävä konsepti. Näin on mahdollista hahmottaa, mihin projektissa tähtäät ja millainen on budjetin suuruusluokka.

Hinnoittelu

Ketterässä projektissa hinnoittelu on tyypillisesti aikaperusteinen, jolloin sprintin kustannus ja siitä saatava tuotos on etukäteen tiedossa. Projektin aikana tiimin kokoa on mahdollista muuttaa, mikä tarkoittaa sitä, että kustannuksiin säilyy kontrolli koko projektin ajan. 

Ketterässä projektissa kiinteään hintaan on täten mahdollista päästä, vaikka siihen liittyy epäkohtia. Projektin laajuus ja hinta eivät ketterässä projektimallissa pysty olemaan yhtä aikaa kiinteitä, koska reaalimaailmaan liittyy aina epävarmuutta. Jommankumman tai molempien tekijöiden on joustettava.

Toisin sanoen kysymys siitä, miten ketterä ohjelmistoprojekti tehdään kiinteään hintaan, olisi hyvän lopputuloksen kannalta mielekkäämpi muotoilla: miten päästä mahdollisimman lähelle tavoitetilaa ja tavoitebudjettia. Tästä aiheesta joskus lisää toisessa tarinassa.