Aiemmassa onnistuneen ohjelmistoprojektin edellytyksiä käsittelevässä tekstissä kerroimme, että myös puutteellinen testaamiseen käytetty aika voi estää ohjelmistoprojektin onnistumisen. Jotta ohjelmiston tärkeimpiä toiminnallisuuksia voidaan testata kaupallisesti, täytyy olla selvillä, mitä ohjelmistolta toivotaan. Toivomusten mukaiset vaatimusmäärittelyt auttavat projektin ideasta eteenpäin.
Prototyyppi on näytekappale tuotteesta. Sen paras piirre on realismi, jonka avulla saadaan suuntaviivoja jatkokehitykselle. Prototyyppejä voi tehdä useampia eri vaihtoehtoja suhteellisen pienellä budjetilla ja lyhyessä ajassa. Ne ovatkin kustannustehokkaita työkaluja koko ohjelmistokehitysprosessin kannalta.
Minimum Viable Product (myöhemmin MVP) on samankaltainen kuin prototyyppi, mutta sen näkökulma on erilainen. MVP keskittyy enemmän tuotantoprosessiin ja markkinoihin, prototyyppi vain tuotteeseen. MVP on “viable” eli käytännössä toimiva tuote, kun taas prototyypin ei välttämättä tarvitse olla.
Ennen kuin uhrataan valtavasti resursseja uuden ohjelmiston kehitykseen, alkuperäistä visiota kannattaa testata ja katsoa kriittisesti. Palveleeko ohjelmisto tarkoitustaan, onko sille kysyntää? Kiinnostuvatko sijoittajat ja muut tärkeät kohderyhmät ohjelmiston lisäarvosta?
Minimum Viable Product on tullut käsitteenä tunnetuksi liike-elämän ja ohjelmistokehityksen parista. Esimerkiksi Lean Startup -metodin mukaan startupin olisi hyvä lähteä liikkeelle tuotteesta, joka toteuttaa MVP:n tunnuspiirteet. MVP-malli soveltuu erityisesti startupeihin, sillä niissä pyritään luomaan jotain mullistavaa ja erilaista. Esimerkiksi täysin uusi tuote tai palvelu, joka tulisi pystyä myymään sekä sijoittajille että loppuasiakkaille, kannattaa toteuttaa ensin MVP:nä.
MVP:n idea on nopea oppiminen: virheistä pyritään palautumaan nopeasti, ja jokainen käyttötilanteesta saatu palaute synnyttää uuden oppimissyklin. Ideana on myös karsia pois ali- ja ylikehittäminen, millä pyritään tuotannon optimointiin. Tämän kaiken valossa voidaan ajatella, että MVP on myös tuotekehitysprosessi, ei pelkkä tuote.
MVP-mallin tarkoitus on toteuttaa tuote sellaisena versiona, jossa kaikki tärkeimmät ominaisuudet ovat täydessä potentiaalissa, vaikka kokonaisuus on joiltain osin vajaa. Alla oleva kuva visualisoi mallia helpon esimerkin avulla.
1. Ensimmäinen rivi ei ole MVP-mallin mukainen. MVP-mallissa tuotetta ei rakenneta kehittämällä erillisiä osioita ja kokoamalla ne yhteen.
2. Toisen rivin MVP-malliin kuuluu, että ensin hahmotetaan tuotteen käyttötarkoitus, ja sen perusteella rakennetaan yksinkertainen, toimiva kokonaisuus. Toisen rivin työnkulku kelpaa MVP-malliksi, jos minimivaatimus on saada suojaa pään päälle. Ongelman määritys ratkaisee kuitenkin MVP:n työnkulun: jos halutaan talo, jonka minimivaatimuksiin kuuluu esim. neljä seinää ja kulmikas katto, silloin maja, teltta ja asuntovaunu eivät voi olla tuotteen MVP-malleja.
3. Alin rivi kuvaa tässä tapauksessa toteutusta hieman tarkemmin: tehdään aluksi talo, joka toteuttaa minimivaatimukset. Välivaiheet ovat kukin MVP-malleja, joiden avulla kerätään palautetta käyttäjiltä ja markkinoilta. Palautteen, oppimisen ja ominaisuuksien optimoinnin seurauksena syntyy tyylitelty, käyttäjien tarpeita vastaava ja ominaisuuksiltaan mainio talo.
MVP-mallia ja prototyyppejä voidaan käyttää samojen projektien yhteydessä, jolloin molemmista voidaan hyötyä. Ne eivät siis sulje toisiaan pois. Prototyyppi voi olla todella nopea tehdä, ja se on useimmiten välttämättömyys, jotta projekti etenee.
Pienemmissä ohjelmistoprojekteissa pelkkä prototyypin teko voi riittää, jos budjettiin ei sovi markkinatestaus tai sitä ei koeta tarpeelliseksi. Erityisesti suuremmissa projekteissa MVP:llä voi kuitenkin hurmata kuluttajat ja sijoittajat paremmin, sillä se toimii myös käytännössä selkeämmin kuin prototyyppi.
Toki Minimum Viable Product kuluttaa resursseja, mutta usein se on projektin kannalta järkevä panostus. Parhaassa tapauksessa MVP minimoi ohjelmistokehityksen kokonaiskustannuksia, ja tuote saadaan nopeammin markkinoille. Jos huomataan, että MVP ei toteuta tavoitteita, ei olla hukattu kaikkia resursseja toimimattomaan ohjelmistoon tai tuotteeseen.
Lähteet, joita hyödynsimme tässä blogitekstissä:
Douglas S. (2018). What’s the difference between a prototype and an MVP? Viitattu 28.9.2018.
Haapahovi, S. (2017) Mikä on MVP eli Minimum Viable Product? Viitattu 28.9.2018.
Duarte, A. (2016) 6 steps to plan and develop a successful MVP. Viitattu 28.9.2018.
Smith, C. (2016) 8 types of MVP Experiments. Viitattu 28.9.2018.
Duc A.N., Abrahamsson P. (2016) Minimum Viable Product or Multiple Facet Product? The Role of MVP in Software Startups. In: Sharp H., Hall T. (eds) Agile Processes, in Software Engineering, and Extreme Programming. XP 2016. Lecture Notes in Business Information Processing, vol 251. Springer, Cham.
