Jak se naceňuje vývoj software?

 .

1. Proč se vývoj software nedá nacenit jako koupě automobilu.
2. Obecné typy problémů a proč je důležité je znát.
3. Nacenění vývoje software většího rozsahu (nad 1 500 000 Kč).
4. Nacenění vývoje software malého rozsahu (do 1 500 000 Kč).
5. Proč se cena násobí koeficientem.
6. Proč i drobné úpravy v zakázce stojí hodně peněz.
7. Zda se pouštět nebo nepouštět do vývoje software.

U automobilu si zvolíte:

Značku, typ, motorizaci, barvu, kola a další příplatkovou výbavu.

Vše je jasně definované, předem spočítané a výsledná cena je přesně daná. Pokud si vyberete konkrétní model s určitou konfigurací, víte, co dostanete a kolik to bude stát. Výrobní procesy jsou optimalizované a opakovatelné, protože auto stejného typu a výbavy se vyrobí tisíckrát stejným způsobem.

U software je to jinak:

Když vyvíjíte software, nejde o to „vybrat si z katalogu“ hotové díly a složit je dohromady. Vývoj software je spíše jako navrhnout a postavit výrobní linku, která teprve umožní daný „produkt“ vytvářet. Tato linka musí být navržena na míru konkrétním potřebám, což znamená hledání nových způsobů, jak propojit různé systémy, technologie a procesy.

To, co jste včera vyřešili pro jednoho klienta, dnes můžete udělat dvaceti dalšími způsoby pro jiného klienta – protože se mění technologie, potřeby i technická omezení. Pod rukama se vám neustále objevují nové nástroje, postupy a výzvy, které musíte každý den adaptovat a integrovat – pokud vám tedy záleží na kvalitě a dlouhodobé životnosti projektu.

Software není hotový produkt z továrny.

Každý projekt je originál, kde výsledná „konfigurace“ vzniká až během samotného vývoje – podobně jako když navrhujete novou výrobní linku, která musí zvládnout specifický proces s jedinečnými požadavky.

Stále to nedává smysl? Pojďme si to vysvětlit pomocí teorie problémů.

Pokud pochopíte, jaké existují typy problémů, tak pochopíte i to, jak se přistupuje k cenotvorbě napříč diametrálně odlišnými obory.

Stavební firma, účetní či řemeslník budou řešit úplně jiné typy problémů než například, softwarový architekt a věděcký pracovník.

Typy problémů:

1. Jednoduché problémy (Simple)

• Charakteristika: Existuje jedno správné řešení, které je snadné najít a aplikovat.
• Přirovnání: Jako když měříte teplotu teploměrem – víte, co dělat, a výsledek je jasný.
• Příklad v software: Změna barvy tlačítka, úprava textu, oprava zjevné chyby.
• Nacenění: Odhad je přesný, protože víme, kolik to zabere času.

2. Složitější problémy (Complicated)

• Charakteristika: Existuje více možných řešení, ale všechna jsou předvídatelná. Vyžaduje to odborné znalosti.
• Přirovnání: Jako když stavíte most – je to složité, ale inženýři přesně vědí, jak na to.
• Příklad v software: Napojení na platební bránu, se kterou již vývojáři pracovali.
• Nacenění: Odhadujeme podle zkušeností z podobných projektů, ale necháváme si rezervu na komplikace.

3. Komplexní problémy (Complex)

• Charakteristika: Výsledek není zcela předvídatelný. Mnoho proměnných se mění během práce.
• Přirovnání: Jako pěstování zahrady – víte, co asi poroste, ale počasí a další faktory vám mohou plány změnit.
• Příklad v software: Vývoj nového modulu, který propojuje více systémů, jež spolu mají komunikovat a interagovat.
• Nacenění: Používáme iterativní přístup – děláme malé kroky, testujeme a přizpůsobujeme se situaci.

4. Chaotické problémy (Chaotic)

• Charakteristika: Neexistují jasná pravidla. Musíte nejdřív zkoušet, co vůbec funguje.
• Přirovnání: Jako když hasíte lesní požár – reagujete na situaci v reálném čase.
• Příklad v software: Vývoj zcela nové technologie bez předchozích zkušeností. Nouzové opravy kritického systému pod tlakem.
• Nacenění: Nedá se přesně odhadnout. Pracuje se na základě hodinové sazby s možností rychlé eskalace.

Vývoj software ve většině případů spadá pod komplexní typy problémů (3). Pokud však vyvíjíte zcela novou technologii, lehce se dostanete k chaotickým typům problémů (4).

Firmy, které zaměstnávají vývojáře, vědí, že vývoj software nelze uzamknout do přesného zadání – vývojáři totiž řeší komplexní (3) až chaotické typy problémů (4), u nichž je známo, že jejich řešení nelze přesně určit, natož nacenit. Pokud má být výsledek kvalitní, nelze vývojáře svazovat detailní specifikací. Situace se stejně velmi rychle mění během samotného řešení problémů (není náhoda, že fráze „vývoj software“ obsahuje slovo „vývoj“).

Už je jasnější, proč se vývoj software nedá přesně nacenit?

U velkých projektů se používá přístup, který připomíná řízení vědeckého výzkumu. Zákazník obvykle disponuje stabilním rozpočtem (například 500 000 Kč měsíčně) a projekt je rozdělen do iterací, které umožňují postupné dodávání výsledků. Tento přístup je typický pro agilní metodiky, kde se průběžně sleduje, co je hotovo, co zbývá dokončit a jak se mění priority.

Klíčové rysy:

• Iterativní vývoj: Pravidelné dodávky funkčních celků.
• Průběžné odhady: Odhady se upravují na základě nových informací během vývoje.
• Flexibilita: Možnost měnit rozsah funkcionalit dle aktuálních potřeb.

Výhodou je, že klient platí za skutečně odvedenou práci a má kontrolu nad tím, jak se projekt vyvíjí. Nevýhodou může být nejasnost celkové konečné ceny, protože ta se odvíjí od průběžného vývoje a měnících se požadavků.

Menší projekty se často nacení na základě odhadu pracnosti jednotlivých funkcionalit. Zde ale nastává problém – i když odhad může vypadat přesně, ve skutečnosti vždy existují neznámé faktory, které odhad zkreslují. Proto je nutné do odhadu zahrnout rezervu na nepředvídatelné komplikace.

Klíčové rysy:

• Fixní cena nebo omezený rozpočet: Snaha o co nejpřesnější odhad, často na základě podobných projektů.
• Nižší flexibilita: Změny během projektu mohou znamenat dodatečné náklady.
• Vyšší riziko: Menší projekty nemají prostor na iterativní vylepšování, což zvyšuje riziko podcenění náročnosti.

Zde platí jednoduché pravidlo: čím menší projekt, tím větší riziko odchylky od původního odhadu. Proto je důležité s tím počítat už při plánování rozpočtu - je potřeba nastavit vyšší koeficient rizika.

Abychom pokryli rizika spojená s nepředvídatelnými komplikacemi, používáme tzv. koeficient rizika, který přidává do celkové ceny rezervu.

Tento koeficient se liší podle velikosti projektu:

• Koeficient: 1,3 (velké projekty nad 5 000 000 Kč)
  U velkých projektů se rizika rozloží v čase díky iterativnímu přístupu. Pravidelné dodávky a kontrola umožňují včas reagovat na problémy. Proto stačí menší rezerva.
  
  
• Koeficient: 1,5 (střední projekty okolo 1 500 000 Kč)
  U těchto projektů už není možné tak efektivně plánovat a rozkládat rizika v čase jako u velkých. Omezenější prostor pro úpravy ale zvyšuje pravděpodobnost neočekávaných komplikací, proto je potřeba počítat s větší rezervou.
  
  
• Koeficient: 2 (malé projekty do 1 500 000 Kč)
  U malých projektů chybí možnost rozkládat rizika v čase, protože se realizují jako celek bez iterativního přístupu. Jakýkoli skrytý problém tak může mít zásadní dopad na celý projekt. Proto násobíme odhadovanou cenu dvěma, abychom pokryli rezervu na nepředvídatelné komplikace.

Proč je tento koeficient důležitý?

Bez rezervy by každá neplánovaná komplikace znamenala, že projekt bude stát víc, než bylo domluveno. Koeficient zajišťuje, že rozpočet pokryje nejen odhadovanou práci, ale i nečekané problémy, které jsou u vývoje softwaru prakticky jistotou – těm se nevyhnete, ani když si najmete ty největší světové profesionály.

Některé firmy s rizikem vůbec nepočítají, aby jejich nabídka vypadala levněji, což ale často vede k neplánovaným vícepracím, které klient musí dodatečně zaplatit. Jiné firmy naopak riziko zahrnou skrytě – koeficient aplikují na odhady, aniž by o tom klient věděl, takže zaplatí víc, aniž by se dozvěděl proč.

I když násobení koeficientem může zavánět nezkušeností, tak opak je pravdou. Jedná se o naprosto transparentní přístup – klient dostane detailní odhad jednotlivých úkolů a výsledná cena je otevřeně navýšena o jasně definovaný koeficient rizika. Díky tomu přesně víte, za co platíte, a vyhnete se nepříjemným překvapením.

Tento přístup je férový pro klienta i dodavatele – minimalizuje riziko nepříjemných překvapení na obou stranách.

I když se tento problém vyskytuje převážně u projektů malého rozsahu do 1 500 000 Kč, rád bych vysvětlil, proč k tomu dochází.

Když je hodinová sazba vývojáře 1 000 Kč/hod, snadno se stane, že i malá úprava vyjde na několik tisíc korun. 

1. Analýza a porozumění (1–2 hodiny):
   Než lze zasáhnout do kódu, je nutné pochopit problematiku, zvážit možné důsledky a určit nejvhodnější způsob provedení změny.
2. Implementace změny (0,5–1 hodina):
   Úprava kódu může být zdánlivě jednoduchá, ale vždy je propojená s dalšími částmi systému, což je třeba zohlednit.
3. Testování (1–2 hodiny):
   Každá změna musí být důkladně ověřena, aby správně fungovala a neovlivnila ostatní části systému.
4. Nasazení do provozu (0,5–1 hodina):
   Změny je nutné bezpečně nasadit, otestovat v reálném prostředí a ověřit jejich správnou funkčnost.
5. Rezerva na nečekané problémy:
   Při úpravách se mohou objevit související komplikace, které je nutné včas identifikovat a vyřešit.

I jedna malá změna tak snadno zabere 4–6 hodin práce, což je 4 000 až 6 000 Kč navíc. Cena za 10 takových malých změn v jednom modulu bude 40 000 Kč až 60 000 Kč. Nyní si představte, že máte 5 modulů, tj. 200 000 Kč až 300 000 Kč navíc.

Toto je situace, do které se nechce dostat ani zadavatel ani zpracovatel - proto je při naceňování potřeba počítat s koeficienty viz předchozí odstavec.

Do vývoje software se raději vůbec nepouštějte, pokud

• Nedokážete rozlišit typy problémů a pochopit způsob naceňování vývoje software.
• Nelíbí se vám způsob naceňování či práce s koeficientem a máte tendenci to měnit.
• Rádi tlačíte na snížení ceny, ale neslevujete z požadavků.

Do vývoje se můžete pustit, pokud

• Reálně a hluboce chápete, jak se naceňuje software a proč tomu tak je.
• Máte dostatečný rozpočet i po vynásobení koeficientem a dává vám to smysl.
• Jste připraveni se zapojit do realizace a věnovat ji alespoň hodinu denně.
• Jste připraveni, že se po spuštění začnou objevovat provozní chyby, které s vámi vývojáři budou řešit, než se vše odladí.

Pokud vás téma zaujalo, v dalším článku se podíváme na to, jak správně připravit zadání projektu, ze kterého vychází odhad ceny.