Zbourejte sila

Nebojte se, nezačal jsem fušovat i do zemědělství. Silo je v tomto případě jen metaforou pro vnitřní rozdělování organizací na jednotlivá oddělení. Oddělení vykonává v rámci organizace svou více či méně opodstatněnou funkci. Mnoho chytrých lidí má problém pracovat v prostředí velkých korporací a důvody často vyplývají právě z fungování těchto sil. Aby toho nebylo málo, často jde o IT oddělení a dokonce mou domovskou doménu, vývoj software. Navazuji tak na svůj článek Zákaznický software potřebuje vývojáře, ne programátory!

Při vzniku těchto organizací vypadalo rozdělení organizace na oddělení jako dobrý nápad. Pro plnění cílů organizace se vymyslely procesy, funkce, zodpovědnosti a výsledkem byla organizační struktura. V perfektním světě, kde všichni lidé v organizaci sdílí informace a jsou motivováni úspěchem celé organizace by záměr fungoval. Realita je horší a pro mnoho lidí demotivující. Členové oddělení se zaměří pouze na plnění funkce svého oddělení. Obstojně dokáží řešit akorát problémy uvnitř oddělení – sila. S ostatními odděleními komunikují málo. Řešení problémů napříč organizací se stává nekonečným řetězem plným alibistických vyjádření jednotlivých oddělení, že jejich problém to není.

Jako zaměstnanec dodavatele se v organizacích setkávám s absurdními situacemi. Oddělení plní výše uvedeným způsobem svou funkci a úspěšně každoročně zvyšuje výkonnost svých vnitřních procesů. Tak kde je problém? Oddělení se zaměřilo jen na své problémy. Už nevidí, že výstupy, které tak rychle dodalo v rámci procesu, nejsou užitečné. Nevidí, jak se matematicky přesně rozhodlo na základě neúplných vstupních informací. Nevidí ani zbytečnost schopnosti dodat report ABC o 200% rychleji – tento report už dávno nikdo nečte. Neplatí už ani původní záměr, aby pro náplň funkce tu bylo jedno oddělení. Realita je taková, že tou samou činností se zabývá i jiné oddělení.

Podobné problémy nemusí vždy potkat jen desítky let staré korporace. Pracoval jsem v softwarové firmě, kde existovalo silo lidí tvoří zákazníkům nabídky (cílem bylo, aby zákazník akceptoval nabídku, úspěšnost sila se počítala dle počtu akceptovaných nabídek a ceny). Další silo vypracovalo (po pár měsících, bez spolupráce s těmi, co tvořili nabídku) detailní dokument, kam zaneslo informace, které pokládalo za užitečné při analýze, co se po systému vlastně chce (to co nejvíce zákazníka v nabídce zaujalo se zpravidla analyzovalo nedostatečně, pracovníci sila se nestarali o to, co budou čtenáři v jejich dokumentu vlastně hledat, informace se od zákazníka získávaly bez jednorázovou formou, bez ověření správného pochopení s více lidmi zákazníka). Dokument opustil analytické silo a přistál v silu vývojářů. Ti se jali dokument přetvářet v software. Co nepochopili nebo chybělo si domysleli sami. Ať už za tím byla lenost jít se zeptat či nedostupnost analytiků, kteří již dostali jiné úkoly. Sami si vytvořili sila v silu, rozdělili tým na skupinky dle technologií (frontend, byznys logika, databáze) a výsledkem bylo odlišné pochopení  věcí v těchto skupinkách – prostor pro další chyby. Silo testerů dokument analýzy buď nedostalo vůbec nebo dokument neobsahoval vodítka, jak otestovat správné používání softwaru. Testeři tak vyšli z toho, co umělo uživatelské rozhranní. Podle rozhranní napsali scénáře, mnoho dnů fajfkovali a nakonec prohlásili sw za otestovaný. Poslední silo ve firmě, aplikační podpora, dostala od vývojářů instalační balíčky a zanesla je k zákazníkovi. Při instalaci musela dost experimentovat a vyžádat si od vývojářů opravné patche, než se podařilo úspěšně aplikaci nasadit do prostředí zákazníka. Po instalaci ověřila fungování aplikace, něco nesrozumitelného zapisovala do logů, tak to snad funguje.

Každé oddělení udělalo to, co bylo z jejich pohledu správné a přece to celé bylo špatně. Zákazník dostal jiný software, než chtěl. Dodavatel obdržel spoustu připomínek. Vývojáři nad připomínkami žasli, často o funkčnosti v připomínce neměli ani tušení. Dodavatel nakonec se značným neplánovaným a drahým úsilím realizoval. Po dodání zákazníkovi se situace opakovala, následovalo další kolečko připomínek. Výsledkem byl ztrátový projekt, dodavatel ve svém byznysu selhal. Proč?

Oddělení mezi sebou nespolupracovaly tak, jak by bylo pro celkový úspěch potřeba. Každý jen dělal svou práci, tak jak to cítil. K neúspěchu přispěla i jedna velká dodávka na místo mnoha menších dodávek. Lidé nebyli k dispozici v čase, kdy to bylo potřeba , chyběla komunikace. Lidem pracujícím na projektu chyběl kontext, kdo se sám proaktivně nestaral, neměl dostatečné informace.

Jak z toho ven? Sila zbourat a postavit tábor. Cílem lidí v táboře je dodat software a starat se o něj celou dobu života. Počátek existence tábora je skromný, řekněme až virtuální, prací na nabídce. V okamžiku akceptace nabídky by se měl rozvinout tábor skutečný. Konec existence jsem spojil s koncem života softwaru. Projekt je často definován jako balíček změn. Zaběhnutá praxe je ukončit projekt úspěšným během v pilotním provozu. Já s tím nesouhlasím a jestli to nějaký odběratel dělá, sám tak draze dodaný software odsoudil k zániku. Zákaznický software se převzít prakticky nedá, dají se jen postupně či najednou přepsat zdrojové kódy. Bez kontinuity není myšlenka a bez myšlenky se s každou změnou koncept systému rozpadá. Moderní zákaznický software není krabice ze supermarketu, co slouží pár let a pak se koupí nová. Existence tábora zajišťujícího podporu a rozvoj řešení je levnější než co pár let tvořit řešení nové.

Posledním střípkem do skládačky je, že i tábor sám musí fungovat bez sil. Činnost lidí by se měla prolínat a tím umožnit vždy držet velikost tábora odpovídající potřebě. Není třeba mít celou dobu zkušené specialisty, často jejich činnost dokáží v době menších nároků převzít generalisté schopní vykonávat i jiné role. Existuje mnoho postupů, jak schopnosti zastupovat se navzájem pomoci. Nástroje pro sdílení kolektivního knowhow, extreme programming (dá se aplikovat i na analýzu a další činnosti), rotace lidí na různých typech činnosti, to vše už existuje. Jakmile se začne něco analyzovat, měl by už vývojář začít připravovat řešení. Pro výběr technologie získat představu o potřebném výkonu, bezpečnosti … Zamyslet se, jak bude řešit různé funčnosti. Velice důležité je zamyslet se, jak řešení testovat a to způsobem podobným, jakým je budou využívat uživatelé. Konečně je také důležité myslet na cílovou infrastrukturu a vytvořit už pro vývoj obdobné prostředí. Vývojář vyvíjející ve svém mikrosilu mnoho měsíců na desktopu v lokálním IDE bez integrace na jiné systémy je stále častým jevem a nasazení takového softwaru do serverového prostředí skutečným porodem.

Závěrem budu trošku skeptický. Když se podívám na tyto problémy ve velkých organizacích mimo IT, jde o běžný a trvalý stav. Novinkou není identifikování těchto problémů ani při vývoji software, třeba Scott W.Ambler (autor Agile Unified Process) o nich píše ve svých knihách již 10 let. Postižené organizace jsou často proti podobným změnám silně rezistentní. Ukázka konkurenční výhody ze změn plynoucí musí být dostatečně přesvědčivá. Otázkou zůstává, začne už konečně vítězit dlouhodobé plánování nad krátkodobým?