Úvaha: Když pravidla vývoje brzdí vývoj samotný | Kapitola 8
Seznam kapitol
V moderním světě oslavujeme pokročilé vývojové metody, a zapomínáme na efektivní vývojové metody ze staré školy. Je to dáno softwarovým vývojem, který prosazuje „ne-průmyslové“ vývojové postupy. Změna je dobrá, buďme agilní, nebojme se změn, přesypávejme procesy během vývoje! Některé jsou opravdu super, ale...
Říká se, že nejhorší manažer není ten, který nečte odborné knihy, ale ten, který je čte a nepochopí. Může se tak snadno stát, že pak prosazuje postupy, které jsou sice moderní, ale příliš se nehodí pro danou organizaci. Částečně za to můžou i evangelisté moderních metod, kteří je nekriticky oslavují a málo, velmi málo zmiňují podmínky, za kterých tyto metody fungují. Nevím, zda to je daň, kterou platíme za příchod moderní americké literatury, která autorům zakazuje jakékoliv pochybnosti a nutí je dokolečka opakovat proud jednoduchých manter, ale varování a upozornění na problémy často v podobných knihách chybí. Jsou tam jen samé příklady a úspěchy.
Před lety jsem objevil obskurní, nicméně zajímavou knihu o moderní magii, která začínala pozoruhodnou, třicet stran dlouhou kapitolou „Magická způsobilost“ rozsáhle pojednávající o tom, proč byste magii neměli používat. Bylo to prakticky pojaté varování v tom smyslu, kdy a proč byste neměli poznatky z dalších kapitol používat, aby se vám to nevymstilo. Podobné varování je v moderních příručkách kupříkladu o agilních metodách nebo reengineeringu velmi vzácné – a pokud se tam vyskytuje, je obvykle jen „pod čarou“.
Nevhodná moderní metoda přitom dokáže způsobit totální chaos. Základem agilních metod je kupříkladu úzký kontakt vývojářů se zákazníkem, propojení odborníků z jednotlivých oblastí do úzce spolupracujících vývojových týmů a krátký cyklus vývojových iterací. Aby to fungovalo, musí tuto metodiku pochopit všichni, všichni s ní musí být srozuměni a musí ji podporovat. Pokud se v týmu uhnízdí nějaký „sabotér“, kupříkladu zákazník, který nechápe pojem „cyklus“ a od začátku vidí jenom „nedodělanou, nevyhovující věc“, máte problém. Pokud nějaký vývojář odmítá sdílet informace, máte problém. Pokud se vedení rozhodne do vývoje nesystematicky zasahovat direktivním způsobem, máte problém. Pokud je tým současně řízen několika způsoby a nebo jsou jeho klíčoví členové nasazeni na více projektů, máte problém. Dobře míněný systém se vám začne rozkládat a vytvářet naprosto neuvěřitelný chaos.
Pokud se rozhodnete použít nějakou novou metodu, na kterou nejste navyklí, není od věci si objednat konzultace od člověka, který s ní má praktické zkušenosti a to ideálně z velmi podobného odvětví. Předtím, než přikročíte k prvnímu kroku její implementace, je zcela na místě nejdřív udělat „krok nula“ a prozkoumat, zda je taková metoda pro vás vůbec vhodná. Možná váš klasický produktový cyklus není ideální, ale všichni mu rozumí a ví, co se od nich kdy čeká. Když si pozvete na přednášku pána, který jedno dopoledne mele abstraktní povídačky a pak ponechá vaše pracovníky ve stavu zmatení s tím, že teď už to zvládnou, neměli byste si připadat bezpečně.
Mnohem výstižnějším pocitem by bylo divné mravenčení u žaludku ve chvíli, kdy před vámi ustupuje moře do dálky: to klesá voda před blížící se tsunami, kterou jenom ještě nevidíte na obzoru...
