Vývoj a implementace softwaru při digitalizaci procesů stejně tak jako uvedení nových digitálních produktů na trh jsou komplexní problémy, ke kterým se stojí za to správně postavit, aby mohla vzniknout užitečná řešení a nedocházelo při tom k plýtvání penězi, časem i lidským kapitálem. Vyvíjet software prostě není jako nakupovat rohlíky v krámě.

Realizovat software v rozsahu, který neodpovídá skutečným potřebám zbytečně prodražuje vývoj i následný rozvoj.

Požadavky v zadání neodráží skutečné potřeby

Vývoj softwaru či nových produktů je velmi drahá záležitost. Realizovat software v rozsahu, který neodpovídá skutečným potřebám zbytečně prodražuje nejen samotný vývoj, ale i jeho provoz a další úpravy a současně neumožňuje naplno čerpat benefity jeho implementace – protože neodpovídá způsobu, jakým jej uživatelé potřebují využívat.

Nefunkční taktiky, se kterými jsme se setkali

• manažer firmy či útvaru sepíše specifikaci výsledného systému podle které se bude programovat
• zadavatel požádá své zaměstnance, aby specifikovali, co by z jejich pohledu měl systém umět, pak je pošle do výroby
• velká IT řešení se vyvíjí roky – přestože původní specifikace vznikla s uživateli a pokrývá skutečné potřeby, než bude systém dokončen, budou potřeby jiné
• představa zadavatele je, že první verze systému bude obsahovat všechny potřeby v hodnotě desítek milionů korun, přestože se dá prioritizovat

Jak doporučujeme postupovat

• pojmenujte si problém, který potřebujete vyřešit
• definujte si cíle a přínosy implementace nového digitálního řešení – na úrovni zvyšujících se tržeb, snížení nákladů nebo nevynaložených nákladů;
• definujte si, jaké změny chování chcete pozorovat u zákazníků, potenciálních zákazníků či vlastních zaměstnanců – více leadů, větší hodnota košíku, atd.;
• zmapujte potřeby klíčových uživatelů, validujte je vůči cílům a přínosům projektu a hledejte řešení, která je adresují; na zbytek říkejte NE;
• vyvíjejte agilně, uveďte co nejdříve do praxe první verzi systému, sbírejte zpětnou vazbu od uživatelů; dle jejich zpětné vazby upravujte výsledné IT řešení

Vzájemná nedůvěra a netransparentnost mezi zadavateli a dodavateli

Vzájemná nedůvěra a netransparentnost mezi zadavateli a dodavateli přináší do spolupráce nevyvážený vztah, který se obě strany snaží vyřešit pomocí smluvních garancí a penále v případě jejich neplnění. Zadavatel je v nadřazeném postavení, protože drží peníze a rozhoduje o tom, jestli je vyplatí či nikoli. To nutí dodavatele taktizovat a hledat cesty, jak obstát.

Nefunkční taktiky

• specifikace pokrývající řešení v hodnotě desítek miliónů korun, jehož realizace bude trvat roky;
• smlouva o dílo obsahující garance a penále neplnění termínů;
• tvorba rezerv kryjící situace plynoucí z nejednoznačné zadání a rizika související s garancemi;

Jak doporučujeme postupovat

• smlouva o spolupráci reflektující agilní princip dodávky podporující společnou práci v týmu při hledání užitečných řešení;
• garance na úrovni dodávky jednotlivých sprintů, na úrovni stálosti týmu a jeho odbornosti, na úrovni technologické kvality, na úrovni práce s vadami;

Pozornost zaměřená na rozpočet a termín, nikoli na výsledek společného úsilí

Běžnou taktikou v nevyváženém vztahu zadavatele a objednatele pak bývá tvorba rezerv kryjící nejednoznačnost zadání a rizika plynoucí ze spolupráce. Na obou stranách působí projektoví manažeři, jejichž zadání jsou často protichůdná – projektový manažer zadavatele chce získat maximum za co nejmenší cenu, projektový manažer dodavatele pak naplnit zadání s co nejmenšími náklady. Zadavatel s dodavatelem řeší peníze, místo toho, aby se věnovali tvorbě maximálně užitečných řešení.

Nefunkční taktika

• specifikace pokrývající řešení v hodnotě desítek miliónů korun a smlouva o dílo obsahující garance a penále;
• neustále otevřené změnové řízení, vyjednávání o tom, co bylo a co nebylo v zadání, tvorba rezerv;
• projektoví manažeři na straně zadavatele i dodavatele, které si musí každá z firem platit a přitom nemusí;

Jak doporučujeme postupovat

• vytvořte společný tým se zástupců zadavatele (product owner) a dodavatele (vývojový tým), kteří společně budou usilovat o naplnění byznysových přínosů;
• nastavte agilní proces doručování výsledků a spolupracujte v týmu na hledání skutečně užitečných řešení;
• o tým se stará delivery manažer (dodavatel), jehož zodpovědností je monitorovat čerpání rozpočtu a řídit rizika. Již nejsou potřeba projektoví manažeři na jedno či druhé straně;

Nejasně nastavené role a odpovědnosti v týmu

Když lidé neví, jak mají přispívat, dochází k chybám, frustraci a nevyužívání plného potenciálu.
Uvědomujeme si, že každý projekt je jiný a dodavatelsko-odběratelské prostředí má svá specifika. Nám se při práci se zákazníky opakovaně osvědčilo následující složení realizačního týmu.

Product owner

• Definuje vizi a cíle dodávky a vyhodnocuje jejich naplnění. Prioritizuje požadavky v backlogu;
• Zajišťuje součinnosti ze strany zadavatele;

Team Leader

• Vede tým, jehož součástí mohou být vývojáři, solution architekti, testeři atd.;
• Odpovídá za doručení rozsahu a kvality, ke kterým se zavázal při plánování iterace/sprintu;

Delivery Manager

• Odpovídá za to, aby spolupráce mezi zadavatelem a dodavatelem fungovala efektivně. Nastavuje pravidla a metodiku spolupráce;
• Reportuje stav dodávky z pohledu termínů a budgetu. Řídí rizika dodávky;

Uchopení agility v rozporu s jejími základními principy

Zadavatelé vývoje softwaru bývají i dnes skeptičtí vůči agilním dodávkám softwaru. Často jsou důvodem historické zkušenosti s dodavateli, kteří agilitu předstírali. Výsledkem byl chaos, nedokončené nebo neužitečné projekty.

V MoroSystems využíváme agilní proces pro doručování užitečných IT řešení. Tento proces nám i zákazníkům umožňuje rychle začít tvořit, iterovat nad rozpracovaným dílem nikoli nad vymazlenou dokumentací, měnit priority a přizpůsobovat výsledné dílo aktuálním potřebám uživatelů i zákazníka.

Náš proces dodávky je postavený nad několika základními ceremoniemi, které nám umožňují doručovat užitečná řešení a zákazníky to s námi baví

• Sprint Planning
• Sprint Review & Demo
• Sprint Retrospective
• Backlog Refinement
• Standup

Agilita v našem případě není chaos. Agilita je mindset a současně systém, který provází vývojové týmy doručením skutečně užitečných řešení.