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?
Nálepky:
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.
- 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.
- 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
Matthew Gertner
CEO v Salsita Software, kde vyvíjíme prvotřídní webové a mobilní applikace pro naše mezinárodní klienty.
Tohle by mělo být povinné čtení pro všechny obhájce zadávání veřejných zakázek způsobem, kdy se soutěží jen o nejnižší celkovou cenu.
Ono to není tak jednoduché, instituce financované ze státního rozpočtu mají každý rok přidělené fixní prostředky, takže už z principu nemůžou vyhlašovat výběrová řízení na něco, u čeho by nebyla známá celková cena. Navíc to by pak bylo řevu tobě podobných expertů, kdyby se veřejné zakázky nesoutěžily na fixní cenu, to by se pak každý divil, kam se až vyšplhala (ne)konečná cena za dílo, že?
Jo, a přečti si zákon o zadávání veřejných zakázek, než něco takového začneš komentovat…
Soukromý sektor je samozřejmě něco jiného, ale i tam si troufám říct, že 90% zákazníků nemá šanci ocenit, co mu IT dodavatel fakturuje za práci, prostě proto, že tomu nerozumí, a tudíž nemá zákazník šanci ani zjistit, jestli ho dodavatel náhodou neodírá. Takže musí poptávat fixní cenu a je na dodavateli, aby ji uměl nastřelit. Tak to prostě je.
Ono to zní jako pěkná pohádka fakturovat jenom skutečně odvedenou práci, ale to může fungovat u freelancerů, OSVČ, malých firem a malých projektů standardního typu, těžko u velkých systémů vyvíjených na míru, tam bohužel musí dodavatel vzít na sebe riziko fixní ceny těžko to lze očekávat od zákazníka, který IT nerozumí a který asi těžko může přijmout riziko, že mu dodavatel udělá půlku systému za takovou částku, že zákazník už nebude mít na dokončení.
Jenom pro pořádek, jsem SW developer s 20 letou praxí na velmi velkých zakázkách pro státní sektor i na malých projektech pro soukromníky…
…no tak se clovek z clanku dozvi, ze dotycni vybec netusi co je software engeneering a project management a objem prace na zakazce umi tak maximáně věštit z kávové sedliny. Pricing je pro ne nezname slovo a vubec netusi z ceho by se mela cena za zakazku skladat, jak by mela by nastavena a jak komunikovana s klientem. A jsou prilis sexy se na to aspon nekoho kdo tomu rozumi zeptat a nebo ho snad zaplatit. Ok, ale proc chteji aby to osoatni delali takto blbe taky moc nechapu. Sebereflexi muzou zacit u toho, ze uctovani podle casu je staveni vlastnich zajmu pred zajmu klienta a takove partnerstvi je od zacatku blbe.
Naprostý souhlas s Caracho….
Jak říkal můj bývalý šéf, pokud nelze projekt přesně nacenit z různých důvodů nebo to neumíš, udělej si nejlepší možný poctivý odhat jednotlivých komponent projektu a času na komunikaci s klientem a testování. Tento odhad vynásob x 3 nákladově a 3 x časově. S velkou pravděpodobností nebudeš ztrátový a projekt uděláš ve dohodnutém termínu (často i dřívě což klient ocení) a pokud ti zákazník nekývně na cenu , tak jsi nejspíš ušetřil čas a peníze :-)
dik777
souhlas, navýšit cenu a čas 3 odpovídá nejblíže realitě – bohužel pro většinu už je špatně dvojnásobné navýšení
Naprostý souhlas. A to hlavně s „staveni vlastnich zajmu pred zajmy klienta a takove partnerstvi je od zacatku blbe„
pochopil jsem vás všechny správně, že chtít po klientovi zaplatit to, co „opravdu odpracuju“ v hodinové sazbě je nečestné. Zatímco udělat odhad a vynásobit třema je v zájmu klienta lepší? Teď to nemyslím nijak zle, ale asi tuhle debatu vůbec nechápu. Můžete prosím někdo přeložit vaše slova pro začátečníky a mírně pokročilé :)
Ne, nepochopils vůbec nic. Není to o těch 2 možnostech s tím, že nic jiného neexistuje. To zavání naivitou a, promiň, omezeností.
Prosím bez urážek! Martin se ptá, jak to myslíte, protože vašemu pohledu nerozumí. Není třeba ho urážet, místo toho mu to můžete vysvětlit. A pokud nechcete, tak třeba ignorovat.
Na tom není nic složitého. Už to napsal Caracho v příspěvku, na který jsem reagoval: „…no tak se clovek z clanku dozvi, ze dotycni vybec netusi co je software engeneering a project management a objem prace na zakazce umi tak maximáně věštit z kávové sedliny.“
A já k tomu ještě dodám, že podnikání je o riziku a pokud veškeré riziko přenesete na zákazníka, je to pro vás sice skvělé, ale jen krátkodobě. Po pár projektech ten zákazník půjde jinam, kde ho berou jako partnera a ne jako kavku.
Máte pravdu s tím, že je krátkozraké přenést veškeré riziko na zákazníka. Jenže právě ta předem daná celková cena je riziko především na straně zákazníka.
Zákazník nikdy nedokáže předem přesně nadefinovat zadání, takže pevná cena přesně podle zadání znamená, že si řešitel odprogramuje své, předá to zákazníkovi, ten zahodí části, které mu nevyhovují a zadá si za další peníze úpravy, aby se přiblížil potřebnému řešení. Ve výsledku tedy stejně zaplatí víc, než byla ta původní „pevná“ cena.
Když se místo toho platí skutečně odvedená práce, může zákazník průběžně zpřesňovat zadání a platí jenom za to, co se na tom skutečně udělalo. Když v průběhu realizace zjistí, že nějakou část nepotřebuje, nebude se to vyvíjet a platit – a ušetřené peníze zákazník použije na něco jiného, pro něj užitečnějšího.
Kruci… sem to melo byt. To forum bez JS neumi sledovat vlakna (asi je pro nekoho progressive enhancement sproste slovo).
Zakaznik mozna neumi presne definovat zadani, ale umi presne rict jake ma potreby a problemy – a v tom je ten rozdil. Jak jsem psal uz jinde, zakaznik nepotrebuje novy sw, zakaznik potrebuje neco vyresit. Je to o komunikaci. Celkova cena na strane zakaznika zadne rizko nepredstavuje, kdyz bude presne vedet co za ni dostane. A pokud to nekdo nechape, tak to holt musi delat jak ti z clanku. V praxi to pak dopadne tak, pak za zakaznikem prijde nekdo jinej, kdo jeho potreby vyresi a dotycny se strasne divi, proc od nej odesel ke konkurenci i kdyz on to prece nabizi o tolik levneji…
Zákazníka, který umí přesně říct, jaké má potřeby a problémy, bych někdy rád potkal. Zákazník u celkové ceny samozřejmě přesně ví, co za ni dostane – přesně to, co na začátku požadoval. Což je – ke smůle zákazníka – něco jiného, než co by chtěl. Zákazníkovy potřeby málokdy vyřeší někdo, kdo od začátku do konce pojede hlava nehlava přesně podle zadání, které si zákazník nadiktoval. Naopak je vyřeší někdo, kdo je schopen se zákazníkem průběžně spolupracovat, průběžně mu dodávat nějaké výsledky a podle zpětné vazby přizpůsobovat další vývoj.
Vas prispevek mi naznacuje, jak to s vami asi bude… Zacinate kategorickym tvrzenim ve smyslu toho za takovi zakaznici nejsou. Ani nereknete, ze jste na takoveho vy osobne zatim nepotkal, natoz aby vas napadlo, jestli to taky neni v necem jinem. Co se takhle napred zamyslet, proc jste takoveho jste nepotkal? Umel jste se na jejich problemy spravne zeptat (ano, nekteri lide se neumi vyjadrit presne, dokud se jich spravne nezeptate)? Zkusite premyset o vecech i jinak, z jinych uhlu a i z pohledu jinych lidi? A vite proc jini premysleji o stejnych vecech jinak? Pokud ne, zeptejte se jich!
BTW nedavno jsem na netu narazil na tohle: https://blog.intercom.io/unflattening-design/ – docela hezky popsano.
Oni takoví zákazníci ale opravdu nejsou. To, že já se ptám, není předem dané zadání od zákazníka, ale je to proces řešení. Navíc to ptaní se není možné udělat jen na začátku a tím skončit, je nutné to neustále opakovat – protože se mění prostředí, mění se potřeby zákazníka, mění se i znalosti zákazníka o tom, co je jeho problém.
Ta fixní cena je použitelná maximálně v případě, kdy se nemá zákazníkův problém vyřešit, ale jen uhasit to nejnutnější – typicky když něco dohání. „Všichni mají web, musíme mít taky web.“ Tam se dá zařídit, že zákazník za fixní cenu „bude mít web“. Ale jeho problém to nevyřeší.
„To, že já se ptám, není předem dané zadání od zákazníka, ale je to proces řešení.“
Ne, to není proces řešení. To je proces zjištění zákazníkových potřeb abych mu mohl nabídnout řešení.
Ano, chápu že komunikace se zákazníkem ve stylu:
jooo, vy potřebujete spojit informační systém a webové stránky? To umíme. Stojí to 1250,- Kč na hodinu. Ptáte se kdy to bude hotové? No, to bude záležet na tom, co budete chtít. A ještě se ptáte kolik že to bude potřebovat hodin? To ale záleží na vás a na tom, co budete potřebovat. Takže jdeme na to?
je náramně pohodlná a jednoduchá. Navíc vás k ničemu nezavazuje a nepřináší rizika. Ale pro zákazníka je to úplně na houby protože neví kolik to bude stát a kdy to bude hotové.
Pro mně takový dodavatel nepřináší naprosto žádnou přidanou hodnotu (teď nemyslím z pohledu technologie, ale z pohledu podnikání a řízení mého businessu), a když nebudu muset, už s ním nebudu nikdy spolupracovat.
„Proces zjištění zákazníkových potřeb, abyste mu mohl nabídnout řešení“ je přesně ta situace, kdy zákazníka donutíte, aby udělal rozhodnutí, která v daném okamžiku kvalifikovaně udělat nedokáže, a dělat je nemusí. Vy ho k tomu donutíte jenom proto, abyste mohl stanovit pevnou celkovou cenu a zakotvit to do smlouvy. A že zákazník později zjistí, že potřebuje něco jiného? To je jeho smůla, ve smlouvě je tohle, tak si to zaplatí, a pak si zaplatí ještě úpravu do stavu, který potřebuje.
Z pohledu dodavatele, který chce na zákazníkovi pěkně rejžovat, je samozřejmě dobré, když zákazníkovi vnutí pevnou cenu za něco, co zákazníkovi nebude vyhovovat, a bude muset platit další a další částky, aby dostal něco aspoň trochu použitelného. Je to známé z mnoha stavebních nebo IT zakázek, které začínají právě tou nepřekročitelnou fixní cenou, a končí několikanásobným překročením rozpočtu i času. Třeba pražská Blanka je modelový příklad takhle postaveného projektu.
Ten váš příklad komunikace se zákazníkem je straw man jak vyšitý. To, že není na začátku řečena fixní částka za fixní zadání, neznamená, že nejsou stanovena vůbec žádná pravidla. Pravidla stanovena jsou, jsou stanovené rámcové částky za nějaké období, je stanoven rámec toho, co se za to období udělá, a také postupy, jak se specifikují detaily.
Zákazník je s tím spokojen už spoustu let, uživatelé taky. Jiné subjekty používají v obdobných případech ta fixní zadání a fixní ceny, a každou chvíli se někde objeví nějaký nefunkční systém, který se za další a další peníze uvádí do stavu, aby aspoň nějak fungoval.
Přemýšlel jsem, jaké slovo nejlépe vystihuje nejlépe článek a nejblíže mě napadlo slovo naivní. Ano v určitém procentu zakázek panuje rozumný vztah mezi klientem a dodavatelem a tam to může fungovat. Často klient ale nechce/nemůže pochopit a to v podstatě až do té míry, že radši zaplatí za přepálený odhad, nebo vyždíme dodavatele (podle úrovně schopností zákopové války na obou stranách). Z vlastní zkušenosti mi přijde, že čím větší je ať už kterákoliv ze zmíněných stran, tím spíše to končí scénářem, který popisuji. Přijde mi naivní a matoucí pro čtenáře si myslet, že to tak může fungovat všude, zálěží na tom kde pracujete a s kým spolupracujete.
Osobně bych moc chtěl věřit, že klienti jsou rozumní lidé, kteří nikdy nezneužijí situace, nebudou projekt vidět schválně svou optikou a uznají, že za polish je třeba si zaplatit, nebo, nedej Bože, pochopí, že unit testy jsou rozumně vynaložený náklad. Ale tak to, bohužel, nefunguje. V zásadě by mi přišla daleko přínosnější diskuse nad následujícími dvěma případy, ke kterým oba tady zmiňované přístupy nevyhnutelně dospějí, ať dříve, nebo později:
Jsem vývojář ne politik. Tudíž, pokud se mnou někdo není spokojený = nechce zaplatit mou práci, beru si kód zpět, a slušně se rozloučím.
Mám tedy následující zkušenosti:
Odhaduji, že ty dva vámi uvedené scénáře prostě patří do prvního, možná druhého případu. Jakmile se klient začne dohadovat o penězích, je něco špatně. A pokud mu posíláte průběžně všechny ty timesheety, a komunikujete s ním, tak klidně může být problém na jejich straně. Nedělejme si iluze. Oni někteří klienti vážně nestojí za ty starosti.
Rozumný klient si umí spočítat, jesti mu stojíte za ty peníze. Někteří hledají kličky, jak vás přečůrat.
Mimochodem, tento můj příspěvek je spíše tak ze života. S obsahem článku se maximálně stotožňuji.
„Jsem vývojář ne politik“
Mnoho zákazníků ale dělá zásadní 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í nedorozumění.
On tyhle věci dnes dělá každý, kdo má (s odpuštěním) do prdele díru. A proto taky potom jsou tyhle hraběcí rady typu buď mi bude platit hodinovou sazbu (a to ještě nejradši na měsíc předem abych nebyl škodný v případě že se mnou nebude chtít pracovat a mohl v klidu skončit) a nebo fixní cenu, ale zato pořádně napálenou. Tyhle dvě varianty vám vypotí každej trochu víc vyčůranej týpek ze základky, kterej chce jen s každým vydrbat.
A nebo se prostě setkají dva lidé, jeden který má vizi (klient) a druhý, který má knowhow (dodavatel). A snaží se tak dlouho spolupracovat, až z toho vyleze výsledek. Což je přesně cíl, ke kterému ani fixní cena a politikaření, ani hodinová sazba nevede. Zato způsob, o kterým hovoří článek ano.
A nebo to taky muze byt uplne jinak. Oba dva zminovane pripady jsou pouze dusledkem nedostatecne komunikace s klientnem pred zacatkem a behem prace. Vysledkem prvotni analyzy kazdeho projektu by mimo jine melo byt stanoveni meritelneho cile a double crosscheck s klientem (resp. vsech zucastnenych osob), ze opravdu mate na mysli totez a premyslite o vysledku stejnym zpusobem. Je to o tom, ze neprogramujete sw podle zadani, ale ze pomahate pomoci prave vznikajiciho sw resit klientovu potrebu/problem – a kdo je v tomhle dobrej, tak si muze rict radove nekolikanasobne vic a bez hodinove mzdy, nez ten kdo jen plni klientova prani a nechava se platit od hodiny. Klient je rad, rad to zaplati a jeste vas doporuci dal – protoze jste vyresili jeho problem, ne proto ze jste neco naprogramovali (a navic odpadne to hadani, zda jste nad tim stravili vic ci min casu).
To jsem si nejdriv taky myslel. Ale v obou pripadech byla komunikace zcela pravidelna (tydenni synchro + ad hoc komunikace mezi tim) a k detailnimu potvrzeni doslo vzdy pred zahajenim dotycne casti praci. I presto – a i pres velkou spokojenost klienta s vysledkem – k tem pripadum dochazi.
V zasade tedy rikate, ze nejlepsi pristup je odhadnout interni naklady, ty vynasobit bezpecnou konstantou zahrnujici marzi a cas straveny na sluzbach navic (coz je to reseni problemu, nikoli presne vyjadreni odhadu)?
Delam projekty v low cost segmentu trhu, realny penize za projekt dokazu dostat tak zhruba u 10% projektu, na zbytku upozornuju ze za ty penize nepujde o stoprocentni praci, a stejne je to marne. Takze v tech 90% zijuz toho ze klientovy nabidnu reseni ktere mam hotove a jsem ochoten ho upravit minimalne, ale porad je to na krev, a ty lidi proste nechteji platit.
Mozna by stalo za zminku, v jakem segmentu presne pusobite. Mam dojem, ze pristup muze byt uplne jiny v ruznych odvetvich – jinymi slovy to, co na jednom miste jste schopny s klientem dojednat, jinde to muze byt temer nemozne – muze to byt vlivy jako konkurence, zavedene postupy apod. Podle me neexistuje jedna univerzalni medicina na vsechno.
to je o pristupu k zakaznikovi, ne o trhu. pokud nabizite hotove reseni s minimalni ochotou ho upravovat a neresite v prvni rade zakaznikovy potreby, tak se nedivte ze nechteji za neco takoveho platit.
Zakaznik mozna neumi presne definovat zadani, ale umi presne rict jake ma potreby a problemy – a v tom je ten rozdil. Jak jsem psal uz jinde, zakaznik nepotrebuje novy sw, zakaznik potrebuje neco vyresit. Je to o komunikaci. Celkova cena na strane zakaznika zadne rizko nepredstavuje, kdyz bude presne vedet co za ni dostane. A pokud to nekdo nechape, tak to holt musi delat jak ti z clanku. V praxi to pak dopadne tak, pak za zakaznikem prijde nekdo jinej, kdo jeho potreby vyresi a dotycny se strasne divi, proc od nej odesel ke konkurenci i kdyz on to prece nabizi o tolik levneji…
Řekl bych, že to vidíte pouze z pohledu zákazníka. Moje zkušenost je taková, že zákazníci jsou skutečně různí, a i když asi většina ví, co chce, tak někdy není snadné jejich přání a potřeby identifikovat, případně se jejich potřeby mění – a někteří (i když jsou to asi spíš výjimky (závisí na segmentu) skutečně nehrají fér (což není jen záležitost IT). Nicméně to, co před čím upozorňuje autor článku je spíš něco jiného – technologické riziko.
Vývoj sw je někdy hodně nepredikovatelný – používá se desítky, stovky komponent – a jejich integrace nemusí být triviální. Pokud se z nějakého důvodu vybere mix komponent, který není 10x prověřený, tak výsledná pracnost může být 10h, ale také klidně 100h u špičkového programátora. A pokud se zákazník nechce podílet na tomto riziku, tak skutečně platí, že takový zákazník je tragédie, které je lépe se vyhnout velkým obloukem. Propálí se stovky hodin bez jakéhokoliv efektu a ve výsledku jsou všichni naštvaní a bez peněz a bez funkčního produktu.
Proto si zákazník dodavatele platí, ne?
Předpokládá, že jde o odborníky, kteří jsou schopni tato rizika odhadnout a eliminovat nebo minimalizovat. Proto si je platí. Je logické, že očekává, že když dodavatel, dostává zaplacenu domluvenou odměnu, tak že nese zodpovědnost za to, aby dodal co slíbil a kdy.
Přesně tak.
Ano, ale pak si samozřejmě dodavatel nechá zaplatit i za to, že nese tohle riziko.
Ano. To je pravda. A je to tak správně. Nicméně zadavatele to vyjde pořád levněji, pokud to riziko odhadne a nese někdo, kdo se tím živí.
Ve většině firem formulují požadavky na IT zakázky lidé z businessu. A je to tak správně. Je celkem logické, že ti nevidí do detailů ´vývoje a implementace informačních systémů – proč taky, neživí je to.
Tak jak mi to zní, tak společnost vlastně dělá bodyshopping. Zákazník si pronajímá vývojářský tým. Podle mého názoru tohle funguje jen v případě, že máte štěstí na
A chtěla bych trochu upozornit na jednu věc. Článek je přeložený asi rok starý z blogu společnosti, která má sice vývojářskou kancelář v Praze, ale pokud jsem si dobře všimla, tak většina zákazníků je US. A mentalita firem za oceánem je přece jen trochu jiná.
Tady se Gabi zmínila jednu důležitou věc, která v předchozích diskusích zůstala překryta jinými argumenty.
V podstatě existují dva modely:
– buď si firma najme někoho externího, platí ho v modelu „čas a materiál“. Pak nese veškerá rizika projektu sama a má dostatečné znalosti a zkušenosti, aby takový projekt uřídila (což většina zákazníků nemá, protože -kupodivu – hlavní náplní práce většiny firem nejsou IS).
– ve druhém případě je přenechá odpovědnost na odborníky, kteří se IS živí. Očekává přitom, že se o rizika projektu podělí (a pokud je dobře napsaná smlouva, tak to není problém). Z pohledu finančního řízení podniku je to mnohem efektivnější cesta a levnější. A to i přesto, že „hodinová cena“ vývojáře je zhruba dvojnásobná oproti předchozímu případu.
Uznávám, že pro freelancery a malé firmy má první model jisté kouzlo – nenesou žádnou odpovědnost a žádné riziko. Z pohledu zadavatele je to ale extrémně drahý „levný“ dodavatel. Pak se celkem není co divit, že to zákazníci dají přednost někomu jinému …
Řekl bych že se jednostraně zaměřujete jen na cenu. Ta ve většině případů není problém. Problémy jsou dva (a oba v článku zmíněné):
I kdybychom pominuli ten druhý bod, tak stále platí, že v článku zmiňovaný postup je pro klienta výhodný, protože může kdykoliv cokoliv změnit, a není to problém. A není pravda, že by to bylo o flákání se dodatavatelů, jak se tu snaží někteří implikovat. Já jako vývojář se ze všech svých profesních sil snažím, abych klientovi dotáhl projekt do úspěšného konce. K tomu ale patří, že mi nic nebude bránit abych měnil řešení, když se klientovi změní situace.
Tohle starý model s „software engeneering a project management“ prostě vůbec neumí podchytit, a jen klienta buzeruje.
uz programuji na zakazku nekolik desetileti. Ale jeste jsem nezazil situaci, ze by nejaky zakaznik vedel co chce a potrebuje, natoz aby to jeste dokazal formulovat. Samozrejme, ze dnes je situace jina nez v roce 1983, kdy jsem zacinal. Tenkrat programy pro mensi firmy proste neexistovaly, dnes ma firma minimalne predstavu, co muze dostat a ocekavat a jak bude nejake reseni navenek vypadat. Dnes kazda firma s nejakym programem jiz pracuje, zna bezne problemy a vetsina lidi zna i beznou pocitacovou terminologii. To vse kdysi davno nebylo, ale narostly zase moznosti zpracovani a provazanost. Pod carou neprinesla vetsi IT-vzdelanost zadne vyhody. Dnes se zakaznik topi v komplexite problematiky a protoze za poslednich 50 let se IT nepohla smerem k industrializaci, tak se i nadale pracuje na projektech misto na produktech.