Jak vytvořit MVP v Agile

Ve světě pokusů a omylů vyhrává ten, kdo nejrychleji najde chyby. Někteří lidé tomuto přístupu říkají „fail fast“. Eric Ries jej nazývá Lean, zatímco Kent Beck a další vývojáři softwaru jej nazývají Agile.

Ať už tomu říkáte jakkoli, jde o to, co nejrychleji zjistit, které z vašich předpokladů ohledně produktu jsou chybné, a to získáním zpětné vazby od skutečných uživatelů.

Agilní metodika předpokládá rozdělení vývoje produktu do sprintů, což umožňuje snížit rizika a rychle reagovat na požadované změny.

Protože je agilní metodika postavena na myšlence iterativního procesu založeného na zpětné vazbě od zákazníků, hraje MVP při agilním vývoji ústřední roli.

Vytvoření minimálního životaschopného produktu (MVP) pomáhá dodat nový produkt s dostatečným množstvím funkcí, které uspokojí první uživatele, což umožňuje získat cennou zpětnou vazbu a později vybudovat kompletní sadu funkcí.

Koncept MVP se většinou praktikuje v softwarovém průmyslu k ověření životaschopnosti produktu. Pokud hledáte společnost, která pro vás MVP vytvoří, podívejte se na tuto společnost zabývající se vývojem softwaru.

Většina softwaru se dnes vyvíjí pomocí agilní metodiky. V agilním prostředí často uslyšíte slovní spojení minimální životaschopný produkt (MVP).

Tento termín jednoduše znamená: co nejméně funkční věc, kterou můžete vytvořit a která bude dostatečně dobře řešit příležitost pro většinu vašich cílových zákazníků a ověří váš trh a produkt.

Jinými slovy, kdybyste se zamysleli nad základní funkcí, kterou se snažíte zákazníkům umožnit, jaký nejjednodušší produkt můžete vytvořit, aby jim umožnil dosáhnout tohoto cíle.

Řekněme, že jste se vrátili v čase a pracovali jste na první verzi aplikace pro noviny. Hlavní funkcí aplikace by bylo informování čtenářů. Proto by nejjednodušším produktem, který byste mohli vytvořit, byl seznam novinových titulků a tlačítko pro aktualizaci.

Klíčem k úspěšné MVP je opět zaměření se na základní hodnotu, kterou aplikace poskytuje, tedy čerstvé zprávy, a ne trávit čas budováním dalších funkcí aplikace.

Všimněte si, že MVP neznamená, že by produkt měl být špatný. Pravdou je, že by měl být velmi dobrý v tom, co dělá, ale měl by se zaměřit na provádění pouze několika základních funkcí.

Zjednodušeně řečeno, hlavní charakteristiky MVP jsou:

  • Má dostatečnou hodnotu, aby jej lidé byli ochotni zpočátku používat nebo kupovat
  • Prokazuje dostatečné budoucí přínosy, aby si udržel první uživatele
  • Zajišťuje smyčku zpětné vazby pro řízení budoucího vývoje

Proč byste měli při vývoji MVP používat agilní metodiku?

Klíčovým rozdílem mezi agilní metodikou a ostatními metodikami je, že agilní metodika využívá MVP. Při agilním přístupu vytvoříte co nejjednodušší věc, shromáždíte data o tom, jak ji zákazníci používají, a pak produkt v případě potřeby zdokonalíte.

To vám umožní pracovat poměrně efektivně a budovat pouze funkce, které zákazníci chtějí a budou používat, místo abyste ztráceli čas budováním věcí, o které zákazníci nemají zájem.

Srovnejte to s přístupy k vývoji produktů, které nejsou založeny na MVP. Při použití jiných přístupů můžete nakonec strávit spoustu času snahou vytvořit „dokonalý“ produkt se všemi funkcemi, které si dokážete představit, ale jakmile je v reálném světě, zjistíte, že zákazníci nepoužívají ani polovinu funkcí, o kterých jste si mysleli, že je budou používat.

Tady je příklad agilního minimálního životaschopného produktu (MVP):

Zdroj: Dropbox

Drew Houston – generální ředitel společnosti Dropbox, se rozhodl vytvořit MVP pro startup cloudového úložiště ve formě videa.

Natočil vysvětlující video a sdílel ho se svou sítí, aby zjistil reakce lidí. Tříminutové video vysvětlovalo, co je Dropbox, a ukazovalo, jak by lidem pomohl.

Po zveřejnění videa společnost přes noc zvýšila počet přihlášených do „předběžného přístupu“ z 5 000 na 75 000 lidí – to vše, aniž by měla skutečný produkt.

Hlavní výhody budování MVP (agile) tedy jsou:

  • Počáteční výzkum spotřebitelů

Čím rychleji se produkt dostane k cílovému uživateli, tím dříve získáte zpětnou vazbu a analyzujete problémy či preference zákazníka. Pokud uživatelé nepovažují váš MVP za hodnotný, máte prostor pro otočení a otestování dalších hodnotových nabídek.

Nebo, pokud je tomu naopak, budete mít jistotu, že vyvinuté funkce jsou pro cílové klienty užitečné, takže můžete pokračovat dál. V nejhorším případě můžete projekt zmrazit a snížit tak své ztráty.

  • Fáze testování

Největší výhodou vývoje MVP je, že umožňuje testovat různé obchodní modely a koncepty.

Pokud nabídnete spíše základní sadu funkcí než produkt s velkým množstvím funkcí, můžete ověřit, zda jejich koncept produktu rezonuje s vaším obchodním modelem, což poskytuje příležitost změnit směr produktu na základě zjištění.

Na rozdíl od produktů s velkým množstvím funkcí budete mít po spuštění MVP možnost zjistit, jaké typy sociálních skupin jsou nejaktivnějšími uživateli, jak s produktem interagují a jak jej můžete zpeněžit.

  • Nákladová efektivita

Kvalitní produkty jsou výsledkem dlouholetého vývoje s odpovídající cenovkou. Protože však tyto produkty vznikaly iterativně po delší dobu, jsou náklady rozloženy v čase.

Přístup MVP také pomáhá šetřit tím, že zabraňuje přílišné komplikovanosti produktu. Jakmile se produkt začne více prosazovat a shromažďovat více informací o tom, jakým směrem se produkt ubírá, můžete své investice zvýšit nebo snížit.

Pokud máte zájem dozvědět se více o agilních metodikách a metodice SCRUM, doporučujeme vám, abyste si přečetli tento článek od SCRUM Institute o tom, jak se stát SCRUM masterem v podrobném postupu krok za krokem. Nabízejí také celosvětově nejoblíbenější a cenově nejvýhodnější certifikační programy Scrum.

Proces budování MVP (Agile)

Když už víte, co je MVP, proč se v Agile používá a jaké jsou jeho výhody, pojďme se podívat na 6 kroků potřebných pro vytvoření MVP.

Krok č. 1: Určete, jaký problém řešíte a pro koho

Při vývoji verze nových produktů není většina lidí dostatečně důsledná při definování problémů, které se snaží vyřešit, a při formulování toho, proč jsou tyto problémy důležité. Bez tohoto procesu může produkt promarnit příležitosti a plýtvat zdroji. Proto je třeba se zlepšit v kladení správných otázek, aby řešily správné problémy.

Podívejte se na svůj nápad na produkt a zeptejte se sami sebe:

  • Kdo je vaše cílová skupina?“

Pokud se v této fázi zaseknete, zkuste identifikovat své osobní problémy. Existuje něco, co byste dokázali dělat lépe, kdybyste měli správný nástroj?

  • Proč vaše cílová skupina potřebuje tento produkt?“

To vám pomůže určit hlavní cíl vašeho produktu a řešení potřeb vašich potenciálních zákazníků.

  • V jaké situaci by ho použili?“

Zdroj: Metabeta

Poznámka: V procesu zjišťování odpovědí na výše uvedené otázky je důležité, aby vše bylo reálné a aby se navíc dělaly odhady času a nákladů.

Krok č. 2: Analýza konkurence

Jakmile jste přišli na to, jaký problém řešíte, je čas podívat se, jak tento problém řeší – nebo se alespoň snaží řešit – ostatní firmy. V tomto okamžiku je zřejmé, že musíte provést analýzu konkurence, pokud jsou na trhu podobné výrobky.

Měli byste také mít na paměti, že i když si myslíte, že nemáte žádné přímé konkurenty, vaše víra v jedinečnost vašeho výrobku bude důvodem pro sebevědomé uvedení vašeho výrobku na trh.

Krok č. 3: Definujte uživatelský tok, wireframe & návrhu

Definice uživatelského toku vašeho budoucího produktu zahrnuje, že se zaměříte přímo na svůj hlavní cíl. Abychom mohli definovat hlavní uživatelský tok, měli bychom nejprve definovat fáze procesu, což je vlastně snadné, protože stačí vysvětlit kroky potřebné k dosažení primárního cíle vašeho produktu.

V tomto bodě byste neměli přemýšlet o funkcích – ale měli byste se zaměřit na základní úkoly, jako jsou typy cílů, které mají vaši koncoví uživatelé, když používají váš produkt, jejich očekávání atd.

Jakmile jste hotovi s definováním uživatelského toku, můžete přejít k wireframingu, což je jednoduše ilustrace webové stránky nebo aplikace. Drátěný rámec je rozvržení, které vyjadřuje, jaké prvky rozhraní najdou místo na důležitých stránkách.

Příklad drátěného rámce:

Design uživatelského rozhraní (UI) spojuje koncepty interakčního designu, vizuálního designu a informační architektury. Zde byste měli zúročit to, co jste se naučili v předchozích fázích, abyste vytvořili zážitek, který koncového uživatele překvapí a potěší.

Ve společnosti Cleevio, když máme hotový první prototyp (obvykle klikací maketu), provádíme uživatelské testování. Uživatelské testování je pro úspěch nové aplikace zásadní. Když máme výsledky uživatelského testování hotové, iterujeme wireframy a znovu je testujeme na uživatelích.

Po otestování wireframů je třeba přejít do fáze návrhu, která by měla být pro každou platformu (iOS, Android, web,…) jiná.

Krok č. 4: Analyzujte své funkce

Víte, že více než 45 % funkcí zabudovaných v softwarových produktech se používá jen zřídka nebo nikdy?

Teď, když jste vytvořili svůj uživatelský tok, můžete začít vytvářet podrobnější seznam funkcí pro každou konkrétní fázi, ale s ohledem na statistiky.

Poté, co jste si stanovili funkce pro jednotlivé fáze, budete je muset seřadit podle priorit. Jakou nejdůležitější činnost chcete, aby vaši uživatelé provedli? To bude vaše hlavní funkce.

Jednou z metod prioritizace funkcí je MoSCoW, která se používá k rozhodnutí, které funkce je třeba dokončit nejdříve, které musí přijít později a které vyloučit. Další technika používaná pro měření nezbytnosti funkcí je založena na obchodní hodnotě (čas na vývoj vs. nice to have vs. náklady)

Zdroj: ProductPlan

Krok č. 5: Vývoj & Testování

Teď, když znáte funkce svého minimálního životaschopného produktu (MVP), je čas uvést je do praxe. Přesunete-li se do fáze vývoje, musíte svůj produkt otestovat a pracovat na zlepšení jeho kvality.

Po schválení wireframů byste měli začít pracovat na architektuře nastavení, databázi a začít vyvíjet API, administraci a veškerý back-end.

Zde vám může pomoci alfa a beta testování, které patří mezi nejoblíbenější způsoby testování výkonu produktu v různých scénářích. Dbejte na to, abyste testování sladili a prováděli pouze ty změny, které ovlivňují celou uživatelskou zkušenost.

Standardně byste měli před spuštěním aplikace provést následující testy v kontrolovaném prostředí:

  • Testování funkčnosti
  • Testování použitelnosti
  • Testování kompatibility
  • Testování davu
  • Testování rozhraní
  • Testování výkonu
  • Testování bezpečnosti

V průběhu vývoje byste měli průběžně testovat všechny implementované funkce.

Například ve společnosti Cleevio vytváříme mobilní aplikace a vydání beta sestavení jsou nahrávána do alfa/beta testování Google a do TestFlight společnosti Apple. Interní testovací sestavení jsou v Appcenteru (oficiální nástroj společnosti Microsoft).

Když je „release candidate“ (produkt připravený pro trh) hotový, provádíme otevřené nebo uzavřené beta testování, kdy do beta testovacího programu pozveme co nejvíce relevantních uživatelů a sbíráme zpětnou vazbu ohledně funkčnosti a chyb.

Krok č. 6: Iterativně se dostaňte k tomu, abyste produkt přizpůsobili trhu nebo selhali

Pokud ověříte MVP, můžete se začít zabývat rozsahem svého produktu a rozšířit jej. V tomto okamžiku buď získáte startovní kapitál, který vám pomůže rychleji se dostat na trh, nebo selžete.

U mobilní aplikace obvykle provádíme „soft launch“, kdy MVP uvolníme do AppStore a Google Play, ale nepodporujeme v této době žádný marketing aplikace.

Jak aplikace získává více uživatelů, mohou se objevit nějaké chyby a my určitě vše co nejdříve opravíme. Obvykle vydáváme nová sestavení každý druhý den. Jakmile bude aplikace stabilní a budeme mít počet uživatelů bez pádů vyšší než 99,9 %, doporučujeme začít s marketingem a získávat další uživatele.

Data jsou opravdu důležitá, a proto doporučujeme sledovat chování uživatelů pomocí analytiky Mixpanel nebo Google Firebase, abychom pochopili, jak uživatelé aplikaci skutečně používají.

Vývoj produktu není nikdy u konce. Velmi důležité je požádat uživatele o zpětnou vazbu a produkt iterovat. Když máme více uživatelů, provádíme testování A/B, abychom mohli vyzkoušet různá řešení a zvýšit zapojení uživatelů.

Zdroj: ProductPlan

Závěr

Ve společnosti Cleevio jsme za posledních 10 let vyvinuli více než 120 MVP, takže máme za sebou dostatek zkušeností, abychom věděli, které MVP škálují a které shoří a odumřou.

Víme, že připravit roadmapu, dokumentaci nebo wireframy pro váš nápad MVP je trochu náročné, takže nás neváhejte oslovit a my vám rádi zdarma poradíme.

Pro konzultaci ohledně vašeho MVP nám napište na [email protected] .

.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.