Kokeile ja erehdy -maailmassa se voittaa, joka löytää virheet nopeimmin. Jotkut kutsuvat tätä lähestymistapaa ”fail fastiksi”. Eric Ries kutsui sitä Leaniksi, kun taas Kent Beck ja muut ohjelmistokehittäjät kutsuivat sitä Ketteräksi.
Kutsuitpa sitä miksi tahansa, tarkoitus on selvittää, mitkä tuotetta koskevista oletuksista ovat vääriä, saamalla palautetta todellisilta käyttäjiltä mahdollisimman nopeasti.
Ketterä menetelmä edellyttää tuotekehityksen jakamista sprintteihin, mikä mahdollistaa riskien vähentämisen ja nopean reagoinnin tarvittaviin muutoksiin.
Koska ketterä menetelmä rakentuu asiakaspalautteeseen perustuvan iteratiivisen prosessin idean ympärille, MVP:llä on keskeinen rooli ketterässä kehityksessä.
Minimaalisen elinkelpoisen tuotteen (MVP, Minimum Viable Product) rakentaminen auttaa toimittamaan uuden tuotteen, jossa on riittävästi ominaisuuksia tyydyttämään varhaisia käyttäjiä, mikä mahdollistaa arvokkaan palautteen saamisen ja täydellisten ominaisuuksien rakentamisen myöhemmin.
MVP-konseptia käytetään useimmiten ohjelmistoteollisuudessa tuotteen elinkelpoisuuden tarkistamiseksi. Jos etsit yritystä, joka rakentaa MVP:n puolestasi, tutustu tähän ohjelmistokehitysyritykseen.
Tänä päivänä suurin osa ohjelmistoista kehitetään ketteriä menetelmiä käyttäen. Ketterässä ympäristössä kuulet usein sanonnan minimum viable product (MVP).
Tämä termi tarkoittaa yksinkertaisesti: minimaalisimmin varusteltu asia, jonka voit rakentaa ja joka vastaa tilaisuuteen riittävän hyvin suurimmalle osalle kohdeasiakkaistasi ja validoi markkinasi ja tuotteesi.
Muilla sanoilla: jos ajattelet ydintoimintoa, jonka yrität antaa asiakkaiden toteuttaa, mikä on yksinkertaisin tuote, jonka voit rakentaa ja jonka avulla asiakkaat voivat saavuttaa tämän tavoitteen?
Sitten esimerkiksi sanotaan, että olet mennyt ajassa taaksepäin ja työstät sanomalehden sovelluksen ensimmäistä versiota. Sovelluksen ydintoiminto olisi lukijakunnalle tiedottaminen. Siksi helpoin tuote, jonka voisit rakentaa, olisi lista uutisotsikoita ja painike päivittämiseen.
Jälleen kerran, avain onnistuneeseen MVP:hen on keskittyä sovelluksen tarjoamaan ydinarvoon eli tuoreisiin uutisiin sen sijaan, että käyttäisit aikaasi sovelluksen lisäominaisuuksien rakentamiseen.
Huomaa, että MVP ei tarkoita, että tuotteen pitäisi olla huono. Totuus on, että sen pitäisi olla erittäin hyvä siinä, mitä se tekee, mutta sen pitäisi keskittyä tekemään vain muutamia ydintoimintoja.
Lyhyesti sanottuna MVP:n tärkeimmät ominaisuudet ovat:
- Tuotteella on tarpeeksi arvoa, jotta ihmiset ovat halukkaita käyttämään tai ostamaan sitä aluksi
- Se osoittaa tarpeeksi tulevia hyötyjä pitääkseen varhaiset omaksujansa
- Se tarjoaa palautesilmukan, joka ohjaa tulevaa kehitystyötä
Minkä takia sinun pitäisi käyttää ketterää metodologiaa kehittäessäsi MVP:tä?
Ketterän ja muiden menetelmien keskeinen erottava tekijä on se, että Ketterä hyödyntää MVP:tä. Ketterässä lähestymistavassa rakennetaan yksinkertaisin mahdollinen tuote, kerätään tietoa siitä, miten asiakkaat käyttävät sitä, ja jalostetaan tuotetta tarvittaessa.
Siten voit työskennellä varsin tehokkaasti ja rakentaa vain ne ominaisuudet, joita asiakkaat haluavat ja käyttävät, sen sijaan että tuhlaat aikaa sellaisten asioiden rakentamiseen, joista asiakkaat eivät välitä.
Vertaa tätä muihin kuin MVP-pohjaisiin lähestymistapoihin tuotekehityksessä. Muita lähestymistapoja käytettäessä saatat päätyä käyttämään paljon aikaa yrittäessäsi rakentaa ”täydellisen” tuotteen, jossa on kaikki mahdolliset ominaisuudet, mutta kun tuote on todellisessa maailmassa, huomaat, että asiakkaat eivät käytä puoliakaan niistä ominaisuuksista, joita kuvittelit heidän käyttävän.
Tässä on esimerkki ketterästä minimi elinkelpoisesta tuotteesta (MVP, Minimum Viable Product):
Lähde: Dropbox
Drew Houston – Dropboxin toimitusjohtaja päätti luoda pilvitallennusstartupille MVP:n videon muodossa.
He tekivät selitysvideon ja jakoivat sen verkostolleen mitatakseen ihmisten reaktioita. Kolmen minuutin mittainen video selitti, mikä Dropbox on, ja osoitti, miten se auttaisi ihmisiä.
Videon julkaisemisen jälkeen yritys lisäsi yhdessä yössä ilmoittautumisia 5 000:sta ihmisestä 75 000:een ”varhaiskäyttöön” – ja kaikki tämä ilman, että sillä oli varsinaista tuotetta.
MVP:n (ketterän) rakentamisen tärkeimmät hyödyt ovat siis:
- Alustava kuluttajatutkimus
Mitä nopeammin tuote tavoittaa kohdekäyttäjän, sitä nopeammin saat palautetta ja analysoit asiakkaan haasteita tai mieltymyksiä. Jos käyttäjät eivät pidä MVP:täsi arvokkaana, sinulla on tilaa kääntyä ja testata muita arvolupauksia.
Tai jos tilanne on päinvastainen, voit olla varma, että kehitetyt ominaisuudet ovat hyödyllisiä kohdeasiakkaille, joten voit siirtyä eteenpäin. Pahimmassa tapauksessa voit jäädyttää projektin tappioiden karsimiseksi.
- Testausvaihe
MVP:n kehittämisen suurin hyöty on se, että se mahdollistaa erilaisten liiketoimintamallien ja -konseptien testaamisen.
Tarjoamalla ydintoiminnot pikemminkin kuin ominaisuuksiltaan raskaan tuotteen, voit tarkistaa, resonoiko heidän tuotekonseptinsa liiketoimintamalliin, mikä tarjoaa tilaisuuden vaihtaa tuotteen suuntaa havaintojen perusteella.
Ominaisuuspainotteisista tuotteista poiketen sinulla on MVP:n lanseerauksen jälkeen mahdollisuus tunnistaa, minkä tyyppiset sosiaaliset ryhmät ovat aktiivisimpia käyttäjiä, miten he ovat vuorovaikutuksessa tuotteen kanssa ja miten voit hyödyntää sitä rahallisesti.
- Kustannustehokkuus
Laadukkaat tuotteet ovat vuosien kehitystyön tulos, ja niillä on asianmukainen hintalappu. Mutta koska nämä tuotteet on luotu iteratiivisesti pidemmän ajan kuluessa, kustannukset jakautuvat ajallisesti.
MVP-lähestymistapa auttaa säästämään myös estämällä tuotteen muuttumisen liian monimutkaiseksi. Kun tuote alkaa saada enemmän vetovoimaa ja kerätä enemmän tietoa siitä, mihin suuntaan tuote on menossa, voit lisätä tai vähentää investointeja.
Jos olet kiinnostunut oppimaan lisää ketteristä ja SCRUM-menetelmistä, suosittelemme tutustumaan tähän SCRUM-instituutin artikkeliin, jossa kerrotaan, miten SCRUM-mestariksi tullaan yksityiskohtaisesti vaihe vaiheelta. He tarjoavat myös suosituimpia ja edullisimpia Scrum-sertifiointiohjelmia maailmanlaajuisesti.
MVP:n rakentamisprosessi (Agile)
Nyt kun tiedät, mikä on MVP, miksi sitä käytetään Agile-ohjelmissa ja mitkä ovat sen hyödyt, tarkastellaan MVP:n rakentamiseen tarvittavia 6 askelta.
Vaihe #1: Tunnista, mitä ongelmaa olet ratkaisemassa ja kenelle
Kehittäessäsi versiota uusista tuotteista useimmat ihmiset eivät ole riittävän tarkkoja määritellessään ongelmia, joita he yrittävät ratkaista, ja artikuloidessaan, miksi nämä ongelmat ovat tärkeitä. Ilman tätä prosessia tuote saattaa jättää käyttämättä mahdollisuuksia ja hukata resursseja. Siksi sinun on opittava paremmin kysymään oikeita kysymyksiä, jotta niillä puututaan oikeisiin ongelmiin.
Katsele tuoteideaasi ja kysy itseltäsi:
- Kuka on kohdeyleisösi?
Jos jäät tässä vaiheessa jumiin, yritä tunnistaa henkilökohtaiset haasteesi. Onko jotain, jonka voisit tehdä paremmin, jos sinulla olisi oikea työkalu?
- Miksi kohdeyleisösi tarvitsee tätä tuotetta?
Tämä auttaa sinua tunnistamaan tuotteesi päätavoitteen ja ratkaisun potentiaalisten asiakkaidesi tarpeisiin.
- Missä tilanteessa he käyttäisivät sitä?
Lähde: Metabeta
Huomautus: Kun kartoitat vastauksia yllä oleviin kysymyksiin, on tärkeää pitää kaikki reaaliaikaisena ja tehdä lisäksi aika- ja kustannusarviot.
Vaihe 2: Analysoi kilpailijasi
Heti kun olet keksinyt, mitä ongelmaa olet ratkaisemassa, on aika katsoa, miten muut yritykset ratkaisevat tämän ongelman – tai ainakin yrittävät ratkaista sitä. Tässä vaiheessa on selvää, että sinun on tehtävä kilpailija-analyysi, jos markkinoilla on samankaltaisia tuotteita.
Sinun on myös muistettava, että vaikka sinulla ei mielestäsi olisikaan suoria kilpailijoita, uskosi tuotteesi ainutlaatuisuuteen pohjaa siihen, että voit tuoda tuotteesi luottavaisesti markkinoille.
Vaihe #3: Määrittele käyttäjävirta, Wireframe & Design
Tulevan tuotteesi käyttäjävirran määrittelyssä keskityt suoraan ensisijaiseen tavoitteeseesi. Tärkeimmän käyttäjävirran määrittelemiseksi meidän pitäisi ensin määritellä prosessin vaiheet, mikä on itse asiassa helppoa, koska sinun tarvitsee vain selittää vaiheet, joita tarvitaan tuotteesi ensisijaisen tavoitteen saavuttamiseksi.
Tässä vaiheessa sinun ei pitäisi miettiä ominaisuuksia – vaan sinun pitäisi keskittyä perustehtäviin, kuten millaisia tavoitteita loppukäyttäjilläsi on, kun he käyttävät tuotetta, heidän odotuksiinsa jne.
Kun olet määrittänyt käyttäjävirran, voit siirtyä rautalankamallinnukseen (wireframing), joka on yksinkertaisesti havainnollistus verkkosivusta tai sovelluksesta. Wireframe on ulkoasu, jossa artikuloidaan, millaiset käyttöliittymäelementit löytävät paikkansa tärkeiltä sivuilta.
Wireframing-esimerkki:
Käyttäjärajapinnan (UI) suunnittelussa yhdistyvät vuorovaikutussuunnittelun, visuaalisen suunnittelun ja tietoarkkitehtuurin käsitteet. Tässä vaiheessa on hyödynnettävä edellisissä vaiheissa opittua, jotta voidaan tuottaa kokemus, joka yllättää ja ilahduttaa loppukäyttäjää.
Täällä Cleeviossa teemme käyttäjätestauksen, kun meillä on ensimmäinen prototyyppi valmiina (yleensä klikattava mock-up). Käyttäjätestaus on olennaisen tärkeää uuden sovelluksen onnistumisen kannalta. Kun meillä on käyttäjätestauksen tulokset valmiina, iteroimme rautalankamalleja ja testaamme ne uudelleen käyttäjillä.
Kun rautalankamallit on testattu, on siirryttävä suunnitteluvaiheeseen, jonka on oltava erilainen jokaisella alustalla (iOS, Android, Web,…).
Vaihe #4: Analysoi ominaisuuksiasi
Tiesitkö, että yli 45 % ohjelmistotuotteisiin sisäänrakennetuista ominaisuuksista käytetään harvoin tai ei koskaan?
Nyt kun olet luonut käyttäjävirtasi, voit alkaa laatia yksityiskohtaisempaa luetteloa ominaisuuksista kutakin tiettyä vaihetta varten, pitäen kuitenkin tilastot mielessä.
Kun olet laatinut ominaisuuksia kutakin vaihetta varten, sinun on asetettava ne tärkeysjärjestykseen. Mikä on tärkein toiminto, jonka haluat käyttäjiesi suorittavan? Tästä tulee pääominaisuutesi.
Yksi ominaisuuksien priorisointimenetelmistä on MoSCoW, jota käytetään päättämään, mitkä toiminnot valmistuvat ensin, mitkä tulevat myöhemmin ja mitkä jätetään pois. Toinen tekniikka, jota käytetään ominaisuuksien tarpeellisuuden mittaamiseen, perustuu liiketoiminta-arvoon (kehitysaika vs. nice to have vs. kustannukset)
Lähde: ProductPlan
Vaihe #5: Kehittäminen & Testaus
Nyt kun tiedät vähimmäiskelpoisen tuotteesi (MVP, minimum viable product) ominaisuudet, on aika toteuttaa ne käytännössä. Siirryttyäsi kehitysvaiheeseen sinun on testattava tuotteesi ja työskenneltävä sen laadun parantamiseksi.
Lankarunkojen hyväksymisen jälkeen sinun pitäisi alkaa työstää asennusarkkitehtuuria, tietokantaa ja aloittaa API:n, ylläpidon ja kaiken back-endin kehittäminen.
Alfa- ja beta-testaus voivat auttaa tässä, sillä ne ovat suosituimpia tapoja testata tuotteen suorituskykyä erilaisissa skenaarioissa. Muista kohdistaa testaus ja tehdä vain ne muutokset, jotka vaikuttavat koko käyttäjäkokemukseen.
Vakiossa sinun tulisi toteuttaa seuraavat testit valvotussa ympäristössä ennen sovelluksen käyttöönottoa:
- Toiminnallisuuden testaus
- Käytettävyystestaus
- Yhteensopivuustestaus
- Yhteensopivuuden testaus
- Yhteensopivuustestaus
- Interfacetestaus
- Suorituskykytestaus
- Turvallisuustestaus
Kehitysprosessin aikana sinun tulisi testata jatkuvasti kaikkia toteutettuja ominaisuuksia.
Me esimerkiksi täällä Cleeviossa rakennamme mobiilisovelluksia, ja beta-buildien julkaisut ladataan Googlen alfa/beta-testaukseen ja Applen TestFlightiin. Sisäiset testirakennelmat ovat Appcenterissä (Microsoftin virallinen työkalu).
Kun ”julkaisukandidaatti” (tuote, joka on valmis markkinoille) on valmis, teemme avointa tai suljettua beta-testausta, jossa kutsumme mahdollisimman monta relevanttia käyttäjää beta-testausohjelmaan ja keräämme palautetta toiminnallisuudesta ja virheistä.
Vaihe #6: Iteratiivisesti päästä tuote-markkinakelpoisuuteen tai epäonnistua
Kun olet validoinut MVP:n, voit ryhtyä tarkastelemaan tuotteesi kattavuutta ja laajentaa sitä. Tässä vaiheessa joko hankit startup-pääomaa, jotta pääset nopeammin markkinoille, tai epäonnistut.
Mobiilisovelluksen osalta teemme yleensä ”pehmeän lanseerauksen”, kun julkaisemme MVP:n AppStoressa ja Google Playssa, mutta emme kannusta sovelluksen markkinointiin tällä hetkellä.
Kun sovellus saa enemmän käyttäjiä, joitain bugeja voi tulla esiin, ja korjaamme varmasti kaiken ASAP. Yleensä julkaisemme uusia versioita joka toinen päivä. Kun sovellus on vakaa ja meillä on yli 99,9 % kaatumisvapaita käyttäjiä, suosittelemme aloittamaan markkinoinnin ja hankkimaan lisää käyttäjiä.
Data on todella tärkeää, ja siksi suosittelemme seuraamaan käyttäjien käyttäytymistä Mixpanelin tai Google Firebase -analytiikan avulla, jotta voimme ymmärtää, miten käyttäjät todella käyttävät sovellusta.
Tuotteen kehittäminen ei ole koskaan valmis. Erittäin tärkeää on pyytää käyttäjiltä palautetta ja iteroida tuotetta. Kun meillä on enemmän käyttäjiä, suoritamme A/B-testausta, jotta voimme testata erilaisia ratkaisuja ja lisätä käyttäjien sitoutumista.
Lähde: ProductPlan
Johtopäätös
Cleeviossa olemme kehittäneet yli 120 MVP:tä viimeisten 10 vuoden aikana, joten meillä on tarpeeksi kokemusta, jotta tiedämme, mitkä MVP:t skaalautuvat ja mitkä palavat ja kuolevat.
Tiedämme, että MVP-ideasi tiekartan, dokumentaation tai rautalankakehysten laatiminen on hieman ylivoimaista, joten ota rohkeasti yhteyttä meihin, niin annamme mielellämme ilmaista neuvontaa.
Konsultointipuhelua MVP:stäsi varten voit soittaa meille sähköpostitse osoitteeseen [email protected] .