Fixní kontrakt a vývoj? Recept na selhání

Někdy se stane, že projekt selže. A to navzdory všemu možnému, co pro jeho úspěch děláme – včetně aplikování toho nejlepšího z osvědčených postupů. Ať už jste dodavatel nebo zákazník, takzvané fixní (fixed price) kontrakty nejspíše udělají z vašeho vysněného projektu noční můru.

Zdroj napětí

Zákazník potřebuje fungující a kvalitní produkt nebo službu. Dodavatel chce takový vyvinout. Ale ve většině případů se to nepovede. A je v podstatě jedno o jaké odvětví se jedná.

Tvoříte pro klienta novou marketingovou strategii? Vyvíjíte nové senzory pro měření stavu počasí? Nebo software? Zbystřete – váš projekt má statisticky velmi malou šanci na úspěch.

Samozřejmě existuje mnoho faktorů, které přispívají k selhání, ale jednou z hlavních příčin bývá kontrakt – formální spojení mezi zákazníkem a dodavatelem. S kontraktem vše začíná a také obvykle končí. Protože v případě problémů je to právě kontrakt, co nakonec rozhoduje. Podívejme se, jaká rizika typické fixní kontrakty přinášejí a jak se jim vyhnout.

Většina softwarových projektů selže

Podívejme se v detailu na vývoj software, protože tam všechny nevýhody a rizika dobře vynikají. Pravděpodobnost úspěchu softwarového projektu je asi jen 37 % [Standish Group - Chaos report 2010, 2012, 2014]. To je docela alarmující, navíc se to s léty nijak nelepší.

Znamená to, že by lidé v IT byli hloupí nebo neschopní? Ne, problémem je, že pro budování software používáme nevhodné modely spolupráce a postupy. Většina zákazníků totiž přistupuje k vývoji software na zakázku stejně jako k nákupu produktů (automobilu, telefonu, počítače, domu).

Pravdou je, že tyto dva případy nejsou stejné. Podívejme se proč.

Jak vidíte na obrázku výše, šance na opakovatelnost úspěchu a opětovné využití znalostí v případě návrhu unikátního software na zakázku je mnohem nižší než v případě výroby např. automobilu.

Použití stejného přístupu bychom mohli přirovnat k realizaci programu Apollo (člověk na Měsíci), plného nezbytného výzkumu a vývoje nových technologií, pomocí tzv. vodopádového modelu – popsat do detailu cíl, navrhnout najednou celé řešení, postavit napoprvé funkční raketu s příslušenstvím a v předem daném datu odpálit posádku k měsíci.

Jsem přesvědčen, že by se jednalo o jednu velikou katastrofu. Byla to až 11. mise Apollo, která nakonec přistála na měsíci. A představte si kolik miliónu cyklů pokus–omyl bylo třeba provést se všemi prototypy a podsystémy před tím, než bylo vůbec možné uspět.

Úspěch v těchto kreativních/inovativních oborech, kam vývoj software nepochybně patří, vyžaduje četné krátké cykly učení. Jen tak je možné vytvořit něco tak složitého, jako je software naplňující neurčité potřeby zákazníka. Problémem je, že k takovým projektům přistupujeme s domněnkou, že jsou předvídatelné. Snažíme se vše zafixovat do kontraktu v okamžiku, kdy vlastně o celém projektu a problému, který řeší, víme nejméně. Kdy ještě neznáme kritické informace, které vyplynou až v průběhu realizace…

Dům snů

Pokud jste někdy stáli na straně zákazníka, určitě víte, jak těžké je definovat požadavky.

Kde začít? Jak celý problém uchopit? Často se stává, že ty nejdůležitější požadavky dokonce chybí.

Když se zeptám lidí na našich workshopech: „Představte si svůj dům snů… Všechno je možné… Jaký by byl?“ Obvykle dostanu odpověď jako že bude mít bazén, velikou televizi, obří obývák, sám se bude uklízet atd. Ale nikdo obvykle neřekne že bude mít okna, dveře, zdi a střechu. Proč? Protože to je „jasné“. Každý dům je přece má. Každý architekt by to měl vědět, ne? A teď si představte zákazníka odmítajícího převzít software, protože je jasné, že každý bankovní systém řeší i pravidelné posílání měsíčních výpisů z účtu, které samozřejmě ani nebylo součástí požadavků. Analytik to přeci měl vědět…

Mary měla malé jehňátko

A to není všechno. I kdybychom byli schopni všechny požadavky popsat, stále bude obtížné je přesně pochopit. Znáte říkanku „Mary měla malé jehňátko“? (Mary had a little lamb) Pokud ji vytrhneme z kontextu – stejně jako to děláme s požadavky – co ta věta znamená? Jak jí rozumíte?

• Starala se Mary o svého mazlíčka jehňátko?
• Nebo snědla malé jehně?
• Nebo snědla malou porci velkého jehněte?
• Porodila jehně?
• Měla s ním intimní poměr?
• Napálila nějakého naivu, aniž by za to nesla následky? (z hantýrky burzovních makléřů)
• ...

Jak vidíte, jediná věta v požadavcích může být interpretována mnoha různými způsoby. Dokonce takovými, které by nikdo ani nehádal – třeba ten s tím naivou. A teď si představte tisíce vět ve specifikaci požadavků, z nichž každá podléhá tomuto takzvanému Mary had a little lamb syndromu. Vidí čtenář požadavků budoucí software stejně jako ten, kdo tuto specifikaci píše?

Proč tedy uzavíráme fixní kontrakty?

Takže pokud…

• se potřebujeme adaptovat na měnící se požadavky po celou dobu projektu
• nedokážeme předem definovat všechny detailní požadavky
• nedokážeme jim jednoznačně rozumět
• a tím pádem ani odhadnout jejich pracnost

…proč tedy tyto fixní kontrakty stále používáme a snažíme se vše odhadnout a zafixovat předem? Obsah projektu, čas doručení a cenu? Předpokládám, že tomu tak je, protože lidé podepisující tyto kontrakty si neuvědomují specifika vývojových projektů nebo prostě neví o žádné rozumnější alternativě. Ale takový omezující kontrakt mívá velmi negativní důsledky.

Představte si sami sebe jako dodavatele svázaného kontraktem, který penalizuje jakékoliv porušení některého z rohů pomyslného trojúhelníku: požadavky – datum doručení – cena.

Představte si, že se objeví nějaká komplikace (což se velmi pravděpodobně stane) a vy musíte volit mezi tím, zda zariskujete a doručíte to, co zákazník opravdu potřebuje, anebo budete hrát bezpečně a doručíte to, co je doslovně napsáno v kontraktu. Co uděláte?

Většina lidí volí „bezpečnou“ variantu a doručí to, co je kontraktováno. A pak je to tady – prohra na obou stranách. Zákazník nedostane to, co pro svůj byznys skutečně potřebuje a dodavatel je za to obviňován. Přepracování produktu a oprava chyb pak násobí cenu celého řešení.

Nedokážeme předvídat budoucnost (nevíme, co nevíme) a v ní a v implementačních detailech jsou ukryta ta nejhorší překvapení. Jako například změny potřeb zákazníka, technické problémy a neplatné předpoklady. Nejvíce překvapení zažijeme, když jsou odhady pracnosti a kontrakt vynuceny velmi brzy, kdy nemáme příliš mnoho informací.

Ze zkušenosti také víme, že tato omezení vyplývající z kontraktu vytvářejí bariéru mezi zákazníkem a dodavatelem, která jim pak brání v aplikování praktiky, která by mohla celou situaci zlepšit – tzv. trvalého zlepšování (continuous improvement). Bariéry prodlužují nebo znemožňují nezbytné cykly učení.

Agile/Lean kontrakt

Co bychom tedy měli udělat? Jednoduše řečeno: „Nedávat do kontraktu detailní popis výsledného produktu, ale raději se v něm zaměřit na to, jak mají dodavatel a zákazník spolupracovat, aby dosáhli společně nejlepšího možného výsledku.“

Zdá se to být kacířská myšlenka, protože selský rozum říká: „Pokud jsme tentokrát nedostali, co jsme chtěli, musíme být příště mnohem více striktnější a definovat vše ještě detailněji.“ To ale, jak jsme si řekli dříve, neřeší příčinu a situaci v konečném důsledku ještě zhorší.

Co by tedy mělo být napsáno v takovém kontraktu? Určitě popis postupu/procesu, jakým způsobem dodavatel společně se zákazníkem vytvoří nejlepší možný výsledek. Vložíme tam osvědčené postupy a praktiky, které empiricky fungují. Co to znamená? Krátce řečeno, kontrakt by měl obsahovat následující:

• Postup/proces tvorby software založený na učících se cyklech (iteracích) a jednotlivé fáze projektu
  • Příprava projektu – vize, byznys cíle, hlavní akceptační kritéria, vysokoúrovňové testy, které musí projít, aby řešení pomáhalo byznysu
  • Tvorba řešení – iterace a jejich akceptace
  • Doručení řešení – termíny a finální akceptace
• Odpovědnosti dodavatele
  • Spolupracovat se zákazníkem na tvorbě požadavků, pomoci mu definovat je z pohledu uživatele, ne systému
  • Před každou iterací se zavázat k tvorbě jejího obsahu a mít připravený funkční výsledek pro následnou demonstraci funkcionality na jejím konci
• Odpovědnosti zákazníka, kdy musí být přítomen nebo k dispozici a na jak dlouho
  • Pomoci připravit detaily k požadavkům před začátkem iterace
  • Být k dispozici k otázkám vývojářů během iterace
  • Účastnit se dema, být na něm schopen akceptovat/odmítnout předváděnou a dohodnutou funkcionalitu
• Učící se cykly
  • Kdy a jak proběhnou společné retrospektivy, aby se předcházelo problémům a spolupráce se neustále zlepšovala
  • V případě, že iterace selže, nebo zákazník není spokojen s výstupem, je automaticky provedena zvláštní společná retrospektiva a jsou přijata opatření, aby se situace neopakovala
• Důsledky porušení dohodnutého způsobu spolupráce
  • Zákazník se nedostaví na demo? Všechna funkcionalita je automaticky akceptována, každá další změna je řešena jako nový požadavek.
  • Objevily se chyby? Musí být opraveny dodavatelem v následující iteraci.
• Obchodní model
  • Na základě čeho se počítá cena?
    • rezervovaná kapacita?
    • cena za iteraci?
    • za požadavek?
    • za jeden StoryPoint?
    • ...
• Bonusy a pokuty
• …

Jak je vidět, takový kontrakt je vždy unikátní, protože odráží konkrétní možnosti a omezení obou partnerů. Takže jeden vzor kontraktu určitě nebude sedět na všechny projekty. Ale jsou zde části, které se obvykle dají znovu použít. Tak jako tak, práce věnována takovému kontraktu se později mnohonásobně vrátí.

Nám se povedlo dostat několik takovýchto kontraktů do praxe s různými zákazníky naších klientů. A podle výsledků a zpětné vazby tento přístup opravdu funguje.

— Tomáš Tureček, Lean&Agile Coach, Consultant and Owner at RainFellows