Ja ir radusies laba biznesa ideja, pirmais impulss bieži ir uzreiz sākt būvēt projektu. Uzrakstīt visu nepieciešamo funkciju sarakstu, izveidot dizainu, pieslēgt maksājumus, sagatavot administrācijas paneli un pēc iespējas ātrāk nonākt līdz “gatavai” sistēmai.
Taču jauna projekta sākumā lielākais risks parasti nav tas, ka tam trūks kādas funkcijas. Lielākais risks ir uzbūvēt projektu, kuru cilvēki nevēlas lietot vai par kuru nav gatavi maksāt.
MVP palīdz šo risku samazināt. Tā nav vienkārši lēta vai nepabeigta projekta versija. Tas ir veids, kā ar iespējami mazu ieguldījumu pārbaudīt svarīgāko pieņēmumu par ideju.
Kas ir MVP?
MVP ir saīsinājums no angļu valodas jēdziena Minimum Viable Product - minimāli dzīvotspējīgs projekts.
Vienkāršāk sakot, tā ir mazākā projekta versija, kas jau sniedz lietotājam konkrētu vērtību un ļauj pārbaudīt, vai ideja darbojas reālajā dzīvē.
MVP nav jābūt lielam. Tam nav jāietver visas iecerētās funkcijas. Taču tam ir jābūt pietiekamam, lai īsts lietotājs varētu izdarīt galveno darbību un lai projekta veidotājs no šīs darbības kaut ko uzzinātu.
Piemēram, ja ideja ir platforma privātstundu rezervēšanai, galvenais pieņēmums varētu būt šāds: vecāki ir gatavi internetā atrast skolotāju un rezervēt konkrētu nodarbības laiku.
Lai to pārbaudītu, pirmajai versijai var pietikt ar:
- nelielu skolotāju sarakstu;
- katra skolotāja profilu;
- pieejamo laiku apskati;
- rezervācijas pieteikumu;
- e-pasta apstiprinājumu.
Sākumā nav obligāti vajadzīga sarežģīta vērtējumu sistēma, automātiska algu izmaksa skolotājiem, mobilā lietotne, videozvani pašā platformā un desmit dažādi abonēšanas plāni. Tie var kļūt svarīgi vēlāk, bet tie neatbild uz pirmo un svarīgāko jautājumu: vai cilvēki vispār šādā veidā rezervēs privātstundas?
Kāds ir MVP mērķis?
MVP mērķis nav vienkārši “palaist kaut ko ātri”. Tā mērķis ir iegūt pierādījumus, pirms projektā tiek ieguldīts vairāk laika un naudas.
Labs MVP palīdz atbildēt uz vienu vai vairākiem konkrētiem jautājumiem:
- Vai cilvēkiem šī problēma tiešām ir pietiekami svarīga?
- Vai viņi saprot piedāvāto risinājumu?
- Vai viņi ir gatavi to izmēģināt?
- Vai viņi atgriežas un lieto projektu atkārtoti?
- Vai viņi ir gatavi par to maksāt?
- Kura projekta daļa viņiem rada vislielāko vērtību?
Piemēram, pieņemsim, ka tiek veidota lietotne, kas katru nedēļu sagatavo ģimenei ēdienkarti un iepirkumu sarakstu. Sākumā var šķist, ka vajadzīga recepšu datubāze, kaloriju aprēķins, pārtikas veikalu cenu salīdzināšana, ģimenes profili, alerģiju filtri un mobilā lietotne.
Tomēr svarīgākais pieņēmums var būt daudz vienkāršāks: vai ģimene ir gatava regulāri izmantot automātiski sagatavotu ēdienkarti?
Pirmā versija var piedāvāt tikai vienu nedēļas plānu, dažas izvēles un automātiski izveidotu iepirkumu sarakstu. Ja cilvēki to izmanto un nākamajā nedēļā atgriežas, ir pamats projektu attīstīt. Ja neatgriežas, vēl desmit funkcijas problēmu, visticamāk, neatrisinās.
MVP nav obligāti programmatūra
Viena no izplatītākajām kļūdām ir pieņemt, ka jebkura digitāla biznesa ideja uzreiz jāpārvērš pilnvērtīgā sistēmā.
Dažreiz pirms MVP pietiek ar vienkāršu eksperimentu.
Ja uzņēmējs vēlas izveidot platformu, kas savieno mājdzīvnieku saimniekus ar pieskatītājiem, viņš var sākt ar landing page. Tajā tiek izskaidrots pakalpojums, norādīta aptuvenā cena un ievietota pieteikuma forma. Pēc tam uz lapu tiek novirzīta neliela reklāmas plūsma.
Šāds tests var parādīt:
- vai cilvēki saprot piedāvājumu;
- cik daudzi atstāj pieteikumu;
- kurš pakalpojuma veids interesē visvairāk;
- vai paredzētā cena šķiet pieņemama.
Ja neviens nepiesakās, iespējams, nav vērts uzreiz būvēt lietotāju kontus, kalendārus, čatu un maksājumu sistēmu.
Citā gadījumā pakalpojuma pirmā versija var būt daļēji manuāla. Klients aizpilda formu, bet pakalpojuma sniedzēju aizkulisēs piemeklē cilvēks, nevis algoritms. Lietotājam tiek atrisināta problēma, savukārt uzņēmums var novērot procesu un saprast, ko vēlāk ir vērts automatizēt.
Šādu pieeju dažreiz sauc par “concierge MVP”. Tā nav krāpšanās vai nekvalitatīvs risinājums. Tas ir eksperiments, kurā vispirms pārbauda pakalpojuma vērtību un tikai pēc tam automatizē to, kas atkārtojas.
Kā saprast, ko MVP būvēt?
Pirms funkciju saraksta veidošanas ir jānosauc galvenais pieņēmums, kuru projekts pārbaudīs.
To var formulēt vienā teikumā:
Mēs uzskatām, ka [konkrēta cilvēku grupa] izmantos vai iegādāsies [konkrētu risinājumu], jo tas palīdzēs viņiem [sasniegt konkrētu rezultātu].
Piemēram:
Mēs uzskatām, ka mazu uzņēmumu īpašnieki maksās par rīku, kas no viņu bankas darījumiem automātiski sagatavo saprotamu naudas plūsmas pārskatu.
No šī pieņēmuma izriet galvenā lietotāja plūsma:
- Lietotājs pievieno vai importē darījumus.
- Sistēma tos apkopo.
- Lietotājs saņem saprotamu pārskatu.
- Tiek pārbaudīts, vai viņš par šo rezultātu ir gatavs maksāt.
Viss, kas nepieciešams šīs plūsmas darbībai, ir MVP kandidāts. Viss pārējais ir jāpamato atsevišķi.
Labs kontroles jautājums katrai funkcijai ir:
Ja šo funkciju neuzbūvēsim, vai joprojām varēsim pārbaudīt galveno pieņēmumu?
Ja atbilde ir “jā”, funkcija, iespējams, var pagaidīt.
Ko MVP parasti vajag būvēt?
Precīzs saturs katram projektam atšķiras, bet fokusētā MVP parasti ietilpst dažas būtiskas daļas.
Viena galvenā lietotāja problēma
MVP jārisina viena skaidri definēta problēma. Nevis “palīdzēt cilvēkiem dzīvot labāk”, bet, piemēram, “ļaut vecākam piecu minūšu laikā rezervēt bērnam attālinātu matemātikas konsultāciju”.
Jo konkrētāka problēma, jo vieglāk saprast, vai risinājums darbojas.
Viena galvenā lietotāja plūsma
Lietotājam jāspēj nonākt no sākuma līdz vērtīgam rezultātam.
Interneta veikalā tā var būt preces atrašana un iegāde. Valodu mācību projektā - nodarbības noklausīšanās un turpināšana nākamajā reizē. B2B sistēmā - datu augšupielāde un gatava pārskata saņemšana.
Sākumā labāk viena pabeigta plūsma nekā piecas daļēji darbojošās.
Minimāla administrēšana
Gandrīz katram projektam nepieciešams veids, kā pārvaldīt tā saturu vai lietotājus. Tomēr administrācijas panelim nav jābūt atsevišķam, perfektam projektam.
Piemēram, pasākumu platformas pirmajā versijā pasākumus var ievadīt vienkāršā formā vai pat tieši datubāzē. Sarežģītu administrācijas lomu sistēmu ir vērts veidot tad, kad ir skaidrs, kas to lietos un kādi pienākumi tiešām jānodala.
Nepieciešamie mērījumi
Ja MVP mērķis ir kaut ko iemācīties, jābūt iespējai novērot lietotāju rīcību.
Atkarībā no projekta svarīgi var būt:
- cik cilvēku sāk un pabeidz galveno darbību;
- cik daudzi atgriežas;
- kurā solī cilvēki apstājas;
- cik daudzi piesakās maksas plānam;
- kuras funkcijas tiek izmantotas;
- kādus jautājumus lietotāji uzdod atbalstam.
Nav vajadzīga milzīga analītikas sistēma. Taču bez mērījumiem MVP var pārvērsties tikai par mazāku projekta versiju, no kuras neko jaunu neuzzinām.
Pietiekama kvalitāte un drošība
Vārds “minimāls” nenozīmē paviršs. Ja projektā tiek apstrādāti maksājumi, personas dati, medicīniska informācija vai cita sensitīva informācija, drošību nedrīkst atlikt uz vēlāku laiku.
Arī galvenajai funkcijai jādarbojas pietiekami uzticami. Ja ēdienu piegādes MVP regulāri pazaudē pasūtījumus, no tā nevar secināt, ka cilvēkus pakalpojums neinteresē. Var secināt tikai to, ka projekts nedarbojas.
MVP drīkst būt šaurs, bet tas nedrīkst maldināt lietotāju vai apdraudēt viņa datus.
Ko MVP parasti nevajag būvēt?
Liela daļa MVP izmaksu rodas nevis no galvenās idejas, bet no funkcijām, kuras šķiet profesionālas un vajadzīgas “īstam projektam”.
Visus iespējamos lietotāju tipus
Ja nākotnē platformu lietos klienti, pakalpojumu sniedzēji, uzņēmumu administratori un partneri, nav obligāti jāautomatizē visi četri profili pirmajā dienā.
Piemēram, klientam var būt savs konts, bet pakalpojumu sniedzēju sākumā pārvalda administrators. Tas ļauj pārbaudīt pieprasījumu, pirms tiek uzbūvēta sarežģīta daudzpusēja platforma.
Sarežģītu tiesību un lomu sistēmu
Lomas un piekļuves tiesības mēdz ātri kļūt sarežģītas. Ja pirmajā versijā sistēmu lieto viens uzņēmums un divi administratori, nav nepieciešams uzreiz projektēt struktūru starptautiskai organizācijai ar desmit nodaļām un pieciem piekļuves līmeņiem.
Funkcijas retiem izņēmumiem
Projekta izstrādē viegli iestrēgt scenārijos “bet kas notiks, ja…”. Daži izņēmumi tiešām ir svarīgi. Taču katra reta situācija nav jāautomatizē pirmajā versijā.
Ja 98 no 100 pasūtījumiem var apstrādāt automātiski, divus īpašos gadījumus sākumā var atrisināt manuāli. Kad to kļūs vairāk, būs arī reāli dati, pēc kuriem veidot pareizo risinājumu.
Mobilo lietotni tikai tāpēc, ka tā šķiet nopietnāk
Daudzi projekti var sākties kā mobilajām ierīcēm pielāgota tīmekļa aplikācija. Atsevišķas iOS un Android lietotnes palielina ne tikai sākotnējās izstrādes apjomu, bet arī turpmāko uzturēšanu.
Mobilā lietotne ir pamatota, ja projektam nepieciešami paziņojumi, darbs bez interneta, regulāra ikdienas lietošana vai specifiskas telefona iespējas. Tā nav obligāta katram MVP.
Perfektu automatizāciju
Ja projekta kodols ir jauns process, sākumā daļu darba var veikt manuāli.
Piemēram, personalizētu ceļojumu plānu serviss var sākumā izmantot formu, kurā klients norāda intereses. Plānu aizkulisēs sagatavo cilvēks ar dažiem palīgrīkiem. Tikai pēc vairākiem desmitiem pasūtījumu kļūst skaidrs, kuras darbības atkārtojas un kuras ir vērts automatizēt.
Ja vispirms tiek uzbūvēts sarežģīts algoritms, pastāv risks automatizēt procesu, kuru vēl neviens nav pietiekami labi sapratis.
Funkcijas “nākotnes miljoniem lietotāju”
Sistēmai jābūt uzbūvētai saprātīgi, taču nav nepieciešams maksāt par infrastruktūru un sarežģītību, kas būs vajadzīga tikai pēc vairākiem gadiem - ja projekts līdz tam vispār nonāks.
Tehniskajiem lēmumiem nevajadzētu bloķēt izaugsmi, bet MVP nav jāprojektē tā, it kā tam nākamajā mēnesī būtu miljons lietotāju.
MVP nav funkciju saraksta saīsināšana
Dažreiz komanda izveido pilna projekta funkciju sarakstu un tad katrai funkcijai uztaisa vienkāršāku versiju. Rezultātā rodas projekts, kurā ir mazliet no visa, bet neviena darbība nav līdz galam vērtīga.
Piemēram, topoša darba meklēšanas platforma pirmajā versijā mēģina iekļaut vakances, kandidātu profilus, čatu, automātisku CV analīzi, uzņēmumu lapas, vērtējumus un abonementus. Katra sadaļa darbojas tikai daļēji, un projekts joprojām neatrisina vienu konkrētu problēmu labāk par jau pieejamajiem risinājumiem.
Labāka MVP pieeja būtu izvēlēties vienu šauru nišu un vienu sāpīgu problēmu. Piemēram, palīdzēt Latvijas restorāniem ātri atrast pavārus īslaicīgām maiņām. Tad pirmajā versijā galvenais ir publicēt maiņu, atrast pieejamu cilvēku un apstiprināt vienošanos. Pārējais var sekot pēc tam.
MVP nav “mazliet no visa”. Tas ir “viss nepieciešamais vienam svarīgam rezultātam”.
Kā zināt, vai MVP ir izdevies?
MVP panākumus nevajadzētu vērtēt tikai pēc tā, vai projekts tika pabeigts laikā un iekļāvās budžetā. Tas ir izstrādes rezultāts, nevis biznesa rezultāts.
Pirms palaišanas jāvienojas, kāds lietotāju signāls apstiprinās pieņēmumu.
Piemēram:
- vismaz 10 no pirmajiem 30 lietotājiem pabeidz galveno darbību;
- vismaz 20% lietotāju atgriežas nākamajā nedēļā;
- pieci uzņēmumi piekrīt izmēģināt maksas pilotprojektu;
- vismaz 3% landing page apmeklētāju atstāj pieteikumu;
- klienti ir gatavi samaksāt paredzēto cenu, nevis tikai saka, ka ideja viņiem patīk.
Konkrētie skaitļi katram projektam būs atšķirīgi. Svarīgi, lai tie būtu noteikti pirms rezultātu redzēšanas. Pretējā gadījumā gandrīz jebkuru iznākumu var sev izskaidrot kā panākumu.
Arī negatīvs rezultāts var būt vērtīgs. Ja neliels tests parāda, ka cilvēki projektu nevēlas vai nesaprot, tas var pasargāt no daudz lielāka zaudējuma. MVP nav eksāmens, kurā obligāti jāsaņem pozitīva atzīme. Tas ir veids, kā lēti iegūt informāciju.
Kas notiek pēc MVP palaišanas?
Pēc palaišanas nevajadzētu automātiski sākt būvēt visu, kas sākumā tika atlikts. Vispirms jāskatās, ko dara lietotāji.
Parasti iespējami četri turpmākie virzieni:
- Turpināt. Galvenais pieņēmums apstiprinās, un var attīstīt nākamo svarīgāko projekta daļu.
- Mainīt. Problēma ir īsta, bet lietotāji vēlas citu risinājumu, cenu vai lietošanas veidu.
- Sašaurināt. Vienai klientu grupai projekts ir ļoti vērtīgs, bet pārējām ne. Tad fokusu var likt tieši uz šo grupu.
- Apstāties. Pieprasījums nav pietiekams vai risinājums nav ekonomiski pamatots.
Piemēram, platforma sākotnēji paredzēta visiem mazajiem pakalpojumu uzņēmumiem, taču pēc palaišanas izrādās, ka to aktīvi izmanto tikai skaistumkopšanas saloni. Tas nav obligāti slikts rezultāts. Tas var būt signāls, ka projektam atrasta konkrēta niša, kurā tas jāattīsta tālāk.
Cik maksā MVP izstrāde?
MVP nav viena noteikta cena, jo ar šo vārdu var apzīmēt ļoti atšķirīgus risinājumus - no vienas landing page līdz platformai ar lietotāju kontiem, maksājumiem un specifisku biznesa loģiku.
Ļoti aptuveni projekta līmeņus var iedalīt šādi:
- Landing page un idejas pieprasījuma tests: aptuveni 300-1 500 eiro.
- Klikšķināms prototips vai vienkārša demonstrācija: aptuveni 1 000-4 000 eiro.
- Ļoti šaurs funkcionāls MVP: aptuveni 3 000-8 000 eiro.
- MVP ar lietotājiem, datiem, maksājumiem un administrēšanu: aptuveni 8 000-20 000 eiro.
- Sarežģītāka platforma ar vairākiem lietotāju tipiem un biznesa procesiem: no 20 000 eiro uz augšu.
Šie nav universāli tarifi. Cenu ietekmē lietotāju plūsmu skaits, integrācijas, dizaina prasības, datu drošība, automatizācijas apjoms un tas, cik daudz nezināmā vēl ir pašā idejā.
Dažreiz pareizais pirmais solis tiešām ir 500 eiro vērta landing page, nevis 10 000 eiro vērta sistēma. Ja vēl nav zināms, vai cilvēki vispār vēlas piedāvāto risinājumu, lētāks tests var dot svarīgāko atbildi.
Savukārt funkcionējošu projektu ar lietotāju reģistrāciju, maksājumiem, datu glabāšanu un administrācijas rīkiem nav godīgi salīdzināt ar vienkāršu mājaslapu. Tās ir dažādas lietas ar atšķirīgu izstrādes un atbildības apjomu.
Labs MVP sākas nevis ar kodu, bet ar pareizo jautājumu
Pirms sākt izstrādi, ir vērts skaidri atbildēt uz trim jautājumiem:
- Kādu konkrētu problēmu projekts atrisina?
- Kurš pieņēmums par lietotāju vai tirgu šobrīd ir visriskantākais?
- Kāds ir vienkāršākais ticamais veids, kā šo pieņēmumu pārbaudīt?
Dažreiz atbilde būs landing page. Dažreiz - manuāli sniegts pakalpojums. Citreiz tiešām būs nepieciešama funkcionējoša web aplikācija.
Svarīgākais nav uzbūvēt pēc iespējas mazāk. Svarīgākais ir neiztērēt laiku un naudu tam, kas vēl nav nepieciešams.
MVP ir labs tad, ja tas ne tikai darbojas, bet arī palīdz pieņemt nākamo lēmumu.