Jak vymezit rozsah MVP: omezte svou první verzi na to, na čem skutečně záleží

Skoro každý, kdo k nám přijde s nápadem na aplikaci, si její plnou verzi už postavil v hlavě. Dokáže popsat přehledový panel, stránku nastavení, doporučovací program, tmavý režim. Co vám obvykle říct nedokáže, je která jediná část toho obrazu by, kdyby fungovala, učinila celou věc smysluplnou. Vymezení rozsahu MVP je neefektní a trochu bolestivá práce, jak tu jedinou část najít — a mít dost odvahy nechat zbytek na později.

Viděl jsem vznikat spoustu prvních produktů a ty, které se trápí, téměř nikdy neselžou proto, že by byl tým líný. Selžou proto, že rozsah byl od prvního týdne špatný. Do první verze se nacpalo příliš mnoho, rozpočet došel dřív, než se kdokoli cokoli naučil, a v době spuštění tým utratil vše jen na to, aby se dostal na startovní čáru — bez peněz, které by zbyly na reakci na to, co skuteční uživatelé doopravdy dělali.

Toto je tedy návod, který lidem dávám předtím, než se napíše jediný řádek kódu. Nejde o agilní rituály ani o nóbl frameworky. Jde o jednu poctivou otázku — jaká je nejmenší věc, kterou můžeme postavit a která nám řekne, zda je tento nápad skutečný? — a o disciplínu na ni dál odpovídat, jak se zpět vkrádá pokušení přidat „už jen jednu funkci“. Protože ono se vždycky vkrádá zpět.

Co MVP doopravdy je (a co není)

Ten výraz se nadužíváním ohladil, buďme tedy přesní. Minimální životaschopný produkt je nejmenší verze vašeho nápadu, která přináší skutečnou hodnotu skutečnému uživateli a naučí vás něco, co byste se z prezentace nedozvěděli. Klíčové slovo, na které lidé zapomínají, je životaschopný. Musí pro někoho skutečně fungovat, od začátku do konce, i kdyby dělal jen jedinou věc.

Tady je, co MVP není. Není to polorozdělaná verze plného produktu s rozbitými rohy na všech stranách. Není to prototyp, který zahodíte. A rozhodně to není „levná verze“ — levnost je vedlejší efekt dobrého vymezení rozsahu, ne cíl. Cílem je učení. Utrácíte co nejméně peněz, abyste zodpověděli tu nejdražší otázku, kterou máte: použije to vůbec někdo, a použije to tak, jak si myslím?

Tento rozdíl je důležitější, než zní. Myšlení „prvních 20 %“ vede k věci, která je rozbitá ve všech směrech a užitečná v žádném. „Jedna věc, udělaná pořádně“ vede k něčemu, co může člověk vzít do ruky, doopravdy použít a utvořit si na to názor. Názory jsou celý smysl. Na ticho se iterovat nedá.

Past přílišného stavění a proč je tak snadné do ní spadnout

Nikdo se nepouští do předimenzování rozsahu úmyslně. Děje se to jedním rozumným rozhodnutím za druhým. Přidáte přihlášení, protože samozřejmě potřebujete účty. Účty znamenají tok obnovy hesla, ověření e-mailu a stránku nastavení. Nastavení znamenají profil, což znamená nahrávání obrázků, což znamená místo, kam je uložit. Každý krok je sám o sobě rozumný. Naskládané dohromady jste utratili dva měsíce a kus rozpočtu dřív, než vůbec začala ta část, která dělá váš nápad výjimečným.

Druhá polovina pasti je emocionální. Škrtání funkcí působí jako přiznání, že váš nápad je malý. Není — je to přiznání, že ještě nevíte, na kterých funkcích záleží, což je prostě pravda. Každá funkce, kterou postavíte dřív, než máte uživatele, je sázka naslepo. Některé z těch sázek budou špatné a ty, které z MVP vyškrtnete, jsou nejlevnější možné sázky, ve kterých se můžete mýlit, protože jste je nikdy nevsadili.

Najděte jediný úkol, který vaše MVP musí plnit

Každý produkt, jakkoli velký se nakonec stane, má základní smyčku — jedinou sekvenci, kterou uživatel opakuje a která vytváří hodnotu. U rezervační aplikace je to najít termín, zarezervovat ho, dostat připomenutí. U tržiště je to vystavit věc, někdo ji najde, peníze změní majitele. U interního nástroje je to zachytit data jednou, použít je všude. Všechno ostatní v produktu existuje proto, aby tu smyčku podpořilo, ozdobilo nebo rozšířilo. Vaše MVP je ta smyčka. Jen ta smyčka.

Abyste tu svou našli, dokončete nahlas tuto větu: „Uživatel přichází k mému produktu, aby ______, a je spokojený, pokud ______.“ První mezera je úkol. Druhá je, jak poznáte, že to fungovalo. Pokud nedokážete obě mezery vyplnit jedním dechem, jádro jste ještě nenašli — a nejste připraveni vymezovat rozsah, natož stavět.

Buďte nesmlouvaví ohledně rozdílu mezi základní smyčkou a věcmi, které působí nezbytně, ale nejsou. Přihlášení působí nezbytně. V první verzi obvykle není — spousta MVP se spustí s jediným sdíleným odkazem, ruční pozvánkou nebo úplně bez účtů a naučí se vše potřebné dřív, než postaví ověřovací mašinerii. Analytické panely působí nezbytně. Nejsou; databázi si můžete přečíst ručně, když máte jedenáct uživatelů. Strhněte to zpět na smyčku a budete žasnout, kolik toho odpadne.

Roztřiďte každou funkci na: musí, mělo by a zatím ne

Jakmile pojmenujete základní smyčku, vezměte svůj velký seznam funkcí a roztřiďte každou do tří košů. Koše jsou záměrně neomalené, protože právě neomalenost zastaví nekonečné rozhovory ve stylu „ale možná“.

• Musí: základní smyčka bez toho doslova nefunguje. Když to odeberete, žádný produkt není. Tento seznam udržujte šokujícně krátký — obvykle tři až šest položek.
• Mělo by: dělá produkt lepším, ale smyčka funguje i bez toho. Vše zde čeká na druhou verzi. V první verzi žádné výjimky.
• Zatím ne: funkce, které se vědomě rozhodnete teď nestavět. Zapsat si je je důležité — tak ujistíte sebe i svůj tým, že nápad není opuštěn, jen seřazen do pořadí.

Trik, díky kterému to funguje, je třetí koš. Většina lidí se hádá jen o „musí“ versus „mělo by“, což je vyčerpávající a nikdy nekončí. Seznam „zatím ne“ je místo, kde žije úleva — je to slib vašemu budoucímu já, že skvělý nápad je v bezpečí a naplánovaný, jen ne teď. Jakmile lidé uvěří, že se nic nezahazuje, přestanou bojovat o to, aby v první verzi udrželi všechno.

Vymezujte rozsah podle času a peněz, ne podle seznamu funkcí

Tady je tichý posun, který mění všechno: přestaňte vymezovat rozsah podle „co chceme“ a začněte ho vymezovat podle „co se vejde do rozpočtu a termínu“. Nejdřív rozhodněte, kolik peněz a kolik týdnů jste ochotni utratit na zodpovězení své základní otázky. Pak seznam funkcí vměstnejte do téhle krabice. Zní to pozpátku, ale je to to nejužitečnější omezení, jaké si můžete dát, protože vynucuje stanovení priorit, kterému byste se jinak vyhýbali.

Pevná krabice dělá i něco psychologického. Když je rozpočet otevřený, každá funkce je diskutabilní a seznam jen roste. Když je krabice pevná — řekněme osm týdnů a daná částka — rozhovor se obrátí. Přestane být „měli bychom tohle přidat?“ a stane se „co vypadne, pokud tohle přidáme?“ Právě tato druhá otázka staví dobrá MVP. Kompromisy jsou viditelné místo skryté a tým je dělá záměrně.

Reálný příklad: zmenšení rozsahu nápadu na správu terénních zakázek

Ukážu to konkrétně na případu, na kterém jsme pracovali — anonymizovaném, ale věrném tomu, jak to chodí. Malá topenářská a instalatérská firma k nám přišla, že chce aplikaci pro svůj terénní tým. Zadání bylo na papíře obrovské: živé plánování zakázek, GPS sledování dodávek, zákaznický portál, automatická fakturace, evidence dílů v každém vozidle, tvůrce nabídek, fotodokumentace a sada reportů pro majitele. Nakonec opravdu užitečný produkt. Jako první verze ovšem zaručený způsob, jak utratit roční rozpočet dřív, než se cokoli naučíte.

Tak jsme udělali to cvičení. Položili jsme majiteli tu větu: „Uživatel k tomu přichází, aby ______, a je spokojený, pokud ______.“ Po menším přetahování vyplynula skutečná odpověď. Největší každodenní bolestí techniků nebylo plánování ani fakturace — byl to papírový kolotoč tam a zpět. Dokončili zakázku, načmárali hodiny a díly na list, dojeli zpátky a někdo v kanceláři to vše znovu přepisoval do účetního systému, často s odstupem dnů, často s chybami. Základní smyčka byla prostě: zachyť, co se na zakázce stalo, jednou, přímo na místě, aby to nikdo nepřepisoval.

Co se do rozsahu dostalo — a co ne

Vše se roztřídilo. Koš musí se smrskl na čtyři věci: seznam dnešních zakázek pro každého technika, jednoduchý formulář pro zaznamenání hodin a použitých dílů u každé zakázky, přílohu fotografie a způsob, jak kancelář uvidí ta data ve chvíli, kdy byla odeslána. To bylo celé MVP. Žádné GPS, žádný zákaznický portál, žádný tvůrce nabídek, žádné nóbl reporty — vše výslovně odloženo na seznam „zatím ne“ s poznámkou, že to přijde.

To jádro jsme postavili za pár týdnů namísto skoro roku. A teď ta část, která celý přístup ospravedlňuje: jakmile to bylo v provozu, ukázalo se, že skutečné priority týmu se od zadání liší. Majitel předpokládal, že další na řadě bude GPS sledování; technici se o něm sotva zmínili. Co hlasitě chtěli, bylo poslat zákazníkovi z aplikace SMS s časovým oknem příjezdu — funkci, která na původním seznamu vůbec nebyla. Protože MVP bylo malé a levné, zbyl rozpočet na to postavit věc, kterou doopravdy chtěli, místo té, kterou před měsíci tipovali.

Chyby, které potichu zničí rozsah MVP

I týmy, které princip „udržte to malé“ přijmou za svůj, mívají sklon klopýtnout o stejných pár věcí. Žádná z nich není dramatická. Jsou to pomalé úniky, které rozsah znovu nafouknou, zatímco se nedíváte, až jednoho dne má „minimální“ produkt zase třicet obrazovek a půlroční harmonogram.

• Zlacení okrajů: trávit dny laděním administračního panelu, který uvidíte jen vy, zatímco základní smyčka je pořád hrubá. Vyleštěte to, čeho se uživatelé dotýkají; zázemí nechte ošklivé, ale funkční.
• Stavění na rozsah, který nemáte: navrhovat architekturu pro milion uživatelů, když potřebujete dokázat, že se vrátí prvních deset. Problém rozsahu řešte, až budete mít ten šťastný problém s rozsahem.
• Záměna „nezbytné“ za „standard v oboru“: jen proto, že každý konkurent má funkci X, neznamená, že ji vaše MVP potřebuje k otestování vašeho základního nápadu. Nespouštíte hotový produkt, provádíte experiment.
• Navrhování každého okrajového případu předem: řešit vzácné, divné vstupy dřív, než víte, zda někdo používá běžnou, normální cestu. Nechte skutečné používání, ať vám řekne, které okrajové případy vůbec existují.
• Žádná definice hotového: bez napsané věty popisující, jak vypadá „dokončeno“, stavba nikdy neskončí. Bobtnání rozsahu miluje projekt bez cílové čáry.

Pokud se budete bránit jen jediné z nich, ať je to ta poslední. Jasná, napsaná definice hotového — „technik dokáže na telefonu zaznamenat hodiny a díly zakázky a kancelář to vidí okamžitě“ — je tím nejmocnějším nástrojem, jak udržet rozsah poctivý. Každý navržený přídavek se přiloží k té větě. Pokud té větě neslouží, je to nápad pro druhou verzi, ať je sebelepší.

Jednoduchý postup pro vymezení rozsahu vašeho MVP

Když to dáme dohromady, tady je posloupnost, kterou bych s kýmkoli prošel před zahájením první verze. Je záměrně nízkotechnologická — většinu zvládnete s dokumentem a poctivým rozhovorem, dávno předtím, než budete v místnosti potřebovat vývojáře.

1. 1
   Pojmenujte základní smyčku

   Dokončete větu: „Uživatel přichází, aby ___, a je spokojený, pokud ___.“ Pokud nemůžete, nejste připraveni vymezovat rozsah — mluvte dál, dokud nevyplyne skutečný úkol.
2. 2
   Vysypte každou funkci, pak třiďte

   Dostaňte celý seznam přání z hlavy na papír. Roztřiďte každou položku na musí, mělo by, nebo zatím ne. Seznam „musí“ udržujte brutálně krátký.
3. 3
   Zafixujte krabici

   Rozhodněte o rozpočtu a termínu dřív, než finalizujete seznam funkcí. Seznam vměstnejte do krabice, ne naopak.
4. 4
   Napište definici hotového

   Jedna konkrétní věta popisující fungující základní smyčku. To je váš štít proti bobtnání rozsahu po zbytek projektu.
5. 5
   Postavte, spusťte, sledujte, pak rozhodněte

   Dodejte jádro skutečným uživatelům. Sledujte, co doopravdy dělají. Nechte jejich chování — ne vaše dřívější odhady — rozhodnout, co dál vyjde ze seznamu „mělo by“.

Všimněte si, že poslední krok vás vrací zpět na začátek. Dobré MVP není jednorázová událost, je to první otočka kola. Vymezíte malý rozsah, dodáte, naučíte se a to, co se naučíte, znovu vymezí rozsah další verze. Týmy, které vyhrávají, nejsou ty, které dopředu naplánovaly dokonalý produkt — to nedělá nikdo. Jsou to ty, které dostaly něco skutečného před uživatele dost rychle na to, aby je realita ještě mohla nasměrovat.

Časté dotazy