MVP mõte ei ole ehitada vähem, vaid õppida kiiremini. Alustame sellest, milline oletus on teie äri jaoks kõige riskantsem, ja ehitame just nii palju, kui on vaja selle kontrollimiseks: päris kasutajatega, mitte koosolekul.
Enamik MVP-projekte ebaõnnestub ühel ja samal moel: ehitatakse väiksem versioon kogu tootest, iga funktsioon poolikuna. Tulemus on midagi, mida keegi ei taha kasutada, ja vastust ei tule — sest kasutaja ei loobunud mitte ideest, vaid poolikust asjast.
Toimiv MVP on täislahendus ühele kitsale probleemile. Ta ei alga küsimusest „mida me ehitame”, vaid küsimusest „milline meie oletus on kõige kallim, kui see on vale”. Kui see oletus on leitud, saab tavaliselt ehitada midagi palju väiksemat, kui algselt plaaniti — ja saada sama vastus nädalatega.
Kõik MVP-d ei ole tarkvara. Odavaim katse, mis annab õige vastuse, on alati parim katse — ja mõnikord ei ole selleks vaja üldse midagi ehitada. Vaatame need variandid koos läbi, enne kui arendust pakume.
Leht, mis kirjeldab toodet nii, nagu see olemas oleks, ja mõõdab, kui paljud registreeruvad. Vastab küsimusele, kas probleem on piisavalt valus — ja maksab päevi, mitte kuid.
Teenust osutatakse esimestele klientidele käsitsi, ilma igasuguse tarkvarata. Kõlab ebaefektiivselt, aga õpetab protsessist rohkem kui ükski intervjuu — ja näitab täpselt, mida automatiseerida tasub.
Kasutaja näeb valmis toodet, aga taga teeb töö inimene. Kasutajakogemus on päris, taristut ei ole. Sobib eriti siis, kui automatiseerimine ise on kallis osa.
Kitsas, aga lõpuni viidud toode. Kõige tavalisem õige vastus: üks asi, mis töötab päriselt, annab rohkem infot kui kümme, mis pooleldi töötavad.
Toode pannakse kokku olemasolevatest teenustest — vormid, automatiseerimistööriistad, tabelid — ilma oma koodita. Kiire viis ideed katsetada, mille võib hiljem päris süsteemiga asendada.
Kõige ausam katse: kas keegi maksab. Ostukavatsus on nõrk signaal, makstud arve on tugev. Ehitame selle jaoks vajaliku, aga mitte rohkem.
MVP puhul valime tuttava ja igava tehnoloogia. Kiirus tuleb mahu piiramisest, mitte uudsest tööriistast — ja kui toode osutub õigeks, ei taha te kuue kuu pärast avastada, et alus tuleb välja vahetada.
MVP eesmärk ei ole toode. Eesmärk on otsus, mille saab teha andmete põhjal — ja need neli on see, mille peal see otsus seisab.
Mitte prototüüp ega esitlus, vaid asi, mida keegi väljaspool teie maja päriselt kasutab.
Kokkulepitud mõõdikud pannakse paika enne ehitamist, muidu tõlgendab igaüks tulemust endale sobivalt.
Kolm võimalikku vastust — jätka, pööra või lõpeta — ja kõik kolm on õiged tulemused.
Kui vastus on „jätka”, ei taha te alustada nullist — ega päranduda koodi, mida keegi enam puutuda ei julge.
MVP-d tellitakse kolmel moel ja valik sõltub sellest, mis teil juba olemas on. Kui meeskonda ei ole, katame terviku: avastusest disaini, arendusse ja väljalaskesse. Kui teil on tootejuht ja oma arendajad, aga käsi jääb lühikeseks, tuleme lisavõimekusena teie protsessi sisse. Ja kui te vajate ainult suunda — kas see idee on üldse tarkvaraprojekt ja milline katse annaks vastuse odavaimalt — on see eraldi tellitav nõustamine, mis ei kohusta midagi ehitama.
Partnerit valides tasub küsida kahte asja. Esiteks: mis on esimene asi, mida te teeksite — kui vastus on „hakkame arendama” ilma küsimuseta, mida täpselt kontrollitakse, siis katset ei kavandata, vaid müüakse tunde. Ja teiseks: mis juhtub siis, kui MVP näitab, et idee ei tööta. Kui sellel juhul ei ole kokkulepitud lõppu, on teil käes projekt, mitte katse.
Esimene küsimus ei ole, mida ehitada, vaid mis on kõige kallim vale oletus. Sageli kahaneb maht pärast seda vestlust poole võrra.
Kui maandumisleht või käsitsi teenus annab sama vastuse odavamalt, soovitame seda — ka siis, kui see tähendab väiksemat projekti meile.
Testid, CI ja arhitektuur on samad mis suuremas projektis. Ära visatakse funktsioonid, mida andmed ei toetanud — mitte kood.
Enne algust lepime kokku, mida mõõdame ja mis number tähendab „jätka” ning mis „lõpeta”. Meie huvi ei ole müüa teile teist faasi.
Kood, disainifailid ja pilvekontod on teie nimel esimesest commit’ist. MVP ei tohi olla põhjus, miks te edasi meiega seotud olete.
Asume Tallinnas, samas ajavööndis ja samas lepinguraamistikus. Andmed jäävad soovi korral täielikult EL-i.
MVP on täielik lahendus ühele kitsale probleemile. Poolik toode on osaline lahendus laiale probleemile. Esimest saab päriselt kasutada ja sellest õppida, teisest ei saa kumbagi.
Meie omast mitte. Kiirus tuleb mahu piiramisest, mitte kvaliteedi ohverdamisest — testid, CI ja arhitektuur on samad, mis suuremas projektis. Ära visatakse funktsioonid, mida andmed ei toetanud, mitte kood.
See on hea tulemus ja odavam kui aasta hiljem sama teada saada. Anname kirjaliku kokkuvõtte sellest, mida andmed näitasid, ja soovitame kas pöörata või lõpetada. Meie huvi ei ole müüa teile teist faasi.
Selleks, et kõige kallim oletus saaks kontrollitud enne, kui selle peale aasta ja eelarve kulub. Iga tooteidee toetub mitmele eeldusele: et probleem on olemas, et see on piisavalt valus, et teie lahendus sobib ja et keegi maksab. Tavaliselt on neist üks selgelt riskantsem kui teised.
MVP ehitatakse just selle ümber. Kui eeldus osutub õigeks, on teil andmed, millega edasi minna ja mille peale raha küsida. Kui vale, siis teate seda nädalate, mitte kuude pärast — ja enamik sellest, mille eest te maksite, on ikkagi kasutatav.
Esimene töötav tulemus tuleb kahe nädalaga. Me ei tööta kuid vaikuses ja ei näita midagi enne lõppu — esimene sprint lõpeb millegagi, mida saab päriselt kasutada, ja edasi kasvab toode kahenädalaste sammudena, mille sisu te ise valite.
Kui kitsas MVP tervikuna, siis tavaliselt jõuab see päris kasutajateni kuue nädalaga. Kui katse ei nõua üldse tarkvara — maandumisleht, käsitsi osutatud teenus või olemasolevatest tööriistadest kokku pandud lahendus — on see päevade küsimus.
See kehtib ainult kitsa mahu juures. Kui nimekirjas on kümme funktsiooni, ei ole tegu MVP-ga ja ausam number on kuud, mitte nädalad. Me ütleme seda ette, mitte kolmandas sprindis.
See sõltub sellest, mida te kontrollite. Kui kahtlus on selles, kas probleem huvitab kedagi, piisab maandumislehest. Kui kahtlus on selles, kas teie lahendus päriselt töötab, tuleb see käsitsi läbi teha — käsitsi osutatud teenus õpetab protsessist rohkem kui ükski intervjuu. Kui kahtlus on ainult automatiseerimises, saab kasutajale näidata valmis liidest, mille taga teeb töö esialgu inimene.
Kui te teate juba, et probleem on olemas ja lahendus sobib, ning küsimus on kasutuses, siis on õige vastus üks funktsioon korralikult lõpuni ehitatud. Käime need variandid avastusfaasis läbi ja valime odavaima, mis annab usaldusväärse vastuse.
Küsige kõigepealt, mis on esimene asi, mida nad teeksid. Kui vastus on „hakkame arendama” ilma küsimuseta, mida täpselt kontrollitakse ja mis number tähendab edu, siis ei kavandata katset, vaid müüakse tunde. Hea partner vaidleb teie mahuga vastu enne, kui selle hinnastab.
Küsige ka, mis juhtub siis, kui MVP näitab, et idee ei tööta — kui sellel juhul ei ole kokkulepitud lõppu, on teil käes projekt, mitte katse. Ja küsige, kellele kuuluvad kood, disainifailid ja pilvekontod. MVP mõte on hoida võimalused lahti; partner, kellest lahkumine on omaette projekt, teeb täpselt vastupidist.
Kirjeldage oma olukorda paari lausega. Vastame ühe tööpäeva jooksul.