Jejich finančně-technologická řešení pomáhají milionům zákazníků denně zaplatit na benzínových pumpách po celém světě nebo vzdáleně monitorovat 120 tisíc pokladen nejznámějších obchodních řetězců. Česká společnost MoroSystems má s vývojem softwaru na všech úrovních velké zkušenosti a teď se je rozhodla sdílet s ostatními. Zjistila totiž, že se opakují pořád ty stejné chyby.

V brněnských kancelářích MoroSystems se vyvíjí také například nástroj, který pomáhá řídit spolupráci marketingových týmů jedné z největších e-commerce platforem světa, a technologie dodávají i do několika inovativních startupů. Po 14 letech na trhu už zkrátka v MoroSystems zažili leccos a teď chtějí, aby jejich zkušeností s vývojem a dodávkou softwaru mohli využít i další firmy.

Proto brněnská technologická společnost spustila iniciativu No Paskvil Agile, která se zabývá tím, aby v dodavatelsko-odběratelském prostředí vývoje softwaru vše fungovalo a aby se z agilního řízení projektů nestal paskvil. Firmy totiž často vyhazují peníze z okna tím, že si například nedokáží optimálně nastavit spolupráci s dodavateli nebo neumí celý projekt efektivně odřídit.

Své dlouholeté zkušenosti z praxe v e-booku Jak vyvíjet software a nevyhazovat peníze z okna sepsal Radek Petr, Head of Delivery v MoroSystems. Bezplatně si ho můžete stáhnout zde. Největší problémy při vývoji a dodávce softwaru pak přímo s Radkem Petrem rozebíráme v našem rozhovoru.

Jaká byla vaše hlavní motivace pro to, abyste se pustili do iniciativy No Paskvil Agile?
Cítíme, že ve vztahy mezi dodavateli vývoje softwaru a jejich zadavateli nefungují dobře. Nacházejí se často v nerovnováze, což zabraňuje vzniku použitelných řešení. Vypozorovali jsme řadu opakujících se vzorců, které to způsobují, a máme chuť s tím něco udělat. Týká se nás to nejen proto, že jsme sami dodavatelé řešení, ale především máme vizi, která chce udávat standard ve spolupráci mezi byznysem a IT.

V MoroSystems máte zkušenosti s vývojem softwaru na všech úrovních. Co všechno chcete předávat dál?
Ve společnostech se vyskytuje velké množství technických expertů. Je však nutno zajistit, aby fungovali efektivně v jednom týmu s byznysem. To na jedné straně umožní maximálně vytěžit jejich potenciál v podobě technologicky vyzrálého řešení a na druhé straně umožní modelovat takové byznysové očekávání, které bude skutečně plnit potřebu a řešit problém zadavatele. Pokud totiž nemáte dobrý nápad, je vysoká technická kvalita na nic. Stejně tak nejlepší byznysový nápad nemůžete stavět na technologicky vratkých základech.

Jelikož máme s řízením dodávek vývoje softwaru (neboli delivery) v byznysovém prostředí dlouholeté zkušenosti, chceme je předávat dále. Soustředíme se zejména na prostředí, kde se potkávají zadavatelé vývojových zakázek s externími dodavateli softwarových řešení, ale aplikovatelný může být tento způsob organizace delivery i v prostředí interního vývoje.

Říkáte, že firmy při vývoji softwaru často vyhazují peníze z okna. Kde vidíte ty největší problémy?
Vidíme především tři roviny: byznysovou, technickou a delivery. V případě byznysové roviny často vznikají zadání či požadavky, které neřeší danou potřebu či problém. V rámci technické roviny vznikají řešení, která jsou postavená na vodě a nedovolují naplnit potenciál byznysového záměru. Jsou často chybové, neškálovatelné či pomalé. A v rámci delivery pak není vytvořeno takové prostředí, kde se mohou výše uvedené roviny setkat a efektivně fungovat.

Bavíme se především o případech, kdy si firma na vývoj softwaru najímá externího dodavatele, nebo to platí o vývoji softwaru obecně?
Většina toho, co říkáme, se dá zobecnit. My jsme se ale zaměřili a akcentujeme více externí vývoj, protože je sám o sobě více náchylný k problémům. Má svoje dvě klíčová specifika. Jednak má nižší toleranci chyb než v případě interního vývoje, protože dodavateli zkrátka tolik neodpustíte, když za něj zaplatíte mnohem víc než za interního zaměstnance. A v potaz je třeba vzít také rozdílné kultury, přístupy, mindsety, hodnoty, které se zpravidla odhalují až v průběhu spolupráce a mohou být pro obě strany likvidující.

Začněme úplně od začátku. Kdy bych měl jít jako firma za externím dodavatelem softwaru? O jak velkých firmách se bavíme?
Bavíme se a máme zkušenost s firmami všech možných velikostí. Jak se startupy o deseti lidech a štědrým investorem na straně jedné, tak o korporátu s 10 tisíci zaměstnanci na straně druhé. Důvodů, proč nás oslovují, je více. Zpravidla se ale jedná o tři důvody:

1. Nemají dostatečnou expertízu v oblasti, kterou chtějí rozvíjet a nevyplatí se jim v této fázi budovat vlastní tým. Někteří ani budování takového týmu neplánují a spoléhají čistě na externí pomoc.
2. Nemají dostatečnou kapacitu na vývoj.
3. Spálili se při interním/externím vývoji a hledají rychlou náhradu, která jim dovolí „zachránit“ řešení. Takových případů přibývá, což jen potvrzuje nutnost se o této problematice více bavit.

Podle čeho by měly firmy dodavatele softwaru hledat a vybírat? Existuje nějaký základní recept, čím se řídit?
Neměly by se orientovat pouze podle tvrdých metrik, jakými jsou cena a termíny. Mnohem důkladněji by se měly soustředit na hmatatelné metriky. Od návštěvy kanceláří dodavatele přes setkání s referenčním klientem až po otestování spolupráce na reálných příkladech.

Všechno to sice vyžaduje více času, ten se však bohatě vrátí v průběhu spolupráce. Čím později se totiž chyba odhalí, tím hůře se napravuje. Klienti si musí uvědomit, že často startují spolupráci na několik let a chystají se utratit někdy i desítky milionů korun.

Například u veřejných zakázek ze státního sektoru víme, že se obvykle hraje především na nízkou cenu – a že to často není nejlepší řešení. Jak je to v IT? Je nutné vůbec dělat výběrové řízení?
Výběrové řízení asi ano, jen ne formou, která nutí dodavatele stanovit fixní cenu a termín zakázky na základě rozsáhlého nebo vágního zadání. Nabídky mohou být jen těžko porovnatelné. Tento princip může fungovat v jiných oborech, ale v IT z principu věci fungovat nemůže, respektive nefunguje. Přesto dnes takto stále vypadá 8 z 10 tendrů.

Na co by dle vašich zkušeností mělo být určitě pamatováno ve smlouvě?
Smlouva je náhradou za nedostatek důvěry. Čím lépe se obě strany znají, tím menší má váhu. Smlouva by v první řadě měla zajistit rovnoměrné rozložení rizika mezi obě strany. Jen tak se dá předejít taktizování a strachu. Dále by se měla více soustředit na definici vize a cíle spolupráce, než se snažit definovat neprůstřelné zadání. Nic takového, jako je dokonalá specifikace zadání při uzavření smlouvy, ve světě vývoje softwaru neexistuje.

Z vašich průzkumů vyplynulo, že velká část zadavatelů IT projektů v Česku se setkala se situací, kdy nebyli zcela spokojeni s průběhem nebo výsledkem projektu. Kde dochází k největším chybám na jedné či druhé straně?
Polovina úspěchu je zajištěna ve chvíli, kdy se obě strany naučí fungovat a organizovat jako jeden tým, tedy zanikne rozlišení na dodavatele a klienta. Nezbytným předpokladem je výše uvedené rovnoměrné rozložení rizika mezi obě strany. Ve chvíli, kdy se jedná o jeden tým, je nutné mu jasně stanovit vizi a cíle. Jinými slovy definovat co řeší za problém a proč.

Další klíčový krok je jasné stanovení rolí a jejich odpovědností. Každý musí vědět, jakou měrou přispívá k úspěchu. To vede k jasnému nastavení hranic a očekávání, vyšší angažovanosti jednotlivců a obecně budování důvěry v týmu. Na druhé straně to předchází chaosu, výčitkám a nenaplněným očekáváním. Rozdělení odpovědností se často zanedbává. Vede to přitom k situaci, kdy za určité věci není odpovědný nikdo a za některé má odpovědnost třeba více lidí současně. K odpovědnosti se pak často přihlásí jen tehdy, když se jim to hodí.

Jak do toho celého vstupuje tzv. agilní řízení, které propagujete?
Agilita přináší hodnoty a principy, které podporují vše, co jsem uváděl. Od prvního kontaktu obou stran až po vznik užitečných řešení. Tyto principy pomáhají budovat důvěru a produktivitu napříč celým životním cyklem spolupráce. Často ale lidé vnímání agility zaměňují za metodiky a frameworky, jako je scrum, kanban, safe, spotify model a podobně. Tím vzniká nejvíce problémů a zklamání, ale to je na delší povídání.

Co tedy vlastně agilita ve vašem podání je?
Agilita je v první řadě soubor hodnot a principů, které vznikly zhruba před dvaceti lety primárně pro oblast vývoje softwaru, ale jsou univerzálně uplatnitelné ve spoustě dalších oborů. Tyto principy staví na budování důvěry, kvalitě interakcí a schopnosti reagovat na změnu více než na precizním plánu a neprůstřelném zadání. V dnešní době není výjimkou agilní HR, marketing nebo leadership.

***

Pokud vás zajímá podrobnější vhled do toho, jak nastartovat vývoj a efektivně nastavit spolupráci s dodavatelem softwaru, stáhněte si e-book z iniciativy No Paskvil Agile, kde se odborníci z MoroSystems této problematice věnují.