Räätälöidyn ohjelmiston hankinnassa on hyvä pohtia, mitä oikein ollaan ostamassa. Kiinteähintaista, vaiko sellaista ohjelmistoa, jonka tuottamia arvovirtoja voidaan maksimoida, kuitenkin ennakkoon tarkasti tiedetyin kustannuksin? Tätä kutsutaan ketteräksi kehitykseksi.
Ensimmäistä, perinteistä kiinteähintaista sovellusta hankittaessa ajaudutaan helposti määrittelemään sovelluksen ominaisuudet etukäteen tarkasti. Siten ei voida varautua muutoksiin, joita välttämättä tulee esiin kehitysprojektien yhteydessä, kun vaatimukset syystä tai toisesta muuttuvatkin. Tässä blogiartikkelissa pääset lukemaan ketterän ohjelmistokehityksen arvontuotosta ja siitä, miten lasket sen.
Ketterä ohjelmistokehitys vs perinteinen ohjelmistokehitys
Ketterä malli
Ketterässä mallissa ostaja yhdessä viitekehysryhmiensä kanssa hyödyntää liiketoimintansa tuntemusta ja hahmottaa tuotteelle kehitysjonon, jossa listataan arvojärjestyksessä ne tuotteen ominaisuudet ja vaatimukset, jotka tuovat eniten lisäarvoa liiketoiminnalle. Kehitystyö tehdään ostajan edellyttämässä arvojärjestyksessä, ja tätä järjestystä muutetaan tarvittaessa esiin tulleiden uusien arvojen myötä. Kuulostaako haastavalta? Sitä se ei välttämättä ole, jos ostaja tietää mitä haluaa.
Nykyaikaisessa ketterässä kehityksessä voidaan rakennettavan ohjelmiston tekeminen pilkkoa osaaville Scrum-tiimeille sekä ohjata ja seurata ohjelmistoprojektin etenemistä lähes reaaliajassa. Tällöin liiketoimintakriittisiä päätöksiä pystyy tekemään nopeasti, mikäli liiketoiminnan tarpeet muuttuvat kesken kehitysprojektin.
Perinteinen malli
Perinteisessä mallissa tuotteen mukauttaminen ei ole joutuisaa, vaan ominaisuuden rakentamisen keskeyttämisestä tai korvaamisesta on neuvoteltava sopimusmuutoksin. Ketterässä mallissa taas turhat osat poistetaan kehitysjonosta ja jatketaan arvokkaimpien tekemistä.
Scrum-mallin edut
Scrum-kehitysmallin suuri etu on, että ostaja tietää etukäteen, paljonko tuotekehitys tulee maksamaan. Lisäksi projektin tuotoksena saadaan juuri eniten liiketoiminnalle arvoa tuottavia ominaisuuksia. Liiketoiminta-arvo verifioidaan jokaisen kehityssyklin yhteydessä ja tarvittaessa suuntaa muutetaan asiakkaan valitsemaan suuntaan. Siten ohjelmisto saadaan nopeammin käyttöön, kun jokaisen kehityssyklin uudet tuotokset otetaan testattaviksi sitä mukaa, kun ne valmistuvat. Vähemmän tärkeät ominaisuudet seuraavat myöhemmissä sykleissä.
Miten tuotteen hinnan voi tietää etukäteen?
Käytännössä ohjelmistokehitykseen varataan budjetti ja valjastetaan avuksi sopivankokoinen tiimi, jonka kuukausikustannukset ovat tarkasti tiedossa. Kulut ovat siis täysin selvillä alusta alkaen.
Mutta sitten tulee se mutta - nimittäin sen sijaan, että kysyttäisiin mitä tuote meille maksaa, kysytäänkin mitä se tuottaa.
Jokaisen tuotteeseen rakennettavan ominaisuuden kohdalla lasketaan siis arvoa. Tuottaako tämä ominaisuus meille enemmän kuin se maksaa, tai maksaako tämän ominaisuuden tekemättä jättäminen yrityksellemme enemmän kuin se kustantaa? Entä millä aikataululla ominaisuus kannattaa tehdä?
Miten arvo sitten lasketaan?
Jos lasketaan vain yhtä arvoa, kannattaa selvittää, paljonko ominaisuuden viivästyminen maksaa (CoD = Arvo / Kesto). Alla esimerkki laskentatavasta:
Taulukon alaosassa ovat vastaavasti ominaisuudet 4-6, joiden kaikkien tekemiseen menee 3 viikkoa. Näistä ensimmäisenä tehtäisiin eniten arvoa tuottava ominaisuus, jolloin kolmen viikon päästä jäljelle jää enää kaksi vähempiarvoista tehtävää.Taulukon yläosassa ominaisuuksien 1-3 tekeminen kestää 3-5 viikkoa. Jokainen ominaisuus on tonnin arvoinen. Tällöin näistä kolmesta samanarvoisesta kannattaa tehdä ensin nopeimmin toteutettavissa oleva ominaisuus eli 1, jolloin kyseisen ominaisuuden arvontuotto alkaa jo kolmen viikon päästä.
Koska toisen taulukon arvot ovat samanmittaisia ja toisessa taulukossa kestot, on näiden keskinäinen tärkeysjärjestys laskettavissa kaavalla (Painotettu = CoD / Aika ). Mikäli kaikkia tehtäviä verrataan toisiinsa, havaitaan että näistä kaikista kuudesta tehtävästä ominaisuus 4 on ensimmäisenä toteutettava ja ominaisuus 3 jää viimeiseksi.
Toteutettavan tuotteen on oltava jokaisen uuden inkrementin jälkeen käyttökelpoinen ja sen on tuotettava lisäarvoa. Tämä tarkoittaa, että ostaja saa jatkuvasti uusia versioita ja lisää ominaisuuksia jo projektin alkuvaiheessa ja pääsee hyödyntämään näiden tuomaa arvonlisää jo alusta alkaen.
Haluatko lisätietoja?
Käyttämällä tässä artikkelissa esitettyä laskentatapaa, ohjelmiston kehityksessä voidaan valita etusijalle juuri ne ominaisuudet, joista syntyy suurin arvontuotto jo projektin alkuvaiheessa. Näin ketterän mallin mukaisesti arvokkaat osat saadaan heti käyttöön ja tuottamaan arvoa, kun perinteisessä vesiputousmallisessa projektissa vielä koodattaisiin ohjelmistoa miettimättä lainkaan, onko tehtävällä toiminnolla mitään arvoa enää käyttöönottovaiheessa.
Mikäli haluat kuulla lisää, otathan rohkeasti yhteyttä meihin. Käy myös tutustumassa taidonnäytteisiimme sekä tietopankkiimme! Tietopankista löydät maksuttomia asiantuntijamateriaalejamme.
