MVP mobilní aplikace: co do něj patří a co ne

Co MVP je a co není

MVP — minimální životaschopný produkt — je nejmenší verze, kterou ověříte jeden konkrétní předpoklad. Nejčastěji ten, že problém, který řešíte, lidi pálí natolik, že si kvůli němu stáhnou aplikaci a použijí ji.

Není to tedy levnější verze hotové aplikace, ani prototyp, který jen vypadá jako aplikace, ani beta bez chyb. Slovo minimální se vztahuje k rozsahu funkcí, ne ke kvalitě provedení. MVP, které padá nebo ztrácí data, neověří nic — uživatelé odejdou kvůli chybám a vy se nedozvíte, jestli je zajímal produkt.

Užitečná kontrolní otázka na začátek: jakou otázku má první vydání zodpovědět? Pokud na ni nedokážete odpovědět jednou větou, rozsah se během vývoje rozroste, protože nebude podle čeho rozhodovat.

Co do prvního vydání patří

Do MVP patří jedna hlavní úloha od začátku do konce a nic, co s ní přímo nesouvisí. Konkrétně:

• Průchod hlavní úlohou. Uživatel přijde, udělá to podstatné a odejde s výsledkem. Bez slepých uliček.
• Nejjednodušší možné přihlášení, a to jen pokud je nutné. Často stačí přihlášení přes Apple nebo Google, případně vůbec žádné.
• Měření. Musíte vidět, kolik lidí úlohu začne a kolik ji dokončí. Bez toho nepoznáte, co MVP ukázalo.
• Způsob, jak dát zpětnou vazbu. Stačí odkaz na e-mail. První uživatelé vám řeknou víc než čísla.

Všechno ostatní je kandidát na odložení — a odložit se dá překvapivě mnoho, aniž by to ohrozilo smysl testu.

Co se skoro vždy dá odložit

Tohle jsou funkce, které se do zadání dostávají automaticky a v prvním vydání zpravidla nejsou potřeba:

• Obrazovka nastavení. Když je čeho nastavovat málo, není co nastavovat.
• Push notifikace. Dávají smysl, až když víte, kdy má smysl uživatele vyrušit.
• Druhá platforma. Ověřit se dá na jedné; druhá zdvojnásobí náklad i dobu.
• Vlastní administrace. První měsíce se dá spravovat přes tabulku nebo hotový nástroj.
• Onboarding s tutoriálem. Pokud aplikace potřebuje návod, obvykle je problém v návrhu, ne v chybějícím návodu.
• Sociální funkce a sdílení. Dávají smysl, až když je co sdílet a mezi kým.

Užitečné pravidlo při škrtání: u každé funkce se zeptejte, co se stane, když v prvním vydání nebude. Když odpověď zní „bude to méně pohodlné“, škrtejte. Když zní „hlavní úloha nepůjde dokončit“, zůstává.

Nejčastější chyby

MVP, které není minimální. Nejběžnější a nejdražší chyba. Zadání obsahuje patnáct funkcí, protože „bez toho to nedává smysl“, a vývoj trvá osm měsíců. Odpověď na otázku, jestli o produkt někdo stojí, tak přijde o půl roku později, než mohla — a za mnohem víc peněz.

MVP bez měření. Aplikace se vydá, něco se stáhne, ale nikdo neví, kolik lidí došlo do konce hlavní úlohy. Bez toho se výsledek vykládá podle nálady.

Šetření na špatném místě. Škrtat se má rozsah, ne kvalita základů. Aplikace bez ošetřených chyb, bez zálohovaných dat nebo s rozbitým přihlášením neověří nic, protože uživatelé odejdou z jiného důvodu, než jste zkoumali.

Prototyp vydávaný za MVP. Klikací návrh v Figmě je skvělý nástroj na ověření, jestli je rozhraní srozumitelné. Neověří ale, jestli lidé produkt použijí v reálném životě, protože v prototypu nejsou jejich data ani jejich situace.

Jak poznat, že MVP odpovědělo

Před vydáním si napište, jaký výsledek bude znamenat pokračování. Ne obecné „bude zájem“, ale číslo: kolik procent uživatelů dokončí hlavní úlohu, kolik se jich vrátí druhý týden, kolik jich je ochotno zaplatit.

Ta hranice se stanovuje předem, protože po vydání je každé číslo vysvětlitelné oběma směry. Padesát stažení je málo, nebo hodně? Bez předem stanoveného kritéria se odpověď přizpůsobí tomu, co si přejete slyšet.

Sledujte přitom dokončení úlohy a návratnost, ne počet stažení. Stažení říká, jak dobře funguje propagace; návrat druhý týden říká, jestli je produkt k něčemu.

Časté otázky

Jak dlouho trvá vývoj MVP?

Dobře ohraničené MVP jedné hlavní úlohy na jedné platformě zabere tři až čtyři měsíce od zadání po vydání, z toho zhruba měsíc připadá na návrh a přípravu. Když slyšíte odhad šest týdnů, jde obvykle o prototyp bez backendu, nebo o rozsah, který se během vývoje rozroste. Delší než půl roku už zpravidla není MVP, ale první verze plného produktu.

Na které platformě začít?

Na té, kde jsou vaši první uživatelé, ne na obou. V Česku má Android větší podíl zařízení, ale u placených produktů a firemních aplikací bývá na iOS vyšší ochota platit. Když opravdu potřebujete obě platformy hned, zvažte React Native nebo Flutter — ušetří část nákladů, byť ne polovinu, jak se někdy slibuje.

Musí mít MVP hezký design?

Musí být srozumitelné, což není totéž jako vypiplané. Uživatel odejde kvůli tomu, že nepochopí, co má udělat, ne kvůli nedokonalé ikoně. Investujte do návrhu hlavní obrazovky a průchodu úlohou; na animace, ilustrace a jemné doladění je čas, až budete vědět, že o produkt někdo stojí.

Co když MVP ukáže, že o produkt není zájem?

Pak splnilo svůj účel a ušetřilo vám peníze, které byste jinak utratili za plnou verzi. To je celý smysl toho postupu. Praktické je předem si říct, jaký výsledek bude znamenat pokračování a jaký ne — po vydání se totiž čísla vykládají překvapivě kreativně.

Závěr

MVP je nástroj na získání odpovědi, ne zlevněná verze produktu. Čím dřív odpověď přijde, tím levněji vás stojí — proto se vyplácí škrtat rozsah agresivněji, než je příjemné.

Konkrétní rozpočty a co všechno se do ceny promítá rozebíráme v článku kolik stojí vývoj mobilní aplikace. Pro odhad prvního vydání počítejte se spodní částí uvedených rozpětí, pokud se vám podaří udržet rozsah u jedné úlohy.