Ako vymedziť rozsah MVP: orežte prvú verziu na to, na čom naozaj záleží

Takmer každý, kto k nám príde s nápadom na aplikáciu, si jej úplnú verziu už postavil v hlave. Vedia opísať nástenku, stránku nastavení, odporúčací program, tmavý režim. Čo vám zvyčajne nedokážu povedať, je, ktorá jediná časť toho obrazu by, keby fungovala, urobila celú vec hodnou námahy. Vymedzenie rozsahu MVP je neglamúrová, mierne bolestivá práca nájsť tú jednu časť — a mať odvahu zvyšok nechať na neskôr.

Videl som vznikať množstvo prvých produktov a tie, ktoré majú problémy, takmer nikdy nezlyhajú preto, že tím bol lenivý. Zlyhajú preto, že rozsah bol nesprávny už od prvého týždňa. Do prvej verzie sa napchalo priveľa, rozpočet vyschol skôr, než sa ktokoľvek čokoľvek naučil, a do spustenia tím minul všetko len na to, aby sa dostal na štartovaciu čiaru — bez peňazí, ktoré by zostali na reakciu na to, čo skutoční používatelia naozaj robili.

Toto je teda návod, ktorý ľuďom dávam skôr, než sa napíše jediný riadok kódu. Nie je o Agile rituáloch ani o vznešených frameworkoch. Je o jednej úprimnej otázke — aká je najmenšia vec, ktorú dokážeme postaviť a ktorá nám povie, či je tento nápad skutočný? — a o disciplíne neustále na ňu odpovedať, keď sa pokušenie pridať „len ešte jednu funkciu“ znova vkráda. Pretože sa vkráda vždy.

Čo MVP naozaj je (a čo nie je)

Tento výraz sa nadmerným používaním ošúchal, tak buďme presní. Minimálne životaschopný produkt je najmenšia verzia vášho nápadu, ktorá prináša skutočnú hodnotu skutočnému používateľovi a naučí vás niečo, čo by ste sa z prezentácie nedozvedeli. Kľúčové slovo, na ktoré ľudia zabúdajú, je životaschopný. Musí pre niekoho naozaj fungovať, od začiatku do konca, aj keď robí len jednu vec.

Tu je, čím MVP nie je. Nie je to napoly hotová verzia úplného produktu s rozbitými rohmi všade naokolo. Nie je to prototyp, ktorý zahodíte. A rozhodne to nie je „lacná verzia“ — lacnosť je vedľajší účinok dobrého vymedzenia rozsahu, nie cieľ. Cieľom je učenie. Miniete čo najmenej peňazí, aby ste odpovedali na najdrahšiu otázku, akú máte: použije to vôbec niekto, a použije to tak, ako si myslím?

Tento rozdiel je dôležitejší, než znie. Myslenie typu „prvých 20 %“ vedie k niečomu, čo je rozbité do všetkých strán a užitočné v žiadnej. „Jedna vec, poriadne“ vedie k niečomu, čo si človek môže vziať, naozaj použiť a mať na to názor. Názory sú celý zmysel. Na tichu sa iterovať nedá.

Pasca prílišného budovania a prečo je tak ľahké do nej spadnúť

Nikto nevychádza so zámerom prekročiť rozsah. Deje sa to jedným rozumným rozhodnutím za druhým. Pridáte prihlásenie, lebo, samozrejme, potrebujete účty. Účty znamenajú tok obnovy hesla, overenie e-mailu a stránku nastavení. Nastavenia znamenajú profil, čo znamená nahrávanie obrázkov, čo znamená miesto na ich uloženie. Každý krok je sám osebe rozumný. Naskladané dokopy ste minuli dva mesiace a kus rozpočtu skôr, než sa časť, ktorá robí váš nápad výnimočným, vôbec začala.

Druhá polovica pasce je emocionálna. Orezávanie funkcií vyzerá ako priznanie, že váš nápad je malý. Nie je — je to priznanie, že ešte neviete, ktoré funkcie sú dôležité, čo je jednoducho pravda. Každá funkcia, ktorú postavíte skôr, než máte používateľov, je stávka naslepo. Niektoré z tých stávok budú nesprávne a tie, ktoré z MVP vyškrtnete, sú najlacnejšie možné stávky, v ktorých sa môžete mýliť, lebo ste ich nikdy nepostavili.

Nájdite jedinú úlohu, ktorú vaše MVP musí splniť

Každý produkt, akokoľvek veľkým sa nakoniec stane, má základnú slučku — jedinú postupnosť, ktorú používateľ opakuje a ktorá vytvára hodnotu. Pri rezervačnej aplikácii je to nájdi termín, rezervuj ho, dostaň pripomienku. Pri trhovisku je to vystav niečo, niekto to nájde, peniaze zmenia majiteľa. Pri internom nástroji je to zachyť údaje raz, používaj ich všade. Všetko ostatné v produkte existuje preto, aby túto slučku podporilo, ozdobilo alebo rozšírilo. Vaše MVP je tá slučka. Len tá slučka.

Aby ste našli tú svoju, dokončite túto vetu nahlas: „Používateľ prichádza k môjmu produktu, aby ______, a je spokojný, ak ______.“ Prvá medzera je úloha. Druhá je to, ako budete vedieť, že to fungovalo. Ak obe medzery nedokážete vyplniť na jeden nádych, ešte ste nenašli jadro — a nie ste pripravení vymedziť rozsah, nieto budovať.

Buďte nemilosrdní voči rozdielu medzi základnou slučkou a vecami, ktoré pôsobia nevyhnutne, ale nie sú. Prihlásenie pôsobí nevyhnutne. Zvyčajne nie je, v prvej verzii — mnoho MVP sa spustí s jediným zdieľaným odkazom, ručnou pozvánkou alebo úplne bez účtov a naučia sa všetko potrebné skôr, než postavia autentifikačnú mašinériu. Analytické nástenky pôsobia nevyhnutne. Nie sú; databázu si môžete čítať ručne, kým máte jedenásť používateľov. Orežte to na slučku a budete prekvapení, koľko toho odpadne.

Roztrieďte každú funkciu na „musí“, „malo by“ a „nebude (zatiaľ)“

Keď ste pomenovali základnú slučku, vezmite si svoj veľký zoznam funkcií a každú roztrieďte do troch košov. Koše sú zámerne tupé, lebo tuposť je to, čo zastaví nekonečné rozhovory typu „ale možno“.

• Musí: základná slučka bez toho doslova nefunguje. Ak to odstránite, niet produktu. Tento zoznam udržujte šokujúco krátky — zvyčajne tri až šesť položiek.
• Malo by: robí produkt lepším, ale slučka funguje aj bez toho. Všetko tu čaká na verziu dva. Žiadne výnimky v prvej verzii.
• Nebude (zatiaľ): funkcie, ktoré sa vedome rozhodnete teraz nestavať. Zapísať si ich je dôležité — takto uisťujete seba aj svoj tím, že nápad sa neopúšťa, len zaraďuje do poradia.

Trik, ktorý to rozbehne, je tretí kôš. Väčšina ľudí sa háda len o „musí“ verzus „malo by“, čo je vyčerpávajúce a nikdy to nekončí. Zoznam „nebude zatiaľ“ je miesto, kde je úľava — je to sľub vášmu budúcemu ja, že skvelý nápad je v bezpečí a naplánovaný, len nie teraz. Keď ľudia uveria, že sa nič nezahadzuje, prestanú bojovať o to, aby v prvej verzii zostalo všetko.

Vymedzujte rozsah podľa času a peňazí, nie podľa zoznamu funkcií

Tu je tichý posun, ktorý mení všetko: prestaňte vymedzovať rozsah podľa „čo chceme“ a začnite ho vymedzovať podľa „čo sa zmestí do rozpočtu a termínu“. Najprv sa rozhodnite, koľko peňazí a koľko týždňov ste ochotní minúť, aby ste odpovedali na svoju základnú otázku. Potom do tej krabice vmestite zoznam funkcií. Znie to naopak, ale je to to jediné najužitočnejšie obmedzenie, aké si môžete dať, lebo si vynucuje stanovenie priorít, ktorému by ste sa inak vyhli.

Pevná krabica robí aj niečo psychologické. Keď je rozpočet otvorený, každá funkcia je sporná a zoznam len rastie. Keď je krabica pevná — povedzme osem týždňov a stanovená suma — rozhovor sa preklopí. Prestáva byť „mali by sme toto pridať?“ a stáva sa „čo vypadne, ak toto pridáme?“ Tá druhá otázka je tá, ktorá buduje dobré MVP. Kompromisy sú viditeľné namiesto skryté a tím ich robí zámerne.

Skutočný príklad: zúženie rozsahu nápadu na správu zákaziek

Dovoľte mi to konkretizovať na prípade, na ktorom sme pracovali — anonymizovanom, ale vernom tomu, ako to chodí. Malá kúrenárska a vodoinštalatérska firma k nám prišla so želaním aplikácie pre svoj terénny tím. Zadanie bolo na papieri obrovské: živé plánovanie zákaziek, GPS sledovanie dodávok, zákaznícky portál, automatická fakturácia, evidencia dielov v každom vozidle, nástroj na tvorbu cenových ponúk, fotografická dokumentácia a sada prehľadov pre majiteľa. Naozaj užitočný produkt, napokon. Ako prvá verzia zaručený spôsob, ako minúť ročný rozpočet skôr, než sa čokoľvek naučíte.

Tak sme urobili to cvičenie. Položili sme majiteľovi tú vetu: „Používateľ k tomu prichádza, aby ______, a je spokojný, ak ______.“ Po istom dohadovaní vyplávala skutočná odpoveď. Najväčšou každodennou bolesťou technikov nebolo plánovanie ani fakturácia — bola to papierová cesta tam a späť. Dokončili zákazku, naškrabali hodiny a diely na papier, odviezli sa späť a niekto v kancelárii to všetko nanovo prepisoval do účtovného systému, často o dni neskôr, často s chybami. Základná slučka bola jednoducho: zachyť, čo sa na zákazke udialo, raz, priamo na mieste, aby to nikto neprepisoval znova.

Čo prešlo — a čo nie

Všetko sa roztriedilo. Kôš musí sa zúžil na štyri veci: zoznam dnešných zákaziek pre každého technika, jednoduchý formulár na zaznamenanie hodín a použitých dielov na zákazku, prílohu s fotografiou a spôsob, akým kancelária uvidí tieto údaje vo chvíli, keď boli odoslané. To bolo celé MVP. Žiadne GPS, žiadny zákaznícky portál, žiadny nástroj na ponuky, žiadne vznešené prehľady — to všetko bolo výslovne zaparkované v zozname „nebude zatiaľ“ s poznámkou, že to prichádza.

To jadro sme postavili za pár týždňov namiesto väčšej časti roka. A tu je tá časť, ktorá ospravedlňuje celý prístup: keď to bolo spustené, skutočné priority tímu sa ukázali byť iné než zadanie. Majiteľ predpokladal, že nasledovať bude GPS sledovanie; technici ho sotva spomenuli. Čo nahlas chceli, bolo poslať zákazníkovi z aplikácie textovú správu s časovým oknom príchodu — funkcia, ktorá v pôvodnom zozname ani nebola. Keďže MVP bolo malé a lacné, zostal rozpočet na to, aby sa postavila vec, ktorú naozaj chceli, namiesto veci, ktorú hádali mesiace predtým.

Chyby, ktoré ticho zničia rozsah MVP

Aj tímy, ktoré prijmú „udržuj to malé“, majú sklon zakopnúť o tých istých pár vecí. Ani jedna z nich nie je dramatická. Sú to pomalé úniky, ktoré nanovo nafukujú rozsah, kým sa nepozeráte, až kým jedného dňa „minimálny“ produkt opäť nemá tridsať obrazoviek a šesťmesačný harmonogram.

• Pozlacovanie okrajov: tráviť dni dolaďovaním administrátorského panela, ktorý uvidíte len vy, kým je základná slučka ešte hrubá. Vyleštite to, čoho sa používatelia dotýkajú; zázemie nechajte škaredé a funkčné.
• Stavanie pre rozsah, ktorý nemáte: navrhovať architektúru pre milión používateľov, keď potrebujete dokázať, že sa prvých desať vráti. Problém rozsahu riešte, keď budete mať príjemný problém rozsahu.
• Zamieňanie „nevyhnutné“ s „odvetvový štandard“: to, že každý konkurent má funkciu X, neznamená, že ju vaše MVP potrebuje na otestovanie vášho základného nápadu. Nespúšťate hotový produkt, robíte experiment.
• Navrhovanie každého hraničného prípadu vopred: ošetrovať zriedkavé, čudné vstupy skôr, než viete, či vôbec niekto používa bežnú, normálnu cestu. Nechajte skutočné používanie, nech vám povie, ktoré hraničné prípady sú vôbec reálne.
• Žiadna definícia hotového: bez napísaného riadku, ktorý opisuje, ako vyzerá „dokončené“, sa práca nikdy neskončí. Rozpínanie rozsahu miluje projekt bez cieľovej čiary.

Ak sa máte chrániť len pred jednou z nich, nech je to tá posledná. Jasná, napísaná definícia hotového — „technik dokáže zaznamenať hodiny a diely zákazky na svojom telefóne a kancelária to vidí okamžite“ — je najmocnejší nástroj na udržanie rozsahu čestným. Každý navrhovaný prírastok sa priloží k tej vete. Ak neslúži tej vete, je to nápad na verziu dva, akokoľvek dobrý.

Jednoduchý postup na vymedzenie rozsahu vášho MVP

Aby som to spojil dokopy, tu je postupnosť, ktorou by som prešiel s kýmkoľvek pred začatím prvej verzie. Je zámerne nízkotechnologická — väčšinu z nej zvládnete s dokumentom a úprimným rozhovorom dávno predtým, než v miestnosti potrebujete vývojára.

1. 1
   Pomenujte základnú slučku

   Dokončite vetu: „Používateľ prichádza, aby urobil ___, a je spokojný, ak ___.“ Ak nedokážete, nie ste pripravení vymedziť rozsah — hovorte ďalej, kým nevyplytaná skutočná úloha.
2. 2
   Vysypte každú funkciu, potom roztrieďte

   Dostaňte celý zoznam želaní z hlavy na papier. Každú položku roztrieďte na „musí“, „malo by“ alebo „nebude zatiaľ“. Zoznam „musí“ udržujte brutálne krátky.
3. 3
   Stanovte krabicu

   Rozhodnite o rozpočte a termíne skôr, než dokončíte zoznam funkcií. Prispôsobte zoznam krabici, nie naopak.
4. 4
   Napíšte definíciu hotového

   Jedna konkrétna veta opisujúca fungujúcu základnú slučku. To je váš štít proti rozpínaniu rozsahu po zvyšok projektu.
5. 5
   Stavajte, spustite, pozorujte, potom sa rozhodnite

   Dodajte jadro skutočným používateľom. Pozorujte, čo naozaj robia. Nechajte ich správanie — nie vaše skoršie dohady — vybrať, čo nasleduje zo zoznamu „malo by“.

Všimnite si, že posledný krok vás vracia na začiatok. Dobré MVP nie je jednorazová udalosť, je to prvé otočenie kolesa. Vymedzíte malý rozsah, dodáte, naučíte sa a to, čo sa naučíte, nanovo vymedzí rozsah ďalšej verzie. Tímy, ktoré vyhrávajú, nie sú tie, ktoré si dokonalý produkt naplánovali vopred — to nikto nerobí. Sú to tie, ktoré dostali niečo skutočné pred používateľov dosť rýchlo na to, aby ich realita ešte mohla nasmerovať.

Časté otázky