Brněnská IT firma MoroSystems před dvěma roky spustila kampaň „No Paskvil Agile“. Jde o osvětu, která má upozornit na úskalí tradičních metod vývoje IT řešení, na výhody metody Agile – a také na podmínky, za nichž je agilní vývoj opravdu výhodnější. „Kampaní jsme reagovali na problém, že ajťáci na straně zákazníků sice typicky agile znají a chtěli by tak s dodavatelem pracovat – ale vedení firem, jejich procurement a právníci mají nacvičené tradiční metody a je pro ně těžké se od toho oprostit,“ vysvětluje Tomáš Páral, CEO společnosti MoroSystems.
Neochota opustit tradiční metody vývoje IT řešení je pochopitelná, protože smlouvy na takové dodávky bývají rozpracované do velkých detailů a dávají tak pocit, že je zadavatel pojištěn proti nekvalitnímu vývoji. Přesně určují, co má dodavatel udělat a kolik to bude stát – tak proč to opouštět?
Důvod pro změnu je už jenom alarmující podíl projektů, které končí fiaskem. A pozor: právě kvůli tomu perfektně jasnému zadání ty projekty pokračují, dokud opravdu nenarazí do zdi. V dnešní dynamické době, kdy se inovační cykly měří v týdnech spíš než v letech, je u každého projektu jasné, že podmínky se budou v jeho průběhu měnit. Všichni ty změny vidí – ale nemají, jak na ně zareagovat. Podle smlouvy prostě nemohou.
Naproti tomu agilní metody vývoje se změnami počítají. Stojí na principu „domluvme se na cíli, který chceme dosáhnout a na zdrojích, které jsou k dispozici – a budeme dělat všechno pro to, abychom se k tomu cíli přiblížili do nejvíc“.
Přestože ajťáci na straně zákazníka vědí, že na tomto principu dosáhnou víc, než když dodavatele sešněrují nerealistickými požadavky, pro vedení jejich firem je takzvaný agilní kontrakt těžko stravitelná novinka. Přesto se ledy pohnuly. Podle Tomáše Párala jsou nyní dvě třetiny poptávek od zákazníků na agilní vývoj. „Ale to není obrázek celého trhu. My se profilujeme jako zastánci agilního vývoje, tak je logické, že se na nás obracejí zájemci o agilní vývoj,“ upozorňuje Páral.
Ty dvě třetiny zákazníků, co chtějí agilní vývoj: započítáváte i klienty, kteří rovnou vyžadují agilní kontrakt, nebo i ty, které v průběhu jednání teprve přesvědčíte?
Jsou to skutečné požadavky na agilní vývoj, se vším všudy. Takže pokud se domluvíme, neztroskotá to na tom, že by zákazník nebyl ochoten uzavřít odpovídající smlouvu. Mimochodem, takovou partyzánskou akci jsme v minulosti zažili: nevěděli jsme, že se náš partner na straně zákazníka vůči nadřízeným tvářil, že spolupracujeme v tradičním režimu s přesně definovaným výsledkem. On to myslel dobře, ale jeho partyzánská akce dobře nedopadla – pro něho, ani pro nás. A byl by zázrak, kdyby to dobře dopadlo. Ono totiž, agilní vývoj není vylepšení tradičního vývoje, je to vylepšení způsobu spolupráce. Neznamená to automaticky, že bychom dosáhli téhož výsledku rychleji a levněji. Znamená to, že správným nastavením spolupráce řádově zvyšujeme šanci na kvalitní a užitečný software, který bude plnit potřeby jeho uživatelů.
Pro nás zmiňovaná zakázka znamenala velké ponaučení. Od té doby trváme na tom, že klíčové milníky prezentujeme nadřízeným těch, s nimiž bezprostředně spolupracujeme.
Dvě třetiny zákazníků se asi dá hodnotit jako velký úspěch vaší osvěty, ne? Přece jenom, kdyby viděl agilní kontrakt manažer – neřkuli právník – který neví, o co jde, tak by asi omdlel…
Ano, já to považuji za úspěch. Bohužel, ty dvě třetiny se týkají poptávek, co přijdou k nám. Do typické firmy našeho zaměření to podle mého odhadu zdaleka nebude ani třetina.
On je to totiž opravdu kulturní šok. Je potřeba silný impuls, aby se ve firmách těch zdánlivých jistot tradičních kontraktů vzdali. Všude jinde totiž fungují: přesně tohle mi dodáš a já ti tolik a tolik zaplatím… Pochopit, že ve vývoji IT řešení to takhle nejde dělat, není snadné. Mimochodem, předpokladem k tomu je pochopit význam IT pro firmu a její byznys – vývoj softwaru je investice a o investici je třeba se pravidelně starat. Kde mají IT čistě jako nákladovou položku, tam žádný agilní vývoj nemá šanci projít.
Pro zajímavost: co ta třetina poptávek na tradiční vývoj?
Nabídneme agilní vývoj. Samozřejmě, že ne automaticky – jenom tam, kde bychom tu práci rádi dělali. Třeba z důvodu používaných technologií, nebo je to vertikála, kde máme zkušenosti. To pak zdůvodníme, proč je agile přístup lepší a nabídneme pilotní miniprojekt, kde bychom jeho výhody demonstrovali.
Jakou máte s těmito nabídkami úspěšnost?
Zatím jsme takto uspěli jenom dvakrát. Ale v obou případech po těch pilotech skutečně následovala celá zakázka, toho si vážím.
A co když poptávky na tradiční vývoj dávaly smysl? Opravdu je agile přístup nejlepší, bez ohledu na cokoli?
Nedávaly smysl. Ne, že by agile byla nějaká modla. I my děláme na základě fixních objednávek – ale jenom v případech, kde známe prostředí a víme, že není, co by nás překvapilo. Okolo vývoje nových řešení ale máte většinou tolik nejistot, že agile je jediná rozumná možnost. A nejen pro nás, nebo z pohledu nějaké imaginární správnosti. Je to opravdu lepší i pro zákazníka.
Máte k tomu nějaký příklad?
Představte si, že v projektu se objeví nečekaná komplikace. Něco v infrastruktuře zákazníka, co nikdo nevěděl, že bude problém, nebo změna v regulatorních podmínkách. Co uděláme v rámci agile? No přece sedneme si se zákazníkem a budeme hledat, jak to co nejlépe vyřešit. Jak se i v nových podmínkách dostat co nejblíž cíli, který jsme si stanovili.
A co udělá dodavatel v rámci tradičního přístupu?
Vytáhne smlouvu, kde bude malým písmem nějaký disclaimer, podle kterého je to překážka v plnění. Takže zákazník má problém a až ho vyřeší, práce mohou pokračovat. A pozor: budou pokračovat podle smlouvy – ale ta nepočítala ani s tou překážkou, ani se změnami, které odstranění té překážky způsobilo.
Nebo smlouvu změní. Fajn, ale už na začátku přece bylo jasné, že se bude narážet na komplikace, na nutnost za pochodu měnit zadání. Každý, kdo dělá IT projekty, takových změn zažil desítky, tisíce… A naopak, nikdy nezažil projekt vývoje IT řešení, kde by žádná velká změna nebyla. Tak proč uzavírat smlouvu, která se změnami nepočítá?
Řekněme, že si tohle přečte manažer a řekne si, že na tom agile přístupu možná fakt něco bude. Co má podle Vás udělat?
Určitě by měl začít u svého CIO a dalších lidí ve svém IT. Ti určitě o agile vědí a nejspíš tuto metodiku u interních projektů aplikují. A určitě pro ně bude vysvobození, když budou moci, ze začátku aspoň v nějakém pilotním projektu, na agile přístup přejít i u spolupráce s externími dodavateli.
PŘEČTĚTE SI: Startupový svět ani v čase útlumu není monolit: Kterým sektorům se daří, a které úpí?
