Také už se vám někdy stalo, že jste museli odložit svoji dovolenou, protože se ve firmě chystala velká změna? Dlouho se o tom mluvilo, dělal na tom snad každý a když nastal onen den D, tak to neproběhlo úplně hladce a ještě dlouho po tom bylo potřeba řešit důsledky?
Jedním z vedlejších jevů procesního řízení firmy dle obvyklých metodik #itil, #prince či #safe bývá ve správě firemního IT použití takzvaných releasů. Určí se hlavní transformační téma, vznikne projekt, provede se celá řada analýz (proveditelnosti, dopadu, nákladů, rizik, …), sežene se rozpočet a roztočí se kolesa změny. Ne zřídka takové „projekty
“ trvají déle než půl roku, využijí kapacity téměř celé společnosti, jejich komplexita má dopad na významnou část firemní infrastruktury a pokud se vůbec podaří realizovat, vyvstane množství návazné práce kterou analýza opomenula.
Dopad takového přístupu je i personální, neb vyžaduje množství doprovodných rolí: projektové, riskové, změnové a releasové managery, analytiky, procesní specialisty, testery a další. V momentě nasazení změny a nějaký čas po ní je lidem logicky znemožněno si vzít dovolenou, neb se musí všichni podílet na výsledku. Často se stává, že na poslední chvíli testeři objeví nedostatek který odsune termín nasazení a s ním se musí upravit harmonogram všech zúčastněných. Mnohdy se takové posunutí termínu opakuje vícekrát a má tak až fatální dopad prakticky na celou společnost.
U větších společností běží v jednu chvíli několik projektů, které se v určitou chvíli stanou na sobě vzájemně závislé a je tak potřeba řešit takzvané tranche, neboli souběžný release několika projektů.
Paradoxně tak snaha o přehled, kontrolu a snížení rizika vede k jeho vzniku.
Téměř protipólem jsou #agile techniky #continuousDelivery, #continuousIntegration a #continuousDevelopment které se snaží výsledný transformační projekt rozdělit na menší a hlavně samostatně nasaditelné části. Využívá se prvku feature flagů, které umožňují nasadit, aniž by to bylo veřejně k dispozici. A když nastane potřeba zveřejnění, jen se změní hodnota proměnné a je zveřejněno. Takový přístup umožňuje navíc techniku #canaryDeployment, kdy má příslušný feature flag jinou hodnotu například pro některé interní zaměstnance. Ti mohou prakticky za provozu ověřovat funkčnost a jiné vlastnosti, zatímco ostatní fungují postaru. Jelikož se navíc jedná o pravidelné a opakované procesy, vyplatí se je automatizovat, čímž se opět snižuje výsledný náklad a míra rizika.
A když se změna nepovede? Tak se ta drobná změna vrátí a dopad je ve srovnání s releasem nebo tranchí výrazně menší. A když má někdo důležitý dovolenou? Je to drobná změna, kterou lze snadno někomu v zástupu vysvětlit, ukázat, otestovat a při nejhorším týden nebo dva počká.
Některé moderní velké společnosti nasazují i několikrát denně. A co ta vaše? Ještě stále hrozí že se bude dovolená odkládat, nebo už využíváte techniku pravidelného růstu?