Zamyšlení a možná trochu povzdech, nad aktuální převahou “Time and Material” SW dodávek, daných agilním přístupem k vývoji, nad “standardním” vývojem na zakázku za pevnou cenu (Fix Time Fix Price). A nad tím jestli to je celé ku prospěchu věci?
V rámci blogu bych se chtěl podělit o své zamyšlení nad stavem softwarového vývoje a co znamenají dodávky v Time and Material módu a proč se domnívám, že to je mód, který zabíjí vývojářské řemeslo. V článku srovnávám T&M a FTFP přístup v různých fázích životního cyklu dodávky SW a poukazuji na jejich výhody a nevýhody.
Co je Time and Material (T&M) a co Fix time Fix Price (FTFP) popsal ve svém článku na našem blogu Michal Seldmajer. Když to shrnu a většina čtenářů to bude jistě znát, tak v T&M platí zákazník dle (většinou) skutečné spotřeby za každý odpracovaný člověkoden, nebo jinou dohodnutou jednotku. U FTFP dodávek platí klient pevnou částku za dohodnutý rozsah - dodám dílo, dostanu zaplaceno.
Neexistují samozřejmě jenom tyto cenové modely, ale i další. Více informací a možná i inspiraci můžete nalézt například zde:
FTFP dodávky vedou na vodopádově řízené projekty - projektový manažer řeší klasický projektový trojimperativ: rozsah - cena - čas a s tím spojená kvalita. Byla doba, kdy jsem jinak než FTFP nedodával - prostě klient něco chtěl, bylo potřeba dle zadání připravit návrh řešení, vymezit si předpoklady, udělat odhady, připravit business case a to všechno dát do nabídky. Odesláním ke klientovi vše teprve začalo...
“Je to drahé”, povídá klient. Takže začal “descoping”, lepší ošetření rizik, revalidace odhadů… Prostě nasazování “růžových brýlí”. Zakázku vyhrál ten z konkurentů, který viděl růžově nejsilněji, nebo prostě kalkuloval s budoucí hodnotou změnových požadavků ( = Change requestů = CR = “síárek”). Nakonec se podepsala smlouva o dílo a začalo se s vývojem. Na konci byla dodávka, která často znamenala něco jiného, než se původně “myslelo”, ale bylo formálně akceptováno a fakturováno. Tím dodavatel přežil nejrizikovější část byznysu a dostal se naopak k té nejvýnosnější a to byl servis a rozvoj dodaného řešení, který ale ze své povahy je většinou T&M s větší či menší mírou fixních plateb daných konkrétní podobou SLA (Servis Level Agreement).
A toto byla realita většiny nabídek, které jsem připravoval do roku 2016.
V T&M módu jsem se naopak snažil vydefinovat nějaký základní rozsah díla - chce se mi říct MVP (Minimal Valuable Product), ale této abstrakce není (nebyla) podstatná část zákazníků schopná. Dejme tomu, že se jednalo o nějakou webovou aplikaci. Řeklo se, že zákazník dostane tým - jednoho scrum mastera, 5 vývojářů, testera, UX designera - ti budou společně pracovat 6 měsíců, což znamená při dvoutýdenním “heartbeatu”, 12 sprintů a musí dodat právě to MVP. Takto dodaná kapacita znamená 8 lidí x 20 x 6 = 960 MDs takže už poměrně zajímavý projekt. Klient platí spotřebovaný čas. Varianty kalkulací jsou i v tomto případě možné různé, od sazeb za členy týmu, přes “blended” sazby až týmové sazby a bonus/malus systémy…
Od roku 2016 jsem začal pomalu připravovat v T&M material módu více a více nabídek, až v roce 2018 jsem i velké dodávky kalkulovat čistě T&M. Člověk by řekl, že to je ideální… Ale ideální není v IT nic.
V případě FTFP dodávek jsem musel na nabídce pracovat se seniory, kteří byli schopni potřebné výstupy připravit a ošetřit možná rizika. Silnou roli hrála spolupráce celého presale týmu a všichni jsme měli strach, když zakázku vyhrajeme, abychom se do ceny vešli, protože rizika šla za námi. Na nabídce se pracovalo do poslední chvíle, protože na ní vždy bylo málo času.
Dodávka byla náročnější na využití opět seniorních lidí, protože jejich “rozředění” znamenalo větší spotřebu kapacity, ohrožení termínů a často zvýšenou nákladovou cenu. Ano, občas to co bylo nutné obětovat, byla kvalita, ale vždy v takové míře, aby to neohrozilo akceptaci. Touto obětí typicky byla dokumentace, reusabilita kódu, čistota architektonického návrhu, automatizace testování… “Byl to boj”.
T&M je proti tomu zdánlivě procházka růžovým sadem - všechna rizika na sebe bere klient, vy musíte dodat kapacitu, na senioritu není zdaleka takový tlak, měl by být větší prostor pro kvalitu - danou správným DoD (Definiton of Done). Vývojáři jsou zvyklí dnes pracovat agilně… V čem je tedy problém? Začněme popořadě srovnáním obou přístupů v jednotlivých fázích.
| FTFP | T&M |
|---|---|
Obchodní fáze | |
V rámci obchodní fáze musí mít tým, pracující na nabídce, jasnou představu CO a JAK bude dodávat. Návrh řešení musí být přizpůsoben kontextu klienta a musí jasně reflektovat známá rizika. Výraznou roli hrají odhady, které jsou z podstaty věci nepřesné a zásadně ovlivňují podobu celého business case a tím nabídkové ceny. Většina rizik je na straně dodavatele. Obchodní potenciál FTFP dodávky je v tom, že její ziskovost může být řádově vyšší, než T&M. Proč? Protože i přes přípravy detailně propracovaných business casů není prodejní cena funkcí nákladů, ale je dána trhem. Pokud dodám řešení, za které je mi klient ochoten zaplatit 10 jednotek, protože to pro něj tuto hodnotu má, a já ho umím vyrobit za jednu jednotku, tak nikdo nemůže říct půl slova. Realita je ale taková, že na trhu nejste sami… A tlak na cenu čistého vývoje je vždy enormní. Tento model je tedy vhodnější pro společnosti s jedinečným know-how a jasnou diferenciací na trhu. | CO je většinou definované velice vágně - často na úrovni kategorizace MUST HAVE, SHOULD HAVE, NICE TO HAVE a WON’T HAVE funkcionalit, epiků, business requestů - dle toho jaký je kde zvyk. JAK je (mělo by být) předjednáno a dáno aplikační stackem klienta nebo prostě aktuálním skillstem dostupného týmu. Nabízí se tedy tým o určitě kapacitě a “skillsetu” na dobu, za kterou by měl dodat určitou funkcionality - často MUST HAVE případně i SHOULD HAVE požadavky. Většina rizik je na straně odběratele. Obchodní potenciál T&M je limitován jednotkovou cenou - běžíte “krysí závod” s konkurencí - nákup klienta tlačí na jednotkové ceny (a to každý procurement umí velice dobře) a z druhé strany tlačí na nákladové ceny zaměstnanec/kontraktor - všichni máme v živé paměti, kde se pohybovaly mzdové požadavky vývojářů před COVID krizí. Výsledný tlak na marži je obrovský a odráží se do přístupu k vývoji, který popisuji níže a jediná cesta k růstu je přes objem a odbavení dodávky levnými zdroji. |
Vývojová fáze | |
Vývoj se opírá o dostatečné seniorní kapacity. Pokud ty na vývojovou fázi chybí, začne projekt silně pokulhávat - odrazí se to zejména na čase dodávky a sekundárně na kvalitě a nákladech. Klíčová je role projektového manažera (PM), který musí zajistit koordinaci všech částí vývoje a součinnost klienta, případně dalších zainteresovaných stran. Projektový manažer musí bránit změně rozsahu díla a veškeré “CR” v prvním kroku “rázně odmítnou” a potom s obchodníkem úspěšně prodat. V momentě kdy neudrží PM rozsah (scope), tak má projekt zásadní problém. Maximalizace zisku je možná pouze minimalizací nákladů, protože prodejní cena je daná. Čili po celou dobu dodávky je nutný až extrémní tlak na vnitřní efektivitu, protože každá efektivně (tj. ne taková hodina, kterou ušetříte díky šlendriánu - tu nakonec zaplatíte a troufnu si říct, že násobně) ušetřená hodina se nakonec počítá. Další možností je navýšení rozsahu, který je prodán ale s vyšší marží než základní dodávka. Rizika plynoucí ze změny složení projektového týmu jdou za dodavatelem - on si musí zvážit, jestli výměna drahého seniora za levnější zdroj se mu vyplatí. | Klient dostal kapacitu a ta začíná s vývojem… Složení členů týmu je k zahájení prací většinou dohodnuto, ale troufnu si tvrdit, že každému z vás se během projektu tým mění a seniorita nových členů je často nižší než těch odcházejících. Říká se tomu “prolevnění” nebo “rozředění”. T&M projekty jsou dodávány často pomocí Scrumu a z toho plyne, že klíčovou rolí je product owner. Ale kdo tuto roli hraje? Zástupce dodavatele? To pouze v případech, kdy je dodavatel schopen lépe definovat a prioritizovat požadavky na výsledný produkt, než zákazník (například u implementace některých balíkových řešení). Ale jinak tuto roli hraje zástupce klienta. Začíná platit jednoduchá rovnice, čím více kapacity dodám tím víc vydělám. Pokud drahé zdroje, které na zakázce pracují vyměním za levnější, tak vydělám víc (někdy to je dokonce jediná cesta, jak vůbec vydělat)! Dodavatel, tak kontroluje kvalitu týmu, klient rozsah a cena díla každým dnem roste. Hlavní motivací dodavatele je sehnat co největší kapacity a ty s marží prodávat. Na kvalitě zdaleka tak nesejde a v extrémních případech to dokonce vede k tomu, že top seniorní lidi musí skončit, protože další navýšení jejich odměny tento model neunese... Toto má dopad na celý trh, kde kvantita převládá nad kvalitou a to je něco, co zabíjí vývoj a celé řemeslo. Na druhou stranu platí, že špatné vývojářské řemeslo zabije spolehlivě i FTFP dodávku. |
Servis | |
Předání do servisu a s tím potřebné činnosti se liší klient od klienta a jsou dané zralostí jeho procesů. Jiné postupy jsou v bance a jiné u střední nebo malé společnosti. To vše je ale možné zařadit do plánu projektu a mít na to připravené kapacity. V případě kdy akceptované (a ideálně i zdokumentované) dílo jde do produkce je potřeba vyřešit jeho další provoz a rozvoj. Nastupuje SLA, maintenance, kapacita na rozvoj. Jde samozřejmě o rozsah rozvoje - ale zde se již typicky platí také podle spotřeby, pokud se nepojmenují vyšší změnové celky, které se naceňují fixně. | Požadavky na předání do servisu musí být součástí Definition of Done, jinak dochází k tomu, že je dílo prohlášeno za “hotové”, ale nechce ho do interního provozu zákazníka nikdo převzít. Případy, kdy si korporát nechal v rámci “shadow IT” krásně, rychle a agilně udělat externě aplikaci XYZ a zpátky “do baráku” to nikdo nechtěl převzít asi pár také znáte… Pokud ale jde vše tak jak má, tak samozřejmě agilita neznamená nemožnost servisu. Odpověď v podobě DevOps sice neřeší vše, ale výrazně přibližuje řízený rozvoj dodaného díla. V případě produktů, které se rozvíjejí kontinuálně stabilním týmem, jednoznačně převládají výhody tohoto přístupu. |
Porovnání je samozřejmě velice zjednodušené a opírá se o mojí ”bublinu” - svět je naštěstí různorodý a krásné je, že na různé situace mohu najít různé postupy a vybrat ten, který bude nejlépe vyhovovat. Vy sami jste určitě zažili spoustu příkladů, kde věci fungovaly úplně jinak, než jsem popsal.
Stejně si ale kladu otázky:
Jak si na takové nebo podobné otázky odpovíte vy?
Prohlášení v nadpisu je samozřejmě nadsázkou, ale moje zkušenost velí, že T&M dodávky vývoje nejsou dlouhodobou výhrou ani pro jednu stranu pokud není enormní tlak na dodanou hodnotu klientovi a kvalitu řemesla.
Tonar Jiří
