Paralela: Problémy stavitelství a softwarového inženýrství

Při vysvětlování problémů vývoje software kolegům, kamarádům a také laikům a po zkušenostech se spoustou nových či rekonstruovaných budov (správní, firemní sídla, software houses) jsem si uvědomil viditelnou paralelu mezi problémy a příčinami softwarového inženýrství a stavitelství. Samozřejmě každá paralela místy pokulhává, ale tato v zásadě krásně ukazuje, proč není vývoj software ani po desítkách let „jednoduše předpovídatelný“ a znalosti v oblasti automaticky aplikovány.

Proč jsou v dnešní době stále ve vývoji software základní problémy je zřejmé, jedná se o soft artefakt, jak už název samotný napovídá a celé to stojí na lidech. Software není nic hmatatelného, je těžké ho komplexně pojmout v hlavě a vyjádřit pomocí tvrdých měřitelných hodnot. Proto dokonce ani sami zákazníci při zadávání uplně přesně neví, co vlastně chtějí. Stejně jako my vývojáři, i oni se učí v průběhu prvních iterací vývoje pochopit svoje potřeby zhmotněné ve formě software. Proto je tak důležité mít na konci iterací pravidelné demonstrace, které umožní zákazníkovi i nám si lépe uvědomit, co vlastně chceme vytvořit a sesbírat zpětnou vazbu.

V případě stavitelství vytváříme hmatatelný výsledek, stavbu, nic, co by bylo jen v našich hlavách a i tady existují úvodní vizualizace, dále projekty a technická dokumentace, dříve, než začneme něco stavět. Pokud jsou problémy běžné ve stavitelství (hmatatelný produkt), ještě aby nebyly i v softwarovém inženýrství (nehmatatelný, abstraktní produkt).

Lidé z oblasti stavitelství asi potvrdí, že v dnešní době je zásadní vstupní veličinou tlak na co nejnižší cenu / náklady (šetření na základní architektuře jako jsou rozvody, menší množství betonu, nekvalitní materiály apod.). Stejně je tomu také na trhu IT. Zakázku většinou vyhrává nejnižší cena, ve státní správě samozřejmě také známosti … a když náhodou konečně přijde koncepční řešení s vizí a architekturou (např. výchozí společná platforma mySAP v případě státní pokladny z důvodu jednotné komunikace, lepší integrace dat a snažší údržby), je smeteno ze stolu, že nahrává jistým firmám. To jsem ale trošku odbočil od tématu. Nejnižší cena ovlivňuje architekturu ve stavitelství stejně jako v IT, tyto zanedbané oblasti se pak vrací jako bumerang v provozu a navíc ještě kromě vyšších nákladů na odstranění znepříjemňují život uživatelům budov / software.

Jeden příklad za všechny: rekonstruovaná budova
Takže pojďme blíže ke slíbené paralele. Přední středoevropský developer kompletně opravoval (revitalizoval a měnil vzhled) samostatně stojící výškovou budovu, kterou nyní pronajímá softwarové firmě. Laik by si řekl, aha, počítačová firma (samé PC, samý server), asi potřebují kvalitní elektrické rozvody, ne tak zkušený developer, ten požadavky zákazníka ani nezjišťoval, ze zkušeností z jiných projektů je zná lépe, proto dimenzoval elektrickou síť tak, jak uznal za vhodné. Jaké překvapení, toto nestačilo! Neznámé či nepochopené potřeby zákazníka (B princip podle RUP / OpenUP), jak běžné v IT, kdy generujeme zbytečné, nikdy nepoužité funkčnosti systémů, ale základní chybí či jsou nepoužitelné, resp. plné chyb.

Dalším problémem v dané budově byla klimatizace a neotvíratelná okna tvořící 80% stěny. V úvodních jarních týdnech byla dopoledne jedna část a odpoledně druhá část budovy nepoužitelná z důvodu ostrého slunečního svitu. Koho by napadlo instalovat žaluzie na dvacetimetrová okna výškové budovy, která není stíněná žádnou zástavbou ani jiným objektem, stromy či kopcem. Stínítka ve formě nástěnek, papírových krabic a jiných workaroundů (dočasných náhradních řešení) byla zakázána z bezpečnostích a technických důvodů (poničení speciálních skel). Až po velké nevoli uživatelů kanceláří se developer rozhodl na okna namontovat obyčejné žaluzie alespoň zevnitř. Tento problém byl opět viditelný a selskému rozumu se příčící, vycházel však opět z chybějící porozumění potřebám a také z chybějící demonstrace či vyzkoušení práce v místnosti (walking in customers shoes). Kdyby jeden z návrhářů funkčních prvků budovy musel sedět v kanceláři za jasného jarního dne s nízkým, přímo do tváře svítícím sluncem a k odstínění by mu nestačila ani svářečská kukla, asi by si uvědomil chybějící doplněk přinášející zásadní užitek. V IT je toto symbolizováno pochopením toho, co vlastně zákazník dělá, co má za problém (tzv. big picture) dříve než ho začneme řešit pomocí software a naleštěných technologií.

Poslední věcí byl vzduch, ano dýchatelný vzduch. Opět přece jasné, zákazník nemusí tuto věc zmiňovat, ale ve specifikaci developera asi opět chybějící požadavek. Jelikož je budova moderně a bezpečně navržena, nemá otevírací okna. Co tomu však chybí, je fungující a výkonná klimatizace. Pokud je klimatizace dimenzována na 5 lidí v kanceláři pro 8 lidí a není možno otevřít okna, jde zaměstnancům téměř o život, nemluvě o tom, je-li někdo z kolegů méně pečlivý na svůj zevnějšek… Opět chybějící implementace kritického požadavku, který je samozřejmý pro uživatele, viditelně však ne pro developera.

Většina požadavků byla na naléhání uživatelů odstraněna za ostrého provozu, ale s určitými důsledky, nízkou kvalitou, za cenu obtěžování uživatelů při práci. To stejné se děje při návrhu software, neexistující a neotestovaná architektura řešení (což elektické sítě či možnost dýchaní v místnosti rozhodně jsou), žádná zpětná vazba od zákazníka a předpokládání, že náš výstup je to, co opravdu zákazník potřebuje a chabé či žádné předávání znalostí mezi projekty (přece už někdo z této firmy musel vidět výškový dům a sedět v něm za svitu slunce a dýchat vzduch…).

Nekritické požadavky (tzv. nice to have features) jako je například potřeba bufetu pro stovky lidí vynechávám a zmíňil jsem opravdu jen zásadní, tj. architektonické problémy. Toto je jen jeden příklad z mnoha, účelnost budov a orientace v nich je další kapitolou.

Řešení
Nedá mi, abych ještě nezmínil pár slov k řešení daných problémů, jelikož zde je paralela pořád zřejmá. Řešením je dodržování či následování správných principů a vzorů. Sdílení znalostí (knowledge sharing) při stavbě domů probíhá tak, že se architekt ve škole naučí základy, ale drobné ale zásadní informace (the evil is in detail ;)) musí nasát v životě od zkušenějších kolegů. Stejně tak to funguje v IT. Junioři se učí od seniorů (například pomocí efektivní techniky párového programování).

V IT existuje praktika zvaná organizace týmů kolem architektury (ortogonální software ve formě nezávislých komponent), kdy je ale nutná neustálá synchronizace ohledně rozhraní a jejich služeb. Ve stavitelství je toto ještě viditelnější – domy mají skelet, elektrické rozvody, ventilaci, datové rozvody, odpady a kanalizaci tvořené různými týmy, které spolu musí komunikovat, aby dům jako celek fungoval správně. Pokud zanedbáme nutnost pravidlené komunikace a potřebu základní architekturu v obou oblastech, problémy se rychle ukáží a jejich ostranění nás většinou stojí řádově více, než úspory nad architekturou či levnými materiály.

Jako první jsem měl samozřejmě zmínit nejzřetelnější a nejdůležitější princip: pochopení potřeb zákazníka a znalost celé problematiky (big picture), který jde ruku v ruce se snahou generovat pravidelný výstup pro demonstraci a zpětnou vazbu. O tom ale zas někdy jindy.

Poznámka: developerem zde míníme firmu realizující a financující stavbu, ne vývojáře software ;)

Příspěvek byl publikován v rubrice Články se štítky . Můžete si uložit jeho odkaz mezi své oblíbené záložky.

Napsat komentář

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