Rozhodl jsem se popsat zkušenosti, které mám se zadáváním zakázek v oblasti implementací software, protože mi přijde, že v této oblasti existuje spousta iluzí a jak jsem zjistil, existuje v oblasti agilního managementu projektů mnoho respektovaných osobností, které považují konečnou cenu buď za dobré řešení, nebo za přijatelný kompromis.
Budu psát o tom, proč jako zákazník považuji „fixed budget“ za chybný model. Jde o mé zkušenosti, nikoliv o stanovisko Agilie. Pokud jsou Vaše zkušenosti jiné, budu rád když se zapojíte do diskuse.
Limituje nebo prodražuje prototypování
V agilní komunitě existuje iluze o tom, že existuje zákazník, který ví, co chce. Scrum má roli Product Ownera (PO), což je člověk který zastupuje zákazníka. Moje zkušenost je, že najít PO, který je toho schopný, je mnohem větší práce než najít Scrum Mastera. Z toho vyplývá, že čím dřív reálný uživatel uvidí nějaký prototyp/mashup, tím lépe pro projekt. U větších projektů se potom vyplatí mít prototypů více a zkoušet, který vyhoví dané potřebě víc. Problém je navrhnout pro tuto činnost budget, pokud chcete dosáhnout odhadu celkové ceny na konci. Management má navíc tendenci při škrtání nákladů omezovat tento druh výdajů. V tomto ohledu považuji za nejlepší model systém kontinuální platby za iterace doplněný vstupním poplatkem do projektu.
Prodražuje projekt
Nikdy nevíte, jestli bude projekt stát 10 milionů nebo 12. Nikdo vám to nikdy neřekne. Pokud máte dobrou zkušenost v tom smyslu, že váš dodavatel vždy dodal minimálně na začátku požadovanou funkcionalitu za stanovenou cenu projektu, vážně uvažujte o změně zaměstnání. Žádný dodavatel neudělá kalkulaci ze svých nákladů a marže, všichni k tomu připočtou minimálně 20 procent. To jsou peníze, o které přijdete. Možná máte déjá-vu a říkáte si: to každý ví, proto každou nabídku stlačíme minimálně o 20 procent. Ale pozor, existuje reálná možnost, že těch dvacet procent není bonus, ale reálná nejistota při odhadu a dodavatelé, kteří nejsou navyklí na prostředí velkých firem vám mohou nabídnout hned na první pokus naprosto fér nabídku (náklady + marže + nejistota). V takovém případě se dostáváme k dalšímu bodu:
Může zastavit projekt nedokončený
Podhodnocený projekt má potom dvě základní varianty vývoje: buď jako zákazník akceptuji navýšení ceny a zachovám vizi, nebo budu trvat na ceně, což zastaví vývoj. Zde se trochu vracíme k bodu 1, pokud jako zákazník vím, co chci a mám schopného PO, tak přijdu jen o vývoj, který není pro funkčnost celku zásadní a jediné co hrozí je, že si znepřátelím ty uživatele, které v těchto případech PO zastupoval. To je však ideální případ, který je málokdy blízko skutečnosti.
Snižuje důraz na excelentní výkon
Uživatel vyžaduje excelentní řešení, řešení, které má v sobě koherentní vizi. Řešení, které pokrývá 90% jeho potřeb je špatné, on očekává, že to co budujete, bude srovnatelné s tím, co je dostupné na internetu. Četl jsem hodně článků na téma různých modifikací Paretova principu, ale přijde mi, že trend je zcela opačný: uživatele nadchnout a ohromit možnostmi systémů, které děláme. 80-20 dnes nestačí.
Takhle to zní dobře, ale sežeňte mi na to budget. Všichni víme, kolik stojí těch posledních 10%. Kontinuální vývoj a platba za skutečnou hodnotu tuto situaci zjednodušují: umožňují interní diskusi mezi tím kdo platí a tím pro koho produkt je v mnohem větší granularitě.
Co říci závěrem…
Existuje spousta řešení jak obejít některé výše zmíněné problémy. Existuje však i docela dost jiných způsobů financování, které tyto problémy od začátku neobsahují. Smyslem článku není tyto varianty popsat a rozebrat, ale zkusím načrtnout základní možnosti.
Velmi často zmiňovaný model je, že se stanoví fixní náklad, který se v případě dřívějšího dosažení cíle dělí v poměru 80/20 (tj. dodavatel dostává 20 procent ze zbytku toho, co by dostal, kdyby v projektu pokračoval až do data D). Tento způsob financování je však podle mě velmi závislý na win-win způsobu jednání obou stran a nemohu říci, že bych s ním měl pozitivní zkušenost.
V našich podmínkách lze určitě uplatnit model platby za sprint, v lepším případě ohodnocený fixní částkou na začátku nebo konci projektu. To umožňuje dodavateli pokrýt prvotní náklady a zároveň udržuje důraz na skutečnou, i pro nezúčastněného pochopitelnou hodnotu na konci období. Mírnou modifikací je potom zúčtování kvartální, které má management raději, ale pro tým znamená, že musí výsledky sprintů sumarizovat.
About author: Adam Sobotka is a member of Agilia team and Project Manager at Globus.