Kaikkien tuntema Facebook on luonut käyttäjilleen merkityksellisen palvelun, joka skaalautuu massiivisiin käyttäjämääriin, pystyy edelleen säännöllisesti innovoimaan ja tuottamaan uusia ominaisuuksia takoen ohessa sievoisen tuloksen. Miten tämä on onnistunut ja mitä mekin voimme oppia siitä?
Tutustuin taannoin Kent Beckin esitykseen Facebookin tuotekehitysprosessista. Yhtenä keskeisenä havaintona oli, että kaaottiselta näyttävä ohjelmistokehitysprosessi muodostuikin kolmesta luonteeltaan erilaisesta tuotekehitysvaiheesta. Projektit noudattavat kypsyysasteensa mukaan kerrallaan yhtä niistä. Menestyvä idea kulkee lopulta koko polun läpi ja kestämättömät ideat tippuvat pois mahdollisimman nopeasti. Tästä hahmottui 3X-malli:
- eXplore: tutkimusvaiheessa tehdään paljon pieniä kokeiluja, joiden tavoitteena on löytää monien hullujenkin ideoiden joukosta merkittävä läpimurto
- eXpand: kun suosittu idea lähtee rakettimaiseen kasvuun, keskitytään ratkomaan mm. skaalausongelmia kaikin mahdollisin keinoin
- eXtract: lopuksi toimivaksi todistetusta ideasta otetaan hyöty irti hallitusti pienellä riskillä optimoiden sekä ylläpidetään kykyä jatkaa tuotteen kehittämistä maksamalla teknistä velkaa ja kehittämällä infraa
Jokaisella vaiheella on omat periaatteensa, jotka eroavat niin projektinhallinnan, ohjelmistokehitysmenetelmien, rahoituksen kuin henkilöstön osaamistarpeiden osalta. Kokonaisuutena toimiva ketju on hallittava tarkasti. Noudattamalla vääriä periaatteita väärässä vaiheessa ajautuu nopeasti pulaan.
Mutta emme ole Facebook
Harvalla organisaatiolla on resursseja noudattaa Facebookin esimerkkiä tehdä ensin nopeasti ja korjata vahingot myöhemmin. Nopeasti kyhätyn koodin ylläpito on kallista ja saattaa kärjistyessään jopa estää jatkokehityksen. Rajallisten resurssien tehokas käyttö edellyttää, että kulloisenkin ohjelmistotuotteen tarpeet tunnistetaan oikein.
Siinä missä täysin uusi tuote voi hakea alussa suuntaa monien nopeiden kokeilujen siivittämänä, kriittinen ja pitkään käytössä ollut tuote edellyttää harkitumpaa kehitystä. Oikean lähestymistavan löytää vastaamalla kysymykseen, paljonko on menetettävää: riskittömiä ja edullisia kokeiluja voi tehdä useita kun taas kalliiseen ja vaikeasti korjattavaan mokaan ei ole välttämättä varaa kertaakaan.
Kohti onnistuneita ohjelmistoprojekteja
Onnistunut lopputulos saavutetaan käyttäen harkitusti kulloinkin sopivia menetelmiä. Yksi ja sama prosessi ei ole paras jokaiseen kehitysvaiheeseen ja niukat ohjelmistokehitysresurssit kannattaa kohdentaa viisaasti.
Alussa tarpeettoman raskas kehitysprosessi hidastaa kypsymättömän idean kehitystä liikaa. Kenties tällöin onkin paras toteuttaa aluksi ongelmakenttää tutkiva projekti. Sen avulla usein saadaan kiteytettyä ongelmaa, löydetään alustavia ratkaisuja havaittuihin ongelmiin, käyttäjien tarpeisiin ja toimintaympäristöön sekä luodaan raamit kokonaiskehitykselle.
Toisaalta varsinkin vuosikymmeniä palvelevan sovelluksen kehittäminen on tärkeä tehdä alusta lähtien laadukkaasti, jotta ei ajauduta ongelmiin jatkokehityksessä. Muutokset niin liiketoiminnan, ympäristön kuin käyttäjien tarpeissa asettavat vaatimuksia pitkän elinkaaren tuotteelle ja siksi sen on oltava jatkuvasti kehitettävissä. Tuotekehityksen kustannuksista lähes kaksi kolmasosaa on todettu kertyvän ylläpidosta ja tästä yli puolet kuluu uusien ominaisuuksien kehittämiseen.
Monadilla uskomme, että ohjelmistoa voidaan kehittää hallitusti pienissä paloissa, jolloin se on keskeneräisenäkin aina valmiina. Laadukas ohjelmisto tuottaa arvoa pitkään, kun se tehdään kestävän ohjelmistokehityksen periaatteita noudattaen.
Ajankohtaista
