Jak definovat MVP a neplýtvat rozpočtem

01Nejprve napište otázku pro další investici

Eric Ries v původní definici MVP spojuje první verzi s ověřeným poznáním zákazníků při omezeném úsilí. Nejde o mechanické zkrácení seznamu funkcí. Vymezte, co potřebujete zjistit, abyste mohli rozhodnout o dalším vývoji. Jinak každý účastník projektu chápe minimum jinak a rozsah postupně roste.

Rozlišujte zájem, použitelnost, technickou proveditelnost a ekonomiku. Rozhovor s nadšeným zájemcem neprokazuje, že skutečný uživatel dokončí úlohu. Funkční integrace zase neříká, kdo za službu zaplatí. Vyberte hlavní nejistotu příští verze a ostatní zapište. Jedna omezená investice nemusí odpovědět na všechny otázky.

Použijme modelovou aplikaci pro rezervaci firemního vybavení. Zaměstnanec najde dostupnou věc, požádá o termín a správce potvrdí předání. Hypotéza může být, že tento postup omezí potřebu opakovaného domlouvání přes e-mail. Je to autorský příklad k ověření, nikoli tvrzení o dosažené úspoře.

Vymezte cílovou skupinu, situaci a potřebný výsledek. První verze pro jednu kancelář nemusí řešit všechny pobočky a složitá schvalování velkého podniku. Připojte rozhodujícího člověka: kdo může na základě výsledku povolit další výdaj, upravit směr nebo projekt zastavit? Bez této pravomoci má ověřování malý praktický účinek.

U firemní aplikace rozlišujte člověka, který ji denně používá, a člověka, který schvaluje její nákup. Mohou potřebovat jiné důkazy. Správce vybavení řeší dokončené předání, vedení celkové náklady a podmínky zavedení. Určete, které rozhodnutí nyní připravujete a od koho potřebujete podklady. Jinak snadno vyhodnotíte nadšení uživatelů jako potvrzení nákupního rozhodnutí.

02Zvolte nejmenší vhodný způsob ověření

MVP nemusí vždy znamenat veřejně dostupnou aplikaci. Forma záleží na otázce. Pro porozumění postupu může stačit prototyp, pro skutečné používání už potřebujete funkční cestu. Ruční zajištění části služby může pomoci poznat potřebu, ale samo nepotvrdí, že ji zvládnete automatizovat a provozovat za přijatelných nákladů.

GOV.UK v doporučeních pro fázi alpha popisuje prototypování rizikových předpokladů a očekávané odložení části kódu. Pro podnikový projekt je užitečný princip vybrat formu podle nejistoty. Britský postup není povinným harmonogramem českého produktu. Předem určete, zda vzniká dočasná pomůcka, nebo verze určená k provozu.

U rezervací nejprve ověřte, zda lidé najdou správné vybavení a rozumějí potvrzení. Jestli se má zkoumat skutečné využívání, potřebujete navíc fungující dostupnost a předání. Část správy může být dočasně ruční. Účastníci mají vědět, jak služba funguje a co od ní mohou očekávat.

03Navrhněte jednu dokončitelnou uživatelskou cestu

Nakreslete začátek, jednotlivé kroky a výsledek. V modelové rezervaci jde o výběr věci, zadání termínu, potvrzení, předání a uzavření. Samostatné přihlášení a katalog bez možnosti získat vybavení tento proces netvoří. Vyberte úzkou cestu, která může být skutečně dokončena ve zvolených podmínkách.

Přidejte potřebné stavy: nedostupný termín, odmítnutí, zrušení a změnu. Rozhodněte, které situace systém podporuje a pro které existuje přehledný ruční postup. Nevyřešená chyba může pokazit pilot a působit jako nezájem. Uživatel přitom mohl službu chtít, jen ji nedokázal použít.

V rozsahu zachyťte také správu, podporu a měření. Zaměstnanec nemusí vidět administrativní obrazovku, ale správce musí umět opravit dostupnost a vyřídit problém. Potřebné oprávnění a ochrana údajů patří k podporované cestě. Minimum omezuje nabídku, nezbavuje tým odpovědnosti za její fungování.

Popište hranice pilotu srozumitelně pro uživatele. Pokud verze podporuje jednu pobočku a konkrétní druh vybavení, uveďte to. Nevykládejte připomínku k nepodporované funkci automaticky jako důvod rozšířit zadání. Nejprve zhodnoťte, zda bez ní nelze odpovědět na původní otázku.

04Z rozsahu udělejte rozhodnutelný podklad

Pro každou položku zapište důvod zařazení, podmínku převzetí a závislost. Rozlišujte nutné pro ověření, nutné pro provoz a odložené. Predikce využití vybavení může být zajímavá, ale pro první ověření rezervace nemusí být potřeba. Funkce, která je někdy užitečná, ještě nemusí patřit do nejbližší verze.

• Cílový uživatel, situace a jedna hlavní hypotéza.
• Podporovaná cesta a jasně vymezené výjimky.
• Zařazené funkce s podmínkami převzetí.
• Odložené možnosti a důvod jejich odložení.
• Závislosti, vlastníci a podmínky zahájení pilotu.
• Způsob měření a rozhodnutí o dalším výdaji.

U podmínky převzetí nahraďte obecné funguje konkrétním scénářem. Správce například potvrdí rezervaci a zaměstnanec uvidí správný stav. Dva lidé nemají bez pravidel dostat stejné vybavení ve stejný termín. Neurčujte implementaci do posledního detailu, ale domluvte očekávané chování a důsledky chyb.

Připomínku během vývoje posuzujte jako změnu rozhodnutí. Co přidává k původní otázce, co stojí a co kvůli ní odložíte? Novou nutnou skutečnost neignorujte. Rozsah ale nemá růst bez souhlasu člověka, který odpovídá za peníze a výsledek. Záznam změny drží společné očekávání i při předání práce.

05Kvalitu a architekturu přizpůsobte skutečnému pilotu

Dohodněte základ kvality pro konkrétní data a účinky. Interní rezervace vybavení a aplikace s platbami mají jiné nároky. Ověřte potřebné přístupy, práci s chybou, zálohu a podporu podle prostředí. Označení MVP není důvodem zveřejnit nechráněná data nebo způsobovat nejasné obchodní operace.

Vyvarujte se architektury pro všechny představitelné budoucnosti. Pro první vymezený proces může být přiměřené jednoduché řešení s přehledným členěním. Rozdělit ho hned do mnoha služeb přináší další provozní práci. Zároveň pojmenujte místa, kde zjednodušení ztíží další krok, aby jej firma nepřehlédla.

Drahou závislost ověřte včas. Pokud se bez rozhraní externího systému neobejdete, zjistěte dostupné operace, přístupy a podmínky před budováním zbytku. Krátký technický experiment může snížit nejistotu integrace. Jeho výsledek ale nezaměňujte s důkazem poptávky po produktu.

U dočasných částí určete vlastníka, omezení a okamžik dalšího rozhodnutí. Ruční zpracování může fungovat pro pilot, dokud tým zvládá požadavky. Evidujte jeho čas a chyby. Pokud by další objem vyžadoval automatizaci, zahrňte ji do nové kalkulace. Pilot nemá skrývat práci, kterou později někdo bude muset zaplatit.

06Uvolňujte rozpočet po vyhodnotitelných krocích

Rozpočet sestavte pro celý krok: přípravu, návrh, vývoj, data, integrace, ověření, podporu a vyhodnocení. Zvlášť evidujte provozní náklady. Odhad bez rozsahu a předpokladů poskytne slabý podklad pro rozhodnutí. Nepoužívejte univerzální cenu MVP; záleží na cestě, prostředí a potřebném ověření.

Rozdělte výdaje na přípravu otázky, vhodný experiment, omezený pilot a případné rozšíření. U každého kroku určete maximální schválený výdaj, potřebný výstup a osobu, která rozhodne o pokračování. Tento návrh není pevnou metodikou pro všechny projekty. Má umožnit reagovat dřív, než se utratí rozpočet za celou představu.

GOV.UK u discovery spojuje pokračování s porozuměním problému, náklady a proveditelnou službou. Připouští také ukončení, pokud další krok nedává smysl. Podobně pro vlastní produkt připravte možnost pokračovat, změnit otázku nebo skončit. Dosavadní výdaj sám neodůvodňuje další investici.

Při odhadu označte otevřené předpoklady. Máte potřebná data a přístup k účastníkům? Kdo dodá obsah a vyřídí podporu? Rezerva nesmí nahrazovat nepojmenovanou zásadní závislost. Před dalším krokem aktualizujte skutečné náklady a přiměřený odhad budoucí práce; automatické navýšení rozpočtu by rozhodování obcházelo.

07Pilot připravte i s pravidly jeho vyhodnocení

Strategyzer Test Card pomáhá předem vyjasnit hypotézu, způsob zkoušky, měření a hranici úspěchu. Určete je ještě před výsledky. Pro rezervace sledujte například dokončené úlohy a potřebnou pomoc správce. Pokud ověřujete ochotu platit, potřebujete odpovídající skutečné jednání, nikoli pouze návštěvy obrazovky.

Dohodněte výběr účastníků, podmínky použití a ukončení zkoušky. Zachyťte neúspěšné pokusy i důvody odmítnutí. Nevydávejte malý pilot s dostupnými známými za reprezentativní výsledek celého trhu. Když nemáte dost použitelných podkladů, popište tuto nejistotu a navrhněte přiměřené doplnění místo silného závěru.

U modelových rezervací si předem vyjasněte, co se počítá jako dokončená úloha a kdy byl nutný zásah správce. Zaznamenejte také důvod, proč člověk přešel zpět k e-mailu. Stejnou definici používejte v celém pilotu. Jestli během zkoušky změníte pravidla nebo podporovanou cestu, označte odlišné podmínky ve výsledcích. Souhrn bez této návaznosti může spojit případy, které ve skutečnosti nelze smysluplně porovnat.

Strategyzer Learning Card odděluje pozorování, výklad a následný krok. Tato disciplína pomůže rozlišit chybné rozhraní, problém procesu a nepotvrzenou potřebu. Výsledek bez návazného rozhodnutí nemusí změnit nic. Sepište, co se skutečně zjistilo a které předpoklady zůstávají otevřené.

Na konci pilotu oddělte opravy první verze od rozšíření pro jinou skupinu či novou úlohu. Znovu určete, co bude další investice ověřovat. Pokud ještě neznáte zájem o samotnou myšlenku, navazuje dřívější průvodce ověřením zájmu před MVP. Definice rozsahu pak převádí další nejistotu do konkrétního zadání.

08Časté otázky k definici MVP