Kako odrediti opseg MVP-a: svedite prvu izradu na ono što je doista važno

Gotovo svatko tko nam dođe s idejom za aplikaciju već je u glavi izgradio njezinu punu inačicu. Mogu opisati nadzornu ploču, stranicu postavki, program preporuka, tamni način rada. Ono što vam obično ne mogu reći jest koji bi jedini dio te slike, kad bi proradio, učinio cijelu stvar vrijednom truda. Određivanje opsega MVP-a neglamurozni je, pomalo bolan posao pronalaženja toga jednog dijela — i hrabrosti da ostatak ostavite za poslije.

Gledao sam kako se gradi mnogo prvih proizvoda, a oni koji muku muče gotovo nikad ne propadaju zato što je tim bio lijen. Propadaju zato što je opseg bio pogrešan već od prvog tjedna. U prvu inačicu nabilo se previše, proračun je presušio prije nego što je itko išta naučio, a do lansiranja je tim potrošio sve samo da bi došao do startne crte — bez preostalog novca da reagira na ono što su pravi korisnici doista radili.

Ovo je dakle vodič koji ljudima dajem prije nego što se napiše ijedan redak koda. Ne radi se o Agile ritualima ni o otmjenim okvirima. Radi se o jednom iskrenom pitanju — koja je najmanja stvar koju možemo izgraditi, a koja nam govori je li ova ideja stvarna? — i o disciplini da na njega stalno odgovaramo dok se napast da dodamo „samo još jednu funkciju” iznova ušulja. Jer uvijek se ušulja.

Što MVP zapravo jest (a što nije)

Izraz se istrošio od prečeste uporabe, pa budimo precizni. Minimalno održiv proizvod najmanja je inačica vaše ideje koja stvarnom korisniku donosi stvarnu vrijednost i uči vas nečemu što ne biste mogli naučiti iz prezentacije. Ključna riječ koju ljudi zaboravljaju jest održiv. Mora doista raditi za nekoga, od početka do kraja, makar radio samo jednu stvar.

Evo što MVP nije. Nije napola dovršena inačica punog proizvoda sa slomljenim kutovima posvuda. Nije prototip koji bacite. I zasigurno nije „jeftina inačica” — jeftinoća je nuspojava dobrog određivanja opsega, a ne cilj. Cilj je učenje. Trošite što manje novca da biste odgovorili na najskuplje pitanje koje imate: hoće li itko ovo koristiti i hoće li to koristiti onako kako ja mislim?

Ta je razlika važnija nego što zvuči. Mentalitet „prvih 20 %” vodi do nečega što je slomljeno u svakom smjeru, a korisno ni u jednom. „Jedna stvar, kako treba” vodi do nečega što osoba može uzeti u ruke, doista koristiti i imati mišljenje o tome. Mišljenja su cijela poanta. Ne možete iterirati na tišini.

Zamka prevelike izrade i zašto je tako lako upasti u nju

Nitko ne kreće s namjerom da prekorači opseg. To se događa jednu po jednu razumnu odluku. Dodate prijavu jer vam, naravno, trebaju računi. Računi znače tijek poništavanja lozinke, i potvrdu e-pošte, i stranicu postavki. Postavke znače profil, što znači učitavanje slika, što znači mjesto za njihovo pohranjivanje. Svaki je korak razuman sam za sebe. Naslagani zajedno, potrošili ste dva mjeseca i dio proračuna prije nego što je dio koji vašu ideju čini posebnom uopće započet.

Druga polovica zamke jest emocionalna. Rezanje funkcija čini se kao priznanje da je vaša ideja mala. Nije — to je priznanje da još ne znate koje su funkcije važne, što je naprosto istina. Svaka funkcija koju izgradite prije nego što imate korisnike oklada je naslijepo. Neke od tih oklada bit će pogrešne, a one koje izrežete iz MVP-a najjeftinije su moguće oklade u kojima možete pogriješiti, jer ih nikad niste ni postavili.

Pronađite jedini posao koji vaš MVP mora obaviti

Svaki proizvod, koliko god velik na kraju postao, ima temeljnu petlju — jedini niz koji korisnik ponavlja i koji stvara vrijednost. Za aplikaciju za rezervacije to je pronađi termin, rezerviraj ga, dobij podsjetnik. Za tržnicu to je postavi nešto, netko to nađe, novac mijenja vlasnika. Za interni alat to je zabilježi podatke jednom, koristi ih svugdje. Sve ostalo u proizvodu postoji da podupre, ukrasi ili proširi tu petlju. Vaš MVP jest petlja. Samo petlja.

Da biste pronašli svoju, dovršite ovu rečenicu naglas: „Korisnik dolazi mom proizvodu da bi ______, i zadovoljan je ako ______.” Prva je praznina posao. Druga je način na koji ćete znati da je uspjelo. Ako obje praznine ne možete ispuniti u jednom dahu, niste još pronašli jezgru — i niste spremni za određivanje opsega, a kamoli za izradu.

Budite nemilosrdni oko razlike između temeljne petlje i stvari koje se čine nužnima, a nisu. Prijava se čini nužnom. Obično nije, u prvoj inačici — mnogi MVP-ovi lansiraju se s jednom dijeljenom poveznicom, ručnim pozivom ili bez računa uopće, i nauče sve što trebaju prije nego što izgrade aparaturu za autentifikaciju. Nadzorne ploče s analitikom čine se nužnima. Nisu; bazu podataka možete čitati ručno dok imate jedanaest korisnika. Svedite na petlju i začudit ćete se koliko toga otpadne.

Razvrstajte svaku funkciju u „mora”, „trebalo bi” i „neće (zasad)”

Kad ste imenovali temeljnu petlju, uzmite svoj veliki popis funkcija i svaku razvrstajte u tri košare. Košare su namjerno grube, jer grubost je ono što zaustavlja beskrajne razgovore u stilu „ali možda”.

• Mora: temeljna petlja doslovno ne radi bez toga. Ako to uklonite, nema proizvoda. Neka ovaj popis bude šokantno kratak — obično tri do šest stavki.
• Trebalo bi: čini proizvod boljim, ali petlja i dalje radi bez toga. Sve ovdje čeka inačicu dva. Bez iznimaka u prvoj izradi.
• Neće (zasad): funkcije koje svjesno odlučujete sada ne graditi. Zapisivanje njih je važno — tako uvjeravate sebe, i svoj tim, da se ideja ne napušta, nego samo raspoređuje.

Trik koji to čini djelotvornim jest treća košara. Većina ljudi prepire se samo oko „mora” naspram „trebalo bi”, što je iscrpljujuće i nikad ne završava. Popis „neće zasad” mjesto je gdje leži olakšanje — to je obećanje vašem budućem ja da je kul ideja sigurna i raspoređena, samo ne sada. Kad ljudi povjeruju da se ništa ne baca, prestanu se boriti da sve zadrže u prvoj inačici.

Određujte opseg prema vremenu i novcu, ne prema popisu funkcija

Evo tihe promjene koja mijenja sve: prestanite određivati opseg prema „što želimo” i počnite ga određivati prema „što stane u proračun i rok”. Najprije odlučite koliko ste novca i koliko tjedana spremni potrošiti da odgovorite na svoje temeljno pitanje. Zatim uklopite popis funkcija u tu kutiju. Ovo zvuči naopako, ali to je jedino najkorisnije ograničenje koje si možete zadati, jer iznuđuje određivanje prioriteta koje biste inače izbjegavali.

Fiksna kutija čini i nešto psihološko. Kad je proračun neograničen, svaka je funkcija upitna i popis samo raste. Kad je kutija fiksna — recimo, osam tjedana i utvrđeni iznos — razgovor se preokreće. Prestaje biti „trebamo li ovo dodati?” i postaje „što izlazi ako ovo uđe?” To drugo pitanje gradi dobre MVP-ove. Kompromisi su vidljivi umjesto skriveni, a tim ih radi namjerno.

Stvaran primjer: sužavanje opsega ideje za upravljanje poslovima

Da to konkretiziram slučajem na kojem smo radili — anonimiziranim, ali vjernim tome kako ovakve stvari teku. Mala tvrtka za grijanje i vodoinstalacije došla nam je želeći aplikaciju za svoj terenski tim. Brief je, na papiru, bio golem: planiranje poslova uživo, GPS-praćenje kombija, korisnički portal, automatsko fakturiranje, popis dijelova u svakom vozilu, alat za izradu ponuda, fotografska dokumentacija i izvještajni paket za vlasnika. Doista koristan proizvod, naposljetku. Kao prva izrada, zajamčen način da potrošite jednogodišnji proračun prije nego što išta naučite.

Pa smo napravili vježbu. Postavili smo vlasniku rečenicu: „Korisnik dolazi ovome da bi ______, i zadovoljan je ako ______.” Nakon nešto natezanja isplivao je pravi odgovor. Najveća svakodnevna muka tehničara nije bila planiranje ni fakturiranje — bio je to papirnati put naprijed-natrag. Završili bi posao, naškrabali sate i dijelove na list, odvezli se natrag, a netko u uredu sve bi to ponovno utipkavao u računovodstveni sustav, često danima poslije, često s pogreškama. Temeljna petlja bila je naprosto: zabilježi što se na poslu dogodilo, jednom, na licu mjesta, da nitko ne tipka ponovno.

Što je prošlo — a što nije

Sve je razvrstano. Košara mora svela se na četiri stvari: popis današnjih poslova za svakog tehničara, jednostavan obrazac za bilježenje sati i utrošenih dijelova po poslu, privitak fotografije i način da ured vidi te podatke u trenutku kad su poslani. To je bio cijeli MVP. Bez GPS-a, bez korisničkog portala, bez alata za ponude, bez otmjenog izvještavanja — sve to izričito parkirano na popisu „neće zasad” uz napomenu da dolazi.

Tu smo jezgru izgradili u nekoliko tjedana umjesto u dobrom dijelu godine. I evo dijela koji opravdava cijeli pristup: čim je proradilo, pravi prioriteti tima pokazali su se drukčijima od briefa. Vlasnik je pretpostavio da će GPS-praćenje biti sljedeće; tehničari su ga jedva spominjali. Ono što su glasno željeli bilo je poslati kupcu poruku s vremenom dolaska iz same aplikacije — funkcija koja nije ni bila na izvornom popisu. Budući da je MVP bio malen i jeftin, ostalo je proračuna da se izgradi ono što su doista htjeli, umjesto onoga što su pogađali mjesecima ranije.

Pogreške koje potiho upropaste opseg MVP-a

Čak i timovi koji prihvate „neka bude maleno” skloni su spotaknuti se o istih nekoliko stvari. Nijedna nije dramatična. To su spora curenja koja iznova napuhuju opseg dok ne gledate, sve dok jednog dana „minimalni” proizvod opet nema trideset zaslona i šestomjesečni rok.

• Pozlaćivanje rubova: trošiti dane na usavršavanje administratorske ploče koju ćete vidjeti samo vi, dok je temeljna petlja još gruba. Ulaštite ono što korisnici dotiču; pozadinu ostavite ružnom i funkcionalnom.
• Gradnja za razmjer koji nemate: projektirati arhitekturu za milijun korisnika kad trebate dokazati da će se prvih deset vratiti. Problem razmjera rješavajte kad budete imali ugodan problem razmjera.
• Brkanje „mora imati” s „industrijski standard”: to što svaki konkurent ima funkciju X ne znači da je vašem MVP-u potrebna da bi testirao vašu temeljnu ideju. Ne lansirate gotov proizvod, provodite pokus.
• Osmišljavanje svakog rubnog slučaja unaprijed: rješavati rijetke, čudne unose prije nego što znate koristi li itko uobičajenu, normalnu putanju. Neka vam stvarna uporaba kaže koji su rubni slučajevi uopće stvarni.
• Bez definicije gotovog: bez zapisane rečenice koja opisuje kako izgleda „dovršeno”, izrada nikad ne završava. Širenje opsega obožava projekt bez ciljne crte.

Ako se čuvate samo jedne od ovih, neka to bude posljednja. Jasna, zapisana definicija gotovog — „tehničar može zabilježiti sate i dijelove posla na svom telefonu, a ured to vidi odmah” — najmoćniji je alat za održavanje opsega poštenim. Svaki predloženi dodatak prislanja se uz tu rečenicu. Ako ne služi rečenici, ideja je za inačicu dva, koliko god dobra bila.

Jednostavan postupak za određivanje opsega vašeg MVP-a

Da sve to spojim, evo niza kroz koji bih prošao sa svakim prije početka prve izrade. Namjerno je niskotehnološki — većinu možete obaviti s dokumentom i iskrenim razgovorom, davno prije nego što vam u prostoriji zatreba programer.

1. 1
   Imenujte temeljnu petlju

   Dovršite rečenicu: „Korisnik dolazi da bi ___, i zadovoljan je ako ___.” Ako ne možete, niste spremni za određivanje opsega — nastavite razgovarati dok ne ispliva pravi posao.
2. 2
   Izbacite svaku funkciju, pa razvrstajte

   Izvadite cijeli popis želja iz glave na papir. Svaku stavku razvrstajte u „mora”, „trebalo bi” ili „neće zasad”. Neka popis „mora” bude okrutno kratak.
3. 3
   Fiksirajte kutiju

   Odlučite proračun i rok prije dovršenja popisa funkcija. Učinite da popis stane u kutiju, a ne obrnuto.
4. 4
   Napišite definiciju gotovog

   Jedna konkretna rečenica koja opisuje radnu temeljnu petlju. To je vaš štit protiv širenja opsega do kraja projekta.
5. 5
   Gradite, lansirajte, promatrajte, pa odlučite

   Isporučite jezgru stvarnim korisnicima. Promatrajte što doista rade. Neka njihovo ponašanje — a ne vaše ranije pretpostavke — odabere što sljedeće dolazi s popisa „trebalo bi”.

Primijetite da vas posljednji korak vraća na početak. Dobar MVP nije jednokratan događaj, on je prvi okret kotača. Odredite mali opseg, isporučite, učite, a ono što naučite iznova određuje opseg sljedeće izrade. Timovi koji pobjeđuju nisu oni koji su unaprijed isplanirali savršen proizvod — nitko to ne radi. To su oni koji su nešto stvarno stavili pred korisnike dovoljno brzo da ih stvarnost još može usmjeravati.

Česta pitanja