Co má společného voják blátošlap s vývojářem lopatou

Co má společného voják blátošlap s vývojářem lopatou, velitel čety s vaším managerem a generál Obětujeme levé křídlo s krizovým manažerem? Rád se zaobírám četbou moderního vojenství a válčení a přestože by se mohlo na první pohled zdát, že to je obor a disciplína na hony vzdálená softwarovému inženýrství, opak je pravdou. Válčení či válečné umění je vnímáno jako cosi barbarského, ačkoliv bráno do důsledku, se svými principy a zákonitostmi se tolik neliší od softwarového vývoje. Ostatně válečná tažení nebo kampaně mají mnohdy podobné metriky a jsou řízeny a hlavně plánovány podobně jako mnoho softwarových projektů. V mé knihovně se za ta léta nashromáždila celá řada titulů popisující všechna bojiště novodobé historie od Severní Afriky, přes ruskou step až po džungli jihovýchodní Asie. V mnoha případech by stačilo jenom trochu pozměnit reálie a použít místo voják vývojář, místo tažení projekt, místo manažer velitel, a měli bychom příběhy jako vystřižené z našeho oboru. Naštěstí nikoliv s fatálními důsledky pro nás samotné.

Vojenství je řemeslo

Jestliže se celé průmyslové odvětví informačních technologií vyvíjí s přimhouřením oka posledních pár desítek let, vojenství je na tom s tím vývojem o dva tisíce let, plus nějaké to staletí, napřed. Vojenství se muselo vyvíjet a reagovat na různé podněty, změny ve vědě a pokroku počínaje a politickými vrtochy konče. Stejně jako byl softwarový vývoj ovlivněný příchodem internetu nebo mobilních zařízení, bylo vojenství ovlivněné například rozvojem letectví. Vojenství vždy vycházelo z reflexe a vlastních omylů, stejně jako my vycházíme z těch našich. Jednou z jeho vlastností, a nebo mi to alespoň připadá, je retrospektiva. Zkoumání toho “jak” k tomu došlo, včetně zkresleného dovětku “proč” k tomu došlo nebo “co by se mohlo”. u softwarového vývoje se spokojíme s tím, že je něco špatně, ale už se moc neanalyzuje, proč je to špatně. Málokdo vám řekne, dělali jsme to špatně a dopustili jsme se těchto chyb.

Blitzkrieg a DevOps

V poslední době propíraný DevOps, tedy spojeni jednotlivých specializovaných skupin do jednoho funkčního celku, není nic, co by nemělo svojí paralelu ve vojenství.

Do začátku 2. Světové války bylo klasické rozdělení armády na jednotlivé zbraně: tankové jednotky, pěchota, dělostřelectvo, letectvo. Každá z těchto jednotek měla vlastní velení a jednotlivé operace se prováděli v jejich součinnosti. Němci přišli s konceptem nasazení těchto zbraní dohromady, protože se tím maximalizovala jejich efektivita a účinnost. Schopnost nasazení tankových jednotek s přímou podporu letectva a pěchoty dohromady byla základem takzvané bleskové války (Blitzkrieg) a faktorem, který měl rozhodující podíl na úspěších během prvních válečných let. Až později se ho snažili s větším či menším úspěchem okopírovat spojenci. Kromě zvýšení efektivity, se odstranily problémy na úrovni plánování a velení — nebylo potřeba koordinovat několik nezávislých struktur. Právě DevOps poukazuje na fakt, že organizační struktura orientovaná na specializovaná sila (QA, Development, Operations), vede k nižší efektivitě, složitému a špatnému plánování. DevOps se naopak snaží o maximální integraci jednotlivých struktur organizace v jeden funkční celek, který maximalizuje efektivitu úzkým začleněním jednotlivých týmů dohromady.

Jeden muž

Na každou vojenskou operaci můžete nahlížet z mnoha úhlů pohledu. Taktické a operační postupy, výcvik, výstroj a výzbroj, početní stavy, terén a povětrnostní podmínky, informace o nepříteli atd. Podobným způsobem se dá nahlížet na softwarový projekt. Vývojové metodiky, nástroje (IDE, kompilátory, jazyky), komplexita problému, počet vývojářů, dostupný hardware. Když si ovšem rozklíčujete konkrétní vojenskou operaci, každý jednotlivý dílčí úspěch nebo neúspěch, zjistíte, že zásadní roli sehraje mnohdy velmi malá skupina mužů a mnohdy jeden jediný. Je to skoro neuvěřitelné, že v soukolí události, do kterých je zapojeno několik desítek tisíc lidí, hraje roli a je zrnkem na misce vah jeden člověk a jeho iniciativa. Když se 6. Června 1944 nad ránem snažili spojenci vylodit na pláži Omaha, byli ve větší šlamastice, než si vůbec dokázali představit. Namísto postupu do vnitrozemí byli přikování palbou k zemi a bez vyhlídek k postupu do vnitrozemí. Většina vojáků měla vůbec problém dostat se na pláž, pokud se neutopili, utopily se pro změnu jejich zbraně. Namísto druhořadého nepřítele zdecimovaného bombardováním je čekal perfektně vycvičený nepřítel, kterému nezpůsobil předchozí spojenecký nálet žádné potíže. Ve chvíli největší krize se v jednom ze sektorů této pláže vylodil i generál Norman Cota, kterému bylo hned jasné, že pokud se z pláže nepohnou do večera, vymetou je Němci košťaty. Posbíral doslova pár vojáků, kterým vysvětlil, že na pláži je čeká jistá smrt, a společně se jim podařilo první průchod ostnatým drátem a minovým polem. Tato akce jedné jediné malé skupinky přiměla i další vojáky k aktivitě a rozhodující měrou přispěla k úspěšnému vylodění. Tento příběh ilustruje prostý fakt, že nikoliv technické prostředky, plány a kalkulace, ani počet může nerozhoduje o úspěchu. To platí i pro softwarové projekty. Proto je důležité mít motivované a schopné lidi. Nepodléhejme iluzi v podobě v uvozovkách dokonalých plánů, metodik nebo nástroje.

Bez spojení není velení

Koncepce německého výcviku, ohledně velení a předávání rozkazů, vycházela z jednoduché zásady: rozkazy říkají co se má udělat, ale neobsahují jak se to má udělat. Díky tomuto pravidlu měli nižší velitelé možnost posoudit lokálně situaci a podle ní zvolit vhodné řešení k provedení rozkazu. Tento koncept se používal od nejvyšších velitelských struktur směrem dolu až k těm nejnižším na úrovni družstva. Každý jednotlivý voják byl cepován k iniciativě a nikoliv k pasivnímu čekání na rozkazy typu jak se má co udělat. To byl hlavní rozdíl nejenom proti Rusům, ale překvapivě i proti Američanům a Angličanům. Pokud jednotka ztratila velitele, byl celý její úkol ohrožen, protože chyběly přesné rozkazy, jak se má co udělat. Naproti tomu si Němci dokázali udržet agilitu, přestože měli srovnatelné nebo větší ztráty na úrovni velitelských kádrů. Tato jednoduchá zásada, říkat lidem co mají udělat a nikoliv jak to mají udělat, je samozřejmě univerzálně přenositelná. To co po vás chce váš nadřízený, stejně jako to, co chcete vy po někom jiném, by mělo akcentovat složku co a upozadit složku jak. Frustrace lidí na softwarových projektech často pramení z faktu, že to jsou pouzí vykonavatelé zadání někoho jiného. Pokud lidem necháte volnost a umožníte jim zapojit kreativitu pro plnění svěřených úkolů, stoupne jejich motivace a pocit odpovědnosti. Výhodné to bude pro obě strany. Pokud budete akcentovat složku jak, dostanete se brzo do pasti, o které pojednává další odstavec.

Detailní plánování a Frikce války

Pruský generál a vojenský teoretik Carl von Clausewitz, s nímž jste se možná nevědomky setkali díky výroku “válka je pokračováním politiky jinými prostředky”, napsal knihu pokládanou za klasiku vojenského umění s názvem O válce. V této knize poprvé definoval termín Frikce války — “ve své podstatě označuje náhodné a nepředpokládané události, které ztěžují vojsku jeho práci. Vzniká s problémy spojenými převáděním rozkazů od vedení do konkrétních akcí”. Existuje ještě jeden krásný citát popisující dopad působení frikcí:”žádný plán nepřežije první dotek s nepřítelem”. Přesně to samé platí pro jakékoliv plánovaní v softwarovém vývoji. Plán může být sebelepší a rozpracován do nejmenších detailů, ale nikdy nepočítá s neočekávanými okolnostmi. Právě proto platí předchozí odstavce o kreativitě, agilnosti a iniciativním přístupu, které umožňují překonat neočekávané události. Ve vojenství by mělo platit, že politici určují cíle tažení, a vojáci si volí prostředky a způsob jakými je dosáhnou. Stejně tak v softwarovém vývoji by měl management určit cíle, a nechat na inženýrech jakými prostředky a způsoby je dosáhnou. Jednou z oblastí, kde hrají nepředvídatelné nebo neočekávané okolnosti hrají zásadní roli, jsou speciální operace , kdy malá skupinka vojáků dokáže v uvozovkách přemoci mnohem početnějšího nepřítele. William McRaven ve stejnojmenné knize zanalyzoval nejvýznamnější operace jednotek zvláštního určení ve 20.století. Jedním z klíčových prvků, kromě momentu překvapení, který spojoval všechny tyto operace, bylo i originální použití určitého technického prostředku, případně úplné technické novinky. Ta útočníkům umožnila překonat standardní konvenční prostředky obránce. Jednou z těchto novinek byli vybaveni Italští žabí muži, kteří překonali protiponorkové zábrany a vnikli do přístavu v Alexandrii, kde pomocí řízených minitorpéd potopili lodě Královského loďstva. I v softwarových projektech se snažíme často prorazit hlavou zeď s pomocí konvenčních technik, namísto toho, abychom použili žebřík k jejímu přelezení.

Schwerpunkt a Nedostatek zdrojů

Shwerpunkt byl termín používaný Němci k označení těžiště útoku. Díky koncentraci veškerých sil mohlo dojít k lokálnímu průniku, odříznutí týlových jednotek nepřítele a vítězství, přestože byl silnější, v lepším postavení nebo měl jinou výhodu. Často mám pocit, že nám chybí shwerpunkt, na který by se soustředily všechny naše zdroje. Místo toho je drobíme na více či méně podstatné úkoly bez zásadního úspěchu (průlomu). Jestliže máme pocit, že se nám často nedostává lidí, a že se nám často mění zadaní, pak vojáci na tom byli a jsou velmi podobně.

Závěr

V tomto článku jsem chtěl poukázat na pár paralel mezi vojenstvím a softwarovým vývojem. Jak je vidět, existuje více podobností, než by si člověk mohl myslet. Nechci tvrdit, že je potřeba hledat inspiraci jenom ve vojenství, ale určitě bychom se měli koukat kolem sebe, protože většina problémů, které máme a řešíme není specifická pro náš obor. Práce s lidmi, plánování a řízení, efektivní využívání zdrojů to všechno jsou společné jmenovatele. K dobru přidávám odkaz na článek Co se firmy můžou přiučit od armády, který mě inspiroval k tomu, abych se o tomto tématu trochu rozepsal.