Proč neděláme softwarové projekty s fixní cenou (a ani vy byste neměli)

Před několika lety jsem přistoupil na jeden freelance projekt: implementaci Internet Explorer komponenty v C++. V té době jsem na jiných projektech fakturoval zdravou hodinovou sazbu, tento konkrétní klient však trval na fixní ceně. Na základě nějakého dočasného zatemnění mysli jsem učinil výjimku a přijal jsem předem odsouhlasený rozpočet. Projekt se zdál přece jen být poměrně zajímavý a požadavky jasné jako facka. Co by se mohlo stát, že?

V anglickém originále zveřejněno na blog.salsitasoft.com.

O několik týdnů později jsem již měl odpracováno třikrát více hodin, než kolik jsem původně odhadoval. Pracoval jsem dvanáct hodin denně, abych mohl projekt dostat ze stolu a věnovat se práci, která by mi přinášela alespoň nějaký zisk. Požádal jsem tedy klienta o navýšení rozpočtu anebo alespoň rozumné proškrtání požadavků. V duchu spolupráce a obchodního přátelství jsem se však z jeho strany dočkal jen poukázání na příslušná ustanovení smlouvy a pomyslného: „Sklapni a makej“.

Byl to poslední projekt s pevnou cenou, který jsem vzal. A této filozofie se v Salsitě držíme dodnes. Klienti se nás ale často ptají, proč na pevnou cenu pro jejich projekt nepřistoupíme. Jsme přeci zkušení profesionálové, ne? To nemůžeme stanovit přesný odhad?

Říkám jim na to tohle.

Každý developer ví, že přesný odhad není možné udělat ani při sebepřesnějších informacích o projektu. Není ho tedy možné udělat téměř nikdy. Jak velmi trefně vystihuje Michael Wolfe v jedné ze svých památných Quora odpovědí, zběžný pohled na začínající projekt ignoruje všechny ty do detailu dotažené drobnosti a neočekávané překážky, které ale nakonec tvoří velmi podstatnou část práce. To je přesně důvod, proč agilní metodiky tak jednoznačně ovládly svět softwarového vývoje. Zahrnují totiž nemožnost udělat na začátku úplně přesný odhad.

Ve spojení se zpravidla velmi nepřesnými odhady vytváří finanční vztah mezi softwarovou firmou a klientem dost nebezpečnou kombinaci. Najednou se již klient neobává pouze toho, kdy svůj software dostane, ale také toho, jak moc to zasáhne jeho peněženku.

Z této situace existují jen dvě východiska. A obě stojí za starou belu.

  1. Dělat stejný typ projektu znovu a znovu. Pokud jsou požadavky klienta dostatečně podobné těm, které jste měli v minulosti, můžete si být dostatečně jistí svým odhadem, zejména pokud jste schopni znovu použít svůj dřívější kód.
  2. Nadhodnotit odhad dle uvážení tak, abyste byli kryti v případě, že se projekt oproti původním předpokladům prodlouží.

První východisko nahrává opakujícím se nerentabilním projektům s nízkou marží a druhé očividně není v zájmu klienta. V souladu s Kuželem nejistoty (Cone of Uncertainty) popisovaným v klasice od Stevea McConnella Software Estimation: Demystifying the Black Art můžeme říct, že odhady na počátku projektu se mohou lišit s faktorem čtyři nahoru i dolů. Museli bychom tedy podstatně navýšit pevnou cenu, což znamená, že klient by projekt téměř jistě v konečném důsledku přeplatil.

Práce za pevnou cenu také vyvolává nezdravé pohnutky ve vývojářském týmu. Jedná se o zcela přirozenou reakci na danou situaci, která svádí k nevhodným zkratkám ve vývoji jen proto, aby byl software co nejdříve hotov. Prostě k přesnému opaku toho, co bychom měli správně dělat.

Dalším velkým problémem je, že každý požadavek klienta se zvrhne ve vyjednávání, na kterém strany vzájemně válčí o to, zda přidáním nekonečného scrollování do widget managementu rozšíří rozsah projektu, a tím i navýší budget, nebo zda se jedná o opravu bugu (který je samozřejmě jen a pouze chybou developera). Jistě se shodneme, že energie investovaná do řešení této tahanice by šla využít mnohem lépe. Například samotným psaním kódu.

Na druhou stranu, pevný rozpočet je pro klienty atraktivní ze stejného důvodu, proč jsou pro manažery atraktivní deadliny. Je to jen o kontrole. Klient se může obávat, že firma bude dělat vše pro to, aby dostala výši faktur na co nejvyšší mez, stejně tak jako se kdejaký průměrně (ne)kompetentní manažer může obávat nízkého pracovního nasazení svých developerů v případě, že nad nimi nevisí damoklův meč v podobě deadlinů.

V obou těchto případech se jedná o laxní přístup k řízení projektu vedoucí pouze k frustraci, hořkosti a špatnému kódu. Paradoxně to ale nevede k včasnému dokončení projektu, protože prosté nalepení deadlinu nebo rozpočtu na projekt neznamená, že tomu tak bude i ve skutečnosti.

Mnohem lepší přístup je tuto realitu softwarového vývoje pochopit a přijmout ji za vlastní. Jedním z nejlepších nápadů pocházejících z agilních metodik je pravidelná a častá komunikace mezi zúčastněnými stranami. Pokud není klient schopen či ochoten docenit posun, kterého bylo dosaženo v průběhu práce na projektu, a adekvátně reagovat v případě, že druhá strana neplní, co má, nemá v této branži jednoduše co dělat.

Pro nás, jako tvůrce softwaru, platí povinnost poskytnout klientovi reálný odhad rozsahu projektu a jeho rozpočtu (zpravidla mnohem vyšší, než si myslí, že bude) a vysvětlit mu, proč jsou úzká spolupráce a komunikace mnohem lepšími předpoklady k úspěchu než nekompromisní pevná cena. A nekonec jedna rada na závěr pro klienty: Pokud se vám nabídnutá pevná cena za komplexní a špatně specifikovaný projekt zdá být příliš dobrá, než aby byla reálná, pravděpodobně se vám to jen nezdá, ale opravdu tomu tak je.

Salsita Software

Salsita Software je softwarová společnost, která se specializuje na vývoj komplexních moderních webových a mobilních aplikací. Sponzorujeme JavaScripting.com, komunitní portál, který pomáhá vývojářům hledat knihovny a frameworky pro JavaScript.

Překlad: Jakub Klouček, Luboš Turek a Adam Eda Zemek

CEO v Salsita Software, kde vyvíjíme prvotřídní webové a mobilní applikace pro naše mezinárodní klienty.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 37

Přehled komentářů

Filip Jirsák veřejné zakázky
Martin Holý Re: veřejné zakázky
caracho
dik777 Re:
Václav Pávek Re:
Honza Re:
martin Re:
Honza Re:
Martin Hassman Re:
Honza Re:
Filip Jirsák Re:
caracho Re:
filip.jirsak Re:
caracho Re:
filip.jirsak Re:
Honza Re:
filip.jirsak Re:
Radim Omáčka
Pavel Dort
Taco Re:
Honza Re:
Taco Re:
caracho
Pavel Dort Re:
Oldis
Pavel Dort Re:
caracho
caracho
Pavel Stehule
Michal Re:
Honza Re:
arron Re:
Michal Re:
Gabi Getty A co česká realita?
Michal Re: A co česká realita?
Taco Re: A co česká realita?
jan.karasek zakaznika, ktery vi co chce nebo potrebuje jsem jeste nepotkal
Zdroj: https://www.zdrojak.cz/?p=17573