Prakticky celá moje dosavadní praxe byla o realizaci webových projektů. Malých i velkých. Měl jsem to štěstí, že mě na mojí cestě doprovázela celá řada lidí, kteří byli hodně inspirativní. Svým přístupem, znalostmi, volností kterou byli ochotni mi dát. Zakrátko jsem seznal, že mi vyhovuje přímý kontakt s vývojáři, řešit s nimi zamýšlené úpravy napřímo. Později jsem přišel na to, že tento přístup má jméno a já si uvědomil, že jsem vlastně velkým fanouškem agilního způsobu vývoje online aplikací.

Už jako šéfredaktor Živě.cz jsem připravoval specifikace pro funkční updaty našeho redakčního systému, pak i specifikace pro zcela nové projekty (služba pro stahování souborů – gigamania.cz). I když jsem si to tenkrát neuvědomoval, jeli jsme „agilně“. Na základě jednoduché specifikace a rukou načmáraných obrazovek vývojáři briskně vyvinuli první verzi požadovaného. My se pustili do testování a dávali další připomínky. Když jich bylo hodně, sepsali jsme je na kusy papíru a šoupali s nimi po stole. Tak vlastně vznikl náš produktový backlog.

V Atlasu to bylo podobné. Dostal jsem za úkol provést funkční upgrade jejich tehdejšího emailu. Zřídil jsem si schránku a prvních pár dní strávil zkoušením služby z pohledu zákazníka. Prošel jsem tehdy myslím jakýkoliv myslitelný use case. Byla to dobrá škola. Pro přípravu opravdu dobrého zadání je potřeba produkt do detailu poznat, protože jinak by některá z myšlenek, nápadů na inovaci, mohla být v konfliktu s částí funkcionality, která třeba není na první pohled vidět, je dostupná jen pro omezený okruh zákazníků, ale je pro ně důležitá.

Dělám agile, ale nevím o tom

I tady se mi osvědčil přímý kontakt s vývojáři. Seděli jsme u čtyř stolů, metr od sebe a z pohledu zadaného úkolu to byla ta nejlepší věc, která nás mohla potkat. Každý den jsme průběžně diskutovali problémy, na které při realizaci mého zadání přicházeli – i když jsem jeho přípravou strávil skoro měsíc, nikdy se nepodařilo domyslet úplně všechny use casy.

V té době už jsem měl představu co to znamená agile a SCRUM, i když náš přístup byl pořád takový spíše semi-agilní. Neměli jsme žádnou oficiální retrospektivu, všechno jsme si vyříkali v průběhu dne (takže i stand-up) nebo večer u piva. Neměřili jsme velocitu a grooming probíhal tak nějak víceméně nahodile.

Z pohledu agilních metodiků noční můra, ale fungovalo nám to skvěle a já si z toho odnesl jedno z hlavních poznání týkajících se agilního vývoje, které ve mě zůstává do dneška – jakákoliv metodika je jen pomocný prostředek, který pomáhá dosáhnout hlavního cíle – dodat to, co si zákazník přeje. Pokud se někdo zaměřuje na správné dělání SCRUMu nebo agilu či jiný proces a nesoustředí se na to hlavní – dodávku pro zákazníka, tak dříve či později pohoří.

Začal jsem studovat první články o SCRUMu a uvědomovat si, že to co dělám, má jméno a je to něco, co ve světě začíná být IN. Psal se rok 2007.

Po úspěšném dodání nového webmailu Atlasu jsem si krátce vyzkoušel pozici produktového ředitele. Měl jsem kolem sebe tým asi 10 lidí a měli jsme za úkol připravit novou produktovou vizi celé firmy. Bohužel, vlastníci se rozhodli firmu prodat, změnilo se vedení a s tím přišly změny, v jejichž důsledku jsem se rozhodl firmu opustit.

Mojí další zastávkou byl na krásných 6 let Vodafone. Korporace s týmem neskutečných profíků, ale taky firma zvyklá jet ve velkých kontraktech a to včetně vývoje IT systémů. Dodavatelé podpoření globálními smlouvami a přístupem, který měl byť jen k náznaku čehokoliv agilního stejně daleko jako z Prahy na Mount Everest.

Mým prvním úkolem byla příprava specifikace pro vznikající portál, který měl podpořit komunikaci mezi zákazníky Vodafonu a budování komunit mezi nimi. Pro ně jsme chystali webový portál, který umožňoval posílat SMS z webové brány do všech sítí a stejně tak číst a zobrazovat SMS a MMS zprávy ve webovém rozhraní. Nad tím měly být vystavěny komunitní funkce. Bylo to v tobě, kdy komunity u nás představoval Xchat a podobné služby. Facebook teprve začínal a když jsem se do něj v roce 2007 registroval, byl jsem cca 2000. registrovaným uživatelem z České republiky.

Agile v korporaci

Ve Vodafonu jsem záhy poznal, že vývoj aplikací může naznat zcela nový rozměr, korporátní. První bitva, kterou jsme museli svést, byla bitva o vhodného dodavatele naší aplikace. Ve firmě nebyli žádní vlastní vývojáři, vše bylo řešeno pomocí kontraktů s externími dodavateli jako IBM, Accenture a podobnými firmami operujícími na globální úrovni.

Vzpomínám, že jsme měli mít schůzku, kde nám globálně preferovaný dodavatel měl představit hlavní členy týmu. Já, jako nezkušené ucho jsem rezervoval zasedačku pro asi třicet lidí. Když jsme dorazili, zástupci protistrany tam už byli… dva. Za nás asi 4 lidé, takže zasedačka vypadala celkem prázdně a smutně. Protistrana však bleskově nastartovala video konferenci s dalšími členy týmu. Sedělo jich tam snad 40… ve velké zasedačce… v budově dodavatele… v Hyderabátu, v Indii.

Rádeš, Ramil, Jaméš, Jamil a tak dále… když se začali představovat, tak společně se sekající se video konferencí a zvukem jako z plechové trouby mě polilo horko. S tímhle týmem mám realizovat projekt, jehož konečný účet se vyšplhá na několik desítek milionů korun a do kterého budou zapojeny skoro dvě stovky lidí z různých týmů v rámci firmy i od externích dodavatelů?

Nicméně, Krzysztof Gawlik, jeden z nejlepších projektových manažerů, se kterým jsem měl možnost kdy pracovat, tehdy řekl něco ve smyslu, že z toho se neposereme a začalo se pracovat na variantě, že realizace projektu by byla vyňata z globálních IT kontraktů a byla realizována s vybraným lokálním dodavatelem, se kterým by byla možná trochu více flexibilní, agilní spolupráce.

Dodavatele máme, ještě aby dělal agile

Proběhlo výběrové řízení, které v podmínkách korporace zabralo několik měsíců. Na jeho konci jsme měli vybraného a z mezinárodního ústředí schváleného lokálního dodavatele. Jednoho z tradičních českých dodavatelů IT služeb pro telco firmy. Brzy jsem ale poznal, že lokální dodavatel není zárukou, že všechno pošlape jak jsem býval zvyklý. I lokální dodavatel byl zvyklý získat na začátku kompletní a relativně detailní specifikaci požadovaného, na jejímž základě připravil finální cenovou nabídku. Změna v dodané specifikaci? No tak dobře, ale bude to řádně zaevidovaný změnový požadavek (v původním návrhu byl dokonce požadavek na dodatek ke smlouvě ke každé změně – v podmínkách korporace záležitost minimálně na několik týdnů).

Naštěstí, na straně dodavatele byli rozumní lidé, kteří chápali, že tenhle náš projekt chceme dělat trochu jinak. Brzy jsme tak přešli na model spolupráce, kdy rámcový kontrakt určoval rozpočet, ale co jsme v rámci něco naplánovali a realizovali (a měnili) už bylo víceméně na nás. Postupem času jsme pak přešli na plně body shopový model spolupráce, kdy jsme si vývoj řídili napřímo, bez dalších extra rolí, které byly nutné v začátcích projektu.

Z práce pro Vodafone mám mnoho poznatků ohledně řízení podobných customer facing projektů ve velké firmě. I dnes, po mnoha letech, kdy korporace jsou už více otevřené agilním přístupům nejen ve vývoji, ale i v marketingu a produktovém řízení, se stále jedná o střet dvou světů, které mají jen málo společného.