Mobiilipalvelun ostaminen ei ole yksinkertaista: vertailtavana on pelkästään Suomessa joukko erilaisia softataloja sekä erilaisia tapoja lähestyä suunnittelun ja toteutuksen budjetointia. Tämän artikkelisarjan tarkoituksena on antaa käytännön vinkkejä mobiiliprojektin ostajalle.

Tässä osassa käsittelemme hyötyjä, jotka saavutetaan jakamalla projekti osakokonaisuuksiksi eli iteraatioiksi.

Sovellusprojektin arviointi on aina epävarmaa

Jason Fried ja David Heinemeier Hansson osuvat mainiossa Rework-kirjassaan naulan kantaan toteamalla, että työrupeamien keston arvioiminen on ihmisille lähtökohtaisesti hyvin vaikeaa. Mitä isompi projekti, sitä vaikeampi on tarjota sellaisia tuntiarvioita, jotka eivät sisältäisi vahvaa arvauselementtiä.

“Kuinka usein oletkaan arvioinut, että käynti ruokakaupassa kestää muutaman minuutin ja olet lopulta jäänyt sinne tunniksi?” Fried ja Heinemeier kysyvät.

Jos emme osaa arvioida vain hetken vieviä asioita, miten voisimme kuvitella pystyvämme ennustamaan puolen vuoden projektin työmääriä?

Jokainen sovellusprojekti sisältää merkittävän määrän epävarmuutta. Emme usein alussa tiedä tarkkaan, mitä olemme rakentamassa, ja matkan varrellakin asiat muuttuvat, mukautuvat ja muovautuvat useita kertoja. Kristallipalloa tähän ei valitettavasti ole niin toteuttajalla kuin ostajallakaan. Suurinta hajontaa sivistyneissä arvauksissa on silloin, kun ollaan tekemässä täysin uutta sovellusta.

Tämä epävarmuus heijastuu myös budjetiin, mikä jättää kaksi mahdollista suhtautumistapaa: joko epävarmuus pitää hyväksyä tai sitä voi pyrkiä hallitsemaan erinäisin tavoin. Yksi tällainen tapa on jakaa sovelluskehitys iteraatioihin. Yhden iteraation sovittu tuntimäärä voi vaihdella paljonkin projektista riippuen, mutta periaate on aina se, että projekti jaetaan sellaisiin palasiin, joissa riskit ovat hyväksyttäviä, mutta joiden tuloksena on aina jotakin hyödyllistä, jonka avulla voidaan edetä seuraavaan vaiheeseen.

Iteraatiot voivat pelastaa budjettiarviosi

Iteraatioihin liittyy huomattavasti vähemmän epävarmuutta kuin sellaiseen tilanteeseen, jossa arvataan hintalappu useamman kuukauden sovellusprojektille. Jokaisella sovelluksella on jokin kokonaisbudjetti. Iteraatioiden hyöty on myös siinä, että niiden avulla kokonaisuutta voidaan viedä tietoisesti suuntaan, joka pitää tämän kokonaisbudjetin mahdollisimman hyvin aisoissa.

Vertauskuvallisesti kyse on eräänlaisesta veneen kurssin tarkistamisesta: iteraatioiden päätteeksi arvioidaan aina, miten hyvin asetetut tavoitteet on saavutettu ja tehdään tarvittaessa korjausliikkeitä arvioidessa seuraavan vaiheen sisältöä ja työmäärää. Mikäli asioita tai ominaisuuksia joudutaan tiivistämään tai karsimaan (mikä on lopputuotteen kannalta usein hyvä asia), tiivistyy fokus jokaisen “varikkokäynnin” jälkeen kunnes kokonaisuus on julkaisuvalmis.

Hyviä tapoja osittaa projekti

Minkälaisiin osiin projekti sitten kannattaa jakaa? Tämä riippuu vahvasti siitä, kuinka laaja projekti on kokonaisuudessaan ja missä vaiheessa se nykyisellään on. Kun palvelua lähdetään kehittämään puhtaalta pöydältä, voidaan usein erottaa erillisiksi iteraatioikseen määrittely, suunnittelu ja tekninen toteutus esimerkiksi yksi toteutuksen kerros tai alusta kerrallaan. Jo julkaistuun palveluun voidaan sen sijaan tehdä iteraatoina esimerkiksi toteutus uudelle alustalle tai vastaavasti jokin uusi ominaisuus tai sarja käyttöliittymäparannuksia.

Uskomme, että suuri osa sovellusprojekteista kannattaa käynnistää erillisellä suunnitteluprojektilla. Artikkelisarjan seuraavassa osassa pureudumme tarkemmin tähän ratkaisevan tärkeään kehitysvaiheeseen.

Voisit olla kiinnostunut myös näistä: