Prečo sa softvérový projekt predraží a ako to zastaviť

Prečo sa softvérový projekt najčastejšie predraží?

Najčastejšie sa projekt predraží nie pre jednu veľkú chybu, ale pre postupnú sériu malých rozhodnutí, ktoré dlho pôsobia nenápadne. Rozsah projektu sa rozširuje, odhad vznikne priskoro, mimo kódovania pribúda neviditeľná práca a kvalita sa rieši až vtedy, keď je prerábka najdrahšia.

Nejde o okrajový problém. Zhrnutie FIIT STU uvádza, že iba 5 až 10 % softvérových projektov možno považovať za úplne úspešné, 30 % za čiastočne úspešné a až 74 % projektov bolo podhodnotených už pri odhade.

Najpravdepodobnejšie príčiny, zoradené podľa toho, ako často rozpočet lámu

1. Rozširovanie rozsahu bez pravidiel
   Projekt začne s jedným cieľom, no počas vývoja pribúdajú ďalšie obrazovky, výnimky, roly, reporty, integrácie a automatizácie. Každá zmena môže samostatne pôsobiť malá, spolu však menia pracnosť, testovanie aj termín.

2. Nejasné zadanie a pomalé rozhodovanie
   Ak nie je jasné, čo presne znamená hotová funkcionalita, tím odhaduje na základe predpokladov. Keď sa neskôr ukáže iné očakávanie, rozpočet platí za prerábku.

3. Odhad vznikol skôr, než bol známy problém do detailu
   Mnohé firmy žiadajú finálnu cenu vo fáze, keď ešte nie sú rozhodnuté scenáre používania, import dát, napojenia ani výnimky. V takom momente je číslo skôr obchodný odhad než riaditeľný rozpočet.

4. Skryté náklady mimo programovania
   Rozpočet netvorí iba vývoj. Patrí doň analýza, UX, projektové riadenie, QA, testovacie scenáre, nasadenie, migrácia dát, školenie ľudí, infraštruktúra a licencie tretích strán.

5. Podcenené integrácie a dáta
   Projekt zostáva lacný najmä dovtedy, kým stojí na obrazovkách. Náklady rastú vo chvíli, keď treba riešiť ERP, účtovníctvo, sklad, CRM, platby, exporty, historické dáta a chybové stavy medzi systémami.

6. Tlak na rýchlosť na úkor architektúry a testov
   Keď sa sleduje iba rýchle dodanie, kód síce pribúda, ale každá ďalšia zmena je pomalšia. Rozpočet potom nečerpá nový vývoj, ale opravy, regresie a obchádzanie starých rozhodnutí.

Ako spoznáte, ktorá chyba rozpočet nafukuje práve u vás?

Rozpočet zvyčajne nenarastie bez varovania. Najskôr sa opakujú symptómy projektu: backlog rastie rýchlejšie než odovzdávky, úlohy zostávajú takmer hotové, rozhodnutia čakajú na schválenie a po každej ukážke pribudne ďalšia vlna prerábok. Tieto signály je potrebné čítať skôr než nový odhad.

Rýchla mapa symptómov a príčin

Symptóm	Čo to zvyčajne znamená	Čo preveriť tento týždeň
Po každom stretnutí pribudnú nové úlohy	Scope creep, chýbajú hranice rozsahu	Máte zoznam must-have, nice-to-have a vedome odložených vecí?
Funkcionalita je dlho na 90 %	Nejasné kritériá dokončenia, chýbajúce testy	Je definované, čo musí byť hotové pred odovzdaním?
Tím čaká na spätnú väzbu alebo podpis	Problém je v governance, nie vo vývoji	Kto má posledné slovo a do koľkých dní musí rozhodnúť?
Po demo ukážke sa veľa prerába	Zadanie bolo príliš abstraktné	Existujú konkrétne scenáre použitia a akceptačné kritériá?
Najväčšie sklzy vznikajú pri napojeniach	Podcenené integrácie, chýbajú technické objavy	Sú známe limity API, dátové formáty a chybové stavy?
Tá istá časť systému sa opravuje opakovane	Technický dlh alebo slabá architektúra	Koľko času ide na zmeny a koľko na opravy po zmenách?

Ak sa požiadavky hromadia v internom schvaľovaní, problém nemusí byť u dodávateľa. Často ide o to, že firma nemá plynulý rozhodovací proces. V takom prípade pomáha upratať tok rozhodnutí skôr, než sa znova prepočítava rozpočet. Užitočný kontext dá aj článok o zrýchlení interného schvaľovania požiadaviek.

Dôležité je odlíšiť 2 veci: zdravé spresňovanie projektu a chaotické menenie projektu. Zdravé spresňovanie upravuje pôvodný cieľ do presnejšej podoby. Chaotická zmena mení samotný cieľ, rozsah alebo architektúru bez prepočítania dopadu na čas, rozpočet a testovanie.

Čo viete opraviť interne ešte predtým, než projekt znova naceníte?

Skôr než si vypýtate nový rozpočet, viete interne urobiť niekoľko lacných, no účinných krokov. Ich cieľom nie je tlačiť tím na vyšší výkon. Cieľom je odstrániť neistotu v projekte, zablokované rozhodnutia a prácu navyše, ktorá nevytvára reálnu hodnotu pre biznis.

Najrýchlejšie zásahy s veľkým dopadom

1. Zafixujte cieľ aktuálnej fázy
   Nepýtajte sa, čo všetko by systém ešte mohol vedieť. Pýtajte sa, čo presne musí fungovať, aby táto fáza priniesla merateľný výsledok.

2. Rozdeľte požiadavky do troch košov
   Must-have, užitočné neskôr, vedome odložené. Bez tohto delenia všetko pôsobí rovnako dôležito a rozpočet stráca jasné hranice.

3. Určite jedného rozhodovateľa za biznis
   Ak má každú drobnosť schvaľovať viac ľudí bez jasnej zodpovednosti, tím čaká a náklady bežia ďalej.

4. Doplňte zoznam skrytých prác
   Ku každej funkcii si dopíšte, či potrebuje testy, migráciu dát, oprávnenia, notifikácie, reporting, školenie alebo integráciu. Až potom je zrejmé, koľko naozaj stojí.

5. Zaveďte tvrdú definíciu dokončenia
   Hotové neznamená nakódované. Hotové znamená otestované, skontrolované, pripravené na použitie a zrozumiteľné pre biznis.

6. Sledujte pomer nového vývoja a prerábok
   Ak sprint za sprintom rastie podiel opráv a dopracovaní, problém nie je v tempe. Problém je v kvalite vstupov alebo v architektúre.

Ak sa ukazuje, že rozpočet mizne najmä na napojeniach medzi systémami, oplatí sa prejsť si aj praktický pohľad na API prepojenie systémov. Firmám často ukáže, že najdrahšia časť projektu nie je obrazovka, ale logika medzi systémami, dátami a procesmi.

Kedy už nestačia interné opravy a treba projekt prekopnúť architektonicky?

Interné zásahy nestačia vtedy, keď problém už nie je v jednej požiadavke, ale v spôsobe, ako je projekt navrhnutý, rozdelený a riadený. Spoznáte to podľa toho, že každá ďalšia zmena je pomalšia, integrácie sa odhaľujú neskoro a tím trávi viac času stabilizáciou systému než rozvojom.

V tejto fáze už nestačí prísnejší backlog. Potrebujete profesionálny zásah, ktorý spojí biznisové procesy, architektúru, vývojový plán a kvalitu do jedného riaditeľného rámca.

Čo má obsahovať profesionálna náprava

• Discovery a technický audit: čo sa má dosiahnuť, aké procesy to majú niesť, aké sú obmedzenia súčasných systémov.
• Prekreslenie architektúry podľa reality firmy: nie podľa všeobecnej šablóny, ale podľa reálnych tokov dát, rolí a rozhodnutí.
• Etapizácia projektu: rozdeliť riešenie na fázy, ktoré vedia prinášať hodnotu priebežne a znižujú riziko veľkého jednorazového omylu.
• Change management: každá nová požiadavka musí mať majiteľa, dopad a rozhodnutie, či sa robí teraz alebo neskôr.
• QA a automatizované kontroly: kvalita sa nesmie presúvať na koniec projektu.

Práve vtedy dáva zmysel postaviť riešenie okolo procesov firmy, napríklad cez CRM na mieru alebo cez systematické automatizované testovanie, aby sa rozpočet nestrácal v ručných regresiách a neskorých opravách.

Dobrý dôvod, prečo QA riešiť skôr, nie neskôr, uvádza aj NIST: viac ako polovica softvérových chýb sa odhalí až neskôr v procese a nedostatočné testovanie má vysoké ekonomické dopady.

Ako predraženiu predísť už pri ďalšej fáze projektu?

Predraženiu najlepšie predídete tak, že projekt od začiatku neberiete ako balík funkcií, ale ako riadenú zmenu vo firme. Keď sú jasné ciele, hranice rozsahu, rozhodovacie práva, integračné riziká a pravidlá kvality, rozpočet sa správa podstatne predvídateľnejšie.

Krátky preventívny checklist

• Má projekt jeden hlavný biznisový cieľ a merateľný výsledok?
• Je určený človek, ktorý za biznis rozhoduje rýchlo a záväzne?
• Sú požiadavky rozdelené na nevyhnutné, neskoršie a odložené?
• Existuje zoznam integrácií, dátových zdrojov a rizikových miest?
• Je vyriešené, kto pripraví dáta, migráciu a používateľské scenáre?
• Je definované, čo presne znamená hotová funkcionalita?
• Má každá zmena počas projektu jasný dopad na čas, cenu a prioritu?
• Je vyhradený priestor na testovanie, nasadenie a stabilizáciu po spustení?
• Ráta sa aj s prevádzkou, podporou a ďalším rozvojom, nielen s prvým odovzdaním?

Ak si firma prejde tento zoznam ešte pred ďalšou etapou, získa 2 veci: realistickejší rozpočet a pokojnejšie rozhodovanie počas vývoja. Práve to býva rozdiel medzi projektom, ktorý rastie kontrolovane, a projektom, ktorý zdražie vždy, keď sa objaví ďalšia nečakaná drobnosť.

Ak už vidíte, že projekt netreba iba prepočítať, ale lepšie ukotviť v procesoch, dátach a rozhodovaní, v BeCode vám vieme pomôcť navrhnúť riešenie postavené okolo vašich procesov tak, aby ďalšia fáza mala jasný rozsah, architektúru aj pravidlá kvality.

Časté otázky

Je väčšie riziko predraženia pri projekte na zelenej lúke alebo pri prerábke starého systému?

Riziko existuje v oboch prípadoch, no pri staršom systéme býva menej viditeľné. Rozpočet najčastejšie nafúknu nezdokumentované procesy, historické dáta, staré integrácie a skryté závislosti. Pri projekte na zelenej lúke je kritické udržať disciplínu rozsahu a nenechať projekt rásť bez pravidiel.

Je bezpečnejšie riadiť vývoj interným tímom alebo externou firmou?

Bezpečnejší nie je konkrétny model, ale jasné riadenie. Projekt funguje lepšie vtedy, keď má jedného biznisového vlastníka, transparentný backlog, pravidlá zmien a zodpovednosť za kvalitu. Externý partner je výhodou najmä vtedy, keď prinesie architektúru, QA, odhadovanie a otvorenú komunikáciu o rizikách.

Dá sa projekt naceniť aj keď máme len hrubú predstavu?

Dá sa to, ale rozumnejšie je naceniť najprv discovery alebo prvú etapu, nie celý budúci systém do posledného detailu. Hrubá predstava stačí na rámec cieľa, nie na presný konečný rozpočet. Vhodnejší postup je rozpočet postupne spresňovať podľa potvrdených požiadaviek, integrácií a rizík.