Mikä on MVP (Minimum Viable Product)?
Ketterä kehittäminen vilisee erilaisia lyhenteitä, joiden merkitys ei välttämättä aukea ulkopuolisille. Ymmärtämistä ei auta, että lyhenteet ovat alkukirjaimia asian englanninkielisistä sanoista, ja että eri organisaatiot käyttävät termejä eri merkityksillä.
MVP eli Minimum Viable Product, suomennettuna pienin toimiva tuote, on malliesimerkki termistä, joka ymmärretään eri tavoin, mutta erikoisuutena joihinkin muihin lyhenteisiin, siihen on liitetty myös paljon myyttejä ja harhaluuloja: halvin mahdollinen versio, huonolaatuinen, beta-versio, hyödytön, toimii vain startupeille, projektin karsittu sisältö, jne. Ja kun nämä esimerkit saavat valtaa, kun MVP:n todellista tarkoitusta ei ole ymmärretty, niin ei mikään ihme, että eräässä organisaatiossa sen epävirallinen uudelleenlanseerattu suomennos oli ”Mitätön Vähäpätöinen Piperrys”.
Mikä ihmeen MVP?
”Aikamme suuri kysymys ei ole voiko sen rakentaa, vaan kannattaako sitä rakentaa?”
Eric Ries (Lean Startup -kirjan kirjoittaja)
Eric Riesin tunnetuksi tekemä MVP syntyi alunperin startup-maailmasta ja heidän tarpeestaan oppia asiakkaistaan, heidän haluistaan ja tarpeistaan, sekä erityisesti arvioidakseen kannattaako tuotetta ylipäätään kehittää valittua suuntaa kohti, vai onko ideoitava jotain uutta. Nykyään MVP määritelläänkin usein Riesin Lean Startup -liikkeen mukaisesti keinona oppia maksimaalisesti asiakkaista pienimmällä mahdollisella työmäärällä, mutta myös pienimpänä toimivana tuoteversiona, joka tuottaa arvoa asiakkaille.
Konkreettiset versiot, joista eri organisaatiot ja tiimit puhuvat MVP:inä, voivat olla hyvin erilaisia, esimerkkeinä prototyypit, beta-/alpha-julkaisut, POC:t (Proof of Concept), puolilaatuinen raakile toimivasta kokonaisuudesta, yms. Onkin tärkeää keskustella auki, mitä MVP:llä tarkoitetaan ja tavoitellaan, kun aletaan työstämään MVP:tä konkreettisesti. Hyvä ohjenuora MVP:lle on keskittyä löytämään pienin elinkelpoinen tuote, jolla validoidaan tehtyjä oletuksia ja tunnistettuja riskejä, sekä saadaan tietoa asiakkaista. Ei siis riitä, että löydetään jokin toteutettavissa oleva parin toiminnallisuuden ratkaisu, jos se ei anna tietoa edellä mainituista asioista.
Hyviä esimerkkejä rohkeasta kokeilusta, prototyypeistä ja MVP:n hyödyntämisestä löytyy vuonna 2013 perustetun Ocean Cleanup:n historiasta, joka alkoi yhden nuoren kysymyksestä ”miksi emme voisi siivota valtameriä muoviroskasta?”. Kouluprojektia varten tehdyistä pienistä kokeiluista on vuosien varrella siirrytty tutkimuksista ja prototyypeistä ensimmäisiin avomerellä ja jokien suistoissa käyttöönotettuihin MVP:ihin, joissa muovi keräämisen jälkeen viedään uusiokäytettäväksi. Eri kehitysversioista saatua tietoa on hyödynnetty ratkaisujen parantamisessa ja tällä hetkellä projekti on siivonnut meristä jo yli 9 miljoonaa kiloa muovia pois.
”Emme me tarvitse MVP:tä, emme ole mikään startup”
Vaikka MVP onkin syntynyt startup-maailmasta, on sen taustalta löytyvää ajattelutapaa arvokasta hyödyntää myös laajemmin. Miten validoimme oletuksiamme ja taklaamme kehitystyön pahimpia riskejä? Jos uskomme, että jokin asia on tärkeä ja hyödyllinen kehittää, miten voimme validoida tämän uskon? Mikä olisi minimiratkaisu, jolla saamme tietoa kannattaako ideaa kehittää pidemmälle? Parhaimmassa tilanteessa organisaatiot voivat säästää paljon kehitystiimiensä aikaa ja budjettia, kun pahimmat riskit ja väärät oletukset on saatu jo alkuvaiheessa päivänvaloon ja seuraavat askeleet voidaan suunnitella aidon tiedon eikä oletusten pohjalta.
MVP projekteissa
Projekteissa ketteryyden ja MVP:n hyödyntämisen mahdollisuuksia raamittaa usein budjetti, aikataulu sekä sisältö, joka voi vaihdella laajoista, tarkoista vaatimuksista puhtaasti tavoitteilla ohjattuun malliin, tai olla mitä vain näiden kahden väliltä. Mitä jäykemmin matkan aikana opittuihin uusiin tarpeisiin ja alkuperäisen askelkartan muutoksiin suhtaudutaan, sitä huonommin MVP soveltuu projektien käyttöön. Mutta jos kaikkia raameja, ja etenkään sisältöä, ei ole hakattu kiveen, ja tekemistä ohjataan tavoitteiden ja toivottujen hyötyjen kautta, MVP ja ketterä toimintamalli voi parhaimmillaan auttaa projekteja saavuttamaan tavoitteensa oletettua aiemmin ja/tai luomaan ratkaisusta parempi kuin mitä alun perin osattiin edes ajatella.
MVP:n summa summarum
Palataan hetkeksi takaisin harhoihin ja myytteihin. Vaikka MVP onkin pienin mahdollinen versio tuotteesta, ja sen vuoksi todennäköisesti halvempi kuin loppuun asti täyteen potentiaaliinsa kehitetty versio, sen tärkein kriteeri ei pitäisi olla hinta. Mahdollisimman halvalla tehty on usein puolittaisella laadulla kiireellä tehty ratkaisu, ja pienuudestaan huolimatta MVP:n on oltava laadukas ja tuotava arvoa käyttäjilleen ja erityisesti oppia kehittäjilleen.
Onnistunut ja laadukas ketterä kehittäminen on mahdollista, kun annetaan työntekijöille mahdollisuus miettiä mitä olemme tavoittelemassa ja tarjotaan mahdollisuus kokeilla ja oppia tehokkain reitti tavoitteiden saavuttamiseksi. Jos haluat parantaa omaa tai organisaatiosi ymmärrystä ja taitoja ketteryydestä, tutustu laajaan koulutustarjontaamme.
Syvenny aiheeseen Tieturin koulutuksissa
- Product owner I (PO I)
- Hyvän käyttäjätarinan luominen
- Kehitysjonojen (Backlog) hallinta
- Ketterä määrittely
- Kompleksisen ongelman ratkaisu
- Scrum Master I (SM I)
- Leading Agile Hardware
- Ketterä projekti – agile projektijohtaminen
- SAFe Product Owner/Product Manager with POPM Certification
- Liiketoimintaprosessien kehittäminen
- Asiakasymmärrys palvelumuotoilussa
- Palvelumuotoilun perusteet
- Kanban perusteet
Tuuli Pesonen
Seniorikonsultti
Tuuli on ketteryyden syväosaaja ja Scrumin, LeSS:n ja SAFen sertifioitu asiantuntija. Hän on työskennellyt useissa organisaatioissa monenlaisten tiimien kanssa. Tuulille on erityisen tärkeää yhteistyö, tavoitteellisuus sekä jatkuva parantaminen ja oppiminen, sillä ketteryyttä voidaan suorittaa mekaanisesti pahimmillaan vuosikausia ilman, että päästään aidosti tuottamaan arvoa ketterästi.
