Se kuuluisa agile-menetelmien timantti MVP, eli Minimum Viable Product, eli tiukin mahdollinen scope, jolla tuotamme eniten arvoa loppukäyttäjälle nopeasti. Miten vaikeaa sen määritteleminen usein onkaan!
Vähän tekisi aina mieli lisätä sitä ja tätä jo MVP-vaiheeseen, kun kaikki mahdollisuudet ovat niin ihania ja houkuttelevia sekä monta kättä ojossa odottamassa. Juurisyy tälle saattaa olla se, että monessa organisaatiossa on ajauduttu viskaisemaan jonkinlainen MVP tuotekehitysputkesta ulos ja unohdettu sitten sen jatkokehitys, joten kaikki on saatava heti, jos jotain joskus haluaa.
Tässä muutama neuvo, joilla pääset liikkeelle MVP scopen rajaamisessa:
1.) Rajaa scope perustuen arvon ja ajan suhteeseen
Usein MVP:n rajaamisessa päädytään ikäviin ja arvolatautuneisiin keskusteluihin siitä, miten kaikki asiat ovat tärkeitä. Tämä johtuu siitä, että muistetaan keskustella vain käyttäjille tuotetusta arvosta, eikä arvosta suhteessa siihen käytettyyn aikaan.
Jos käytät MVP:tä oikein, keskity nimenomaan arvon ja ajan suhteeseen, jotta voit tuottaa edes jollekin arvoa kohtuullisen nopeasti.
Joku idea voi olla itsessään arvokas, mutta jos sen tekeminen kestää kuukausia tai vuosia, suhteellinen arvo vähenee ja maailma ehtii muuttua. Julkaisematon koodi yrityksesi pöytälaatikossa ei tuota kenellekään mitään, oli se sitten kuinka timanttista hyvänsä. Julkaisematon koodi on pelkästään iso kuluerä.
2.) MVP:n rajaaminen käyttäjäryhmän perusteella
Mietitään seuraavaksi kehitystä ohjaavan käyttäjätarinan (englanniksi user story) rakennetta, joka perustuu kuka, mitä, miksi -rakenteeseen.
Esimerkiksi:
Avainasiakaspäällikkönä haluan saada tietoa jälleenmyyjän tekemistä kampanjoista tuloksineen, hyödyntääkseni oppeja ja myydäkseni enemmän.
Usein rajatessa MPV scopea lähdemme luontevasti miettimään mitä-osiota, eli esimerkiksi sitä millaista dataa tämä loppukäyttäjä tarvitsee, ja voiko siitä jotain vielä karsia.
Hyvä toimiva käytäntö on kuitenkin keskittyä kuka-osioon.
Onko meillä muutama avainasiakaspäällikkö, jotka tarvitsevat tätä tietoa vielä kipeämmin kuin kukaan muu? Missä palveluissa ja liiketoiminnoissa? Voimmeko aloittaa heistä?
Kuten ensimmäisessäkin kohdassa, emme siis sano etteivät muut olisi tärkeitä, vaan että näin tuotamme arvoa kaikista nopeiten edes jollekulle.
3.) Validoi enemmän, älä aseta eurotavoitteita.
Niin kerrataan nyt vielä, mikä se MVP scope olikaan? Se on pienin toimiva tuote tai ratkaisu, jossa on vain ja ainoastaan sellaiset ominaisuudet, jotka tyydyttävät ensimmäisten asiakkaiden tärkeimmät tarpeet. Pienimmän toimivan tuotteen tarkoitus ketterässä mallissa on kerätä palautetta tuotekehitykseen.
Jos siis olet asettanut erittäin kunnianhimoisia euromääräisiä myyntitavoitteita MVP:lle, olet jo luultavasti mennyt metsään ja scopannut mukaan liikaa.
Luetaanpa tämä vielä kerran. MVP:n tavoite ei ole siis tuottaa satoja tuhansia myyntejä, vaan kerätä palautetta, jotta siihen pisteeseen päästään.
Jos siis olet asettanut erittäin kunnianhimoisia euromääräisiä myyntitavoitteita MVP:lle, olet jo luultavasti mennyt metsään ja scopannut mukaan liikaa. Toki ensimmäisiä myyntejä voi seurata indikaationa oikeasta suunnasta ja asiakkaiden kiinnostuksesta, mutta luultavasti voit rajata scopeasi lisää saadaksesi nopeampaa palautetta.
Idea siis on, että voit päättää seuraavista kehitysaskeleista tietoon perustuen etkä sokeasti fiilispohjalta. Onko MVP:si siis riittävän pieni, että saat nopeasti validoitua ideoitasi sekä kerättyä palautetta käyttäjiltä?
Voisiko MVP olla jopa prosessitesti oikeasti koodatun tuotteen sijaan.
Mietitään vaikka, että ideasi on se, että jatkossa lähetät kaupanpäällisenä jokaiselle nettikaupasta ruokakorin ostavalle asiakkaalle pehmolelupupun. Ennen kuin koodautat riviäkään, voisitko lähetellä niitä päivän manuaalisesti ja kerätä asiakkailta palautetta pupu-kokemuksesta? Vaikka ideasi olisi rutkasti isompi kuin pehmo pupu, yritä tunnistaa siitä sellaisia osioita joita voit testata samaan tapaan ja kerätä palautetta.
4.) Älä henkilöidy ideoihin ja järjestelmiin
Muista, kun keskustelet scopesta, niin aseta vastakkain ideoita ja hypoteeseja, älä ihmisiä. Jos yrityksessä on aidosti läpinäkyvä kulttuuri ja yhteiset tavoitteet, tällaista keskustelua on huomattavasti helpompi käydä.
Tarkista myös, työskenteletkö järjestelmien vai asiakasarvon eteen? Jos organisaatiosi tiimit on nimetty järjestelmien mukaan, niin voi olla vaikeampi priorisoida ajatuksia perustuen asiakasarvoon.
Tavoitteet pitäisikin pystyä näkemään ohi järjestelmien ja keskittyen asiakkaalle tuotettavaan arvoon.
Yritä kutsua pöydän ääreen samaa käyttäjäryhmää, arvovirtaa ja tarvetta palvelevia henkilöitä yli komponentti- tai järjestelmätiimien. Usein keskustelu tätä kautta on paljon vähemmän omaa tonttia suojelevampaa ja näin tuottavampaa. Vaikkei sinulla olisikaan natsoja piirtää uudestaan organisaatiokaaviota, niin voit ainakin rikkoa turhia tiimien välisiä muureja.
5.) Mieti vielä kerran, onko se sittenkään tärkeää
Ajattele, että suunnittelet pitkää viikonloppua rakkaasi kanssa. Stressaat kaikkea mahdollista ja kuinka kaiken pitää olla kohdillaan, onhan tämä laatuaika niin harvinaista. Jos kuitenkin pysähtyisit miettimään moniko sinua stressaava asia on oikeasti tärkeä, niin vastaus saattaisi yllättää. Luotko loputtomalla vaatimuslistalla onnistumista vai epäonnistumista?
Scrumin kehittäjän Jeff Suttherlandin tunnettu esimerkki tästä perustuu Microsoft Word- ohjelmaan. Kuinka montaa prosenttia sen ominaisuuksista sinä käytät oikeasti? Luultavasti erittäin pientä osaa. Jos tutkailet kaikkea mitä Wordin yläpalkista löytyy, niin oletko käyttänyt niistä koskaan edes kymmenystä? Luoko se sinulle arvoa vai vähentääkö se arvoa ja luo kompleksisuutta?
Arvioi siis myös omia ideoitasi kriittisesti. Monesti kun saat kaikista tärkeimmän tehtyä, huomaat ettei muuta enää tarvita.
Haluatko järkevämmän arjen ? Lähde muutosmatkalle kanssamme täältä