Zabijí Time and Material vývojářské řemeslo?
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.
Time and Material vs Fix Time Fix Price
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:
https://quintagroup.com/services/pricing
FTFP
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.
T&M
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.
Proč teda T&M něco zabíjí?
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.
A jaké zkušenosti máte vy?
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:
- Nechal bych si postavit dům agilně?
No nenechal. - Mám ve FTFP jistotu, že mě dílo bude stát dohodnuté peníze?
No nemám. - Umí procurementy nakupovat lépe FTFP nebo T&M?
Řekl bych, že T&M a to z prostého důvodu - jednoduchého porovnávání ceny a ignorování dostatečného posouzení kvality kapacity vývojářů. Posoudit cenu komplexního řešení v kontextu jeho kvality a dalších atributů je netriviální úloha a většina procurementů si s tím neví moc rady. - Je možné změnit motivaci dodavatele v T&M dodávce od prodat co největší kapacitu k dodat co největší hodnotu?
Věřím že ano, ale cesta k tomu je trnitá a změna bude muset přijít na obou stranách. Klient i dodavatel musí v T&M chtít více než kapacitu a musejí být obě strany ochotny na to navázat alespoň část odměny. - Pamatuji si na nějaké dobré příklady z praxe?
Ano. Většinou se vyznačují fungující “chemií” tj. ke spolupráci došlo díky vzájemnému poznání a získání důvěry. Jednalo se o menší projekty. Obě strany jsou schopny si je vzít za své - neexistuje my vs. vy, ale pouze my společně. Lidi na obou stranách moc chtěli dodat a profesně na to měli. - Nesrovnávám jablka s hruškami?
Trochu srovnávám. Při jasné definici produktu a jeho dlouhodobém rozvoji nijak nezpochybňuji agilní přístup jako vhodnější. Ale “produktem” není všechno a jsou stále oblasti, kdy je potřeba doručit konkrétní rozsah v čase a tam má standardní projektové řízení a FTFP dodávka stále své místo.
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.
