Kas tas MVP

Apie MVP kalbama daug. Beveik kiekvienas projektas turi savo „MVP“. Problema tik ta, kad labai dažnai tuo žodžiu pavadinamas tiesiog mažesnis projektas, apkarpyta produkto versija arba atidėtas tobulumas.

Bet tikras MVP nėra „padarykime mažiau“.

Tikras MVP yra atsakymas į daug svarbesnį klausimą: koks mažiausias veikiantis sprendimas jau gali sukurti realią vertę ir duoti mums realų grįžtamąjį ryšį?

Ir čia prasideda esminis skirtumas tarp produkto, kuris juda į rinką, ir produkto, kuris mėnesiais gyvena prezentacijose, backloguose ir susitikimuose.

Kas yra MVP

MVP reiškia Minimum Viable Product. Lietuviškai paprastai tai būtų minimalus gyvybingas produktas arba minimalus veikiantis sprendimas.

Agile kontekste tai nėra tik techninis terminas. Tai mąstymo būdas.

MVP reiškia, kad jūs nebandote nuo pirmos dienos sukurti tobulo produkto visiems galimiems vartotojams ir visiems įmanomiems scenarijams. Jūs bandote kuo greičiau paleisti tokį sprendimą, kuris jau gali būti naudojamas, jau sprendžia konkrečią problemą ir jau leidžia mokytis iš realaus vartotojo elgesio.

Kitaip tariant, MVP nėra apie tai, ką jūs dar norėtumėte pridėti. MVP yra apie tai, be ko produktas dar negali egzistuoti.

Kodėl MVP yra svarbus

Didžiausia MVP vertė nėra greitis pats savaime. Didžiausia vertė yra ta, kad jis apsaugo komandą nuo labai brangios iliuzijos.

Iliuzijos, kad mes tikrai žinome, ko reikia vartotojui.

Kol produktas nėra naudojamas realiame pasaulyje, didelė dalis sprendimų yra spėjimai. Net jei jie atrodo logiški. Net jei komanda labai stipri. Net jei analizė buvo gera. Rinka labai dažnai pataiso mūsų logiką.

Todėl MVP leidžia daug greičiau pereiti nuo nuomonės prie fakto.

Vietoje ilgo kūrimo ciklo atsiranda trumpesnis kelias: paleidžiame, stebime, mokomės, taisome, plečiame.

Agile metodikoje tai labai svarbu, nes visa logika remiasi iteracijomis, grįžtamuoju ryšiu ir prisitaikymu, o ne vienkartiniu „didžiuoju paleidimu“.

Kas nėra MVP

Kad geriau suprastume, kas yra MVP, verta aiškiai įvardyti, kas juo nėra.

MVP nėra brokuotas produktas.

MVP nėra nebaigtas chaosas.

MVP nėra pasiteisinimas paleisti kažką prasto.

MVP nėra „sudėjome pusę funkcijų ir tikimės, kad sueis“.

MVP taip pat nėra tiesiog pigiausia įmanoma projekto versija.

Jei vartotojas negali suprasti, ką su tuo sprendimu daryti, jei jis negali gauti vertės, jei produktas nesprendžia aiškios problemos, tai nėra MVP. Tai tiesiog nebaigtas produktas.

Pagrindinė MVP logika

MVP remiasi labai paprasta idėja.

Reikia rasti tašką, kuriame susitinka trys dalykai:

pirma, reali vartotojo problema
antra, minimalus funkcionalumas jai spręsti
trečia, galimybė greitai gauti realų grįžtamąjį ryšį

Jei šių trijų dalykų nėra, dažniausiai kuriate arba per didelį produktą, arba per silpną produktą.

Kaip nustatyti MVP savo projekte

Čia ir prasideda didžioji praktinė dalis. Daug komandų supranta MVP idėją teoriškai, bet stringa bandydamos ją pritaikyti savo projekte.

Tam padeda keli universalūs klausimai.

1. Kokią vieną problemą mes sprendžiame

Pirmas ir svarbiausias klausimas.

Ne kokį produktą kuriame.
Ne kokias funkcijas planuojame.
Ne kokią viziją turime.

O kokią konkrečią problemą sprendžiame.

Jei į šį klausimą negalite atsakyti vienu sakiniu, MVP greičiausiai dar nėra aiškus.

Pavyzdžiui:

ne „kuriame platformą personalo valdymui“
o „padedame komandų vadovams greičiau patvirtinti atostogas ir matyti komandos užimtumą vienoje vietoje“

Čia jau atsiranda konkretumas.

2. Kam tiksliai mes tai kuriame

MVP beveik niekada neturėtų būti kuriamas visiems.

Jei produktas skirtas visiems, pradžioje jis dažniausiai netinka niekam pakankamai gerai.

Todėl reikia aiškiai apsibrėžti pirmą vartotoją arba pirmą vartotojų segmentą.

Kas jis?
Kokioje situacijoje jis yra?
Koks jo konkretus skausmas?
Ką jis daro dabar, jei jūsų produkto nėra?

Šitas klausimas labai padeda nupjauti „gražias“, bet nereikalingas funkcijas.

3. Koks mažiausias rezultatas vartotojui jau būtų vertingas

Čia vienas svarbiausių klausimų visame MVP mąstyme.

Ne kokia mažiausia funkcijų apimtis.
O kokia mažiausia vertė.

Pavyzdžiui, jei kuriate rezervacijų sistemą, MVP nėra būtinai „registracija, profilis, filtrai, apmokėjimai, priminimai, integracijos“.

MVP gali būti daug paprastesnis: žmogus gali rasti laiką ir sėkmingai užsirezervuoti vizitą.

Jei pagrindinė vertė jau sukuriama, visa kita gali ateiti po to.

4. Be kokių funkcijų šitas sprendimas dar vis tiek veiktų

Šitas klausimas labai naudingas komandose, kurios linkusios viską plėsti.

Jis verčia ne klausti „ko dar reikia“, o klausti „ką galime atidėti“.

Kiekviena funkcija turi būti patikrinta taip:

Jei šitos funkcijos nebus pirmoje versijoje, ar vartotojas vis tiek galės gauti pagrindinę vertę?

Jei atsakymas taip, vadinasi, ši funkcija nėra MVP dalis.

5. Ką mes norime išmokti paleidę pirmą versiją

Tikras MVP visada turi mokymosi tikslą.

Jis kuriamas ne tik tam, kad kažkas veiktų, bet ir tam, kad komanda gautų atsakymą į svarbią nežinomybę.

Pavyzdžiui:

ar vartotojai išvis nori šito sprendimo
ar jie supranta pasiūlymą
ar problema jiems pakankamai skausminga
ar jie pasiruošę mokėti
ar jie naudojasi būtent taip, kaip mes tikėjomės

Jei paleidę produktą negaunate jokio naujo aiškumo, labai tikėtina, kad paleidote ne MVP, o tiesiog mažesnę pilno produkto versiją.

Universalus testas: ar tai tikrai MVP

Jei norite pasitikrinti savo projektą, užduokite šiuos klausimus.

Ar vartotojas gali gauti aiškią naudą jau iš pirmos versijos?

Ar produktas sprendžia vieną aiškią problemą, o ne dešimt iš karto?

Ar pirmoji versija skirta konkrečiam vartotojui, o ne visiems?

Ar galime ją paleisti pakankamai greitai, kad gautume realų grįžtamąjį ryšį?

Ar aiškiai žinome, ką norime išmokti iš pirmojo paleidimo?

Ar vartotojas jau gali naudotis sprendimu, o ne tik pamatyti jo pažadą?

Ar pagrindinė produkto vertė egzistuoja be papildomų „gražumų“?

Jei į kelis iš šių klausimų negalite atsakyti aiškiai, MVP dar nėra išgrynintas.

Dažniausios klaidos

Klaidą Nr. 1 būtų galima pavadinti „dar truputį pridėkime“

Tai klasikinė situacija, kai komanda sako: dar šitą pridėkime, dar aną, dar vieną scenarijų padengkime, dar vieną integraciją padarykime. Ir taip MVP išsipučia iki beveik pilno produkto.

Dažniausiai taip nutinka ne dėl blogos valios, o dėl baimės paleisti netobulą versiją.

Klaida Nr. 2: painiojamas MVP ir Proof of Concept

Proof of Concept tikrina, ar technologiškai kažkas įmanoma.

MVP tikrina, ar vartotojui tai kuria vertę.

Tai nėra tas pats.

Klaida Nr. 3: kuriamas produktas, o ne tikrinama hipotezė

Labai daug komandų iš karto puola statyti sistemą, nors dar neturi aiškumo, ar jų prielaidos teisingos.

MVP turi tikrinti svarbiausias projekto hipotezes, ne tik kurti funkcionalumą.

Klaida Nr. 4: bandoma patenkinti visas suinteresuotas puses

Kai projekte daug interesų, atsiranda spaudimas į MVP sudėti viską po truputį. Tada jis tampa kompromisų rinkiniu, bet nebe aiškiu produktu.

MVP turi būti griežtas prioritetų sprendimas.

Kaip suprasti, kad MVP jau pakanka paleisti

Labai paprasta taisyklė.

Jei vartotojas jau gali pasiekti pagrindinį rezultatą, o jūs jau galite iš jo išmokti kažką kritiškai svarbaus, dažniausiai MVP jau pakanka paleisti.

Jei dar vis laukiate „kol bus gražiau“, „kol uždengsime visus kampus“, „kol sudėsime visas papildomas galimybes“, greičiausiai nebe kuriate MVP. Jau kuriate patogesnę psichologinę būseną sau.

Rinkai dažniausiai to nereikia.

Praktinis mąstymo modelis

Jei norite labai paprasto filtro, naudokite šitą formulę:

Koks yra mažiausias veikiantis sprendimas, kuris:

sprendžia vieną aiškią problemą
sukuria aiškią vertę konkrečiam vartotojui
gali būti paleistas pakankamai greitai
leidžia mums ko nors svarbaus išmokti

Jei šituos keturis kriterijus išpildote, esate arti tikro MVP.

Pabaigai

Didelis, bet nepabaigtas projektas dažnai yra mažiau vertingas nei mažas, bet veikiantis sprendimas.

Agile esmė ir yra ne tobulo produkto laukimas, o nuolatinis vertės kūrimas per mažesnius, greitesnius ir realesnius žingsnius.

Todėl MVP nėra silpnesnė produkto versija.

MVP yra brandesnis požiūris į kūrimą.

Jis sako labai paprastą dalyką: geriau turėti mažiau, bet tikra, nei daugiau, bet tik PowerPoint'e.