15.12.2018

Ať jsme všichni Spotify 2! Neviditelná technologická otázka

Agilní transformace není všelék pro jakoukoliv firmu řešící (všechny) její problémy. Naopak je možné, že taková transformace jen odstartuje odchody klíčových lidí, kterým agilita nesedí a jsou zvyklí fungovat jinak nebo zhorší již existující problémy firmy, protože agilita problémy odkrývá. Pokud je však agilita blízká kultuře a hodnotám vaší organizace, zvykům a nepsaným pravidlům uvnitř firmy a manažerskému stylufirmy (téma bylo otevřeno v prvním dílu), je zde ještě jedno téma, které vaši případnou transformaci významně ovlivní.

Tímto tématem jsou existující omezení vašich IT systémů, včetně kapacit klíčových IT expertů. Je důležité, aby tomuto tématu rozuměl management, protože mu to pomůže pochopit možné obtíže a také skepticismus některých lidí, kteří o problému dávno ví a snaží se na něj upozornit.

Pokud jste tedy manažersky a kulturně připraveni na významnou změnu toho, jak nyní pracujete, plánujete, řídíte projekty, počítáte jako manažeři s další ztrátou moci a kontroly (protože ji dále předáváte end-to-end týmům), s výkyvy produktivity během transformace, možným odchodem klíčových lidí a berete transformaci jako investici (ne jako cost-cutting nákladovou akci, co ušetří peníze), pořád ještě vás může zabrzdit historie vašich IT systémů a s nimi spojená obslužná práce.

Mladé firmy používají moderní IT technologie a principy vývoje softwaru

Uvážíme-li kontext Spotify, uvědomíme si, že je to mladá firma založená roku 2006. Jako mladá firma měla tedy od startu k dispozici moderní technologie, programovací jazyky a principy vývoje softwaru jako je na služby orientovaná architektura s minimem závislostí, cloudová infrastruktura a nástroje, DevOps principy a podpůrné nástroje, configuration management a automatizované testování, AJAX-based technologie, NoSQL databáze, technologie umožňující časté sestavování a releasování za provozu atd.

Mladé firmy za sebou nemají historické technologické břemeno jako telco firmy, banky, pojišťovny, státní instituce, které mají klidně i desítky let staré monolitické core systémy, monolitické aplikace a hodně „zadrátovanou“ architekturu. O zvycích vývojářů, které doprovází tyto technologie ani nemluvě.

Faktor úspěchu 1: minimální technologické závislosti mezi týmy

Organizace týmů podle value-streamů (ony známé squady) tedy hodně závisí na tom, co vám umožní vaše technologické prostředí a jeho závislosti. Cílem je mít tzv. loosely-coupled mikro systémy, kdy se snažíme minimalizovat závislosti mezi nimi a definovat jasná rozhraní, která umožní jednoduchý přístup jiným systémům. Proto je nutné mít nejdříve end-to-end systémy, aby mohly vzniknout opravdu fungující end-to-end týmy nad nimi.

S tímto krokem jsou spojené také omezené technologické dovednosti a kapacity klíčových lidí. Například jediný technologický guru, na kterém stojí klíčový zastaralý systém, který využívá více value streamů, nemůže být zároveň v x týmech. Takovou dovednost musíte ostatním dodávat jako službu nebo předat základní dovednosti do týmů a experta nechat dělat jen těžší věci opět jako službu pro více týmů. V tomto sdíleném modelu, kdy si end-to-end týmy udělají základní změny samy a expert řeší všem týmům jen architekturu a složitější zásahy, zase musíte vyřešit vlastnictví kódu, akceptaci změn, paralelní práci nad stejným kódem a řešení konfliktů v kódu, protože to starší technologie může hůře podporovat.

Faktor úspěchu 2: vhodná startovní architektura nebo nutný technologický zásah

Málo se ví, že jak Spotify, tak ING udělalo nejdříve architektonicko-technologické „čistící“ změny a projekty, které architekturu původních propojených systémů překopaly do minimálně provázané formy s modernějšími prvky architektur a technologií. Dále pak technologicky a organizačně umožnili časté sestavování a nasazování kódu do produkce.

Spotify konkrétně rozřezalo svoji původní monolitickou aplikaci do mikrosystémů (klientských aplikací) běžících v prohlížeči, aby se jednotlivé týmy navzájem neovlivňovaly, nekolidovaly svými změnami a mohly nezávisle a často releasovat.

Ředitelství ING Netherlands začalo tím, že integrovalo týmy produktového vývoje a IT Operations dohromady se zaměřením na DevOps kulturu a rychlou zpětnou vazbu při sestavování a nasazování řešení. Paralelně s tím ING začalo uskutečňovat projekty modularizace původní architektury a postupné automatizace sestavování a nasazování. Paradoxně to bylo díky tomu, že si board, tedy nejvyšší vedení, uvědomil, že už nejsou ani tak firmou poskytující finanční služby, ale spíše technologickou firmou pohybující se ve finančním byznysu. Proto se rozhodli začít jako technologická firma fungovat. A jsme opět u nejvyšších míst a kultury a fungování firmy, tedy tématu diskutovaném v prvním díle.

Tento projekt obě firmy stál nějaký čas a peníze, ale o této části se už moc nemluví, kopírují se jen squady, kmeny a value-stream orientace týmů. Přitom stav technologického pozadí a systémů je jádrem úspěchu, aby mohla hladce fungovat ta organizačně-procesní stránka agility.

Málo se ví, že jak Spotify, tak ING udělali nejdříve technologické změny, kterými překopali původní IT systémy do minimálně provázané formy a umožnili automatizované časté nasazení do produkce. Toto úsilí je stálo čas a peníze, ale o této části se už moc nemluví. Přitom to je základ úspěchu, aby mohly fungovat end-to-end value stream týmy.

Rozjeďte proto nutnou diskuzi, do které zahrňte hlavně architekty a klíčové IT experty (zvláště ty brblající, určitě k tomu mají důvod) a řešte s nimi následující:

  • které IT systémy a vazby jsou nejproblematičtější?
  • kde nejdéle čekáme na kapacity nebo máme hodně chyb a problémů?
  • kterých systémů je lepší se zbavit (drahá údržba, končící licence, omezené kapacity lidí nebo možnosti systému)?
  • kde máme duplikované funkce (a věřte že těch bude!) a kde je lepší je mít?
  • co nás brzdí v častější (automatizované) integraci, sestavení, testování a nasazení?
  • jak tento problém vyřešit a automatizovat?

Často takové kroky mohou znamenat reorganizaci týmů, nutný nákup technologie nebo i ukončení poskytování nějaké byznys služby, zrušení feature v produktu nebo ukončení existence celého systému, protože jejich provoz stojí o dost víc, než přinesou na zisku nebo jiných příležitostech (není to door-opener nebo jádro freemium business modelu). A tady se připravte, že byznys může hodně křičet, protože pro ně to může být ten „nejdůležitější systém na světě“, i když stejnou funkci dělá i nový systém, jen trochu jinak a oni jsou přece zvyklí zmáčknou pětkrát F3 a pak dát Enter. To je nadsázka, ale chci tím ukázal časté iracionální chování spojené s tímto tématem. Nebo se byznys nebude chtít bavit vůbec a jakoukoliv diskuzi ukončí slovy „prostě to tak bude“. Pak ale IT není pro byznys partnerem a nebavíme se zde o agilitě.

Faktor 3: existující produktové a IT strategie a jejich vzájemný dialog

Popsaná inventura smysluplnosti produktových funkcí a IT systémů je základní funkce produktového a IT managementu a jejich neustálých diskusí a slaďování. Nejedná se o jednorázovou akci, ale neustálý dialog, který musí pokračovat, jak se mění a upravuje samotná firma. Obě strategie (jak produktová, tak IT) totiž vychází z cílů a strategie firmy a podporují její naplnění.

Výsledná produktová a IT strategie je tedy jakási domluva mezi tím, co by chtěl ideálně byznys mít, co umožňují aktuální technologie a co umí firma a její lidé (dovednosti). No a současný stav vaší IT architektury a systémůbude základem úspěchu agilní transformace. Tedy pokud jste po manažerské a kulturní stránce kompatibilní a připraveni.

Faktor úspěchu 4: Inženýrská kultura

Toto vše zní pěkně na papíře, ale v praxi je to někdy náročné realizovat. Proč? IT je totiž v mnoha firmách typicky nákladovou složkou, která je brána jako nutnost a černá díra konzumující peníze. Často bývá IT také zařazeno v organizaci pod CFO. Někdy dokonce ani nemá zástupce v boardu. Jak může být IT v takové roli rovnocenným partnerem a spolu udávat směr transformace a prodat potřebu úpravy architektury, který nic přímo nevydělá a navíc stojí peníze a nějakou dobu trvá?

Agilní transformace jsou úspěšné zvláště u technologických firem jako je například zmíněné Spotify proto, že tyto firmy mají inženýrsko-produktovou kulturu a v jejím vedení jsou často inženýři-zakladatelé. Tito lidé chápou technologie, nebojí se jich a nevidí je jako nutné zlo, ale naopak prostředek umožňující změnu. Ve firmě je také většina inženýrů, kteří se věnují vývoji, takže je pro vedení snadnější takové změny uvnitř firmy prodat. Produktové a byznysové role, které vládnou v bankách či pojišťovnách jsou zde v menšině. Proto je důležitost architektury systémů a IT strategie na stejné úrovni jako ta produktová.

Jak bylo zmíněno výše, u ING bylo právě uvědomění boardu, že jsou vlastně technologickou firmou ve finančním byznysu, jedním z prvních kroků úspěšné změny.

Máte k tomu co říct?

Jeden komentář: “Ať jsme všichni Spotify 2! Neviditelná technologická otázka”

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *