Když firma plánuje webovou aplikaci, jednou z prvních otázek, které padnou na stůl, je, jak dlouho bude vývoj trvat. Odpověď však nikdy není univerzální číslo – délka vývoje webové aplikace se liší projekt od projektu a závisí na kombinaci faktorů, které společně určují jeho reálnou náročnost. V tomto článku se podíváme na to, co jsou tyto faktory a proč mají na harmonogram větší vliv než samotný typ aplikace.
Proč neexistuje jednotná odpověď na otázku, jak dlouho trvá vývoj appky
Otázka, jak dlouho trvá vývoj appky, patří mezi nejčastější, ale zároveň nejobtížněji zodpověditelné bez bližší analýzy. Dva projekty, které na první pohled vypadají podobně – například dva firemní portály se správou objednávek – mohou mít zcela odlišnou náročnost, pokud jeden pracuje s jednoduchou datovou strukturou a druhý potřebuje propojení na desítku externích systémů. Namísto obecných čísel proto dává větší smysl podívat se na konkrétní proměnné, které rozsah a složitost projektu formují.
Rozsah funkcí a jejich vzájemná provázanost
Počet uživatelských rolí a scénářů
Aplikace s jedním typem uživatele a lineárním workflow se navrhuje i testuje jednodušeji než systém, kde má administrátor, běžný uživatel a externí partner každý svá oprávnění, pohledy a omezení. Každá další role znamená další kombinace stavů, které je třeba ošetřit – a tedy i více práce v analýze, vývoji i testování.
Integrace s externími systémy
Propojení na ERP, platební bránu, fakturační systém nebo CRM výrazně zvyšuje náročnost projektu, protože vývojový tým nepracuje jen s vlastním kódem, ale i s omezeními, dokumentací a stabilitou cizího API. Pokud firma plánuje taková propojení, vyplatí se podívat i na to, jak funguje systémová integrace ERP, CRM a e-shopu – logika propojení systémů je podobná i u jiných typů řešení.
Stav podkladů a vstupů před startem projektu
Design a UX podklady
Pokud má projekt hotový a odsouhlasený design, tým může rovnou přejít k implementaci. Pokud design teprve vzniká souběžně s vývojem, každá změna v rozvržení nebo toku obrazovek se promítá zpět do kódu. Chybějící nebo neúplné podklady patří mezi nejčastější důvody, proč se reálný průběh projektu odchyluje od původního plánu.
Datový model a existující infrastruktura
Stejně důležité je, s jakými daty aplikace pracuje a odkud pocházejí. Migrace dat ze starého systému, čištění nekonzistentních záznamů nebo práce s datovým modelem, který nikdo v minulosti pořádně nezdokumentoval, prodlužuje analytickou fázi ještě dříve, než se napíše první řádek funkčního kódu.
Rozhodování a zapojení klienta během projektu
Softwarový projekt není jen o práci vývojového týmu. Rychlost, s jakou dokáže klient na své straně odsouhlasit návrh řešení, poskytnout zpětnou vazbu k testovací verzi nebo rozhodnout mezi dvěma alternativami, přímo ovlivňuje časový harmonogram softwarového projektu. Projekt s jasně definovaným rozhodovacím procesem a jedním kontaktním bodem na straně klienta postupuje plynuleji než projekt, kde se každá změna musí projednat napříč více odděleními.
Kvalita, testování a požadavky, které nejsou vidět na první pohled
Část práce, která se v odhadech často podceňuje, jsou netechnické, ale stejně závazné požadavky – ochrana osobních údajů, přístupnost pro uživatele se zdravotním znevýhodněním nebo bezpečnostní testování před nasazením do produkčního provozu. Tyto oblasti se neřeší až na konci, ale průběžně během vývoje, a jejich rozsah závisí na typu aplikace i odvětví, ve kterém firma působí. Pokud aplikace zpracovává citlivá data nebo platby, vyplatí se od začátku počítat s kybernetickou bezpečností jako součástí návrhu, ne jako dodatečným krokem.
Následující tabulka shrnuje nejčastější faktory a směr, jakým ovlivňují průběh projektu.
| Faktor | Jak ovlivňuje průběh projektu |
|---|---|
| Počet uživatelských rolí | Více rolí znamená více kombinací stavů k analýze a testování |
| Integrace s externími systémy | Závislost na cizím API zvyšuje nejistotu i nároky na testování |
| Stav designových podkladů | Nedokončený design způsobuje zpětné úpravy již napsaného kódu |
| Kvalita a stav existujících dat | Migrace a čištění dat prodlužují analytickou fázi |
| Rychlost rozhodování klienta | Pomalé schvalování zpomaluje každou následující fázi |
| Bezpečnostní a legislativní požadavky | Přidávají kroky, které se nedají přeskočit bez rizika |
Následující graf ilustruje princip, podle kterého narůstá relativní náročnost projektu s přidáváním dalších vrstev funkcionality – nejde o reálná měření konkrétního projektu, ale o zjednodušené znázornění toho, proč se jednoduchý web a systém s integracemi nedají srovnávat stejným měřítkem.
Jak přistoupit k odhadu rozsahu vlastního projektu
Namísto hledání univerzálního čísla se vyplatí nejprve rozebrat zadání na jednotlivé části – funkce, role, integrace, datové zdroje a legislativní požadavky – a u každé z nich si položit otázku, v jakém stavu se reálně nachází. Přesně takto postupuje i tým při vývoji webových a softwarových řešení: analýza rozsahu předchází jakémukoli odhadu, protože pouze na jejím základě dokáže tým posoudit, co projekt skutečně obnáší. Podrobnější fáze tohoto procesu popisuje článek o tom, jak probíhá vývoj softwaru na míru, i samostatný text věnovaný přímo tomu, co ovlivňuje rozsah a náročnost vývoje softwaru na míru.
Přesný odhad trvání vývoje dostane firma jen tehdy, když někdo se zadáním skutečně projde krok za krokem – zohlední počet rolí, integrace, stav podkladů i interní procesy schvalování. Pokud plánujete webovou aplikaci a chcete vědět, co konkrétně bude její vývoj obnášet, nejspolehlivější cestou je nezávazná konzultace, během které si zadání společně rozeberete do detailu.