Vývoj webové aplikace na míru: kdy už tabulky firmě nestačí
Když se firemní proces dělí mezi tabulky, e-maily a ruční přepisování, může pomoci vlastní aplikace. Projdeme cestu od zadání a první použitelné verze přes prototyp a integrace až po spuštění a správu.
Kdy tabulky firmě stačí a kdy už potřebuje aplikaci
Tabulka je dobrý nástroj pro výpočty, přehledy a práci s daty, jejichž strukturu potřebujete rychle měnit. Pokud je postup jednoduchý a odpovědnosti jsou jasné, může sloužit dlouhodobě. Před zahájením vývoje proto nejprve prověřujeme, zda pomůže lepší nastavení současných nástrojů nebo vhodná hotová služba.
Webová aplikace na míru začíná dávat smysl ve chvíli, kdy potřebujete propojit více lidí a kroků, řídit přístup k jednotlivým záznamům a spolehlivě hlídat jejich stav. Typickým příkladem je klientský portál, schvalování podkladů, evidence servisních požadavků nebo interní řízení zakázek.
Více návazných kroků
Jeden člověk zakládá požadavek, další doplňuje podklady a někdo jiný schvaluje. Potřebujete vědět, kdo má právě jednat.
Různá oprávnění
Zaměstnanec, vedoucí a klient mají vidět odlišné informace a provádět různé úkony. Rozhoduje i jejich vztah ke konkrétní zakázce.
Společná historie
Potřebujete dohledat, která verze podkladu byla schválená, kdo změnil termín a jaké údaje se předaly do dalšího systému.
Firemní web převážně představuje nabídku a přivádí poptávky. Aplikace navíc umožňuje lidem vykonávat konkrétní úkoly nad společnými daty. Její rozsah proto neurčuje jen počet obrazovek, ale také pravidla, návaznosti a situace, které musí zvládnout.
Vyberte jeden proces, který půjde dokončit celý
Pro první etapu je užitečné vybrat konkrétní pracovní postup. Například schválení podkladů od jejich nahrání až po potvrzení finální verze. Tým si tak vyzkouší skutečné použití a získá podklady pro další rozvoj.
Takto vymezená první použitelná verze se často označuje jako MVP. Má obsahovat vše potřebné pro zvolený úkol včetně oprávnění, srozumitelných chybových stavů a provozního zajištění.
Modelový příklad: schvalování podkladů
Autor nahraje soubor a vybere schvalovatele. Ten dokument schválí nebo vrátí s připomínkou. Aplikace eviduje konkrétní verzi, rozhodnutí i čas změny. Další etapa může přidat podrobné reporty nebo napojení na fakturaci.
U každého kroku si položte otázku, co se má stát při výjimce. Kdo převezme úkol za nepřítomného kolegu? Co když autor nahraje nový soubor během schvalování? Je možné rozhodnutí odvolat? Právě tyto situace zpřesňují skutečný rozsah aplikace.
Kdo pracuje s jakými daty a co smí měnit
Před návrhem obrazovek potřebujeme pojmenovat hlavní záznamy a jejich vztahy. Zakázka může mít klienta, odpovědného pracovníka, termín, soubory a historii schválení. U každého údaje určíme, kde vzniká, kdo jej mění a zda se mají uchovávat předchozí hodnoty.
Současně vznikají pravidla přístupu. Obecná role „klient“ nestačí, pokud má každý klient vidět pouze vlastní zakázky. Rozhodnutí musí zohlednit také vztah uživatele ke konkrétním datům.
| Role | K čemu má přístup | Co může udělat |
|---|---|---|
| Autor podkladu | Ke svěřeným zakázkám a jejich souborům. | Nahrát verzi a předat ji ke schválení. |
| Schvalovatel | K podkladům, které mu byly přidělené. | Schválit konkrétní verzi nebo připojit připomínku. |
| Klient | K zakázkám své firmy a zpřístupněným výstupům. | Provést pouze výslovně povolené klientské úkony. |
| Správce | Ke správě uživatelů a nastavení podle dohodnutého rozsahu. | Měnit přidělení rolí a řešit provozní nastavení. |
Oprávnění musí aplikace kontrolovat na serveru při každém požadavku. Skrytí tlačítka samo přístup k datům nechrání. Kontrolu jednotlivých požadavků a udělování jen potřebných oprávnění doporučuje také OWASP v přehledu zásad autorizace.
Do návrhu patří i práce se soubory, zrušení přístupu při odchodu zaměstnance a přehled důležitých změn. U klientského portálu je oddělení dat jednotlivých firem jedním ze základních scénářů ověřování.
Nechte budoucí uživatele projít skutečný úkol
Interaktivní prototyp pomáhá ověřit strukturu a ovládání ještě před dokončením vývoje. Uživatel dostane konkrétní zadání: najít zakázku, doplnit termín, vrátit podklad nebo zjistit, na koho čeká další krok.
Sledujeme, zda rozumí názvům, pozná aktuální stav a ví, co se stane po potvrzení akce. Důležitá je také práce s delším obsahem, prázdným přehledem nebo formulářem, ve kterém něco chybí.
Pro práci v kanceláři
Přehledy, vyhledávání, filtrování a rychlé opakované úkony. Rozložení má odpovídat tomu, co lidé používají nejčastěji.
Pro práci v terénu
Čitelné stavy, jednoduché zadávání a ovládání na telefonu. Pokud je potřeba práce bez připojení, zahrneme ji výslovně do technického zadání.
Prototyp prověří srozumitelnost postupu. Výkon, bezpečnost a skutečné propojení systémů se ověřují samostatně během vývoje a testování.
Vizuální prostředí má také navazovat na značku. Jak vznikají jeho základní pravidla, popisuje článek Tvorba loga firmy a vizuální identity. Propojení identity, webu, aplikace a kiosků ukazuje naše veřejná reference 360 Pizza.
Jak aplikace naváže na CRM, ERP a další nástroje
Aplikace může využívat zákazníky z CRM, přebírat údaje z podnikového systému nebo předávat dokončené zakázky k dalšímu zpracování. Nejdříve ověříme dostupnost rozhraní, podmínky přístupu a kvalitu existujících dat.
U každého propojení určujeme:
- Zdroj dat: ve kterém systému se daný údaj spravuje.
- Směr přenosu: co se pouze čte a co aplikace může měnit.
- Četnost: zda je potřeba okamžitá změna, nebo pravidelná synchronizace.
- Identifikaci: podle čeho poznáme stejnou firmu, zakázku nebo dokument.
- Chyby: co se zopakuje automaticky a co musí vyřešit člověk.
Součástí zadání je i to, co se stane při nedostupnosti druhého systému. Potvrzené schválení například musí zůstat uložené i tehdy, když se nepodaří odeslat návazné upozornění. U opakovaného přenosu je potřeba zabránit nechtěnému vytvoření stejného záznamu podruhé.
Jak probíhá vývoj webové aplikace
Vývoj rozdělujeme do částí, které lze průběžně předvést a zkontrolovat. Díky tomu se zpětná vazba promítá do konkrétního fungování aplikace a tým má přehled o hotových i otevřených bodech.
Analýza a zadání
Popíšeme proces, role, data a hranice první verze. Ujasníme výstupy a podmínky, podle kterých se bude řešení přebírat.
Návrh a technické ověření
Připravíme uživatelské scénáře a prototyp. Rizikové integrace nebo zvláštní požadavky ověříme včas, aby další práce vycházela z reálných možností.
Programování po ucelených částech
Postupně vzniká rozhraní, práce s daty a návazné funkce. Průběžné ukázky spojujeme s kontrolou konkrétních úkolů budoucích uživatelů.
Testování a převzetí
Ověříme dohodnuté scénáře, oprávnění, chybové stavy a potřebná zařízení. U očekávané zátěže posoudíme také výkon a limity návrhu.
Příklady podmínek pro převzetí
- Klient se nedostane k zakázce jiné firmy ani přímým odkazem.
- Schválení je přiřazené ke konkrétní verzi podkladu.
- Opakované odeslání požadavku nevytvoří nechtěnou duplicitu.
- Neúspěšný přenos do dalšího systému je dohledatelný a má postup nápravy.
- U importu je zřejmé, které záznamy se převedly a které potřebují opravu.
Konkrétní podmínky se odvíjejí od projektu. Čím dříve vzniknou, tím snáze se porovnává nabídka, řídí vývoj a rozhoduje o připravenosti ke spuštění.
Spuštění zahrnuje data, lidi i následnou správu
Před ostrým nasazením připravíme způsob převodu dat, zaškolení uživatelů a řešení případných problémů. U větší změny může pomoci pilotní provoz s vybranou skupinou. Důležité je určit, od kterého okamžiku se konkrétní údaje spravují v nové aplikaci.
Co patří do předání
Přístupy, provozní dokumentace, návod ke správě a přehled integrací. Smlouva má vyjasnit podmínky používání zdrojového kódu, vlastnictví účtů a způsob získání dat.
Co se řeší průběžně
Aktualizace, dohled nad chybami, zálohování a ověřená obnova, změny oprávnění i požadavky uživatelů. Rozsah podpory a reakce na incidenty se domlouvají podle významu aplikace pro provoz.
Provoz potřebuje odpovědnou osobu na straně firmy. Ta sbírá požadavky, určuje priority a rozhoduje, co patří do další verze. Zpětnou vazbu doplňují údaje o používání: například doba vyřízení požadavku, počet vrácených podkladů nebo množství ručních oprav.
Co ovlivňuje cenu webové aplikace na míru
Individuální nacenění vychází z procesů, pravidel a technických návazností. Jednoduchý přehled může být náročný, pokud pracuje se složitými oprávněními nebo několika zdroji dat. Pro první nabídku pomůže skutečný příklad práce, kterou má aplikace usnadnit.
Co připravit pro úvodní konzultaci
- Popis jednoho procesu od začátku do konce a jeho současných problémů.
- Seznam uživatelů a rolí včetně externích klientů či partnerů.
- Ukázku struktury používaných tabulek a formulářů s anonymizovanými daty.
- Přehled systémů, se kterými má aplikace komunikovat.
- Požadavky na zařízení, dostupnost a případnou práci bez připojení.
- Očekávaný počet uživatelů, objem dat a důležité provozní špičky.
- Priority první verze, potřebný termín a odpovědnou osobu.
Nabídka má oddělit analýzu, návrh, vývoj, integrace, převod dat, testování a spuštění. Vedle jednorázové realizace je potřeba vyjasnit také hosting, externí služby a správu. Obdobný způsob práce s rozsahem popisujeme v článku Web na míru: co ovlivňuje cenu a jak vzniká rozpočet.
V HONEWA můžeme začít zmapováním procesu a prototypem. Podle výsledku navrhneme další etapy a rozsah realizace. Přehled spolupráce najdete mezi online službami včetně vývoje aplikací a prototypování.
Nejčastější otázky
Jaký je rozdíl mezi webovou a mobilní aplikací?
Webová aplikace se používá v prohlížeči a může být přizpůsobená telefonu i počítači. Mobilní aplikace bývá určená pro instalaci do zařízení. Volbu řešení určují potřebné funkce, způsob používání a požadavky na propojení se zařízením.
Kdy zvolit hotový nástroj a kdy vývoj na míru?
Hotový nástroj je vhodný, pokud pokrývá klíčové procesy a přijatelné jsou jeho podmínky i omezení. Vlastní aplikaci posuzujeme tam, kde jsou rozhodující specifická pravidla, integrace nebo způsob práce, který hotové řešení nepokrývá.
Lze začít jen prototypem?
Ano. Analýza a prototyp mohou tvořit samostatnou první etapu. Pomohou zpřesnit zadání a ověřit ovládání s budoucími uživateli před rozhodnutím o rozsahu vývoje.
Dokážete převést data ze současných tabulek?
Možnost převodu posoudíme podle struktury a kvality dat. Nejdříve určíme, jak se staré záznamy převedou do nových polí, co potřebuje vyčistit a jak se zkontroluje výsledek importu.
Jak dlouho trvá vývoj webové aplikace?
Termín závisí na rozsahu první verze, integracích, připravenosti dat a rychlosti schvalování. Po úvodním rozboru připravíme harmonogram s konkrétními etapami a návaznostmi.
Co se s aplikací děje po spuštění?
Navazuje dohodnutý provoz a správa: dohled, aktualizace, zálohy a řešení chyb. Nové funkce plánujeme podle priorit a zkušeností z používání. Podmínky podpory je vhodné vyjasnit už v nabídce.
Který firemní proces potřebujete zjednodušit?
Popište nám, jak dnes probíhá, kdo se do něj zapojuje a kde vznikají komplikace. Navrhneme první smysluplnou etapu, potřebné podklady a individuální nacenění.
Požádat o nezávazné nacenění
