Kako določiti obseg MVP: skrčite prvo različico na tisto, kar je resnično pomembno

Skoraj vsak, ki pride k nam z zamislijo za aplikacijo, si je njeno celotno različico že zgradil v glavi. Znajo opisati nadzorno ploščo, stran z nastavitvami, priporočilni program, temni način. Česar vam običajno ne znajo povedati, je, kateri edini del te slike bi, če bi deloval, naredil celotno stvar vredno truda. Določanje obsega MVP je neglamurozno, nekoliko boleče delo iskanja tega enega dela — in poguma, da preostanek pustite za pozneje.

Videl sem nastajati veliko prvih izdelkov in tisti, ki se mučijo, skoraj nikoli ne propadejo zato, ker bi bila ekipa lena. Propadejo, ker je bil obseg napačen že od prvega tedna. V prvo različico se je natlačilo preveč, proračun je presahnil, preden se je kdorkoli karkoli naučil, in do izdaje je ekipa porabila vse zgolj za to, da je prišla do štartne črte — brez preostalega denarja, da bi se odzvala na to, kar so resnični uporabniki dejansko počeli.

To je torej vodnik, ki ga ljudem dam, preden je napisana ena sama vrstica kode. Ne govori o ritualih Agile ali imenitnih ogrodjih. Govori o enem iskrenem vprašanju — katera je najmanjša stvar, ki jo lahko zgradimo in nam pove, ali je ta zamisel resnična? — in o disciplini, da nanj nenehno odgovarjamo, ko se skušnjava, da bi dodali »samo še eno funkcijo«, znova prikrade. Kajti vedno se prikrade.

Kaj MVP v resnici je (in kaj ni)

Izraz se je od prepogoste rabe obrabil, zato bodimo natančni. Minimalno sprejemljiv izdelek je najmanjša različica vaše zamisli, ki resničnemu uporabniku prinaša resnično vrednost in vas nauči nečesa, česar se iz predstavitve s prosojnicami ne bi mogli naučiti. Ključna beseda, ki jo ljudje pozabljajo, je sprejemljiv. Za nekoga mora dejansko delovati, od začetka do konca, tudi če počne samo eno stvar.

Tukaj je, kaj MVP ni. Ni napol dokončana različica celotnega izdelka s polomljenimi vogali povsod. Ni prototip, ki ga zavržete. In zagotovo ni »poceni različica« — poceni je stranski učinek dobrega določanja obsega, ne cilj. Cilj je učenje. Porabite čim manj denarja, da odgovorite na najdražje vprašanje, ki ga imate: ali bo to sploh kdo uporabljal in ali bo to uporabljal tako, kot si mislim?

Ta razlika je pomembnejša, kot se sliši. Miselnost »prvih 20 %« vodi do nečesa, kar je polomljeno v vse smeri in koristno v nobeni. »Ena stvar, kot je treba« vodi do nečesa, kar lahko človek vzame v roke, resnično uporabi in si o tem ustvari mnenje. Mnenja so celotno bistvo. Na tišino ne moreš iterirati.

Past pretiranega razvoja in zakaj je vanjo tako lahko pasti

Nihče ne začne z namenom, da bi presegel obseg. To se zgodi z eno razumno odločitvijo za drugo. Dodate prijavo, ker seveda potrebujete račune. Računi pomenijo postopek ponastavitve gesla, in potrditev e-pošte, in stran z nastavitvami. Nastavitve pomenijo profil, kar pomeni nalaganje slik, kar pomeni prostor za njihovo shranjevanje. Vsak korak je sam zase razumen. Ko se naložijo skupaj, ste porabili dva meseca in kos proračuna, preden se je del, ki vašo zamisel dela posebno, sploh začel.

Druga polovica pasti je čustvena. Rezanje funkcij se zdi kot priznanje, da je vaša zamisel majhna. Ni — je priznanje, da še ne veste, katere funkcije so pomembne, kar je preprosto resnica. Vsaka funkcija, ki jo zgradite, preden imate uporabnike, je stava na slepo. Nekatere od teh stav bodo napačne, in tiste, ki jih iz MVP izrežete, so najcenejše možne stave, pri katerih se lahko zmotite, ker jih nikoli niste vplačali.

Poiščite edino nalogo, ki jo mora vaš MVP opraviti

Vsak izdelek, naj na koncu postane še tako velik, ima osrednjo zanko — edino zaporedje, ki ga uporabnik ponavlja in ki ustvarja vrednost. Pri rezervacijski aplikaciji je to najdi termin, rezerviraj ga, prejmi opomnik. Pri tržnici je to objavi nekaj, nekdo to najde, denar zamenja lastnika. Pri internem orodju je to zajemi podatke enkrat, uporabljaj jih povsod. Vse drugo v izdelku obstaja zato, da to zanko podpre, okrasi ali razširi. Vaš MVP je ta zanka. Samo zanka.

Da najdete svojo, na glas dokončajte ta stavek: »Uporabnik pride k mojemu izdelku, da bi ______, in je zadovoljen, če ______.« Prva praznina je naloga. Druga je to, kako boste vedeli, da je delovalo. Če obeh praznin ne morete zapolniti v enem dihu, jedra še niste našli — in niste pripravljeni na določanje obsega, kaj šele na razvoj.

Bodite neusmiljeni glede razlike med osrednjo zanko in stvarmi, ki se zdijo bistvene, pa niso. Prijava se zdi bistvena. Običajno ni, v prvi različici — veliko MVP se zažene z eno samo deljeno povezavo, ročnim povabilom ali sploh brez računov in se naučijo vsega potrebnega, preden zgradijo aparaturo za avtentikacijo. Analitične nadzorne plošče se zdijo bistvene. Niso; bazo podatkov lahko prebirate ročno, dokler imate enajst uporabnikov. Skrčite na zanko in presenečeni boste, koliko odpade.

Razvrstite vsako funkcijo med »mora«, »naj bi« in »ne bo (zaenkrat)«

Ko ste poimenovali osrednjo zanko, vzemite svoj velik seznam funkcij in vsako razvrstite v tri vedra. Vedra so namenoma topa, kajti topost je tisto, kar ustavi neskončne pogovore v slogu »ampak morda«.

• Mora: osrednja zanka brez tega dobesedno ne deluje. Če to odstranite, izdelka ni. Ta seznam naj bo šokantno kratek — običajno tri do šest postavk.
• Naj bi: izdelek naredi boljši, a zanka deluje tudi brez tega. Vse tukaj čaka na drugo različico. Brez izjem v prvi izdelavi.
• Ne bo (zaenkrat): funkcije, ki se jih zavestno odločite zdaj ne graditi. Pomembno jih je zapisati — tako pomirite sebe in svojo ekipo, da zamisel ni opuščena, ampak le razporejena.

Trik, ki to spravi v tek, je tretje vedro. Večina ljudi se prepira le o »mora« proti »naj bi«, kar je izčrpavajoče in se nikoli ne konča. Seznam »ne bo zaenkrat« je kraj, kjer leži olajšanje — je obljuba vašemu prihodnjemu jazu, da je odlična zamisel na varnem in razporejena, le ne zdaj. Ko ljudje verjamejo, da se nič ne zavrže, se nehajo boriti, da bi v prvi različici obdržali vse.

Obseg določajte po času in denarju, ne po seznamu funkcij

Tukaj je tih premik, ki spremeni vse: nehajte določati obseg po »kaj želimo« in ga začnite določati po »kaj se prilega proračunu in roku«. Najprej se odločite, koliko denarja in koliko tednov ste pripravljeni porabiti, da odgovorite na svoje osrednje vprašanje. Nato seznam funkcij vmestite v to škatlo. To se sliši narobe, a je edina najbolj koristna omejitev, ki si jo lahko zadate, ker vsili določanje prednosti, ki bi se mu sicer izognili.

Fiksna škatla naredi tudi nekaj psihološkega. Ko je proračun odprt, je vsaka funkcija sporna in seznam le raste. Ko je škatla fiksna — recimo osem tednov in določen znesek — se pogovor obrne. Neha biti »naj to dodamo?« in postane »kaj izpade, če to vključimo?« To drugo vprašanje je tisto, ki gradi dobre MVP. Kompromisi so vidni namesto skriti in ekipa jih sprejema namenoma.

Resničen primer: krčenje obsega zamisli za upravljanje naročil

Naj to ponazorim s primerom, na katerem smo delali — anonimiziranim, a zvestim temu, kako te stvari potekajo. Majhno podjetje za ogrevanje in vodovodne instalacije je prišlo k nam z željo po aplikaciji za svojo terensko ekipo. Naročilo je bilo na papirju ogromno: živo načrtovanje naročil, GPS-sledenje kombijem, portal za stranke, samodejno izstavljanje računov, evidenca delov v vsakem vozilu, orodje za pripravo ponudb, fotografska dokumentacija in nabor poročil za lastnika. Naposled resnično koristen izdelek. Kot prva izdelava zajamčen način, kako porabiti enoletni proračun, preden se česarkoli naučite.

Zato smo opravili vajo. Lastniku smo zastavili stavek: »Uporabnik pride k temu, da bi ______, in je zadovoljen, če ______.« Po nekaj usklajevanja je priplaval pravi odgovor. Največja vsakdanja bolečina tehnikov ni bila načrtovanje ali izstavljanje računov — bila je papirnata pot tja in nazaj. Dokončali so naročilo, načečkali ure in dele na list, se odpeljali nazaj, in nekdo v pisarni je vse to znova vtipkaval v računovodski sistem, pogosto dneve pozneje, pogosto z napakami. Osrednja zanka je bila preprosto: zajemi, kaj se je pri naročilu zgodilo, enkrat, na kraju samem, da nihče ne tipka znova.

Kaj je prišlo skozi — in kaj ne

Vse je bilo razvrščeno. Vedro mora se je skrčilo na štiri stvari: seznam današnjih naročil za vsakega tehnika, preprost obrazec za beleženje ur in porabljenih delov na naročilo, priponko s fotografijo in način, da pisarna te podatke vidi v trenutku, ko so bili oddani. To je bil celoten MVP. Brez GPS, brez portala za stranke, brez orodja za ponudbe, brez imenitnih poročil — vse to izrecno parkirano na seznamu »ne bo zaenkrat« z opombo, da prihaja.

To jedro smo zgradili v peščici tednov namesto v večjem delu leta. In tukaj je del, ki upravičuje celoten pristop: ko je zaživelo, so se resnične prioritete ekipe izkazale za drugačne od naročila. Lastnik je predvideval, da bo naslednje GPS-sledenje; tehniki so ga komaj omenjali. Kar so glasno želeli, je bilo, da bi stranki iz aplikacije poslali sporočilo s časovnim oknom prihoda — funkcija, ki je sploh ni bilo na prvotnem seznamu. Ker je bil MVP majhen in poceni, je ostalo proračuna, da se zgradi stvar, ki so jo resnično želeli, namesto stvari, ki so jo ugibali mesece prej.

Napake, ki tiho uničijo obseg MVP

Tudi ekipe, ki sprejmejo »naj bo majhno«, se ponavadi spotaknejo ob istih nekaj stvareh. Nobena od njih ni dramatična. So počasna puščanja, ki obseg znova napihujejo, medtem ko ne gledate, dokler nekega dne »minimalni« izdelek spet nima trideset zaslonov in šestmesečnega roka.

• Pozlačevanje robov: dneve porabljati za izpopolnjevanje skrbniške plošče, ki jo boste videli samo vi, medtem ko je osrednja zanka še groba. Zloščite tisto, česar se uporabniki dotikajo; zaledje pustite grdo in funkcionalno.
• Gradnja za obseg, ki ga nimate: snovati arhitekturo za milijon uporabnikov, ko morate dokazati, da se bo prvih deset vrnilo. Problem obsega rešujte, ko boste imeli prijeten problem obsega.
• Mešanje »nujno« in »industrijski standard«: to, da ima vsak konkurent funkcijo X, ne pomeni, da jo vaš MVP potrebuje za preizkus vaše osrednje zamisli. Ne izdajate dokončanega izdelka, izvajate poskus.
• Snovanje vsakega robnega primera vnaprej: obravnavati redke, čudne vnose, preden veste, ali kdo sploh uporablja običajno, normalno pot. Naj vam resnična raba pove, kateri robni primeri so sploh resnični.
• Brez opredelitve dokončanega: brez zapisane vrstice, ki opisuje, kako izgleda »končano«, se izdelava nikoli ne konča. Širjenje obsega obožava projekt brez ciljne črte.

Če se varujete le pred eno od teh, naj bo to zadnja. Jasna, zapisana opredelitev dokončanega — »tehnik lahko ure in dele naročila zabeleži na svojem telefonu, pisarna pa to vidi takoj« — je najmočnejše orodje za ohranjanje obsega poštenega. Vsak predlagan dodatek se prisloni k temu stavku. Če stavku ne služi, je zamisel za drugo različico, naj bo še tako dobra.

Preprost postopek za določanje obsega vašega MVP

Če to povzamem, tukaj je zaporedje, skozi katero bi šel s komerkoli pred začetkom prve izdelave. Namenoma je nizkotehnološko — večino zmorete z dokumentom in iskrenim pogovorom, davno preden v sobi potrebujete razvijalca.

1. 1
   Poimenujte osrednjo zanko

   Dokončajte stavek: »Uporabnik pride, da bi naredil ___, in je zadovoljen, če ___.« Če ne morete, niste pripravljeni na določanje obsega — pogovarjajte se naprej, dokler ne priplava prava naloga.
2. 2
   Izvrzite vsako funkcijo, nato razvrstite

   Spravite celoten seznam želja iz glave na papir. Vsako postavko razvrstite med »mora«, »naj bi« ali »ne bo zaenkrat«. Seznam »mora« naj bo brutalno kratek.
3. 3
   Določite škatlo

   O proračunu in roku se odločite, preden dokončate seznam funkcij. Poskrbite, da se seznam prilega škatli, ne obratno.
4. 4
   Zapišite opredelitev dokončanega

   En konkreten stavek, ki opisuje delujočo osrednjo zanko. To je vaš ščit pred širjenjem obsega do konca projekta.
5. 5
   Gradite, izdajte, opazujte, nato se odločite

   Dostavite jedro resničnim uporabnikom. Opazujte, kaj zares počnejo. Naj njihovo vedenje — ne vaša prejšnja ugibanja — izbere, kaj sledi s seznama »naj bi«.

Opazite, da vas zadnji korak vrne na začetek. Dober MVP ni enkraten dogodek, je prvi zasuk kolesa. Določite majhen obseg, dostavite, učite se, in to, kar se naučite, na novo določi obseg naslednje izdelave. Ekipe, ki zmagujejo, niso tiste, ki so popoln izdelek načrtovale vnaprej — tega ne počne nihče. So tiste, ki so nekaj resničnega postavile pred uporabnike dovolj hitro, da jih je resničnost še lahko usmerjala.

Pogosta vprašanja