Ako odhadnúť rozpočet na softvérový projekt bez drahých prekvapení

Čo potrebujete skôr, než začnete odhadovať rozpočet?

Na prvý odhad rozpočtu Vám stačí 7 presných vstupov, nie 80-stranové zadanie: cieľ projektu, používatelia, MVP, integrácie, termín, interný vlastník a jednoduchá tabuľka nákladov. Bez nich vzniká skôr pocitová suma než použiteľný rozpočet. Podľa PMI skončilo v roku 2021 v rámci rozpočtu v priemere 62 % projektov.

Pripravte si tieto vstupy:

• Biznis cieľ projektu: čo sa má zlepšiť v číslach alebo v procese, napríklad kratšie schvaľovanie objednávok, menej ručného prepisovania dát alebo rýchlejšie spracovanie leadov.
• Kto bude systém používať: obchod, servis, manažment, zákazník alebo externý partner.
• MVP: čo musí fungovať v prvej verzii, aby mal projekt zmysel.
• Existujúce systémy: ERP, účtovníctvo, CRM, sklad, e-shop, dochádzka, e-mailing alebo interné databázy.
• Dátový rozsah: koľko údajov budete migrovať a v akej kvalite sú dnes.
• Termín a obmedzenia: pevný deadline, sezónnosť, legislatívne požiadavky alebo interné schvaľovanie.
• Vlastník projektu na strane firmy: človek, ktorý rozhoduje o prioritách a potvrdzuje zadanie.

Na prvý odhad stačí tabuľka so stĺpcami: modul, popis funkcie, rola, odhad hodín, sadzba, externé náklady, riziko, poznámka. Keď túto kostru pripravíte na začiatku, neskôr viete porovnávať ponuky dodávateľov v rovnakom formáte.

Najčastejšie vynechané nákladové položky sú:

• analýza a návrh riešenia
• UX/UI návrh a používateľské scenáre
• frontend a backend vývoj
• testovanie a opravy
• projektové riadenie
• nasadenie, hosting a monitoring
• licencie a externé API služby
• migrácia dát
• zaškolenie tímu a podpora po spustení

Ak niektorý z týchto bodov v odhade chýba, rozpočet nie je nízky preto, že je projekt efektívny, ale preto, že je neúplný.

Ako si z projektu urobiť zrozumiteľný rozsah a MVP?

Rozpočet sa spresní až v momente, keď oddelíte nevyhnutné funkcie od želaní. Najpraktickejší postup je previesť nápad na biznis cieľ, používateľské scenáre a MVP, ktoré sa dá dodať v prvej fáze bez zbytočných odbočiek, odkladov a rozširovania rozsahu.

1. Pomenujte problém, nie len riešenie.
   Namiesto vety „chceme vlastný systém“ si napíšte, čo sa má zmeniť. Presnejšie zadanie znie: „obchodník dnes prepisuje dopyt do troch systémov, po novom ho zadá raz a manažér vidí stav zákazky v reálnom čase“.

2. Vypíšte hlavné roly a ich kľúčové úlohy.
   Rozpočet sa lepšie odhaduje cez scenáre než cez všeobecné funkcie:

   • obchodník založí lead
   • manažér schváli cenovú ponuku
   • servisný technik uzavrie úlohu v teréne
   • zákazník skontroluje stav požiadavky

3. Rozdeľte požiadavky do troch skupín.

   • MVP: bez toho systém nedáva zmysel
   • Fáza 2: zlepší prácu, ale neblokuje štart
   • Neskôr: pekné mať, nie nutné mať

4. Pri každej funkcii doplňte podmienku hotovo.
   Nestačí napísať „reporting“. Odhadovateľná požiadavka znie: „manažér vidí pipeline podľa obchodníka, obdobia a zdroja leadu, export do XLS“.

5. Spíšte predpoklady.
   Napríklad: prihlásenie bude cez firemné účty, texty dodá klient, mobilná verzia zatiaľ netreba, schvaľovací proces má dve úrovne. Práve neviditeľné predpoklady bývajú dôvodom, prečo sa 2 ponuky na prvý pohľad líšia aj o desiatky percent.

Dobré MVP nie je najmenší softvér, ale najmenší funkčný kus softvéru, ktorý reálne vyrieši dôležitý proces. Keď ho viete pomenovať, rozpočet prestane byť streľbou naslepo.

Ako rozbiť softvérový projekt na moduly, roly a hodiny?

Najpresnejší odhad nevzniká z jednej celkovej sumy, ale z rozpadu projektu na moduly, činnosti a roly. Keď každú časť naceníte samostatne, rýchlo uvidíte, čo rozpočet tvorí, ktoré oblasti sú rizikové a kde má zmysel projekt rozdeliť do fáz.

1. Rozdeľte projekt na moduly, nie len na obrazovky.
   Typické moduly sú používateľské účty a oprávnenia, dashboard, formuláre, workflow, notifikácie, reporty, fakturácia, API integrácie a administrácia.

2. Ku každému modulu priraďte roly.
   V custom softvéri zvyčajne nevznikajú náklady iba na programátora. Pri jednom module sa často strieda analytik alebo solution architect, UX/UI dizajnér, frontend developer, backend developer, QA tester, project manager a podľa potreby DevOps alebo mobile developer.

3. Odhadujte po menších celkoch.
   Namiesto „CRM modul: 120 hodín“ je lepšie rozdeliť ho na menšie bloky: zoznam kontaktov, detail kontaktu, história komunikácie, filtre, import, export a práva používateľov. Čím menší blok, tým menšia odchýlka.

4. Pri každom bloku doplňte komplikátory.
   Odhad rastie najmä vtedy, keď pribudnú viacúrovňové oprávnenia, schvaľovacie workflow, prepojenia na iné systémy, reporty a analytika, importy a migrácia dát, notifikácie e-mailom alebo SMS, offline režim alebo mobilné použitie.

5. Nezabudnite na činnosti mimo samotného kódovania.
   Do hodín musia vstúpiť aj technický návrh, code review, testovacie scenáre, opravy po testovaní a nasadenie. Ak chcete mať tieto položky lepšie pod kontrolou, pomáha vopred riešiť spôsob testovania a kvalitu cez automatizované testovanie.

Jednoduchá štruktúra odhadu môže vyzerať takto:

Oblasť	Čo má obsahovať
Analýza a architektúra	workshopy, procesy, dátový model, integračná mapa
UX/UI	wireframy, návrh obrazoviek, používateľské toky
Vývoj	frontend, backend, databáza, API
QA	manuálne testy, regresia, opravy
Riadenie	plánovanie, demo, komunikácia, prioritizácia
DevOps	prostredia, deploy, monitoring, zálohy

Výsledkom nemá byť jedna suma v PDF, ale pracovný odhad, pri ktorom rozumiete každej väčšej položke. Veľký vplyv na cenu má aj zvolená architektúra a stack, preto je dôležité vedieť, na akom technologickom základe má riešenie stáť a ako má rásť v ďalších fázach.

Ako pripočítať skryté náklady, rezervu a prevádzku po spustení?

Najviac podhodnotených rozpočtov nevzniká v kódovaní, ale v chýbajúcich položkách okolo neho. Reálny odhad musí počítať s integráciami, migráciou dát, nasadením, školením, podporou a rozpočtovou rezervou podľa miery neistoty. Bez toho získate nižšiu sumu, nie nižšiu cenu projektu.

1. Spočítajte všetky tretie strany.
   Platobné brány, mapové podklady, e-mailing, SMS, cloudové úložiská, podpisové služby, AI API a analytické nástroje pridávajú analýzu, testovanie aj prevádzkové poplatky. Pri integračných projektoch pomáha spísať mapu systémov a dátových tokov podobne ako pri API prepojení systémov.

2. Dajte samostatný riadok migrácii dát.
   Import dát nie je len nahratie súboru. Často zahŕňa čistenie duplicít, mapovanie polí, validáciu, skúšobný import a opravy.

3. Oddelte jednorazové a opakované náklady.
   Do jednorazových patrí analýza, návrh, vývoj a prvé nasadenie. Do opakovaných patria hosting, monitoring, licencie, support, bezpečnostné aktualizácie a ďalší rozvoj.

4. Pridajte rezervu podľa neistoty.
   Ak máte presné zadanie, málo výnimiek a jasné integrácie, rezerva býva nižšia. Ak sa ešte menia procesy, pribúdajú nové nápady alebo neviete kvalitu vstupných dát, rezerva musí byť vyššia. Prakticky je lepšie mať rezervu ako samostatný riadok než ju schovať do sadzby.

5. Po schválení rozpočtu sledujte odchýlky priebežne.
   Nestačí schváliť cenu na začiatku. Rozpočet treba porovnávať s plánom a skutočnosťou po moduloch alebo fázach. Aj Microsoft Support odporúča sledovať pôvodné odhady, skutočné náklady, plánované náklady a odchýlky, aby ste videli problém skôr, než narastie.

Dobrý rozpočet odpovedá na 2 otázky naraz: koľko stojí vyrobiť prvú verziu a koľko bude stáť systém bezpečne prevádzkovať a ďalej rozvíjať.

Ako porovnať ponuky od dodávateľov tak, aby ste nekúpili lacný problém?

Najlacnejšia ponuka býva často najlacnejšia preto, že neobsahuje niečo dôležité. Aby ste porovnávali férovo, všetci dodávatelia musia mať rovnaké zadanie, rovnaké predpoklady a rovnakú definíciu toho, čo je v cene a čo už nie.

1. Pošlite všetkým rovnaký rozsah.
   Ideálne jednu verziu zadania, zoznam modulov, MVP a zoznam integrácií. Ak každý nacenil niečo iné, neporovnávate cenu, ale rôzne produkty.

2. Pýtajte si rozpad ceny, nie len finálnu sumu.
   Dobrá ponuka ukáže aspoň hlavné bloky: analýza, dizajn, vývoj, QA, projektové riadenie, nasadenie a support.

3. Skontrolujte, čo je výslovne vylúčené.
   Typické výluky sú migrácia dát, testovanie na reálnych dátach, obsah, napojenia tretích strán, školenie používateľov a podpora po spustení.

4. Pýtajte sa na metodiku odhadu.
   Je to hrubý odhad podľa jednej konzultácie, alebo odhad po workshope a rozpade modulov? Robil ho seniorný architekt, delivery lead, alebo iba obchodník?

5. Porovnajte tím, nie len hodinovú sadzbu.
   Nižšia sadzba nemusí znamenať nižší finálny účet. Rozhoduje seniorita, kvalita analýzy, skúsenosť s integráciami, rýchlosť QA a schopnosť pripraviť architektúru, ktorá sa nebude po pár mesiacoch prerábať.

6. Zistite, ako sa budú riešiť zmeny.
   Pri softvéri sa takmer vždy niečo spresní. Dôležité je vedieť, čo sa stane pri zmene zadania, ako sa schvaľujú dopady do ceny a ako sa priorizuje ďalšia fáza.

Ak má jedna ponuka o tretinu nižšiu cenu, neberte to automaticky ako výhodu. Najprv si overte, či v nej nechýba práve tá časť práce, ktorá sa neskôr zmení na dodatky, sklzy a drahé opravy.

Aké sú najčastejšie chyby pri odhade rozpočtu na softvérový projekt?

Najčastejšie chyby sa opakujú: firmy podcenia rozsah, zabudnú na prevádzku, miešajú MVP s kompletnou víziou a porovnávajú iba sumu na konci ponuky. Väčšine z nich viete predísť jednoduchou kontrolou ešte pred tým, než si vyžiadate finálne nacenenie.

• Počítate iba programovanie.
  Ako sa tomu vyhnúť: vždy si odškrtnite aj analýzu, QA, projektové riadenie, nasadenie a support.

• MVP je v skutočnosti celý wishlist.
  Ako sa tomu vyhnúť: ku každej funkcii sa spýtajte, či bez nej systém v prvej verzii naozaj nemôže fungovať.

• Neexistuje jeden vlastník zadania.
  Ako sa tomu vyhnúť: určte jedného decision makera, ktorý schvaľuje priority a zmeny.

• Integrácie sú v zadaní iba jednou vetou.
  Ako sa tomu vyhnúť: pri každom napojení doplňte, aké dáta sa prenášajú, ako často, kto je vlastník API a kto zabezpečí testovacie prístupy.

• Ignorujete interný čas svojho tímu.
  Ako sa tomu vyhnúť: započítajte workshopy, pripomienkovanie, testovanie používateľmi, školenia a interné schvaľovanie.

• Porovnávate len hodinovú sadzbu.
  Ako sa tomu vyhnúť: pozerajte sa na celkový model doručenia, senioritu tímu, rozsah výstupov a kvalitu odhadu.

• Po spustení nemáte plán ďalšieho rozvoja.
  Ako sa tomu vyhnúť: oddeľte rozpočet na prvú verziu od rozpočtu na údržbu a ďalšie fázy.

Ak sa rozpočet poctivo rozpadne, väčšina problémov sa ukáže ešte v tabuľke. Práve v tomto momente je ich riešenie najlacnejšie.

Kedy sa už oplatí ísť cez discovery workshop a profesionálny odhad?

Ak projekt zasahuje viac oddelení, obsahuje viacero rolí, integrácie, migráciu dát alebo má rásť po fázach, profesionálny odhad sa oplatí pred prvým nacenením naslepo. Šetrí prepisovanie zadania, spory o rozsah aj situáciu, keď zdanlivo lacná ponuka nezahŕňa podstatné práce.

Profesionálny postup dáva najväčší zmysel vtedy, keď:

1. riešite viac než jeden proces naraz
2. softvér sa má napájať na existujúce systémy
3. potrebujete rôzne úrovne oprávnení a schvaľovania
4. plánujete CRM, interný systém, zákaznícky portál alebo AI automatizácie
5. očakávate, že riešenie bude rásť v ďalších fázach

Pri tejto ceste by mal partner dodať viac než len cenovku. Potrebujete výstup, ktorý obsahuje rozpad procesov, prioritizovaný backlog, návrh architektúry, integračnú mapu, odhad po moduloch a jasné predpoklady, z ktorých rozpočet vychádza. Presne tak sa dá pripraviť zadanie aj pre CRM na mieru, aj pre iný typ firemného softvéru.

Riešenia staviame okolo reálnych procesov klienta, škálovateľnej architektúry a merateľného výsledku, takže rozpočet nevzniká ako univerzálna tabuľka, ale ako plán naviazaný na konkrétne workflow, dáta, integrácie a priority. Ak chcete prejsť od orientačného odhadu k použiteľnému rozpočtu a roadmape, prirodzený ďalší krok je nezáväzná konzultácia s tímom BeCode, na ktorej sa spresní rozsah, fázy a spôsob realizácie.

Časté otázky

Je lepšie pýtať si fixnú cenu alebo hodinový odhad?

Rozhoduje miera istoty zadania. Fixná cena funguje najlepšie pri presne definovanom rozsahu, jasných akceptačných kritériách a malom počte neznámych. Hodinový alebo fázovaný odhad je vhodnejší pri custom softvéri, kde sa požiadavky ešte spresňujú a projekt prirodzene rastie po etapách.

Ako často treba rozpočet počas vývoja aktualizovať?

Pri aktívnom vývoji kontrolujte rozpočet priebežne po sprintoch, fázach alebo aspoň raz týždenne. Nejde len o celkovú sumu, ale najmä o odchýlky v konkrétnych moduloch, integráciách a testovaní, aby ste problém zachytili skôr, než prerastie do sklzu.

Mám do rozpočtu rátať aj interný čas mojich ľudí?

Áno, interný čas často rozhoduje o reálnej cene projektu pre firmu. Do interných nákladov patria workshopy, schvaľovanie, dodanie podkladov, testovanie používateľmi, školenia aj rozhodovanie o zmenách. Ak ich nevidíte v tabuľke, projekt pôsobí lacnejšie, než v skutočnosti je.

Čo robiť, keď mám na projekt pevný rozpočtový strop?

Najprv zafixujte strop a až potom doň napasujte MVP, nie opačne. Vyberte funkcie s najväčším dopadom na biznis, znížte počet integrácií v prvej fáze a ostatné presuňte do roadmapy. Pevný limit sa dá zvládnuť, keď rozsah riadia priority, nie želania.