Jak vytvořit MVP bez zbytečných funkcí

MVP není zmenšená kopie celého budoucího produktu. Je to první funkční verze, která má ověřit, zda produkt řeší důležitý problém a zda ho lidé dokážou používat v praxi.

Neznamená to ale, že se má hned po schválení nápadu začít programovat. U většiny projektů dává smysl nejdříve ověřit proces, hlavní scénáře a podobu rozhraní pomocí wireframů nebo klikacího prototypu. Teprve potom lze rozumně rozhodnout, co patří do první funkční verze a co může počkat.

Dobré MVP proto nevzniká pouze škrtáním funkcí. Vzniká postupným snižováním nejistoty: nejprve ověříte problém, potom návrh řešení a nakonec chování produktu v reálném provozu.

Prototyp, proof of concept a MVP nejsou totéž

Tyto pojmy se často zaměňují, přesto slouží k různým účelům.

Wireframe nebo klikací prototyp

Prototyp pomáhá ověřit, zda jsou obrazovky, návaznosti a hlavní pracovní postup pochopitelné. Nemusí obsahovat skutečná data ani funkční backend.

Je vhodný například tehdy, když potřebujete s klientem nebo budoucími uživateli projít:

• jak bude uživatel postupovat;
• které informace bude zadávat;
• co uvidí po dokončení jednotlivých kroků;
• kde mohou vznikat nejasnosti;
• které části procesu jsou zbytečně složité.

Změnit prototyp je výrazně levnější než předělávat hotovou aplikaci. Proto má tato fáze smysl i u projektů, které se později budou vyvíjet jako plnohodnotný systém.

Proof of concept

Proof of concept ověřuje hlavně technickou proveditelnost. Může jít například o test napojení na externí systém, zpracování velkého množství dat nebo ověření, zda zvolená technologie zvládne kritickou část projektu.

Výsledek nemusí být použitelný pro běžného uživatele. Jeho cílem je zjistit, zda konkrétní technické řešení funguje.

MVP

MVP je první funkční verze produktu určená k reálnému používání, obvykle omezenému počtu uživatelů nebo zákazníků.

Nemusí obsahovat všechny budoucí funkce. Měla by ale umožnit ověřit hlavní hodnotu produktu. Část interních kroků může být v první fázi záměrně prováděna ručně, pokud to nezkresluje to, co chcete ověřit.

Například zákazník může přes aplikaci odeslat požadavek a obdržet výsledek, zatímco některé interní zpracování ještě probíhá ručně. To může být rozumný způsob, jak ověřit poptávku dříve, než se investuje do úplné automatizace.

Nejdříve určete, co chcete ověřit

Před seznamem funkcí je potřeba stanovit cíl první verze.

Může jít například o ověření, zda:

• zákazníci mají o řešení skutečný zájem;
• uživatelé dokážou dokončit hlavní proces;
• nový systém zkrátí konkrétní pracovní postup;
• jsou zákazníci ochotni za službu platit;
• produkt sníží chybovost nebo množství ruční práce;
• zvolený distribuční kanál dokáže přivést relevantní uživatele.

Bez jasného cíle nelze po spuštění rozumně vyhodnotit, zda MVP uspělo. Tým může dodat mnoho funkcí, ale stále nebude vědět, zda řešil správný problém.

Začněte hlavním pracovním postupem

Při návrhu MVP je užitečné popsat jeden hlavní scénář od začátku do konce.

Například u systému pro správu obchodních partnerů může pracovní postup vypadat takto:

1. Uživatel založí nového partnera.
2. Doplní potřebné údaje a dokumenty.
3. Odpovědná osoba provede kontrolu.
4. Partner je schválen nebo vrácen k doplnění.
5. Systém uchová stav a historii změn.

Teprve potom má smysl řešit jednotlivé obrazovky a funkce.

Původní seznam požadavků může obsahovat dashboard, mobilní aplikaci, více jazyků, pokročilé reporty, veřejné API a desítky filtrů. Pro první ověření ale mohou být důležité pouze evidence partnerů, nahrání dokumentů, schválení a historie změn.

Rozsah MVP se tedy neurčuje podle toho, co by produkt jednou mohl umět. Určuje se podle toho, co je potřeba pro ověření hlavního přínosu.

Jak rozhodnout, co patří do první verze

U každé funkce je vhodné položit několik otázek.

Je funkce nutná pro hlavní scénář?

Pokud bez ní uživatel nedokončí proces, pravděpodobně do MVP patří.

Je nutná pro pilotní provoz?

Do této skupiny mohou podle typu projektu patřit například:

• přihlášení;
• základní oprávnění;
• správa účtů;
• ochrana citlivých dat;
• logování chyb;
• základní administrace;
• zálohování;
• napojení na klíčový externí systém.

Konkrétní rozsah závisí na typu produktu, zpracovávaných datech, počtu uživatelů a rizicích projektu. Interní nástroj pro několik zaměstnanců má jiné požadavky než veřejná aplikace pracující s osobními nebo finančními údaji.

Ověřuje funkce důležitý předpoklad?

Některá funkce nemusí být součástí hlavního scénáře, ale může být nutná pro ověření obchodního modelu. U placeného SaaS produktu může jít například o zkušební tarif, objednávku nebo základní způsob platby.

Lze funkci dočasně nahradit ručním postupem?

Pokud ano, je potřeba posoudit, zda ruční řešení nezkreslí výsledek.

Ruční schválení nového účtu může být v pilotu přijatelné. Ruční vytváření výsledku, který má být hlavní hodnotou automatizovaného produktu, už může vést k falešnému závěru o funkčnosti řešení.

Je funkce potřebná až při větším provozu?

Pokročilé reporty, mnoho integrací, rozsáhlé role nebo automatizace výjimečných situací mohou být důležité později, ale nemusí patřit do první verze.

Praktická matice priorit

Otázka	Typické rozhodnutí
Bez funkce nelze ověřit hlavní hodnotu	Zařadit do MVP
Bez funkce nelze bezpečně nebo spolehlivě spustit pilot	Zařadit nebo zvolit jednodušší náhradu
Funkce ověřuje důležitý obchodní předpoklad	Zařadit podle cíle MVP
Funkci lze dočasně řešit ručně bez zkreslení výsledku	Zvážit odklad
Funkce zvyšuje komfort, ale nemění hlavní přínos	Přesunout do další fáze
Funkce bude nutná až při větším počtu uživatelů	Přesunout do další fáze
Funkce řeší vzácnou výjimku	Obvykle odložit

Matice nenahrazuje rozhodnutí týmu, ale pomáhá oddělit skutečně důležité části od požadavků, které pouze zvětšují rozsah.

Rozsah nestačí určit, musí se také chránit

MVP se často prodraží až během vývoje. Jednotlivé změny vypadají malé, ale jejich součet může ovlivnit datový model, oprávnění, testování i termín.

Proto je vhodné před zahájením vývoje jasně popsat:

• hlavní scénář;
• seznam funkcí první verze;
• co do první verze nepatří;
• předpoklady a omezení;
• způsob vyhodnocení výsledku;
• postup schvalování změn.

Neznamená to, že se zadání nesmí změnit. Změny jsou běžné. Měly by ale být vědomé a tým by měl znát jejich dopad na cenu, termín a technické řešení.

Jak vypadá rozumný postup vývoje MVP

Konkrétní proces se liší podle velikosti a typu projektu. V praxi ale často dává smysl následující postup.

1. Rozbor problému a současného procesu

Nejdříve je potřeba pochopit, co se dnes děje, kde vzniká problém a kdo ho skutečně řeší.

2. Vymezení hlavního scénáře

Tým určí, jakou konkrétní hodnotu má první verze dodat a jak se bude její přínos hodnotit.

3. Wireframy nebo prototyp

Klient a případně budoucí uživatelé projdou hlavní tok aplikace ještě před vývojem. V této fázi lze levně opravit nejasnosti v zadání a rozhraní.

U jednodušších interních nástrojů může být prototyp velmi základní. U složitějšího produktu může být potřeba více kol ověření.

4. Technický návrh

Po upřesnění scénářů se řeší datový model, integrace, oprávnění, provozní požadavky a základní architektura.

Cílem není navrhnout konečný systém pro všechny možné budoucí potřeby. Cílem je zvolit řešení odpovídající prvnímu provozu a zároveň se vyhnout zbytečným technickým slepým uličkám.

5. Vývoj po menších částech

Průběžné ukázky snižují riziko, že klient uvidí výsledek až na konci a zjistí, že některé části chápe jinak.

Ukázka rozpracované funkce ale není náhradou za předchozí návrh. Je to způsob, jak kontrolovat, že se vývoj drží schváleného směru.

6. Pilotní provoz

První verze se nasadí omezené skupině uživatelů. V této fázi se sleduje nejen technická funkčnost, ale také to, zda lidé rozumějí procesu a zda produkt přináší očekávaný výsledek.

7. Vyhodnocení a další etapa

Teprve data z provozu ukážou, co má smysl automatizovat, zjednodušit, rozšířit nebo naopak odstranit.

Technický základ: ani jednorázový prototyp, ani systém pro milion uživatelů

U MVP vznikají dvě časté chyby.

První je technické řešení, které bylo vytvořeno pouze pro rychlou ukázku, ale začne se používat jako produkční systém. Každá další změna je potom drahá a riziková.

Druhou chybou je zbytečně složitá architektura navržená pro provoz, který možná nikdy nenastane. Tým investuje čas do škálování, oddělených služeb nebo infrastruktury, i když ještě není ověřeno, zda produkt někdo potřebuje.

Rozumné řešení odpovídá očekávanému pilotnímu provozu a typu rizik. Mělo by mít přehlednou strukturu, rozumný datový model a základní provozní dohled. Nemusí ale předem řešit každý budoucí scénář.

Ani dobře navržené MVP nezaručí, že se část systému později nebude muset změnit. Zpětná vazba může změnit pracovní postup, obchodní model i cílovou skupinu. Smyslem technického návrhu je omezit zbytečné přepisování, ne slíbit, že k němu nikdy nedojde.

Co testovat před pilotem

Rozsah testování se odvíjí od rizika.

Největší pozornost obvykle vyžadují:

• hlavní pracovní postup;
• oprávnění a přístup k datům;
• výpočty;
• platby;
• ukládání důležitých dat;
• integrace s externími systémy;
• procesy, jejichž selhání by způsobilo finanční nebo právní problém.

Není nutné automatizovat každý test. Kritické části by ale měly být ověřeny tak, aby běžná chyba neznehodnotila celý pilot.

Co měřit po spuštění

Metriky musí odpovídat cíli MVP.

U komerčního SaaS produktu může být důležité sledovat:

• kolik uživatelů dokončí registraci;
• kolik z nich dosáhne hlavního momentu hodnoty;
• zda se k produktu vracejí;
• zda jsou ochotni přejít na placenou verzi.

U interního systému mohou být důležitější jiné výsledky:

• zkrácení času procesu;
• snížení počtu chyb;
• menší množství ruční práce;
• rychlejší schválení;
• lepší dohledatelnost změn;
• menší závislost na tabulkách a e-mailech.

Čísla je vhodné doplnit rozhovory a pozorováním reálného používání. Uživatel může proces dokončit, ale s velkým úsilím. Naopak nízké používání funkce nemusí znamenat, že je zbytečná. Možná ji lidé nenašli nebo jí nerozumějí.

Nejčastější chyby při tvorbě MVP

Vývoj začne dříve než návrh

Tým začne programovat na základě obecné představy. Nejasnosti se potom řeší až v kódu, kde jsou změny dražší.

První verze obsahuje celý budoucí produkt

Příliš velký rozsah prodlouží dobu bez reálné zpětné vazby a zvyšuje cenu změn.

MVP je zaměněno za nekvalitní řešení

Omezený rozsah neznamená, že mohou být ignorována rizika, práce s daty nebo základní provozní potřeby.

Ruční práce zakryje skutečný problém

Dočasný ruční proces může být užitečný, ale nesmí vytvářet dojem, že produkt zvládá něco, co ve skutečnosti závisí na neúměrném množství práce lidí.

Tým nemá předem stanovené metriky

Po spuštění potom není jasné, zda produkt uspěl, ani které změny mají přednost.

Rozsah se mění bez vyhodnocení dopadu

Malé požadavky se hromadí a projekt se prodlužuje, aniž by někdo vědomě rozhodl o změně ceny, termínu nebo cíle.

Jak k návrhu MVP přistupujeme v Nextrey

U projektů v Nextrey se snažíme nejprve pochopit problém a hlavní pracovní postup. Podle typu projektu může následovat jednoduchý wireframe, klikací prototyp nebo technické ověření rizikové části.

Teprve po upřesnění scénářů dává smysl stanovit rozsah vývoje první funkční verze. Konkrétní postup se liší podle složitosti produktu, dostupného rozpočtu, požadavků na bezpečnost a toho, co má MVP ověřit.

Smyslem této přípravy není prodlužovat projekt další analýzou. Má snížit riziko, že se bude vyvíjet něco, co klient nebo uživatelé potřebují jinak.

Závěr

Dobré MVP není nejmenší množství kódu ani rychle vytvořená ukázka. Je to první funkční verze navržená kolem konkrétního problému a jasného cíle ověření.

V praxi často dává smysl nejprve připravit prototyp, projít ho s klientem nebo budoucími uživateli a teprve potom zahájit vývoj. Rozsah první verze by měl být dostatečně malý, aby bylo možné získat zpětnou vazbu v rozumném čase, ale zároveň dostatečný pro ověření hlavní hodnoty produktu.

Pokud připravujete SaaS produkt, interní systém nebo webovou aplikaci, nejdůležitější otázka nezní „kolik funkcí stihneme“. Důležitější je, co potřebujete zjistit a jaká nejjednodušší verze vám dá spolehlivou odpověď.