Blogi

Minimum Viable Product – pilko, opi ja hyödynnä

Tämä on toinen osa blogisarjaa, jossa pureudutaan aiheeseen ”Aikataulutus ketterässä projektissa: milloin tämä on valmis?” Jokainen osa esittelee yhden edellytyksen ketterälle aikataulutukselle. Tässä kirjoituksessa käsitellään Lean Startup -metodologian kautta pinnalle noussutta Minimum Viable Product (MVP) -mallia, jota voi ajatuksen tasolla hyödyntää myös yleisemmin kuin pelkästään ohjelmistokehitysprojekteissa.

MVP:n tarkoitus on validoida oletuksia oikeilla asiakkailla tekemällä mahdollisimman suppea tietyn tarpeen kokonaisuudessaan kattava järjestelmä. Kyseessä on enemmän oppimiskokemus kuin tuote, josta oikeasti halutaan sellaisenaan hyötyä. Tämä ajatusmalli on lähellä monissa ketterissä menetelmissä keskiössä olevaa iteratiivista ja inkrementaalista mallia, jonka mukaan ohjelmistot rakennetaan pienissä osissa vähitellen, ja iteraatio iteraatiolta järjestelmästä tulee valmiimpi. Molemmat vähentävät riskiä siitä, että tehdään vääriä asioita liian pitkään.

Vaikka MVP on ensimmäinen prototyyppi, pilottitoteutuksen kaltainen tuotos, jonka tarkoituksena on kerätä tietoa, se on kuitenkin kokonainen, tuotantokelpoinen, ehjä ja laadukas kokonaisuus. Se ei siis ole keskeneräinen raakile, beta-laatuinen tai roskiin heitettävä proof-of-concept -toteutus, vaan lähtökohtaisesti maksimaalista arvoa tuottava ja minimaalisella panoksella tehty.

Analogiaa voi yleistää ohjelmistokehityksen ulkopuolelle, mutta monissa yhteyksissä ajatusmallilla on rajoitteensa. Siinä missä startup voi pyöräyttää muutamassa viikossa tai kuukaudessa tuotteen, joita innokkaimmat käyttäjät voivat kokeilla, monet IT-projektit kattavat niin laajoja kokonaisuuksia, että vastaavaan ei ole mahdollisuuksia. Välillä MVP saattaa olla koko suunniteltu projektin lopputuotos, eikä siitä ole irrotettavissa osia, jotka eivät olisi oleellisia kokonaisuuden kannalta. Monesti kuitenkin voidaan tehdä priorisointia. Tällöin esimerkiksi kysymykset ”tarvitaanko tätä toiminnallisuutta heti aluksi?” tai ”kuinka suuri joukko ihmisiä tätä toiminnallisuutta käyttää?” voivat olla avuksi.

Otetaan esimerkiksi toimiston muutto toiseen toimitilaan. Oleellista on, että kaikki perusasiat ovat kunnossa. MVP voisi muodostua esimerkiksi siitä, että toimistolle on hankittu työpisteet ja verkkoyhteydet, ensimmäiset ihmiset voivat muuttaa ja saavat tässä minimalistisessa ympäristössä aikaan sen mitä pitääkin. Sen sijaan yhteisten tilojen sisustaminen voidaan helposti hoitaa loppuun myös jälkikäteen, ja tulostinta saattaa käyttää hyvin harva. On kuitenkin hyvä konkreettisesti sopia, mitä MVP pitää sisällään ja keskustella asiasta. Joissain organisaatioissa tulostin voi olla elintärkeä, ja se pitää olla asennettuna ensimmäisestä päivästä alkaen uudessa toimipisteessä.

MVP:n lisäksi kannattaa käyttää muita, vieläkin kevyempiä menettelyjä oppimiskokemuksien saavuttamiseksi, esimerkiksi esitellä asiakkaalle rohkeasti keskeneräisiä tuotoksia (demotilaisuus on yksi ketterien menetelmien kulmakivistä). IT-järjestelmien määrittelyt ja suunnittelut saattavat viedä huomattavan panostuksen, jopa vuosia, ja silti lopputulos jää abstraktiksi ja monitulkintaiseksi. Lopulta toteutettu järjestelmä ei välttämättä olekaan se, mitä luultiin sovitun. Monesti tekstimuotoinen kommunikointi on haastavaa. Tekemällä jokin osa järjestelmästä niin valmiiksi, että sitä voidaan käydä läpi asiakkaan kanssa, voi auttaa väärinkäsitysten välttämisessä ja tuoda konkretiaa määrittelytyöhön. Tällöin ei ole kyse varsinaisesta MVP-toteutuksesta, vaan demo-kelpoisesta tuotoksesta.

Aina ei ole mahdollista lähteä liikkeelle niin pienestä projektin osasta, että voitaisiin puhua varsinaisesta MVP:stä. MVP-ajatusta voidaan silti hyödyntää suuremmissakin järjestelmissä tuottamalla kerrallaan minimalistinen lopputulos, sisältäen tietyn osa-alueen valitut ja hyvin rajatut tavoitteet. Ketjuttamalla näitä ”MVP-toteutuksia” voidaan pilkkoa isoja kokonaisuuksia hallittavammiksi, varmistaa että kaikkein kriittisimmät osat projektia saadaan tehdyksi ajoissa ja oppia matkan varrella. Projektin tarkoituksenmukainen vaiheistus ja välituotosten käyttöönotot ovat jo erittäin hyvä alku. Oppimisen hyödyntäminen ja tilanteen tiivis uudelleenarviointi ovat kuitenkin tapoja varmistaa, että tehdään arvontuottoa maksivoivia asioita.

Monen hyvin rajatun, MVP-henkisen, pienen projektin läpivienti voi olla huomattavasti helpompaa kuin laajemman, etukäteen suunnitellun projektin — periaatteessa mitä lyhempiä kehitysjaksot ovat, sitä helpompaa toteutus on. Joissain ohjelmistoyrityksissä viedään muutoksia tuotantoon hyvin automatisoitujen menettelyjen tukemana usein, jopa päivittäin. Vastaus kysymykseen ”milloin tämä on valmis?” voi äärimmäisyyteen viedyssä ketterässä maailmassa olla ”joka päivä”.

Asiantuntijakirjoittajana Project-IT:n konsultti Miikka Lötjönen

Jaa artikkeli:

Lataa IT-ostamisen ABC -opas!

Asiantuntijoiden kanssa yhteistyössä kirjoitettu IT-ostamisen ABC pitää sisällään paljon käytännönläheisiä ohjeita IT-ostamiseen.

  • Kenttä on validointitarkoituksiin ja tulee jättää koskemattomaksi.