Pri plánovaní aplikácie sa oplatí oddeliť dve otázky: čo má vedieť výsledný produkt a čo potrebujete vytvoriť ako prvé. Nemusí to byť rovnaký rozsah.
V tomto článku si ukážeme, čo ovplyvňuje cenu prvej verzie, ktoré položky preveriť v cenovej ponuke a ako porovnávať rozpočty bez toho, aby ste zamieňali jednoduchý prototyp s kompletným systémom.
Čo vlastne porovnávate
Keď dostanete tri ponuky s rozdielom v cene niekoľkonásobne, väčšinou to neznamená, že jeden dodávateľ je drahý a druhý výhodný. Znamená to, že každý počítal iné zadanie.
Ukážkový prototyp
Klikateľná ukážka obrazoviek. Vyzerá ako aplikácia, ale nič neukladá a nepočíta. Slúži na to, aby ste videli postup a ukázali ho ľuďom, ktorí ho majú používať.
Prvá funkčná verzia
Aplikácia, v ktorej funguje hlavný scenár: dáta sa naozaj ukladajú, používatelia sa prihlasujú, výsledok sa dá používať v praxi. Vedome neobsahuje všetko.
Rozsiahlejší systém
Viac rolí, viac scenárov, prepojenia na ďalšie systémy, história zmien, prehľady a náročnejšie požiadavky na prevádzku.
Prvá funkčná verzia nie je automaticky riešenie pripravené na akúkoľvek prevádzku. To, čo musí zvládnuť, závisí od použitia: nástroj pre päť ľudí v jednej firme má iné požiadavky ako aplikácia, do ktorej denne vstupujú stovky zákazníkov.
Pri porovnávaní ponúk si preto najprv ujasnite, ktorú z týchto troch vecí vám kto ponúka.
Čo tvorí cenu
Cena nie je jedno číslo z cenníka. Skladá sa z týchto vecí a pri každej sa dá v ponuke overiť, ako ju dodávateľ počítal.
Počet a zložitosť používateľských scenárov
Nie počet obrazoviek, ale počet vecí, ktoré musí používateľ vedieť dokončiť od začiatku do konca. Otázka do ponuky: ktoré scenáre sú zahrnuté a ktoré nie?
Používateľské roly a oprávnenia
Jeden typ používateľa je výrazne jednoduchší než štyri roly s rôznym prístupom k údajom. Otázka: koľko rolí ponuka počíta a čo každá vidí a smie zmeniť?
Integrácie
Prepojenie na účtovníctvo, e-shop, sklad alebo kalendár. Cena závisí od toho, či má daný systém použiteľné rozhranie a či k nemu máte prístupy. Otázka: je integrácia v cene, alebo je to samostatná etapa?
Pri POS, platbách a fiškalite môže byť samostatnou témou aj návrh vrstvy medzi systémami. Prakticky ho vysvetľujeme v článku Ako prepojiť POS, platby a fiškalitu bez výmeny celého systému.
Migrácia a kvalita dát
Prenos údajov z tabuliek alebo staršieho systému je samostatná práca. Ak sú dáta nekonzistentné, čistenie často trvá dlhšie než samotný prenos. Otázka: kto pripravuje a kontroluje dáta?
Dizajn
Rozdiel medzi použitím ustálených komponentov a grafikou navrhnutou od nuly. Otázka: ide o vizuál na mieru alebo o čisté a prehľadné rozhranie zo štandardných prvkov?
Testovanie
Prechádzanie dohodnutých scenárov vrátane chybových stavov. Otázka: čo presne sa testuje a kto potvrdzuje, že to funguje?
Požiadavky na prevádzku
Počet používateľov, citlivosť údajov, potreba zálohovania a dostupnosti. Otázka: s akým používaním ponuka počíta?
Odovzdanie a podpora
Čo dostanete pri ukončení a čo sa deje potom. Otázka: čo konkrétne je súčasťou odovzdania a v akom rozsahu je dohodnutá podpora?
Ak dve ponuky odpovedajú na tieto otázky odlišne, nie sú porovnateľné — bez ohľadu na to, ktorá má nižšiu sumu.
Kde sa dá ušetriť
Menším prvým rozsahom
Najväčšia úspora nie je v hodinovej sadzbe, ale v tom, že nezaplatíte funkcie, ktoré sa nakoniec nepoužívajú. Lacnejšia prvá verzia je výhodná práve preto, že vedome neobsahuje všetko — nie preto, že by bola urobená povrchne.
Jasným zadaním
Nejasné zadanie znamená prerábanie, a prerábanie je najdrahšia forma vývoja. Pomôže, keď rozsah dohodnete písomne skôr, než sa začne pracovať.
Vhodnými existujúcimi komponentmi
Prihlasovanie, notifikácie, platby alebo export do tabuliek nie je potrebné vymýšľať od začiatku. Použitie overených komponentov šetrí čas aj neskoršiu údržbu.
Použitím AI pri konkrétnych úlohách
AI nástroje pomáhajú pri opakujúcej sa práci — základoch rozhrania, štandardnom kóde, návrhoch testov. Ušetrený čas sa prejaví na cene. Podrobnejšie o tom píšeme v článku Vývoj aplikácií s AI: kedy dáva zmysel a čo si treba ustrážiť.
Ušetriť sa nedá na pochopení problému a na kontrole výsledku. To je práve tá časť, ktorá rozhoduje, či bude riešenie použiteľné.
Čo treba kontrolovať aj pri vývoji s AI
Rýchlejšie vygenerovanie kódu nie je to isté ako overený výsledok. Bez ohľadu na použité nástroje má zmysel prejsť:
či dohodnuté scenáre naozaj fungujú od začiatku do konca;
kto vidí a smie meniť ktoré údaje;
čo sa stane pri chybe — nesprávne zadanie, prerušené spojenie, dvojité odoslanie;
či riešenie zvládne predpokladané používanie a či existuje zálohovanie údajov.
Toto je všeobecné odporúčanie pre každý projekt, nie zoznam plnení, ktoré by boli automaticky súčasťou každej dodávky. Čo z toho je zahrnuté v našej práci, závisí od dohodnutého rozsahu — a je to jedna z vecí, ktoré si vyjasníme pred začiatkom.
Čo sa platí po spustení
Aplikácia potrebuje niekde bežať, takže po odovzdaní vznikajú prevádzkové náklady:
hosting a databáza;
domény a certifikáty;
platené rozhrania a externé služby, napríklad e-mailové, mapové, platobné alebo AI služby;
údržba: aktualizácie, riešenie chýb, reakcia na zmeny v prepojených systémoch;
ďalší rozvoj podľa toho, čo ukáže reálne používanie.
Ich výška závisí od poskytovateľov a od objemu používania, takže konkrétne čísla má zmysel počítať až na konkrétne zadanie. Pri malom internom nástroji ide zvyčajne o rádovo iné sumy než pri aplikácii pre verejnosť.
Modelový príklad: interný nástroj na správu zákaziek
Nasledujúce je modelový príklad na vysvetlenie rozsahu, nie realizovaný zákaznícky projekt.
Firma dnes rieši zákazky v tabuľke a telefonicky. Nikto presne nevie, kto má čo na starosti a dokedy.
Prvá verzia
založenie zákazky so základnými údajmi;
pridelenie zodpovednej osoby;
stav zákazky a termín;
jednoduchý prehľad, kto má čo otvorené.
Tu už firma prestane hľadať informácie v tabuľke a v telefóne. To je merateľná zmena.
Neskoršie rozšírenie
klientsky portál, kde zákazník vidí stav svojej zákazky;
fakturácia a prepojenie na účtovníctvo;
integrácie na ďalšie systémy;
pokročilé reporty a vyhodnocovanie.
Rozdiel v cene medzi týmito dvoma rozsahmi je násobný. Rozdiel v tom, kedy firme prestane chýbať prehľad, je nulový — pomôže už prvá verzia.
Zhrnutie
Najprv si ujasnite, čo porovnávate: prototyp, prvú funkčnú verziu alebo systém.
Cenu tvoria scenáre, roly, integrácie, dáta, dizajn, testovanie, prevádzka a odovzdanie. Pri každej položke sa dá zistiť, ako ju dodávateľ počítal.
Ušetríte menším prvým rozsahom a jasným zadaním, nie preskočením kontroly výsledku.
K cene vývoja pripočítajte prevádzkové náklady, ktoré bežia aj po odovzdaní.
Ak zvažujete, čo do prvej verzie patrí, pomôže aj článok Ako overiť nápad na aplikáciu skôr, než investujete do kompletného vývoja.
