Vývoj webové aplikace od nápadu po spuštění

Nápad na novou aplikaci je pouze začátek. Aby z něj vzniklo řešení, které lidé skutečně používají a firma může dlouhodobě rozvíjet, musí projekt projít analýzou, návrhem, vývojem, testováním i správným nasazením. Při vývoji webové aplikace na míru proto není důležitý jen samotný kód, ale celý postup od prvního zadání až po práci s aplikací v ostrém provozu. V tomto článku vám specialisté z Expert Dev vysvětlí, jak jednotlivé fáze probíhají a na co se v každé z nich zaměřit.

Dobře vedený vývoj pomáhá držet pod kontrolou rozsah projektu, omezit zbytečné předělávky a soustředit rozpočet na funkce, které mají pro uživatele skutečný přínos. Ne každý projekt přitom potřebuje stejné technologie ani stejný rozsah první verze. Důležité je nejprve pochopit problém a teprve potom hledat nejlepší způsob jeho řešení.

Co je webová aplikace a čím se liší od běžného webu?

Běžný firemní web slouží především k prezentaci informací. Uživatel si prohlíží služby, produkty nebo reference a případně odešle formulář. Webová aplikace jde dál. Umožňuje lidem aktivně pracovat s daty, přihlašovat se do účtu, měnit stavy, objednávat, rezervovat, schvalovat požadavky nebo provádět další činnosti podle konkrétního procesu.

Mezi webové aplikace mohou patřit například:

• klientské a partnerské portály

• rezervační systémy

• interní evidence zakázek

• B2B objednávkové systémy

• CRM a další firemní systémy

• 2D a 3D konfigurátory

• online kalkulačky

• SaaS služby

• administrační nástroje

• zákaznické zóny

Při vývoji webových aplikací se proto neřeší pouze vzhled jednotlivých obrazovek. Důležitá je také logika aplikace, struktura dat, oprávnění uživatelů, automatizace a případná komunikace s dalšími systémy. Pokud teprve hledáte, jaký typ řešení může odpovídat vašemu projektu, pomůže také přehled různých typů webových aplikací.

1. Nápad nejprve převeďte do konkrétního problému

První fáze vývoje nepatří programování. Nejdříve je potřeba přesně popsat, proč má aplikace vzniknout a komu má pomáhat. U nového digitálního produktu může být cílem nabídnout zákazníkům službu, která na trhu chybí. U interní aplikace bývá důvod praktičtější. Firma například potřebuje nahradit ruční přepisování dat, sjednotit několik tabulek nebo zjednodušit předávání zakázek mezi odděleními.

Na začátku má smysl ujasnit si zejména:

• Jaký problém má aplikace odstranit?

• Kdo bude aplikaci používat?

• Jak uživatelé stejný úkol řeší dnes?

• Kde v současném procesu vznikají chyby nebo zdržení?

• Jaký výsledek má aplikace přinést?

• Podle čeho poznáme, že projekt splnil svůj účel?

U zákaznického produktu je vhodné přidat také průzkum trhu a dostupných alternativ. U interního systému je naopak často důležitější detailní popis současného procesu.

Zapojte budoucí uživatele už na začátku

Vedení firmy obvykle zná obchodní cíle projektu, ale každodenní detaily procesu nejlépe znají lidé, kteří ho skutečně vykonávají. Obchodník může upozornit na výjimky při schvalování nabídky, pracovník skladu na specifický způsob evidence a zákaznická podpora na informace, které potřebuje při komunikaci s klientem. Pokud se tyto zkušenosti dostanou do zadání až po zahájení vývoje, mohou vznikat zbytečné změny a přepracování.

2. Z požadavků vytvořte zadání a rozsah první verze

Po základní analýze přichází chvíle, kdy se obecné představy musí změnit na konkrétní funkce a scénáře používání. Místo požadavku „potřebujeme systém na zakázky“ je například vhodnější popsat, že obchodník založí novou zakázku, technik doplní parametry, odpovědný pracovník potvrdí termín a zákazník následně vidí stav realizace ve své sekci. Takové scénáře pomáhají vývojářům i zadavateli pochopit, co má aplikace skutečně dělat.

MVP pomáhá udržet první verzi pod kontrolou

U většiny projektů není nutné vytvořit všechny plánované funkce hned při prvním spuštění. Praktickou cestou bývá MVP neboli první použitelná verze aplikace, která řeší hlavní potřebu uživatele. Dobré MVP není aplikace vytvořená co nejlevněji. Jde o nejmenší rozsah, který už dokáže přinést uživateli hodnotu a umožní ověřit, zda zvolený koncept funguje. Požadavky lze například rozdělit do tří skupin:

1. Nutné pro první spuštění
   Bez těchto funkcí aplikace nemůže splnit svůj základní účel.

2. Důležité pro další fázi
   Funkce mají přínos, ale první verze může fungovat i bez nich.

3. Možné budoucí rozšíření
   Nápady, které má smysl vyhodnotit až podle reálného používání.

Představme si modelový B2B portál. Pro spuštění může potřebovat přihlášení, produktový katalog, vytvoření objednávky a historii nákupů. Pokročilý reporting, personalizované dashboardy nebo další automatizace mohou přijít později, pokud se ukáže, že je zákazníci nebo interní tým skutečně využijí. Současně se nevyplatí z MVP vynechávat základní technické prvky, které chrání další rozvoj. Patří mezi ně přiměřené zabezpečení, správa přístupů, logování chyb, zálohování nebo promyšlená struktura dat.

3. UX, UI a prototyp ukážou aplikaci ještě před programováním

Jakmile je známý rozsah aplikace, začíná se navrhovat způsob, jakým s ní budou lidé pracovat. Nejprve mohou vzniknout jednoduché wireframy. Ty ukazují rozmístění obsahu, navigace, formulářů a dalších prvků bez řešení finální grafiky. Díky tomu lze relativně snadno upravit logiku obrazovek ještě předtím, než se začne programovat. Na wireframy následně navazuje vizuální návrh a případně interaktivní prototyp. Kvalitní UX a UI pomáhá uživateli rychle pochopit, co má v aplikaci udělat, kde najde potřebné informace a jak se dostane k výsledku.

U návrhu je vhodné sledovat zejména:

• srozumitelnou navigaci,

• logické pořadí jednotlivých kroků,

• jednoduché formuláře,

• čitelné stavy a upozornění,

• přehledné zobrazení důležitých dat,

• pohodlné používání na relevantních zařízeních.

Prototyp může odhalit problém dříve než hotový kód

Pokud uživatel neví, kam má kliknout v prototypu, bude mít stejný problém i v naprogramované aplikaci. Opravit návrh obrazovky před zahájením vývoje bývá výrazně jednodušší než měnit hotovou funkcionalitu. Proto má smysl důležité scénáře projít ještě před samotným programováním a ověřit, zda odpovídají běžné práci uživatelů.

4. Technický návrh určí základ budoucí aplikace

Technologie by se neměla vybírat jen podle popularity nebo osobní preference vývojáře. Rozhoduje typ aplikace, práce s daty, integrace, bezpečnostní požadavky, očekávaný provoz a plán dalšího rozvoje.

V této fázi se řeší například:

• struktura databáze,

• frontend a backend aplikace,

• způsob přihlášení a oprávnění,

• propojení s dalšími službami,

• hosting a infrastruktura,

• ukládání a zálohování dat,

• požadavky na výkon,

• možnosti dalšího rozšiřování.

Konkrétní projekt může využívat například Laravel, React, Vue nebo jiné technologie. Pro zadavatele ale není nutné jednotlivé možnosti vybírat bez technického kontextu. Důležitější je rozumět tomu, proč dodavatel konkrétní řešení navrhuje a jaké důsledky má pro další provoz. Širší problematice technologického rozhodování se věnuje také článek o tom, proč záleží na výběru frameworku.

Architektura má odpovídat skutečným potřebám

Ani u aplikace s plánovaným růstem není automaticky potřeba začít nejsložitější možnou architekturou. Často je výhodnější navrhnout řešení tak, aby odpovídalo současným potřebám a současně umožňovalo další rozvoj. Předčasně komplikovaná infrastruktura může zvýšit cenu vývoje i následné správy, aniž by uživatelům přinesla odpovídající hodnotu.

5. Samotný vývoj probíhá po jednotlivých částech

Po schválení zadání, návrhu a technického řešení může začít samotná tvorba webové aplikace. Vývoj se zpravidla dělí na dvě propojené oblasti. Frontend představuje část aplikace, kterou uživatel vidí a ovládá. Backend zpracovává data, aplikační logiku, oprávnění a komunikaci s dalšími systémy. U rozsáhlejšího projektu se nevyplatí čekat několik měsíců na okamžik, kdy vývojový tým poprvé ukáže hotový výsledek. Praktičtější je postupovat po menších etapách, ve kterých lze jednotlivé části průběžně kontrolovat.

Takový způsob práce umožňuje:

• ověřovat funkce v průběhu vývoje,

• včas zachytit odlišné očekávání klienta a týmu,

• lépe řídit priority,

• zapracovávat relevantní zpětnou vazbu,

• průběžně kontrolovat rozsah projektu.

Součástí profesionálního vývoje je také verzování kódu a oddělení vývojového, testovacího a produkčního prostředí. Změny se tak mohou před zveřejněním bezpečně ověřit mimo aplikaci, kterou používají skuteční uživatelé. Pokud chcete širší pohled na možnosti zakázkového softwaru, navazuje na toto téma také služba vývoj aplikací.

6. Integrace propojí webovou aplikaci s dalšími systémy

Firemní aplikace často nefunguje samostatně. Potřebuje přebírat nebo předávat data do účetnictví, CRM, ERP, e-shopu, skladu, platební brány nebo jiné interní aplikace. Nestačí přitom pouze zajistit, že mezi systémy „nějak tečou data“. Je potřeba určit:

1. který systém představuje hlavní zdroj konkrétní informace,

2. kdy se mají data synchronizovat,

3. co se má stát při chybě nebo nedostupnosti externí služby,

4. jak se řeší duplicity a rozdílné hodnoty,

5. kdo dostane informaci, pokud přenos selže.

Pro tato napojení lze využít API konektory nebo vytvořit vlastní integrační logiku podle možností jednotlivých systémů.

Přemýšlejte o datech jako o součásti celého procesu

Modelový příklad může představovat zákaznický portál napojený na ERP. Zákazník odešle objednávku v portálu, aplikace ji předá do podnikového systému a následně zákazníkovi zobrazuje aktuální stav. Pokud se přenos nepodaří, systém musí chybu zachytit a nesmí uživateli zobrazovat informace, které neodpovídají realitě. U projektů, kde aplikace propojuje obchod, servis, finance nebo další větší části firmy, může být vhodné uvažovat také v širším kontextu informačních systémů na míru.

7. Testování ověřuje víc než jen to, zda tlačítko funguje

Testování nezačíná až poslední den před spuštěním. Kvalitu je vhodné kontrolovat průběžně během celého vývoje. Podle charakteru projektu se ověřuje několik oblastí:

• Funkčnost – zda jednotlivé procesy odpovídají zadání.

• Použitelnost – zda uživatel dokáže aplikaci bez zbytečných překážek ovládat.

• Integrace – zda správně probíhá předávání dat mezi systémy.

• Oprávnění – zda uživatel vidí a může měnit pouze to, k čemu má mít přístup.

• Bezpečnost – zda aplikace přiměřeně chrání účty, data a citlivé operace.

• Výkon – zda systém zvládá očekávaný způsob používání.

• Chybové situace – co se stane při neplatném vstupu, výpadku služby nebo jiné nestandardní situaci.

Část kontrol lze automatizovat, jiné vyžadují manuální průchod aplikací. Nejdůležitější je, aby se netestoval pouze ideální scénář. U objednávkového systému například nestačí ověřit úspěšné vytvoření objednávky. Je potřeba vědět také, co se stane při neúspěšné platbě, nedostupném skladu nebo výpadku napojeného systému.

8. Nasazení do ostrého provozu vyžaduje vlastní plán

Po dokončení a otestování aplikace přichází spuštění produkční verze. Ještě před ním je potřeba připravit prostředí, ve kterém aplikace poběží. Patří sem konfigurace serveru, databáze, certifikátů, záloh, monitoringu a dalších služeb podle charakteru projektu. Pokud nová aplikace nahrazuje starší systém, součástí nasazení může být také migrace dat. Ta vyžaduje kontrolu struktury a kvality převáděných informací. Není vždy vhodné automaticky přenést všechna historická data jen proto, že existují.

První spuštění nemusí znamenat okamžitý přístup pro všechny

U některých projektů je vhodné nasadit aplikaci nejprve omezené skupině uživatelů. Tým tak může sledovat reálné používání, získat první zpětnou vazbu a upravit případné problémy před širším spuštěním. U interního systému to může znamenat pilot v jednom oddělení. U zákaznické aplikace například přístup pro vybranou skupinu klientů. Způsob spuštění závisí na riziku, velikosti změny a významu aplikace pro běžný provoz.

9. Spuštěním vývoj webové aplikace nekončí

Teprve v ostrém provozu se ukáže, jak uživatelé s aplikací skutečně pracují. Některé předpoklady se potvrdí, jiné bude potřeba upravit. Po spuštění má proto smysl sledovat například:

• technické chyby,

• výkon aplikace,

• využívání jednotlivých funkcí,

• místa, kde uživatelé nedokončují proces,

• požadavky zákaznické podpory,

• zpětnou vazbu uživatelů.

Na základě těchto informací lze plánovat další vývoj. Důležitá je také pravidelná technická správa. Aplikace může potřebovat aktualizace frameworků a knihoven, bezpečnostní opravy, úpravy integrací nebo změny vyvolané novými požadavky firmy. Dobrá webová aplikace proto není jednorázový produkt, který po spuštění zůstane několik let beze změny. Je to nástroj, který by měl reagovat na vývoj firmy i skutečné chování uživatelů.

Kolik stojí vývoj webové aplikace?

Na tuto otázku neexistuje univerzální částka. Rozdíl mezi jednoduchým interním nástrojem a rozsáhlým zákaznickým portálem s integracemi, platbami a různými uživatelskými rolemi může být velmi výrazný. Cena vývoje závisí zejména na:

• rozsahu funkcionality,

• složitosti obchodních pravidel,

• počtu uživatelských rolí,

• požadavcích na UX a UI,

• integracích na další systémy,

• migraci existujících dat,

• bezpečnostních a provozních požadavcích,

• rozsahu testování,

• potřebné infrastruktuře,

• dalším rozvoji po spuštění.

Integrace mohou ovlivnit rozsah více, než se na začátku zdá

Napojení na účetnictví nebo ERP neznamená jen technicky „propojit dvě API“. Je potřeba určit, která data se přenášejí, jak se mapují, co se děje při změně nebo chybě a jak se budou řešit výjimky. Podobně roste rozsah s počtem odlišných uživatelských rolí a pravidel. Každé oprávnění nebo nestandardní workflow přidává další scénáře, které je potřeba navrhnout, naprogramovat a otestovat.

Kvalita zadání pomáhá držet rozpočet pod kontrolou

Pokud projekt začne s jasně popsaným cílem, prioritami a rozsahem první verze, lze další etapy plánovat mnohem lépe. Neznamená to, že se během vývoje nesmí nic změnit. Zpětná vazba je přirozenou součástí projektu. Rozdíl je mezi řízenou změnou a situací, kdy se základní představa o aplikaci mění až během programování. Při plánování rozpočtu je proto vhodné myslet nejen na vytvoření první verze, ale také na provoz, údržbu a další rozvoj.

Webová aplikace na míru, nebo hotové řešení?

Vývoj vlastní aplikace není správnou volbou pro každý proces. Pokud firma řeší standardní potřebu, kterou hotový systém pokrývá bez zásadních omezení, může být takové řešení rychlejší i ekonomičtější. Vlastní aplikace získává větší význam ve chvíli, kdy proces vyžaduje specifická pravidla, integrace, více uživatelských rolí nebo způsob práce, který se do možností běžného nástroje nevejde.