nav line

Agilní projekty z pohledu zákazníka

Jako zákazníka, klienta či sponzor projektu vás příliš nemusí zajímat detaily samotného vývoje projektu a techniky a nástroje jeho řízení. Zajímá vás ale určitě jak agilní přístupy ovlivňují přístup k rozpočtům a termínům. Aneb je možné mít agilně vyvíjený web integrační projekt stejně dobře pod kontrolou?

Agilní přístupy a metodiky jsou dnes ve světě vývoje software a online aplikací už známým a hojně využívaným nástrojem. Většina z nich (např. nejznámější SCRUM) byl a defakto stále je primárně metodikou samotného vývoje. Agilní přístup ale není jen o tom, jak software vyvinout. Nutně s sebou nese dopady do toho jak jej projektově řídit, jak jej rozpočtovat, zobchodovat a jakou formou jej smluvně podchytit. V případě využití agility pro vnitrofiremní vývoj (interním IT oddělením) nejsou tak zásadní, jako v případě, kdy si jako klient chcete nakontraktovat firmu, která chce agilní přístup k projektu a jeho řízení aplikovat.

Podívejme se na rozdíl oproti klasickému projektovému řízení optikou tzv. projektového trojúhelníku.

V tradičním přístupu se nejčastěji používají tzv. „fix time – fix price“ kontrakty (FTFP). Ve skutečnosti ale to, co je nejčastěji smluvně zafixováno, je „scope“, aneb funkční rozsah projektu a výsledného produktu. Čas a rozpočet tu není výsledkem reálných odhadů, ale často spíše obchodního vyjednávání obou stran a deklarací „přání“ na straně klienta vs snahy si započíst veškerá rizika na straně dodavatele.

Ve snaze funkční rozsah popsat co nejdokonaleji se řeší velmi detailní analýzy, ještě před dohodou o samotném realizačním kontraktu. Jejich výstupů se pak realizační team drží (ve snaze dodržet fixní scope) bez ohledu na změny v externích okolnostech či obchodních prioritách zákazníka. A s blížícími se termíny a vyčerpáním rozpočtovaných hodin často i s dopadem na kvalitu. Výsledné dílo pak často není v daném termínu, řeší se jednání na téma „vícepráce“ a produkt je chybový. Zákazník má „na papíře“ slíbeno FTFP, ale výsledek je často přesně opačný – čas a peníze jsou v projektu díky natvrdo zafixovanému scope ve výsledku proměnné!

Základní myšlenka agilního přístupu zde spočívá v aplikaci tzv. „reversed project triangle“. Ten říká, že na daný projekt máte prostě určitý čas (a musíte ho dodržet) a umíte investovat určitou částku peněz (a chcete ji dodržet) a chcete dodržet určitou úroveň kvality produktu (ze které neslevíte). Tyto parametry jsou tedy opravdu fixní. Jedinou proměnnou projektu je rozsah funkcí, které lze reálně v daném mantinelu času a peněz doručit, tj. funkční scope. Nakolik je v tradičních metodách požadavek na změnu (change request) nepřítelem klienta a i projekťáka, tak v agilním přístupu jsou návrhy na změny naopak velmi vítané a žádoucí – mohou totiž reflektovat změny okolností, priorit a umožňují vnášet během projektu nové nápady a vylepšení a to i ze strany realizačního teamu. Vzhledem k logice otočeného trojúhelníku to neznamená automaticky změnu termínu, ani času – znamená to jen, že se rozhodnete něco důležitějšího a přínosnějšího udělat dříve a tedy možná na úkor něčeho méně podstatného. Tato logika není lidem vůbec cizí – všichni často uvažujeme ve smyslu: mám půl roku a 2 miliony, co nejlepšího za to mohu vytvořit?

Samozřejmě ani takto pojatý projekt nemůže začít zcela bez zadání a bez nastavení oněch fixních parametrů trojúhelníka. Nevzniká ale velmi detailní dokument – naopak je snaha popsat jen základní „mantinely“ a základy projektu. Tyto tzv. „foundations“ dají základní rámec projektu z pohledu jak věcného, tak obchodního a manažerského. Z pohledu řešení pak popíší hlavní misi, obchodní přínos řešení (tedy CO chci, ale nikdy ne JAK to bude fungovat).

Zde je samozřejmě nutné si nastavit též ony limity rozpočtu a času. A tady je jedno citlivé místo tohoto přístupu. Bez detailní analýzy nelze aplikovat techniky různých bottom-up estimates. Je třeba se spolehnout na expertní odhady, na benchmarky z oboru, na analogické přístupy. A je třeba si nelhat do kapsy. Mantinely času a peněz musí být nastaveny tak, aby realisticky umožnily vytvořit alespoň základní, do provozu nasaditelné řešení (Must have). Zde je vhodné využít například techniku zvanou MoSCoW, která hi-level business požadavky třídí na:

  • Must have (musí být splněny, jinak nelze produkt „spustit“, jinak je bezcený a projekt selhal)
  • Should Have (mělo by být)
  • Could Have (někdy též „nice to have“)
  • Won’t have (v řešení nebude obsaženo a nebudeme se diskusí nad nimi už ani vteřinu zdržovat)

Nastavení projektu na začátku by mělo odpovídat cca expertnímu odhadu na realizaci „Must have“ + „Should have“. Pokud půjde realizace dobře, stihne se pravděpodobně i něco navíc. Pokud půjde hůře, je tam určitá rezerva. A samozřejmě, jak bylo uvedeno výše – priority požadavků se během projektu mohou a budou měnit!

Takto nastavený projekt už se z pohledu technického projektového řízení vede poměrně snadno. Změny ve scope a prioritě požadavků jsou vlastní samotnému agilnímu přístupu. Klíčová „manažerská“ změna spočívá případně jen v rozhodnutí o přenastavení mantinelů času a rozpočtu.

Kontrola nad projektem je u agilních přístupů defakto kontinuální. Všechny metodiky mají společné řešení projektů v určitých časových intervalech, iteracích, obecně nazývaných „time-boxing“. Po každé takové iteraci probíhá revize dosaženého výsledku a funkcí i se zadavatelem. Po každé iteraci se zhodnotí znovu priority pro tu příští a také se vyhodnotí výkonnost realizačního teamu. Už v raných fázích projektu je vidět, jak vývoj postupuje a zda lze realisticky dosáhnout výsledku. Vzhledem k tomu, že u těchto projektů se pracuje většinou ve fixně velkých teamech, je cena za každou iteraci daná dle velikosti teamu a tedy snadno predikovatelná.

Pokud se ukáže, že dané mantinely času a peněz neumožní dodat alespoň minimální funkční produkt, je to nepříjemné a patrně selhal expertní odhad – ale i tak je tato informace k dispozici mnohem dříve, než u klasických projektů! Je na zákazníkovi, zda řízení dokoupí další iterace a kapacitu, nebo např. projekt zastaví. Stejně tak se zákazník může kdykoli rozhodnout udělat posun v čase či navýšení rozpočtu proto, že chce realizovat i více volitelných či nových požadavků (nenutí ho do toho dodavatel formou vícepráce a ani jednu stranu v tom nebrzdí složitý kontrakt).

Na závěr bych zmínil dvě věci, které jsou možnou překážkou ale také nutnou podmínkou úspěšného fungování dvojice zákazník vs dodavatel v takto nastaveném duchu.

Tou první je nutná ochota zákazníka se do projektu více a intenzivněji zapojit. Zástupce zákazníka musí žít též srdečním tepem projektu, účastnit se vyhodnocení jednotlivých iterací, průběžně revidovat priority a diskutovat s realizačním teamem vylepšovací nápady. Nebude to fungovat, pokud je přístup zákazníka ve smyslu: „tady máte zadání na A4 a nechci vás vidět dříve, než v den předání díla. Jste profíci, tak očekávám bezchybný výstup! A hlavně se mě na nic už neptejte“.

Tou druhou je nastavení určitého partnerského vztahu a vztahu důvěry. Lépe se tento model aplikuje s dodavatelem, se kterým už má zákazník zkušenost. Kde věří, že umí danou věc dodat (či na ní má jasné reference) a věří nezaujatým expertním odhadům jeho konzultantů. Na druhou stranu, pokud jako zákazník nevěříte v to, že firma dílo úspěšně dodá, neměli byste s takou jít asi ani do klasického FTFP, nebo ano?

Samozřejmě existuje spoustu detailnějších metod a nástrojů a šablon na řízení projektu v agilním pojetí, ale výše byly nastíněny ty základní myšlenky a určitá změna paradigmatu. Já osobně pracuji v oblasti IT projektů na straně dodavatele téměř 15 let a „hraní si“ na neprůstřelné analýzy, smlouvy a bolestné vyjednávání změnových požadavků vycházející z nenaplněných očekávání mne už opravdu unavuje. A pozoruji tu únavu často i na straně klienta. A jak jste na tom vy? Agilně nastavený projekt v atmosféře důvěry může být nejen úspěšnější, ale i celkově příjemnější forma spolupráce pro obě strany!

PS: některé vizualizace a pojmy v tomto článku jsou vypůjčeny z www.dsdm.org. DSDM je dle mého názoru velmi zajímavý agilní framework, který na rozdíl od jiných řeší nejen vývojovou, ale i projektovou stránku věci a doporučuji se s ním seznámit i osoby ze strany zákazníků!

Ohodnoťte článek

Agilní projekty z pohledu zákazníka

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících