Keď firma plánuje webovú aplikáciu, jedna z prvých otázok, ktoré padnú na stole, je, ako dlho bude vývoj trvať. Odpoveď však nikdy nie je univerzálne číslo – dĺžka vývoja webovej aplikácie sa líši projekt od projektu a závisí od kombinácie faktorov, ktoré spolu určujú jeho reálnu náročnosť. V tomto článku sa pozrieme na to, čo tieto faktory sú a prečo majú na harmonogram väčší vplyv než samotný typ aplikácie.
Prečo neexistuje jednotná odpoveď na otázku, ako dlho trvá vývoj appky
Otázka, ako dlho trvá vývoj appky, patrí medzi najčastejšie, no zároveň najťažšie zodpovedateľné bez bližšej analýzy. Dva projekty, ktoré na prvý pohľad vyzerajú podobne – napríklad dva firemné portály so správou objednávok – môžu mať úplne odlišnú náročnosť, ak jeden pracuje s jednoduchou dátovou štruktúrou a druhý potrebuje prepojenie na desiatku externých systémov. Namiesto všeobecných čísel preto dáva väčší zmysel pozrieť sa na konkrétne premenné, ktoré rozsah a zložitosť projektu formujú.
Rozsah funkcií a ich vzájomná previazanosť
Počet používateľských rolí a scenárov
Aplikácia s jedným typom používateľa a lineárnym workflow sa navrhuje aj testuje jednoduchšie než systém, kde má administrátor, bežný používateľ a externý partner každý svoje oprávnenia, pohľady a obmedzenia. Každá ďalšia rola znamená ďalšie kombinácie stavov, ktoré treba ošetriť – a teda aj viac práce v analýze, vývoji aj testovaní.
Integrácie s externými systémami
Prepojenie na ERP, platobnú bránu, fakturačný systém alebo CRM výrazne zvyšuje náročnosť projektu, pretože vývojový tím nepracuje len s vlastným kódom, ale aj s obmedzeniami, dokumentáciou a stabilitou cudzieho API. Ak firma plánuje takéto prepojenia, oplatí sa pozrieť aj na to, ako funguje systémová integrácia ERP, CRM a e-shopu – logika previazania systémov je podobná aj pri iných typoch riešení.
Stav podkladov a vstupov pred štartom projektu
Dizajn a UX podklady
Ak má projekt hotový a odsúhlasený dizajn, tím môže rovno prejsť k implementácii. Ak dizajn ešte len vzniká súbežne s vývojom, každá zmena v rozložení alebo toku obrazoviek sa premieta späť do kódu. Chýbajúce alebo neúplné podklady patria medzi najčastejšie dôvody, prečo sa reálny priebeh projektu odchyľuje od pôvodného plánu.
Dátový model a existujúca infraštruktúra
Rovnako dôležité je, s akými dátami aplikácia pracuje a odkiaľ pochádzajú. Migrácia dát zo starého systému, čistenie nekonzistentných záznamov alebo práca s dátovým modelom, ktorý nikto v minulosti poriadne nezdokumentoval, predlžuje analytickú fázu ešte skôr, než sa napíše prvý riadok funkčného kódu.
Rozhodovanie a zapojenie klienta počas projektu
Softvérový projekt nie je len o práci vývojového tímu. Rýchlosť, akou sa na strane klienta dokáže odsúhlasiť návrh riešenia, poskytnúť spätná väzba k testovacej verzii alebo rozhodnúť medzi dvomi alternatívami, priamo ovplyvňuje časový harmonogram softvérového projektu. Projekt s jasne definovaným rozhodovacím procesom a jedným kontaktným bodom na strane klienta postupuje plynulejšie než projekt, kde sa každá zmena musí prejednať naprieč viacerými oddeleniami.
Kvalita, testovanie a požiadavky, ktoré nie sú vidieť na prvý pohľad
Časť práce, ktorá sa v odhadoch často podceňuje, sú netechnické, no rovnako záväzné požiadavky – ochrana osobných údajov, prístupnosť pre používateľov so zdravotným znevýhodnením alebo bezpečnostné testovanie pred nasadením do produkčnej prevádzky. Tieto oblasti sa neriešia až na konci, ale priebežne počas vývoja, a ich rozsah závisí od typu aplikácie aj odvetvia, v ktorom firma pôsobí. Ak aplikácia spracúva citlivé dáta alebo platby, oplatí sa od začiatku počítať s kyberbezpečnosťou ako súčasťou návrhu, nie ako dodatočným krokom.
Nasledujúca tabuľka zhŕňa najčastejšie faktory a smer, akým ovplyvňujú priebeh projektu.
| Faktor | Ako ovplyvňuje priebeh projektu |
|---|---|
| Počet používateľských rolí | Viac rolí znamená viac kombinácií stavov na analýzu a testovanie |
| Integrácie s externými systémami | Závislosť od cudzieho API zvyšuje neistotu aj nároky na testovanie |
| Stav dizajnových podkladov | Nedokončený dizajn spôsobuje spätné úpravy už napísaného kódu |
| Kvalita a stav existujúcich dát | Migrácia a čistenie dát predlžujú analytickú fázu |
| Rýchlosť rozhodovania klienta | Pomalé schvaľovanie spomaľuje každú nasledujúcu fázu |
| Bezpečnostné a legislatívne požiadavky | Pridávajú kroky, ktoré sa nedajú preskočiť bez rizika |
Nasledujúci graf ilustruje princíp, podľa ktorého narastá relatívna náročnosť projektu s pridávaním ďalších vrstiev funkcionality – nejde o reálne merania konkrétneho projektu, ale o zjednodušené znázornenie toho, prečo sa jednoduchý web a systém s integráciami nedajú porovnávať rovnakým meradlom.
Ako pristúpiť k odhadu rozsahu vlastného projektu
Namiesto hľadania univerzálneho čísla sa oplatí najprv rozobrať zadanie na jednotlivé časti – funkcie, role, integrácie, dátové zdroje a legislatívne požiadavky – a pri každej z nich si položiť otázku, v akom stave sa reálne nachádza. Presne takto postupuje aj tím pri vývoji webových a softvérových riešení: analýza rozsahu predchádza akémukoľvek odhadu, pretože iba na jej základe vie tím posúdiť, čo projekt skutočne obnáša. Podrobnejšie fázy tohto procesu opisuje článok o tom, ako prebieha vývoj softvéru na mieru, aj samostatný text venovaný priamo tomu, čo ovplyvňuje rozsah a náročnosť vývoja softvéru na mieru.
Presný odhad trvania vývoja dostane firma len vtedy, keď niekto so zadaním skutočne prejde krok za krokom – zohľadní počet rolí, integrácie, stav podkladov aj interné procesy schvaľovania. Ak plánujete webovú aplikáciu a chcete vedieť, čo konkrétne bude jej vývoj obnášať, najspoľahlivejšou cestou je nezáväzná konzultácia, počas ktorej si zadanie spoločne rozoberiete do detailu.