Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Vytvoření softwarového projektu se zaměřením na prevenci zdraví s využitím
metody Lean Startup
DIPLOMOVÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Informační systémy a technologie
Autor: Bc. Jaromír Malec
Vedoucí diplomové práce: Ing. Jan Černý Praha, květen 2021
Prohlášení
Prohlašuji, že jsem diplomovou práci Vytvoření softwarového projektu se zaměřením na prevenci zdraví s využitím metody Lean Startup vypracoval samostatně za použití v práci uvedených pramenů a literatury.
V Praze dne 3. května 2021 ...
Jaromír Malec
Poděkování
Rád bych tímto poděkoval vedoucímu práce Ing. Janu Černému za odborné vedení této diplomové práce a za spolupráci na tomto projektu. Také bych rád poděkoval všem členům týmu, kteří se podíleli na vývoji první fáze projektu.
Abstrakt
Tato diplomová práce se zabývá vytvářením softwarového projektu pomocí metody Lean Startup.
Cílem je vytvoření softwarového projektu, který bude pomáhat ve zdravotní prevenci. Pro dosažení tohoto cíle byla využita metoda Lean Startup, která se zaměřuje na vývoj produktu prostřednictvím průběžného provádění experimentů a následné úpravě produktu. V teoretické části práce jsou představeny agilní metodiky, metoda Lean Startup a nejmodernější technologie používané pro vývoj webové aplikace. Praktická část se zabývá samotným vytvářením softwarového projektu pomocí jednotlivých technik metody Lean Startup. Nejprve bylo nutné provést analýzu konkurence a ověření prvotní myšlenky. Následně byl zdokumentován podnikatelský plán využitím modelu Lean Canvas a poté byla vyvinuta samotná aplikace. Pro vývoj aplikace byla využita metodika Scrum, která zvyšuje transparentnost vývoje a napomáhá pravidelnému nasazování přírůstků aplikace.
Výsledkem práce je vytvořená a volně dostupná aplikace, která se snaží informovat společnost o nutnosti zdravotní prevence. Tato aplikace bude nadále upravována na základě zpětné vazby, jež pomůže produkt vyvíjet správným směrem.
Klíčová slova
agilní vývoj, Lean Canvas, Lean Startup, Scrum, Startup, zdravotní prevence
Abstract
This thesis describes the process of creating a software project using the Lean Startup
methodology. The goal is to create a software project that will help in preventive healthcare. In order to achieve this goal Lean Startup methodology was used. This methodology focuses on product development by means of continuous experiments.The theoretical part of the work introduces agile methodologies, Lean Startup and the most up to date technologies used in web application development. The practical part concerns the actual creation of a software project with the help of techniques from the Lean Startup methodology. At the beginning it was essential to analyze competition and validate the original idea. Then the business case was created using the Lean Canvas model and at the end the code itself was written. The development process followed Scrum methodology that increases development transparency and help with continuous incremental application deployment. The product of this work is a publicly accessible application that aims to inform the public about the necessity of preventive healthcare. This application will be updated based on feedback that will help improve the product.
Keywords
Agile Development, Lean Canvas, Lean Startup, Preventive healthcare, Scrum, Startup
Obsah
Úvod ... 10
Motivace výběru tématu ... 10
Cíl práce ... 10
Struktura práce... 11
1 Rešerše ... 12
1.1 Zdroje vyhledávání ... 12
1.2 Výsledky rešerše ... 12
2 Teoretická část ... 14
2.1 Agilní metodiky ... 14
2.1.1 Scrum ... 15
2.1.2 Extreme Programming ... 17
2.2 Lean Startup ... 18
2.2.1 Historie metody Lean Startup ... 18
2.2.2 Představení metody Lean Startup ... 18
2.2.3 Rozšíření metody Lean Startup ... 19
2.2.4 MVP ... 25
2.3 Technologie ... 26
2.3.1 Javascript ... 26
2.3.2 ReactJS ... 26
2.3.3 Node.js ... 26
2.3.4 GraphQL ... 27
2.3.5 Apollo server ... 27
2.3.6 Ant design ... 27
2.3.7 Styled components ... 28
3 Praktická část ... 29
3.1 Vznik a ověření prvotní myšlenky ... 29
3.1.1 Analýza prvotní myšlenky ... 29
3.1.2 Aplikace Premas ... 30
3.2 Analýza konkurence ... 31
3.2.1 Loono ... 31
3.2.2 Liga proti rakovině ... 32
3.2.3 Muži proti rakovině ... 33
3.2.4 STK pro chlapy ... 33
3.2.5 VZP ... 33
3.3 Zdokumentování plánu pomocí Lean Canvas ... 34
3.3.1 Problém ... 35
3.3.2 Zákaznický segment ... 35
3.3.3 Unikátní nabídka hodnoty ... 35
3.3.4 Řešení ... 36
3.3.5 Cesty k zákazníkům ... 36
3.3.6 Cenový model ... 36
3.3.7 Struktura nákladů ... 36
3.3.8 Indikátory ... 36
3.3.9 Neférová výhoda ... 37
3.4 Identifikace největších rizik ... 37
3.4.1 Produktové riziko ... 37
3.4.2 Zákaznické riziko ... 37
3.4.3 Tržní riziko ... 38
3.5 Analýza a návrh MVP aplikace Premas ... 38
3.5.1 Produktový backlog ... 38
3.5.2 Wireframe aplikace ... 41
3.5.3 Klíčová data ... 43
3.6 Vývoj MVP ... 43
3.6.1 Využití agilních metodik při vývoji ... 43
3.6.2 Vývoj v rámci předmětu 4IT580 ... 46
3.7 Otestování plánu ... 47
3.7.1 Kvalitativní validace ... 47
3.8 Zapracování zpětné vazby a úprava produktu ... 48
3.8.1 Úprava prvotní myšlenky ... 48
3.8.2 Vložení nových funkcionalit do produktového backlogu ... 48
3.8.3 Úprava metodiky pro další vývoj ... 50
3.8.4 Vývoj upraveného produktu ... 50
3.9 Nasazení aplikace ... 57
3.9.1 Webhosting ... 57
3.9.2 Konfigurace serveru ... 58
3.9.3 Doména ... 58
3.9.4 Analytická část aplikace ... 59
3.10 Výsledná aplikace Premas ... 59
3.10.1 Architektura aplikace ... 59
3.10.2 Databázový model ... 59
3.10.3 Úvodní stránka ... 60
3.10.4 Vyšetření ... 63
3.10.5 Blog ... 67
3.10.6 Preventivní programy ... 69
3.10.7 Můj profil ... 74
3.10.8 Pozvat uživatele ... 75
3.10.9 Správa uživatelů ... 75
3.10.10 Přihlášení/Registrace ... 75
3.11 Validace vytvořeného produktu ... 77
3.12 Následující kroky ... 78
4 Závěr ... 79
5 Zdroje ... 81
9
Seznam obrázků
Obrázek 1: Cyklus Vytvoř-Změř-Pouč se (RIES, 2011) ... 19
Obrázek 2: Lean Canvas (HÁJKOVÁ, VESELÝ, 2021) ... 21
Obrázek 3: Tři základní rizika byznys plánu (MAURYA, 2012) ... 23
Obrázek 4: Postup k validaci plánu (MAURYA, 2012) ... 25
Obrázek 5: Logo aplikace... 30
Obrázek 6: Lean Canvas aplikace Premas ... 34
Obrázek 7: Detail User Story v aplikaci Trello ... 41
Obrázek 8: Wireframe vyhledávacího formuláře na úvodní stránce ... 42
Obrázek 9: Wireframe stránky všech vyšetření pro administrátora ... 42
Obrázek 10: Trello nástěnka... 46
Obrázek 11: Pozvání nového uživatele ... 52
Obrázek 12: Správa uživatelů ... 52
Obrázek 13: Profil uživatele ... 53
Obrázek 14: Nastavení upozornění na preventivní vyšetření ... 54
Obrázek 15: Emailová šablona ... 55
Obrázek 16: Emailová zpráva po aktivaci pravidelného upozornění na vyšetření ... 56
Obrázek 17: Architektura aplikace ... 59
Obrázek 18: ER Diagram aplikace Premas ... 60
Obrázek 19: Formulář zdravotního profilu na úvodní stránce ... 61
Obrázek 20: Nejnovější články na úvodní stránce ... 62
Obrázek 21: Kalendář akcí ... 62
Obrázek 22: Partnerské programy na úvodní stránce ... 63
Obrázek 23: Stránka preventivních vyšetření ... 64
Obrázek 24: Detail preventivního vyšetření ... 65
Obrázek 25: Karta vyšetření pro přihlášeného administrátora... 65
Obrázek 26: Editační formulář vyšetření ... 66
Obrázek 27: Interaktivní prvek pro zvolení pravidel preventivního vyšetření ... 66
Obrázek 28: Blog ... 67
Obrázek 29: Detail článku ... 68
Obrázek 30: Karta článku pro přihlášeného administrátora ... 69
Obrázek 31: Stránka preventivních programů ... 70
Obrázek 32: Detail preventivního programu ... 71
Obrázek 33: Karta preventivního programu pro přihlášeného administrátora ... 72
Obrázek 34: Editační formulář preventivního programu ... 73
Obrázek 35: Editační formulář události ... 74
Obrázek 36: Stránka uživatelského profilu ... 74
Obrázek 37: Přihlašovací okno ... 75
Obrázek 38: Okno zapomenutého hesla ... 76
Obrázek 39: Registrační okno... 77
10
Úvod
Diplomová práce se zaměřuje na oblast vývoje softwarového Startupu. V současné době je velice jednoduché začít podnikat a každý, kdo přijde s nějakým nápadem, si může založit svůj Startup.
Pomocí internetu může každý Startup oslovit ohromné množství zákazníků. Problémem je, že většina startupů neuspěje. Většina nových produktů není úspěšná. Většina nových podniků svůj potenciál nenaplní (RIES, 2011). Z tohoto důvodu je pro vývoj Startupu v tomto řešení využitá metoda Lean Startup, která počítá s vývojem produktu za extrémně nejistých podmínek.
Tato práce má za cíl pomocí metodiky Lean Startup vytvořit softwarový Startup, který bude pomáhat v prevenci zdraví. V dnešní době existuje mnoho preventivních programů, ale nejsou centralizované na jednom místě a uživatel je schopný si dohledat pouze preventivní vyšetření, o které se v současné době zajímá. Existuje však mnoho dalších preventivních vyšetření, o která by se měl uživatel zajímat, i když se v dané chvíli cítí zdravý. Právě na ně se snaží upozornit tento projekt pomocí vytvořené aplikace, která umožní uživatelům mezi možnými vyšetřeními vyhledávat a najít právě ta, která se jich týkají.
Motivace výběru tématu
Více jak 7 let je mou hlavní pracovní náplní vývoj webový aplikací ve společnosti U.plus, která pomáhá Startupům vytvořit produkt z jejich prvotní myšlenky a následně se prosadit na trhu. Jelikož vývoj probíhá pomocí agilních metodik, tak jsem denně v kontaktu se zákazníky a participuji na vytváření produktu. Během své kariéry jsem se již podílel na několika úspěšných Startupech, ale také na Startupech, které na trhu neuspěly. V rámci mé práce mě neustále fascinuje proces tvorby produktu a jeho neustálé posouvání dopředu.
Dalším důležitým faktorem při výběru tohoto tématu bylo zapsání předmětu 4IT580, při kterém jsem potkal Jana Černého, jenž přišel s nápadem na Startup, který se zabývá zdravotní prevencí.
V rámci tohoto předmětu jsme zpracovali MVP, které ale mělo daleko k tomu, aby mohlo být uvedeno na trh. Avšak myšlenka tohoto Startupu mě natolik zaujala, že jsem se dohodl s Janem Černým na tématu této diplomové práce, při které produkt dokončím a pomocí metodiky Lean Startup vytvořím udržitelné podnikání.
Cíl práce
Cílem diplomové práce je vytvoření softwarového Startupu pomocí metody Lean Startup, který bude pomáhat v prevenci zdraví. Hlavní cíl je následně rozložen na dílčí cíle:
DC1: Analýza konkurence, která poslouží jako zdroj informací pro správné nastavení podnikatelského plánu.
11
DC2: Zdokumentování plánu pomocí modelu Lean Canvas, který je základním dokumentem Lean Startup a stručně popisuje vytvářený produkt.
DC3: Vytvoření webové aplikace, kterou budou uživatelé používat pro vyhledávání preventivních vyšetření. Tato aplikace se bude vytvářet iterativně a průběžně se bude zapracovávat zpětná vazba, která bude v průběhu vývoje získávána od uživatelů. Vývoj samotné aplikace bude probíhat s využitím agilních metodik a nejvíce využívanou metodikou bude metodika Scrum, která zajistí neustálou kontrolu nad vytvářeným produktem.
DC4: Ověřování a validování plánu, které poskytne zpětnou vazbu na vytvářený produkt, a zajistí, aby vyvíjený produkt směřoval cestou, která osloví uživatele. Výstupem z tohoto dílčího cíle bude zpětná vazba, která bude získána využitím osobních rozhovorů s prvotními uživateli produktu.
Struktura práce
Práce je rozdělena na teoretickou a praktickou část.
Teoretická část se skládá ze tří částí. V první části jsou popsány agilní metodiky použité při vývoji.
Konkrétně se jedná o metodiku Scrum, která se používá pro řízení vývoje a metodiku Extreme Programming, pomocí jejíž praktik lze dosáhnout kvalitnějšího kódu. V druhé části je popsána metoda Lean Startup, pomocí níž je upravován celý životní cyklus budování Startupu. Ve třetí části jsou popsány jednotlivé technologie, které se používají pro vývoj.
V praktické části je popsán proces budování Startupu metodou Lean Startup. Celý tento proces probíhá prostřednictvím validační smyčky, kterou definuje Lean Startup. Nejprve je popsána prvotní myšlenka produktu, následuje vývoj MVP, které je následně otestováno, a na základě zpětné vazby proběhne úprava produktu, čímž se znovu zahájí validační smyčka.
12
1 Rešerše
Hlavním tématem diplomové práce je vytvoření softwarového projektu s využitím metody Lean Startup. Z tohoto důvodu byla provedena rešerše odborné literatury a online zdrojů, které se věnují popisu metody Lean Startup a využití této metody v praxi.
1.1 Zdroje vyhledávání
Hlavním zdrojem, který byl využit pro vyhledávání odborné literatury, je Google Scholar. Pomocí prvního vyhledávacího dotazu jsem se snažil vyhledat publikace, které se zabývají obecným popisem metody Lean Startup, proto vyhledávací dotaz vypadal následovně:
"Lean Startup"
Výsledky vyhledávání byly následně seřazeny podle relevance.
Pomocí dalšího vyhledávacího dotazu jsem se snažil najít publikace, které se zabývají reálným využitím metody Lean Startup a modelu Lean Canvas. Vyhledávací dotaz vypadal takto:
"Lean Canvas" AND "Lean Startup"
Dalším zdrojem rešerše byl portál Theses.cz, který obsahuje vysokoškolské kvalifikační práce a je možno mezi nimi vyhledávat. Pro vyhledávání byly zvoleny tyto dotazy:
• „Využití metody Lean Startup“
• „Vývoj aplikace Lean Startup“
1.2 Výsledky rešerše
Při důkladném vyhledávání byla nalezena kniha Erica Riese, The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (RIES, 2011), která je hlavním informačním zdrojem pro oblast metody Lean Startup. Tato kniha vyšla v roce 2011 a na základě myšlenek z této knihy vzniklo globální hnutí, ve kterém podnikatelé začali vytvářet lokální skupiny a aplikovat myšlenky Lean Startup.
Nejčastější knihou, která byla citována ve výsledcích Google Scholar po zadání dotazu "Lean Canvas"
AND "Lean Startup", byla kniha Running Lean: Iterate from Plan A to a Plan That Works od autora Ash Maurya (MAURYA, 2012). Tato kniha navazuje na knihu Erica Riese a metodu Lean Startup rozšiřuje o zdokumentování plánu pomocí modelu Lean Canvas. V této knize jsou také popsány
13
konkrétní příklady aplikace metody Lean Startup a obsahuje návody, jak tuto metodu aplikovat v průběhu vývoje Startupu.
Pomocí portálu Theses.cz bylo identifikováno několik kvalifikačních prací, které se zabývají vývojem Startupu pomocí metody Lean Startup. Diplomová práce Vývoj inovativní mobilní aplikace (MYSLIVEČEK, 2015) se zabývá vývojem inovativní aplikace od nápadu až po funkční prototyp užitím metody Lean Startup. Autor nejprve představuje v teoretické části metodu Lean Startup na základě knihy od Erica Riese (RIES, 2011) a Ash Maurya (MAURYA, 2012) a následně navazuje praktickou částí, ve které popisuje vývoj aplikace. V závěru práce autor shrnuje přínosy metody Lean Startup a popisuje, jak mu tato metoda pomohla při vytváření aplikace. Výsledkem této práce je aplikace, která byla vytvořena s využitím metody Lean Startup. Na rozdíl od této kvalifikační práce je v této mé kladen důraz na iterativní vývoj a zapracování zpětné vazby do výsledného produktu, což je hlavní podstata metody Lean Startup
Další identifikovanou kvalifikační prací je Vývoj webové aplikace v rámci platformy Coinbase Pro (ČECH, 2019), která se zabývá vývojem webové aplikace vylepšující obchodní možnosti platformy Coinbase Pro s využitím metody Lean Startup. V teoretické části jsou popsány a analyzovány metody vývoje a následně je vybrána metoda Lean Startup jako nejvhodnější pro daný problém.
Autor následně na základě cyklu „Vytvoř-Změn-Pouč se“ vytvořil MVP, ve formě věrohodného prototypu aplikace, a toto MVP ověřil na základě rozhovorů s uživateli a na základě zpětné vazby tuto aplikaci upravil. Vývoj probíhal iterativně a několikrát proběhl cyklus „Vytvoř-Změn-Pouč se“, čímž byla naplněna podstata metody Lean Startup. Na rozdíl od této kvalifikační práce je v mé použit rozšířený model Lean Startup na základě knihy Running Lean (MAURYA, 2012), který navíc obsahuje zdokumentování plánu pomocí modelu Lean Canvas. Dalším rozdílem oproti zmíněné kvalifikační práci je využití jiné metodiky pro samotný vývoj. Autor práce využívá pouze metodu Lean Startup pro řízení projektu i samotný vývoj, ale v mé práci je zvolena metodika Scrum pro vývoj aplikace, pomocí které se docílí transparentnějšího vývoje a dokáže pružně reagovat na změny v zadání produktu.
14
2 Teoretická část
První kapitola se zabývá teorií a popisem hlavních metodik a technologií, které jsou použity pro vytváření projektu Premas. V první části jsou popsány agilní metodiky použité pro řízení vývoje a samotný vývoj, kde největší roli hraje metodika Scrum. V druhé části je popsána metoda Lean Startup, která pomáhá při vytváření samotného produktu na extrémně nejistém trhu, a pomocí neustále opakující se smyčce pomáhá navrhnout, vytvořit a otestovat produkt. Poslední částí je popis technologií, které se využívají při vytváření produktu.
2.1 Agilní metodiky
Tento projekt je vyvíjený pomocí agilních metodik, které dávají přednost rychlé implementaci před dlouhodobou analýzou potřebnou pro zahájení. Využitím těchto metodik můžeme získat častější reakci od zákazníka, kterou lze ihned zapracovat do vyvíjeného produktu. Oproti tradičním metodikám, jako je například vodopádový model, je pomocí tohoto přístupu vedení projektu mnohem flexibilnější a ve výsledném produktu se objeví méně chyb díky tomu, že se chyby dříve identifikují a ihned opraví. Přístup agilních metodik je založený na neustálé komunikaci se zákazníkem, a proto lze produkt neustále upravovat a vylepšovat, dle jeho požadavků a vzájemné shodě. Díky tomu, že se zákazník osobně účastní vývoje, tak pozoruje, jak produkt vzniká, a může se k němu okamžitě vyjadřovat.
Agilní metodiky staví na základech Agilního manifestu, který vznikl v roce 2001, a dodržuje jeho 12 základních principu, kterými jsou (BECK, BEEDLE, VAN BENNEKUM, et al, 2001):
1. Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru.
2. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka.
3. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody.
4. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu.
5. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci.
6. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace.
7. Hlavním měřítkem pokroku je fungující software.
8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale.
9. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu.
10. Jednoduchost--umění maximalizovat množství nevykonané práce--je klíčová.
11. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů.
15
12. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti.
2.1.1 Scrum
Scrum je nejvíce používanou agilní metodikou dle průzkumu „State of agile“ z roku 2020 (DIGITAL.AI, 2020). Tuto metodiku vytvořili v roce 1995 Ken Schwaber a Jeff Sutherland, kteří sepsali dokument s názvem „The Scrum Guide“ (SCHWABER, SUTHERLAND, 2020) a stále ho doplňují a udržují aktuální. Poslední aktualizace proběhla v roce 2020, při které byla zjednodušená jazyková forma pro lehčí pochopení této metodiky širokou veřejností. Metodika je primárně zaměřena na organizaci vývojového týmu softwarového projektu, ale dá se uplatnit i na jiná odvětví. Pro vývoj produktu pomocí metodiky Scrum je charakteristická vysoká flexibilita, proto je vhodná pro produkty, které nejsou na začátku vývoje plně specifikované a definice požadavků se bude v průběhu vývoje měnit.
Tato metodika se skládá ze Scrum týmu a jeho přidružených rolí, událostí, artefaktů a nejlepších praktik pro vývoj a organizaci projektu.
Scrum tým
Základní jednotkou metodiky Scrum je malý tým, který se nazývá Scrum tým. Díky nízkému počtu členů, typicky 10 a méně, efektivně funguje komunikace uvnitř týmu, a z toho plyne i vyšší produktivita. Scrum se řídí sám, to znamená, že si sám rozhodne, co, kdy a jak se bude dělat. Celý Scrum tým je také odpovědný za vytvoření přírůstku produktu, který má užitečnou hodnotu pro zákazníka. Scrum tým definuje tři základní role:
• Vlastník produktu (Product Owner) – Je zodpovědný za maximalizování hodnoty produktu vyplývající z práce celého Scrum týmu. Vlastník produktu má také na starosti produktový backlog, ve kterém je nutné připravit požadavky, které je potřeba vykonat, a vytvořit pro tyto požadavky akceptační kritéria.
• Scrum Master – Jeho zodpovědností je správné nastavení Scrum metodiky při vývoji produktu a pomáhá členům týmu s pochopením těchto praktik. Jeho povinností je také správa nástroje pro agilní prostředí, jako je například Trello a vedení všech ceremonií, které jsou definovány pro konkrétní Scrum tým.
• Vývojáři – Součástí vývojářského týmu jsou všichni členové, kteří jsou nutně potřební pro vývoj produktu. Do této role patří samotní vývojáři, ale i testeři, analytici a další členové, kteří se technicky podílí na vývoji produktu. Vývojáři se na začátku každého sprintu zavážou vytvořit určitý přírůstek produktu a v průběhu tohoto sprintu dělají vše, aby dosáhli svým závazkům.
Scrum události
Scrum události zajišťují pravidelnost a minimalizují počet potřebných událostí, které nejsou definovány v rámci Scrum metodiky. Každá událost má předem definovanou maximální délku a při dosažení cíle události může být ukončena dříve, avšak kromě sprintu, který musí vždy trvat po dobu,
16
na kterou byl před jeho zahájením definován. Sprint je souhrnem všech ostatních událostí, které jsou navrženy tak, aby zvýšily transparentnost a umožnily větší kontrolu nad vyvíjeným produktem.
Mezi tyto události patří (SCHWABER, SUTHERLAND, 2020):
• Sprint – Je základním prvkem metodiky Scrum. Délku každého sprintu si sám zvolí Scrum tým, ale obecně platí, že jeden sprint by neměl trvat déle než jeden měsíc. Během jednoho sprintu se konají všechny definované události v metodice Scrum, mezi které patří například Sprint Planning, denní Stand-upy, Sprint retrospektiva a Sprint review. Během sprintu se nesmí provádět změny, které by ohrozily cíl sprintu stanovený na začátku a také se nesmí snižovat kvalita tohoto cíle. Nový sprint začíná ihned po ukončení předchozího sprintu.
• Sprint Planning – Probíhá vždy první den sprintu a na této události se Scrum tým dohodne jaká práce bude vykonána během sprintu a jeho cíl. Během Sprint planningu musí být zodpovězeny tyto tři otázky „Proč je tento Sprint cenný?“, „Co lze udělat tento Sprint?“ a
„Jak bude zvolená práce provedena?“ (SCHWABER, SUTHERLAND, 2020).
• Refinement – Jedná se o událost, během které tým do detailu rozebírá položky z produktového backlogu a ohodnocují jednotlivé User Stories „story pointy“, což je relativní měrná jednotka určená k definování náročnosti konkrétní položky. Pro ohodnocení náročnosti položky z produktového backlogu se využívá Poker Planning, který probíhá formou hry, kdy všichni členové týmu mají karty s číselnými hodnotami dle Fibonacciho posloupnosti, a po uvedení do problému konkrétní User Story všichni členové najednou ukážou kartu s hodnotou, kterou shledávají jako adekvátní náročnost pro tuto User Story.
Každý tým si před zahájením prvního Poker Planningu musí stanovit, kolik práce obnáší jeden „story point“, a to například podle nějaké User Story, kterou tým v minulosti vykonával. Následně se náročnost další User Story určuje tím způsobem, že si tým odpoví na otázku „Kolikrát byla tato User Story náročnější, než naše výchozí User Story“. Tým se následně musí shodnout jakou hodnotu určí pro danou User Story. Častou metodou, jak dosáhnou kompromisu při volení náročnosti User Story, je diskuse mezi členem týmu, který ukázal největší a nejmenší hodnotu. Díky této metodě hodnocení lze identifikovat, zda mají všichni členové týmu dostatek informací o konkrétní User Story, a kdyby se hodnoty na kartách velmi lišily, tak je vhodné User Story znovu probrat a upřesnit si detaily.
• Stand-up (Daily Scrum) – Tato každodenní událost má za cíl kontrolovat pokrok směrem k cíli sprintu. Každý člen, který se aktivně podílí na vývoji produktu, sdělí, na kterých činnostech pracoval předchozí den, jaká práce ho čeká dnes a zda ho blokují nějaké závislosti. Tato událost trvá maximálně 15 minut a probíhá každý den ve stejný čas a na stejném místě.
• Sprint Review – Účelem této události je zkontrolovat výsledek sprintu a určit budoucí úpravy. Scrum tým během Sprint Review prezentuje výsledky své práce klíčovým zúčastněným stranám. Na základě zpětné vazby od zúčastněných stran se dohodne další postup a při této události se může upravit produktový backlog tak, aby odpovídal těmto novým postupům. Tyto nové poznatky následně poslouží jako vstup pro Sprint planning.
• Sprint retrospektiva – Během této události celý Scrum tým hodnotí, jak probíhal poslední sprint a snaží se identifikovat problémy, které bránily týmu pracovat efektivněji, a také zde vyzvednout nově zavedené způsoby, které během uplynulého sprintu efektivitu zvyšovaly.
17
Na konci této události se nejvýznamnější vylepšení zapíšou a budou se aplikovat následující sprint.
Scrum artefakty
„Artefakty Scrumu představují práci nebo hodnotu. Jsou navrženy tak, aby maximalizovaly transparentnost klíčových informací. Každý, kdo je kontroluje, má tudíž stejný základ pro přizpůsobení.“ (SCHWABER, SUTHERLAND, 2020). Mezi tyto artefakty patří:
• Produktový backlog – Je seřazený seznam toho, co je potřeba udělat pro zvednutí hodnoty produktu. Tento seznam funguje jako jediný zdroj práce prováděné Scrum týmem.
Produktový backlog obsahuje nové funkcionality, změnové požadavky, požadavky na opravu atd. a tyto položky jsou řazeny podle priorit.
• Sprint backlog – Jedná se o podmnožinu produktového backlogu a obsahuje plán vývojářů, který je primárně určen pro vývojáře. Sprint backlog obsahuje položky vybrané z produktového backlogu, ke kterým se vývojáři zavázali a pomocí těchto položek se dosáhne splnění cíle sprintu.
• Inkrement – Představuje přírůstek všech dokončených User Stories během sprintu, které tvoří celek. Každý inkrement musí být aditivní ke všem předchozím inkrementům a spojením těchto inkrementů vznikne funkční řešení.
2.1.2 Extreme Programming
Extreme Programming (XP) je lehký, účinný, nepříliš rizikový, pružný, předvídatelný, vědecký a zábavný způsob, jak vyvíjet software (BECK, 1999). Oproti Scrum metodice je Extreme Programming více zaměřený na jednotlivé praktiky než na konkrétní proces. Hlavními hodnotami jsou komunikace, jednoduchost, zpětná vazba a kuráž.
Základní myšlenkou Extreme Programming, je dovést ověřené činnosti do extrému. Pokud tým vývojářů shledá nějakou činnost jako účinnou, tak proč nedělat jenom to.
Mnoho praktik z metodiky Extreme Programming již přebrala i metodika Scrum a zahrnula je do svého procesu. Postupy z metodiky Extreme Programming ohledně samotného programování v metodice Scrum popsány nejsou, avšak jejich implementace do procesu může zvýšit kvalitu kódu a spokojenost vývojářů. Jedna z praktik, která se používá v tomto projektu, je extrémní revize kódu.
To znamená, že veškerý vytvořený kód musí projít revizí dalším členem týmu kontrolou kódu v repositáři projektu. Pro účely revize kódu je také využívaná metoda párového programovaní, při které jeden kód vytváří dva vývojáři. Princip spočívá v tom, že jeden vývojář píše kód a druhý vývojář vše sleduje, přidává poznámky a přemýšlí o možných souvislostech. Díky této metodě je výsledný kód ihned zkontrolován, a také může více zkušený vývojář rychle předat zkušenosti méně zkušenému.
18
2.2 Lean Startup
V této kapitole pojednávám o metodě Lean Startup, kterou představil Eric Reis v roce 2011 (REIS, 2011).
2.2.1 Historie metody Lean Startup
Metodu Lean Startup představil v roce 2011 Eric Reis v knize „The LEAN STARTUP: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses“ (REIS, 2011).
Této knize předcházela kariéra Erica Riese jakožto programátora, který dlouhá léta pracoval na zajímavých produktech, jenž ale na trhu neuspěly. Zpočátku autor nahlížel na vše jako na technický problém, který si vyžaduje technická řešení, ta ale vedla jen k dalším neúspěchům. Následně se autor stal spoluzakladatelem společnosti IMVU a rozhodl se použít nové metody, jak budovat společnost. V tomto mu pomohli další spoluzakladatelé společnosti, kteří byli také ochotni experimentovat, a největší podporu mu poskytl investor a rádce v této společnosti, Steve Blank, s jeho metodou Customer Development neboli vývoj se zákazníky (BLANK, 2007). Dále se Eric Ries snažil vyhledávat a praktikovat metody v jiných odvětvích, až se dostal ke štíhlé výrobě, která byla praktikována v Japonsku ve firmě Toyota. Po aplikování těchto nových metod, jež musel přizpůsobit vývoji softwarového produktu, dosáhla firma IMVU úspěchu. Na základě nově získaných poznatků začal Eric Reis své zkušenosti předávat dalším podnikatelům, ale často se setkal s negativní reakcí, proto začal psát blog, přednášet a navázal také spolupráci s řadou jiných autorů, dalšími podnikateli a díky tomu vzniklo hnutí Lean Startup (REIS, 2011).
2.2.2 Představení metody Lean Startup
Před představením metody Lean Startup je nutné si rozebrat, co znamenají obě součásti názvu metody, tedy „Lean“ a „Startup“. Pojem „Lean“, nebo „Štíhlý“ pochází z 90. let 20. století z firmy Toyota. Pomocí Štíhlé metody se firmy snaží zachovat nízké koncové ceny produktu s minimálním plýtváním na vstupu. Minimálního plýtvání firmy dosahují tím, že se snaží eliminovat všechny činnosti při výrobě produktu, které mu nepřidávají hodnotu a zvyšují jeho náklady. Pojem Startup Ries definuje následovně: „Startup je lidskou institucí navrženou pro vytvoření nového produktu nebo služby v podmínkách extrémní nejistoty“ (RIES, 2011, překlad autora). Eric Ries oba tyto pojmy spojil a definoval tím metodu Lean Startup, pro kterou vytvořil následujících 5 základních principů:
• Podnikatelé jsou všude. Ries tvrdí, že podnikatelé jsou všude a Lean Startup může fungovat ve společnostech libovolné velikosti, a to nehledě na obor podnikání, nebo odvětví.
• Podnikání rovná se řízení. Startup je instituce, ne pouze produkt, a proto vyžaduje nový způsob řízení, který je orientovaný na extrémně nejisté podmínky
• Ověřované učení. Cíl startupu není pouze vytvářet produkty, sloužit zákazníkům a generovat peníze. Cílem Startupu je i vytvoření udržitelného podnikání, kterého lze dosáhnout častými experimenty, které umožní podnikateli otestovat každou část jejich vize.
• Vytvoř-Změř-Pouč se. Základní aktivitou každého Startupu je co nejrychleji přeměnit myšlenku v produkt, vyhodnotit odezvu zákazníků a na základě zpětné vazby se
19
rozhodnout, zůstat v nastaveném směru, nebo provést pivot neboli tento produkt zásadně změnit.
• Vykazování inovací. Aby bylo možné zlepšit výsledky podnikatelských pokusů, tak se musí nastavit metriky, které měří růst, reakce zákazníků, a lze pomoci nich stanovit milníky projektu a pracovní priority.
Celou tuto metodu nejlépe vystihuje smyčka Vytvoř-Změn-Pouč se (Obrázek 1), která popisuje základní aktivitu metody Lean Startup.
Obrázek 1: Cyklus Vytvoř-Změř-Pouč se (RIES, 2011)
Celá smyčka začíná ve fázi „Build“ (Vytvoř), ve které je zapotřebí co nejrychleji vytvořit minimální životaschopný produkt (Dále jen MVP). Tento produkt nám umožní rozběhnout celý cyklus s minimální spotřebou zdrojů na vývoj. Následuje fáze „Measure“ (Změř), ve které je produkt otestován zákazníka a ze zpětné vazby jsou získána kvalitativní i kvantitativní data potřebná k další fázi. V poslední fázi nazývané „Learn“ (Pouč se) se získaná data vyhodnotí, ověří se, zda prvotní myšlenka byla správná a také z těchto dat mohou vzniknout myšlenky nové. Pokud je prvotní myšlenka vyhodnocena jako správná, tak se zachová. V opačném případě je třeba prvotní myšlenku přepracovat, nebo provést pivot, při kterém se změní směr rozvoje produktu.
Společnosti, které využívají Lean Startup, se stanou více efektivní díky tomu, že dokážou dříve rozpoznat, kdy je potřeba provést pivot, a to jim ušetří mnoho času a peněz, které by jinak spotřebovaly na rozvoj nepotřebného produktu.
2.2.3 Rozšíření metody Lean Startup
Ash Maurya ve své knize „Running Lean: Iterate from Plan A to a Plan That Works“ (MAURYA, 2012) navázal na práci Erica Riese, popsal zde praktické použití metody Lean Startup a rozšířil tuto metodu o nový zápis byznys plánu, který nazval Lean Canvas.
Stále platí, že většina startupů selže, ale na startupech, které uspěl je zajímavé to, že dvě třetiny z těchto Startupů musely během své cesty zásadně změnit své plány. (MULLINS, KOMISAR, 2009)
20
Podle autora tedy nezajistí úspěch Startupu lepší počáteční byznys plán, ale spíš to, zda najdou správný fungující plán dříve, než jim dojdou zdroje. Z tohoto důvodu doporučuje Maurya následující tři základní kroky (MAURYA, 2012):
1. Zdokumentujte svůj plán A.
2. Identifikujte nejrizikovější části plánu.
3. Systematicky testujte svůj plán.
Zdokumentujte svůj plán A
Prvním krokem při vytváření Startupu je zapsání své počáteční vize na papír a její představení alespoň jedné osobě. Klasickým přístupem je vytvořit několikastránkový byznys plán, ve kterém podnikatel popíše svou vizi, avšak tuto metodu shledal Ash Maurya jako neefektivní, protože vytvoření takového plánu může trvat i měsíce a pro čtenáře je poté náročné se v tomto byznys plánu zorientovat. Proto přišel autor s novou metodou zaznamenání byznys plánu, která se rychleji píše, je stručná a zároveň se může rychleji přizpůsobit proměnlivým podmínkám. Tento nový formát nazval Lean Canvas a vejde se na jednu stránku papíru (Obrázek 2).
Ještě před vyplňováním Lean Canvasu je zapotřebí si uvědomit, kdo je zákazník a kdo je uživatel.
Jako příklad se může použít společnost Facebook. Její uživatelé jsou lidé, kteří aplikaci používají ke sdílení příspěvků, psaní zpráv a čtení reklam. Naopak jejími zákazníky jsou inzerenti, kteří platí za to, aby běžní uživatelé viděli jejich reklamy. Dále by mělo následovat rozdělení zákazníků do menších segmentů. Pokud je identifikováno více zákaznických segmentů, tak je vhodné nejdříve vyplnit jeden společný Lean Canvas a barevně odlišit jednotlivé zákaznické segmenty. Toto pomůže vše vizuálně odlišit na jedné stránce. Následně je doporučeno vybrat dva, nebo tři nejdůležitější, nebo nejnadějnější zákaznické segmenty, a pro ty vytvořit vlastní Lean Canvas.
Při vytváření Lean Canvasu je vhodné se držet několika základních pravidel (MAURYA, 2012). První verze Lean Canvasu by se měla vytvořit během jednoho sezení, méně než 15 minut. Cílem je hlavně zachytit, co má autor v hlavě a následně provádět další iterace. Je v pořádku nechat některá pole nevyplněná, místo toho, aby se dlouho diskutovalo o tom, co zde vyplnit. Lean Canvas je organický dokument, a proto je možné se k nevyplněným polím později vrátit a vyplnit je. Dalším pravidlem je být stručný. Díky tomu, že jednotlivé pole v Lean Canvasu mají omezený prostor, nutí to autora stručně a výstižně popsat problém. Dále je třeba myslet v přítomnosti, protože je nemožné předvídat budoucnost a je lepší se zaměřit na to, ve které fázi se zrovna nacházíme a jaké jsou nové hypotézy, které jsou třeba otestovat, aby se produkt posouval dopředu. Posledním pravidlem je používání přístupu zaměřeného na zákazníka.
21
Obrázek 2: Lean Canvas (HÁJKOVÁ, VESELÝ, 2021)
Lean Canvas obsahuje 9 částí a čísla na obrázku (Obrázek 2) zde zobrazují doporučený postup při vyplňování jednotlivých částí.
1. Problém (Problem). Nejprve je třeba definovat několik nejdůležitějších problémů, které řeší produkt pro zákazníky. Od těchto problémů se odvíjí zbytek Lean Canvasu a v tomto poli je vhodné definovat 1-3 nejzásadnější problémy. Zároveň je zde vhodné zdokumentovat alternativy, které cíloví zákazníci používají k uspokojení jejich potřeb.
2. Zákazníci (Customer segments). V této části se vypíšou všechny zákaznické segmenty, se kterými konkrétní Lean Canvas pracuje. V tomto bodě je zapotřebí si uvědomit, kdo je zákazníkem a kdo uživatelem. Uživatelé jsou lidé, kteří produkt využívají, ale neplatí za něj.
Naopak zákazníci jsou lidé, kteří za produkt platí. Dále je třeba určit tzv. „první vlaštovky“, neboli zákazníky, kteří budou produkt používat jako první.
3. Unikátní nabídka hodnoty (Unique value proposition). Unikátní nabídka hodnoty by se měla popsat jednou větou a mělo by z ní být jasné, čím je produkt odlišný a čím by si měl zasloužit pozornost. V tomto bodě se také napíše srozumitelný opis, což znamená popis vytvářeného produktu pomocí již existujících.
4. Řešení (Solution). Řešení přímo navazuje na problémy, a proto by pro každý definovaný problém mělo být popsáno i řešení. Není však doporučeno věnovat se jednotlivým řešením příliš dopodrobna, protože definované problémy nejsou stále otestované a je možné, že budou změněny, nebo dokonce odstraněny.
22
5. Cesty k zákazníkům (Channels). V tomto bodě se definují cesty, kterými se Startup dostane k zákazníkovi. Prvotním cílem Startupu je poučit se, a proto je v pořádku spolehnout se na jakoukoliv cestu, která jej dostane k zákazníkům.
6. Cenový model (Revenue streams). V této části se nastíní předpokládané zdroje příjmů. Je vhodné zpoplatnit produkt již ve fázi MVP, protože tím Startup získá možnost otestovat nastavenou cenu přímo na zákaznících. Pro správné nacenění produktu může sloužit také srovnání s již existující konkurencí.
7. Struktura nákladů (Cost sctructure). Náklady v budoucnu je složité vyčíslit, a proto se tato část věnuje nákladům, které se pojí s dostáním produktu na trh. Můžou se zde objevit náklady například na vytvoření MVP, náklady na otestování hypotéz a základní ceny fixních a variabilních nákladů.
8. Indikátory (Key metrics). Každý byznys má několik klíčových čísel, které je potřeba sledovat a určit pro ně metriky, díky kterým se může měřit výkonnost. Zde je důležité stanovit si jasné limity, čeho chce Startup dosáhnout a pokud by se to nepovedlo, tak včas změnit směr vývoje pivotem, nebo ukončit podnikání, aby se zamezilo plýtvání zdrojů. Maurya definuje 5 skupin uživatelů produktu (MAURYA, 2012), pro které je vhodné v tomto poli definovat metriky. První skupinou je „Acquisition“ – jedná se o uživatele, kteří projeví zájem o produkt například tím, že na webové stránce produktu provedou nějakou aktivitu. Další skupinou je
„Activation“ – zde se nachází uživatelé, kteří poprvé vyzkouší produkt. Třetí skupina je nazývaná „Retention“ a jedná se o uživatele, kteří produkt užívají opakovaně. Další důležitou skupina se nazývá „Revenue“ - do této skupiny spadají uživatelé, kteří za produkt platí. Poslední skupinou je „Referral“ – tu tvoří spokojení uživatelé, kteří službu sdílí dále, a tím přivádí k produktu nové uživatele.
9. Neférová výhoda (Unfair advantage). Posledním bodem v Lean Canvasu je neférová výhoda a obvykle bývá tento bod nejtěžší na vyplnění. Jedná se o neférovou výhodu, kterou konkurence nemůže jednoduše vzít a využít ji ve svém řešení. Často se jako neférová výhoda uvádí to, že je konkrétní produkt první na trhu, avšak to je ve většině případů spíše nevýhoda, protože každý další startup může tento koncept zkopírovat a má tím ulehčenou práci. Maurya ve své knize uvádí několik příkladů neférových výhod (MAURYA, 2012):
• Přístup k tajným informacím.
• Expertní potvrzení produktu.
• „A dream team“, neboli výborně sehraný tým.
• Velký dosah na sociálních sítích.
• Existující komunita.
• Existující zákazník.
• Výborné SEO (optimalizace pro vyhledávače, aby se produkt zobrazil na předních příčkách).
Často se stává, že žádná nefér výhoda na začátku vývoje produktu neexistuje, proto nevadí, když se toto pole zanechá prázdné. Je však vhodné neustále na tuto nefér výhodu myslet, protože je to bod, který může odlišit Startup od konkurence.
23 Identifikujte nejrizikovější části plánu
Po vyplnění Lean Canvasu následuje druhý krok, kterým je identifikace nejrizikovější části plánu.
Maurya identifikuje tři základní rizika, kterými jsou produktové riziko, zákaznické riziko a tržní riziko.
Každé riziko se týká několika částí Lean Canvasu, jak je zobrazeno na obrázku níže (Obrázek 3).
Obrázek 3: Tři základní rizika byznys plánu (MAURYA, 2012)
Pro postupné minimalizování rizik Maurya doporučuje 4 kroky (MAURYA, 2012) pro každou skupinu rizik.
Produktové riziko – jedná se o riziko, které se týká části Problém, Řešení, Nabídka jedinečné hodnoty a Klíčové metriky. V tomto riziku si musí podnikatel uvědomit, zda vyrobí správný produkt.
Pro minimalizaci produktového rizika Maurya navrhuje:
1. Ujistit se, zda řešený problém je hodný řešení.
2. Definovat MVP.
3. Vytvořit a ověřit MVP v malém měřítku.
4. Ověřit MVP v širším měřítku.
Zákaznické riziko – toto riziko pokrývá části Zákaznický segment a zejména jeho prvotní zákazníky a cesty k zákazníkům. Při tomto riziku se musí podnikatel zamyslet nad tím, zda buduje správné cesty k zákazníkům. Zákaznické riziko lze minimalizovat následovně:
24
1. Nejprve je třeba identifikovat skupinu zákazníků, kteří mají daný problém a potřebu jeho řešení.
2. Poté zúžit tuto skupinu na prvotní uživatele, kteří chtějí produkt využívat okamžitě.
3. Využití „outbound“ kanálů neboli nátlakových marketingových kanálů, jako je třeba reklama na sociálních sítí, nebo televizní reklama.
4. Postupným vytvoření „inbound“ kanálů neboli marketingových kanálů, jako je například blog. Tyto kanály je vhodné začít tvořit co nejdříve, protože snižují náklady na marketing a postupně budují důvěrný vztah se zákazníkem.
Tržní riziko – Toto riziko pokrývá části Toky příjmů, Struktura nákladů a existující alternativy řešeného problému. Během analyzování tohoto rizika si musel musí odpovědět na otázku, zda buduje udržitelné podnikání. Poslední riziko navrhuje Maurya minimalizovat takto:
1. Identifikovat konkurenci, která poskytuje alternativní řešení a na základě této alternativy nacenit produkt.
2. Otestovat nastavenou cenu pomocí rozhovoru se zákazníky.
3. Otestovat cenu podle reálného chování zákazníků.
4. Optimalizovat strukturu nákladů tak, aby byznys model fungoval.
Systematicky testujte svůj plán
Po vytvoření Lean Canvasu a identifikování nejrizikovějších částí plánu nastává čas na systematické testování plánu. V metodě Lean startup je toho docíleno pomocí série experimentů, pro které se používá již zmíněná validační smyčka Vytvoř-Změn-Pouč se. Pomocí těchto experimentů se Startup posouvá dále v jeho základních fázích, které Ash Maurya (MAURYA, 2012) definuje následovně:
1. Problem/Solution Fit – jedná se o úvodní fázi, ve které se ověřuje, zda existuje problém, který by produkt měl řešit. V této části je třeba zodpovědět následující otázky: „Jedná se o produkt, který zákazníci chtějí?“, „Budou za tento produkt zákazníci platit? A pokud ne, kdo tedy?“, „Je tento problém řešitelný?“. Na tyto otázky se získává odpověď pomocí kombinace kvalitativních výzkumů a rozhovorů se zákazníky.
2. Product/Market Fit – do další fáze startup vstoupí, jakmile se řeší problém, který stojí za to řešit, a je vytvořeno MVP. V této fázi startup ověřuje, jak dobře řeší navržený produkt problém zákazníka, pomocí vytvořeného MVP spolu s kvalitativními a kvantitativními metrikami. V této fázi se stále využívá smyčka Vytvoř-Změn-Pouč se, při které se upravuje strategie a navržené řešení pomocí pivotů a řízených experimentů. Klíčová otázka v této fázi, která je třeba zodpovědět zní „Vytvořil jsem něco, co lidé chtějí?“.
3. Scale – po úspěšném vytvoření produktu, který nalezl své zákazníky a cílový trh, následuje fáze, ve které je třeba zaměřit se na kontinuální vylepšování a růst. Nadále se využívá validační smyčka, při které se sbírá zpětná vazba od zákazníka a upravuje produkt.
Nejdůležitější otázka v této fázi produktu zní „Jak mohu urychlit růst?“.
Cílem fází Problem/Solution Fit a Product/Market Fit je validovat plán, s cílem eliminovat, nebo minimalizovat jeho nejrizikovější části. Pro tyto dvě fáze vytvořil Ash Maurya postup (Obrázek 4),
25
který pomocí 4 iterací napomáhá k validaci plánu, eliminování největších rizik a následným přechodem do další fáze Scale.
Obrázek 4: Postup k validaci plánu (MAURYA, 2012) Iterace zobrazené na obrázku (Obrázek 4) jsou definované následovně:
1. Porozumění problém (Understand Problem) – v rámci této iterace, která probíhá ve fází
„Problem/Solution Fit“, je nejprve nutné porozumět problémům, které zákazník řeší.
2. Definování řešení (Define Solution) – po porozumění problémům zákazníků přichází na řadu iterace, během které definuje řešení těchto problémů. Při této iteraci se nejprve vytvoří návrh řešení a poté se vytvoří MVP, které se využije jako nástroj k získání zpětné vazby v dalších iteracích.
3. Kvalitativní validace (Validate Qualitatively) – jakmile je vytvořeno MVP, je třeba ho nasadit na prostředí, kde ho může využívat malé množství zákazníků. Tímto se produkt dostane do fáze „Product/Market Fit“ a po nasazení MVP se vedou rozhovory se zákazníky, kteří již MVP vyzkoušeli, a při tomto rozhovoru se sbírá zpětná vazba na vytvořené řešení.
4. Kvantitativní verifikace (Verify Quantitatively) – po kvalitativní validaci přichází iterace, při které se vytvořené řešení nasadí na produkční prostředí, kde ho může vyzkoušet široká škála zákazníků. Následně se analyzuje využívání produktu v dlouhodobějším horizontu pomocí analytických nástrojů implementovaných v MVP. Výstupem z této analýzy se sleduje míra růstu implementovaného řešení.
2.2.4 MVP
Jak už bylo zmíněno v předchozích kapitolách, minimální životaschopný produkt neboli MVP je nedílnou součástí při budování Startupu pomocí Lean metodik. Eric Ries definoval MVP takto:
„Minimum viable product (MVP) je taková verze nového produktu, kterou tým využije pro sběr co největšího množství ověřených poznatků o zákaznících při vydání co nejméně energie a prostředků.“
(RIES, 2009). Cílem MVP je vytvoření takového produktu, který dovolí, co nejrychlejší zahájení smyčky „Vytvoř-Změn-Pouč se“ a tím nám umožní sbírat zpětnou vazbu od zákazníků a vylepšovat produkt. Nejčastěji se jedná o nejjednodušší formu produktu, který zákazníkům sdělí funkcionalitu produktu a přináší jim jasnou hodnotu. Nejedná se však o produkt s nedokončenou funkcionalitou.
MVP by měl obsahovat kompaktní funkcionalitu, ucelený a kvalitní design, produkt by měl být spolehlivý a zároveň by měl být použitelný. Avšak MVP nemusí být pouze aplikace, může to být například i video, které zákazníkům představí produkt a na základě něhož může následně započít smyčka „Vytvoř-Změn-Pouč se“.
26
2.3 Technologie
Tato kapitola představuje jednotlivé technologie použité při vývoji aplikace v rámci této práce. Pro vývoj aplikace byl použity nejmodernější technologie, které se využívají pro vývoj webových aplikací, a jejich využitím se dosáhne udržitelného kódu, který bude v budoucnosti jednoduchý na údržbu a následující vývoj.
V této kapitole je nejprve popsán samotný jazyk Javascript, který používají všechny následující technologie jako hlavní programovací jazyk. Další popsanou technologií je ReactJS, který se používá pro tvorbu klientského prostředí. Další technologií je Node.js, který je používán pro vytváření serverové části aplikace. Dále je popsán dotazovací jazyk GraphQL, který je využíván pro komunikaci mezi klientskou a serverovou částí aplikace. Dalšími popsanými technologiemi jsou Apollo server, pomocí kterého se implementuje GraphQL server, UI knihovna Ant design a Styled components pro zápis stylů.
2.3.1 Javascript
Javascript je nejrozšířenějším programovacím jazykem pro psaní webových aplikací. Tento jazyk byl vytvořen v roce 1995 firmou Netscape. Původně byl Javascript představen jako jednoduchý skriptovací jazyk, ale postupem času se rozvíjel a dostal se až do podoby, kdy pomocí tohoto programovacího jazyku je stavěna velká část klientských i serverových částí aplikací. V tomto projektu jsou na Javascriptu postaveny všechny knihovny použité při vývoji.
2.3.2 ReactJS
ReactJs je jedním z nejvíce oblíbeným javascriptovým frameworkem pro tvorbu klientské části (UI) aplikace (STATE OF JS, 2020). Jedná se o open-source knihovnu od společnosti Facebook, původně zveřejněnou v roce 2013, pomocí které se vytváří uživatelské rozhraní aplikace. Základním prvkem této knihovny jsou komponenty, díky nimž se zapouzdří HTML elementy se svou funkcionalitou a mohou se opakovaně používat v aplikaci, čímž vzniká komplexní UI aplikace. Každá komponenta má také své vlastnosti (props) a uchovává si svůj vnitřní stav. Tento způsob s daty vede k předvídatelnému chování i snadnému ladění, a to je jeden z důvodů, proč tato knihovna získala svou popularitu (MÁCA, 2019). Díky své popularitě má ReactJS ohromnou komunitu, která vytváří další knihovny pro usnadnění vývoje klientských aplikací.
2.3.3 Node.js
Node.js je prostředí, které umožňuje spouštět javascriptový kód na serveru. Toto prostředí je postaveno na Chrome V8 javascript enginu, díky kterému je JS prostředí stejné jako ve webovém prohlížeči. Node.js je primárně určený pro vytváření serverové části webových aplikací, ale využít se může kdekoliv.
27
Hlavní výhodou Node.js je to, že využívá událostmi řízený neblokující model (Node.js, 2020), díky čemuž se požadavky zpracovávají asynchronně a neblokují vstup/výstup, jako je tomu u PHP serverů.
V této práci se Node.js využívá pro tvorbu serverové části aplikace. Díky tomu, že se jako základní programovací jazyk používá na klientské i serverové části, tak je možné znovu používat některé části kódu a také je možné využívat stejné knihovny.
2.3.4 GraphQL
GraphQL je dotazovací jazyk, který konkuruje dlouhodobě nejužívanějšímu řešení REST API. Tato technologie vznikla v roce 2012 ve firmě Facebook při vývoji jeho nativní aplikace. V roce 2015 ji Facebook zveřejnil jako open-source řešení a od té doby začalo tuto technologii využívat stále více vývojářů.
Mezi největší přednosti GraphQL patří snížení počtů dotazů na rozhraní. Toho je docíleno tím, že tato technologie využívá pouze jeden „endpoint“ a dynamicky se měnící data. Díky tomu, že odpověď se přizpůsobuje struktuře dotazu, je možné docílit toho, že klientská část aplikace si vyžádá pouze nutná data a pracuje se pouze s daty, která jsou nezbytně nutná pro běh aplikace. Tím se docílí nižší datové náročnosti požadavků, aplikace je výkonnější a zajišťuje spolehlivější reakce.
Pomocí GraphQL je také jednoduché mockování dat neboli nahrazení funkčnosti její imitací, které je možno využít při vývoji klientské části aplikace, pokud ještě není vytvořená serverová část. Díky typovému systému v GraphQL je možné sdílet mezi serverovou a klientskou částí aplikace definice typů, pomocí kterých se získají potřebné informace pro mockování dat.
V tomto projektu se GraphQL využívá jako hlavní dotazovací jazyk, pomocí kterého klientská část komunikuje se serverovou částí aplikace.
2.3.5 Apollo server
Apollo server je open-source knihovna pro implementaci GraphQL serveru, pomocí kterého se vytváří pně funkční GraphQL API a automaticky vytváří svou dokumentaci. Apollo také nabízí GraphQL klienta pro klientskou část aplikace, která je psána pomocí ReactJS (APOLLO, 2020). Na serverové části aplikace je třeba definovat schéma, jenž popisuje strukturu dat, na která se může klientská část aplikace dotazovat.
V tomto projektu je využit Apollo serve, jenž se stará o komunikaci s databází a vytváří GraphQL server, na který se dotazuje klientská část aplikace pomocí Apollo Client.
2.3.6 Ant design
Pro ReactJS je vytvořeno mnoho UI knihoven, které obsahují již vytvořené komponenty. Tyto komponenty jsou v rámci jedné knihovny vytvořeny v jednotném designu a jejich používání ušetří mnoho času při vytváření aplikace a také dodají aplikaci ucelený vzhled bez nutnosti vytváření
28
grafických návrhů. Jednou z nejvíce používaných UI knihoven je Ant Design, který vytvořila čínská skupina Alibaba a využívá ji ve svých produktech.
Knihovna Ant Design má velice dobře strukturovanou anglicky psanou dokumentaci a díky tomu je její použití velice lehké. Pro použití komponenty stačí naimportovat komponentu, která již obsahuje svou logiku a UI. Tato knihovna obsahuje více než 60 vytvořených komponent, mezi něž patří základní komponenty, jako jsou texty, ikony, tlačítka, ale také ty pokročilejší, které se starají o vytváření layoutu, vykreslování dat a správu formulářových prvků.
V tomto projektu jsou nejvíce používané právě komponenty pro správu formulářových prvků z knihovny Ant Design, ale také se využívají základní komponenty pro vytváření grafického obsahu.
2.3.7 Styled components
Pro stylování elementů v ReactJS existuje několik přístupů. Tím nejzákladnějším je stylování elementů pomocí klasického zápisu CSS v CSS souborech, které se poté importují do aplikace. Tímto způsobem se ale přichází o mnoho výhod, které může nabídnout CSS preprocesor, proto je vhodné k tomuto způsobu přidat například preprocesor SASS, který klasický zápis CSS rozšíří o důležité funkce, jako jsou například proměnné, nebo mixiny. Stále je ale důležité myslet na to, že React aplikace jsou velmi dynamické a CSS styly musí reagovat na změny stavu komponenty. Kvůli tomuto důvodu vznikl další způsob zapisování stylů, který se nazývá „CSS-in-JS“. Základní myšlenkou tohoto přístupu je to, že se nevyužívá žádný CSS soubor, ale styly jsou definované přímo v javascriptovém kódu. Pro tento druh zápisu je nutné využít knihovnu, jež se naimportuje do projektu. V aplikaci Premas se využívá knihovna Styled Components, která je jednou z nejvíce využívaných knihoven pro
„CSS-in-JS“. Pomocí Styled Components se vytváří komponenty z HTML elementu a řetězce textu, který definuje styly elementu. Zápis pomocí této knihovny nejlépe vysvětlí úryvek kódu přímo z aplikace (Výpis kódu 1).
import styled from 'styled-components';
export const Container = styled.div`
margin: auto;
width: 100%;
max-width: ${({ theme }) => theme.dimensions.pageWidth};
padding: 0 20px;
`;
Výpis kódu 1: Ukázka zápisu komponenty pomocí Styled Components
Na tomto výpisu kódu jde vidět, že komponenta se vytvoří pomocí funkce styled, která rozšíří jakýkoliv HTML element o možnost definování stylů. Výhodou tohoto přístupu je to, že vytvořená komponenta může využívat proměnné definované v javascriptovém kódu. V této ukázce se používá proměnná „theme“, pomocí níž se definují základní proměnné dokumentu. Dále také může komponenta pracovat s props, které se do komponenty předávají, a díky tomu může měnit svůj vzhled v závislosti na stavu komponenty.
29
3 Praktická část
V této kapitole je popsán proces vývoje aplikace Premas, který probíhá pomocí metody Lean Startup. Nejprve je ověřena prvotní myšlenka na základě diskuse týmu a rozhovoru s prvotními uživateli produktu. Následně je vytvořen Lean Canvas a jsou analyzovány největší rizika produktu.
Dalším krokem je analýza a návrh aplikace a na základě této analýzy je poté aplikace implementována. Na závěr je popsáno samotné nasazení aplikace, sledování získaných dat a zpětné vazby na ni.
Analýza, návrh a vývoj prvního MVP aplikace Premas probíhaly v rámci předmětu 4IT580. Během těchto činností byla zpracována i první verze modelu Lean Canvas, ten byl však v rámci této diplomové práce přepsán, aby více odpovídal vytvářenému produktu.
3.1 Vznik a ověření prvotní myšlenky
Prvotní myšlenka byla představena vedoucím této diplomové práce Janem Černým formou Elevator pitche (ČERNÝ, 2020). V krátké prezentaci byly představeny základní myšlenky tohoto produkty, který si klade za cíl zvýšit povědomí o zdravotní prevenci. Problémem je, že lidé nechodí k lékaři na preventivní prohlídky, protože nemají žádné obtíže, nebo protože se bojí, případně nevědí, že by měli na preventivní prohlídky chodit. Na internetu se již nacházejí informace o preventivních programech, které se zabývají konkrétní problematikou, ale nevýhodou je, že tyto informace jsou decentralizované. Z toho důvodů si uživatelé buďto najdou pouze prevenci toho, co je trápí a pro nezkušené uživatele je složité si najít i tyto základní informace. Také existuje spousta nemocí, které dlouho nemají vnější příznaky, ale diametrálně se liší jejich řešení podle termínu záchytu. Proto vznikla myšlenka na vytvoření aplikace, která umožní uživatelům vyhledat a vyfiltrovat preventivní vyšetření, které se jich týkají. Také umožní uživatelům centralizovat informace o zájmových skupinách a zároveň inspiruje uživatele k podstoupení preventivních vyšetření na základě příběhů lidí, kterým prevence zachránila život.
3.1.1 Analýza prvotní myšlenky
Prvotní myšlenka, která byla představená Janem Černým formou Elevator pitche (ČERNÝ, 2020) byla následně diskutována a analyzována v rámci týmu, který vznikl v předmětu 4IT580 na VŠE. Během diskuse se tato prvotní myšlenka rozšířila o další možné funkcionality, které by mohla aplikace nabídnout a ověřilo se, že tato myšlenka se členům týmu zamlouvá a vidí v ní velký potenciál.
Během analýzy prvotní myšlenky byl také proveden úvodní průzkum, zda by o aplikaci měli zájem i doktoři, kteří by spolupracovali na tomto produktu a plnili obsah aplikace články a informacemi o
30
vyšetření. Tato myšlenka se osloveným doktorům zalíbila a přislíbili účast při tvorbě obsahu, který bude klíčový pro úspěch tohoto produktu.
Další průzkum byl proveden formou oslovení koncových uživatelů aplikace. Osloveni byli členové rodin a přátelé členů týmu a ihned byla získána pozitivní zpětná vazba, která potvrdila zájem o tento produkt. Nejvíce se osloveným lidem zamlouvala myšlenka o tom, že preventivní programy budou centralizované na jednom místě, protože v současné době neví, kde by informace o prevenci měli vyhledávat.
3.1.2 Aplikace Premas
Po analýze prvotní myšlenky projektu, který byl původně nazván „Prevence má smysl“ se zkratkou projektu „PMS“ byl zvolen vhodnější název aplikace, kterým je „Premas“ s podtitulem „Prevence má smysl“. Tento nový název je i brandem projektu a pro tento brand bylo vytvořeno logo, které je zobrazeno na obrázku níže (Obrázek 5).
Obrázek 5: Logo aplikace
Cílem této aplikace je informovat občany o nutnosti prevence, čehož bude docíleno hlavně pomocí článků na blogu. Ty budou obsahovat mimo jiné i příběhy lidí, kteří se vyléčili díky včasné prevenci.
Tato aplikace se dále snaží o to, aby lidé měli jednoduchý přístup k informacím o preventivních vyšetřeních, které se jich týkají. Aplikace bude obsahovat širokou škálu vyšetření a uživatelé budou mít možnost si vyhledat právě ta, která jsou pro ně momentálně vhodná. Tohoto cíle bude dosaženo pomocí jednoduchého formuláře, ve kterém uživatel vyplní svůj zdravotní profil.
Aby aplikace byla neustále aktuální, bude obsahovat rozhraní pro lékaře, kteří se budou podílet na tvorbě obsahu a v tomto rozhraní budou moci jednoduše přidávat nové články, preventivní vyšetření a nastavovat pravidla vyšetření, která budou určovat, pro jaký zdravotní profil jsou doporučená.
Aplikace bude volně přístupná na internetu a bude vyvíjená pro desktopové i mobilní zařízení, aby si uživatelé mohli nalézt informace o prevenci na jakémkoli zařízení. Důležitým prvkem je i to, aby administrace byla přístupná i na mobilním zařízení, aby lékaři mohli ihned upravovat informace v aplikaci s využitím jejich mobilního telefonu.
31
3.2 Analýza konkurence
I na trhu, který se zabývá zdravotní prevencí se nachází konkurenční firmy, které je zapotřebí monitorovat a vědět, jaké projekty realizuje. V případě projektu Premas je ale konkurence specifická z důvodu, že identifikované společnosti, které konkurují našemu produktu jsou zároveň vhodnými partnery pro náš projekt, a proto je důležité tyto společnosti podrobně analyzovat a následně oslovit s nabídkou spolupráce, při které bychom se navzájem podporovali.
Přímou konkurencí pro náš Startup byla identifikována pouze společnost Loono. V případě dalších identifikovaných společností se jedná pouze o nepřímou konkurenci. Jsou většinou zaměřeny na informování společnosti o konkrétním problému, organizují preventivní akce a další aktivity, které mají za cíl rozšířit povědomí o něm. Nevýhodou toho, že existuje mnoho společností, které informují pouze o konkrétním problému je, že jsou tyto informace decentralizované a pacient si zjistí pouze informace o problému, který ho trápí a k dalším preventivním programům se nedostane. Proto bychom chtěli tyto společnosti oslovit s nabídkou spolupráce, při které budeme prezentovat jejich aktivity v naší aplikaci, a tím se dosáhne většího dosahu kampaní, při kterých se informuje společnost o nutnosti zdravotní prevence.
Specifickou konkurenci představují i zdravotní pojišťovny, které na svých stránkách představují preventivní prohlídky, které by měl každý podstoupit.
3.2.1 Loono
První identifikovanou konkurencí je společnost Loono. Jejich poslání nejlépe vystihuje sdělení, které mají uvedené na webových stránkách.
„Ukazujeme, jak je prevence důležitá. Jsme tým mladých lékařů, studentů medicíny a dalších profesionálů. Skrze workshopy a webináře ve školách, firmách i na festivalech vzděláváme veřejnost v oblasti prevence onkologických (#prsakoule) a kardiovaskulárních onemocnění (Žiješ srdcem).
Nezapomínáme ale ani na reprodukční (Dole dobrý) a duševní zdraví (Dobré nitro).“ (Loono, 2021)
Společnost Loono byla založena v roce 2014 Kateřinou Vackovou poté, co jí byl ve 22 letech diagnostikován zhoubný nádor vaječníku. Díky včasné diagnostice, která byla učiněna na základě preventivních prohlídek, se Kateřina vyléčila, a rozhodla se inspirovat další mladé lidi. Společnost se věnuje pořádání workshopů ve školách a firmách, organizaci panelových diskusí na lékařská témata, vzdělávání veřejnosti skrze web a sociální sítě, dodávání edukačních materiálů do ordinací, natáčení vlastního podcastu, psaní blogu a také poskytuje online poradenství (Loono, 2021).
Financování společnosti Loono probíhá pomocí pravidelných crowfundingových kampaní, přijímáním darů od soukromých i firemních dárců a prodejem vlastních produktů s logem společnosti.
Loono je jedinou identifikovanou společností, která poskytuje podobné služby jako náš projekt.
V rámci webové aplikace tato společnost prezentuje širokou škálu preventivních vyšetření, což je podobná funkcionalita jako klíčová funkcionalita našeho projektu, avšak náš produkt se liší tím, že
