Vesiputousmalli
Ohjelmistokehityksessä vesiputoukseksi kutsutaan projektimallia, jossa ratkaistava ongelma ensin määritellään, tämän jälkeen ratkaisu suunnitellaan, ja lopulta toteutetaan ja testataan. Vesiputousmallissa määrittely ja suunnittelutyö ovat suhteellisen raskaita toimia ja vaativat suurta määrää dokumentaatiota ja mahdollisesti useita kommenttikierroksia. Termi vesiputous viittaa siihen, että vaiheet etenevät järjestyksessä, mikä sopi valmistavan teollisuuden tarpeisiin luontevasti vielä Internetin alkuaikoina. IT-ratkaisut olivat tuolloin tyypillisesti vahvasti sidoksissa fyysisiin tuotteisiin ja eivätkä verkon yli tehtävät päivitykset olleet tavallisia.
Ketterät menetelmät
2000-luvun alkupuolelle tultaessa, kun Internettiin alkoi ilmestyä ensimmäisiä web-sovelluksia ja puhelimiin tuli datayhteydet, alkoi nousta uusia menetelmiä, jotka poikkesivat oleellisesti vesiputousmallista. Näistä alettiin käyttää nimitystä ketterät menetelmät. Menetelmiä oli useita, mutta kaikkia niitä yhdisti ajatus, että ratkaisua ei tarvinnut suunnitella etukäteen kokonaisuudessaan, vaan niissä keskityttiin luomaan arvoa ja saamaan palautetta nopealla syklillä. Näistä tunnetuin lienee Scrum-viitekehys, jossa kehitystyötä tehdään muutaman viikon pituisissa jaksoissa, joita kutsutaan sprinteiksi, tavoitteena saada inkrementaalinen parannus edelliseen versioon.
Millainen malli soveltuu minun tarpeisiini
Vesiputousmalli soveltuu tilanteisiin, jossa tavoite on selkeä, ratkaisu ja teknologia ymmärretään syvällisesti, laajuus ja tiimi ovat kooltaan pieniä ja projektin riskit ovat erittäin pienet. Kuten arvata saattaa, tällaisia tilanteita on ohjelmistoprojekteissa vain harvoin ja siksi ketterät menetelmät ovat huomattavasti yleisempiä. Meille tärkeintä on, että valittu projektimalli on selkeä sinulle ja asiantuntijoille ja lisäksi tilanteeseen sopiva.
Budjetointi
Ohjelmistokehitysprojektit ovat moneen muuhun toimialaan verrattuna herkempiä monenlaisille epävarmuuksille ja budjettiriskille. Koska ohjelmistoprojekti on investointi, tulee sen kannattavuus arvioida ennen projektiin ryhtymistä. Miten sitten laatia budjetti ohjelmistoprojektille, jos kerran 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?
Eräs tapa arvioida projektin lopputulosta ja siitä saatavaa arvoa on luoda konsepti tai prototyyppi idean perusteella. Tämä tuo idealle lisää konkretiaa ja luo paremmat edellytykset myös budjetin arvioimiselle. Olemme auttaneet asiakkaitamme tämän kaltaisissa asioissa järjestämällä 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 käsität budjetin suuruusluokan.
Hinnoittelu
Ketterässä projektissa hinnoittelu on tyypillisesti aikaperustainen, jolloin sprintin kustannus ja siitä saatava tuotos on etukäteen tiedossa. Projektin aikana tiimin kokoa on mahdollista muuttaa, mikä tarkoittaa, että kustannuksiin säilyy kontrolli koko projektin ajan. Ketterässä projektissa kiinteään hintaan on siis mahdollista päästä vaikkakin siihen liittyy eräs probleema. 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 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.