Stanovení ceny softwarových projektů

Setkáváme se jak s velmi komplexním zadáním sepsaným na mnoha stránkách, ale také s vágním zadáním o dvou či třech větách.

Dva hraniční přístupy pro tvorbu zadání

V ideálním světě pro vývojáře software by to fungovalo tak, že společně s klientem pracujeme na úvodním zadání, začneme s realizací projektu, průběžně projekt upravujeme podle nových požadavků, každý měsíc vyfakturujeme spotřebované hodiny vývojářů a konzultantů a takto postupujeme až ke skvělému finále.

Tak to ale nefunguje. Klient většinou požaduje celkovou cenu za přesně stanovený rozsah práce a s konkrétním termínem dokončení.

Abychom byli schopni takovou nabídku zpracovat, mohli bychom společně s klientem strávit dlouhé měsíce tvorbou komplexního zadání o desítkách stran. Vše předem promyslet do úplného detailu. Podle takového zadání už lze cenu a termín realizace odhadnout docela přesně. Past je v tom, že i kdybychom strávili nad tvorbou zadání rok, tak stejně nevychytáme vše a nevyhneme se „aha“ momentům, kdy si klient uvědomí další potřeby či bude chtít funkcionalitu řešit jinak.

Jak si tedy udělat relevantní představu o rozsahu výsledného produktu, jeho ceně a termínu?

Většinou se tak při naceňování softwarových projektů pohybujeme někde uprostřed těchto mantinelů.

Než se firma pustí do vývoje software na míru, může poslat poptávku na více stran. Jak je možné, že u různých dodavatelů vznikají nabídky s cenou rozdílnou v násobcích?

Není to jenom o hodinové sazbě vývojářů. Cena samotného vývoje je jenom jedním z aspektů. Hodně záleží na tom, co vše nabízená cena obsahuje a asi nejdůležitější je samotná kvalita nabídky, do které se propisuje zkušenost.

Zejména u začínajících programátorů se můžeme setkat s přístupem: „Čím míň víš, tím víc si myslíš že víš.“ Je to relevantní, každý musí začínat jako junior. Často tyto nejlevnější nabídky nepracují s předpokládanými překážkami a riziky, s možným rozšířením funkcionality nebo neobsahují vše.

Softwarový projekt totiž začíná pochopením záměru klienta. Proč chce právě to co chce a v čem mu to v byznysu pomůže.

Pokračuje analýzou, která by měla být zpracována kvalitně, do hloubky a s přesahy. Teprve poté dojde na řadu vlastní vývoj. Často se podceňuje fáze testování, pilotní nasazení a podpora uživatelů v prvních měsících užívání. A téměř vždy cenová nabídka nepočítá s následným rozvojem produktu.

Mnoho zákazníků dělá chybu v tom, že si objednává vývojáře a ne někoho, kdo mu umí uspokojit jeho potřeby.

Z toho potom pramení nespokojenost z výsledku práce.

Jak tedy většinou postupujeme? Poskytneme hrubý cenový odhad, za který lze dodat požadované řešení pokrývající definované byznysové potřeby.  Zákazník možná neumí přesně definovat zadání, ale umí přesně říct, jaké má potřeby a problémy.

Analýza – vývoj – testování – nasazení – podpora - rozvoj

Tento odhad zpřesníme zpracováním analýzy. Tu děláme vždy. Ptáme se, proč vlastně zákazník chce to, co chce, proč takto, zda by to nešlo vymyslet jinak, jednodušeji, komplexněji. Ověřujeme, zda to, co je v zadání skutečně řeší problémy a povede k dodání toho, co klient potřebuje. Využíváme tak léta získávané know-how. Proto analýzy neděláme zdarma.

Stanovíme mantinely, v rámci kterých je nabídnutá cena platná. Vyvíjíme, průběžně komunikujeme a s klientem hrajeme s „otevřenými kartami“. Naší filosofií je dodržet nabídnutou cenu. V situaci, kdy jsme se opravdu silně netrefili, požádáme klienta o revizi rozpočtu. Je ale na něm, jestli nám ji povolí.

Agilní způsob vývoje by se nám samozřejmě zamlouval nejvíc. Pracovat v kratších iteracích a průběžně dodávat a fakturovat po částech a stále zpřesňovat zadání je ideální přístup při vývoji software. I sebelepší analýza na začátku má vždy nedotažené drobnosti a vždy se narazí na neočekávané překážky. Zatím jsme ale nenatrefili na klienta, který by s tímto přístupem souhlasil.