Vraťmě se do školních let a vzpomeňmě si na fáze, kterými softwarový projekt prochází. Pěkně postupují jedna za druhou a na konci je hotová aplikace. Jak praktické, jednuduché. Nejdříve uděláme specifikaci v níž popíšeme business logiku budoucí aplikace … a ouha. Jak často právě zde uhodí kosa na kámen. Ať už se jedná o vývoj interní nebo externí na zakázku, začnou se dít věci. Zadavateli jevše jasné, ale nedokáže to jasně popsat. Jím dodávané dokumentace jsou neúplné, nesrozumitelné … nejsou nejenomže 100 procentní, ale ani 99% procentní.

“S tím nemohu pracovat!”, vykřikne Dilbertův inženýr. Nemám zadání, nevím co mám dělat! “Pravdu díš” může vykřiknout jeho šéf a se zlou se potáže zadavatel – tedy zákazník. A zde máme první konflikt. Situace je pod kontrolou:

1. Ví se co je potřeba – 100% specifikace
2. Ví se kdo za to může – zadavatel
3: Vše se zastaví dokud nebude zadání

Jak ten příběh skončí? Zadavateli se rozvidí, sedne, vypracuje dokonalou specifikaci a s úsměvem ji druhý den předá? Paradoxně něco takového se nestane téměř nikdy. Pak se tu logicky objevuje otázka: OK, ale jak tato civilizace mohla vůbec něco vyvinout? A odpověď je: “Chyba není v civilizaci”.

Řada lidí považuje metodologie řízení (projektů, procesů, softwarového vývoje a další) za něco co je zbytečné, byrokratické, odnášející kreativitu a něco co více patří do příběhů o Dilbertovi a Dogbertovi než do reality.

Ve většině případů je důvodem neznalost nebo neochota přijmout nějaká pravidla chování. Během studia jednotlivých metodologií v posledních letech mě ale překvapovalo kolik životních mouder je v nich ukryto. Potíž je, že člověk bez zkušeností je nemusí vidět a implementovat jakoukoliv metodologii “naslepo” je stejně moudré jako jet podle mapy zdi, nezdi, řeky neřeky….

RUP (Rational Unified Process) je procesně orientovaný framework určení k řízení softwarového vývoje. Původně ho vyvinula Rational Software Corporation, která je nyní jednou z divizí IBM. RUP je poměrně známá a uznávaná metodologie. Myslím, že se s ní setkala většina lidí, i když málo kdo ji opravdu ovládá. To proč RUP zmiňuji je jeho jakýsi “základní diagram softwarového vývoje”:

Všimněte si, že projekt sice prochází posloupností několika fází, ale řešené disciplíny jimi prolínají dle potřeby. A v tom je onen zelený strom života.

Dokonalé zadání je téměř jako perpetum mobile. Bylo by to hezké, ale je to zhola nemožné.

Ačkoliv Dilbertův inženýr vše myslí poměrně v dobrém, ve zlé se to obrací. Největší dopady má vývoj řízený syndromem stoprocentního zadání na:

Našlo by se toho víc, ale už nyní když si přečtete ony 4 body, zjistíte, že Dilbertův inženýr horší než hurikán. Napáchá přibližně stejně škody a ještě je velice obtížné najít viníka. Což u hurikánu typicky neastává.

Syndrom stoprocentního zadání jde často v ruku v ruce se Syndromem mrtvého koněa má velkou tendenci do něj přerůstat. Je to dáno právě skrytostí příčin a znepřehledněním situace i když ta na povrchu naopak vypadá velice přehledně.

V systémech, které dokáží měřit výkonost ( a jsou tedy typicky velice dobře a hlavně přirozeně(!) organizované) se Syndrom stoprocentního zadání nevyskytuje. Typickým místem jeho vzniku jsou začínající rostoucí firmy s vnitřním “kreativním chaosem”. Od určitého okamžiku se právě v něm zrodí tato příšerná choroba.

Celá situace je vnitřně dlouhodobě neudržitelnou. I když to tak v některých fázích nemusí vypadat, je to jen díky “zneviditelňovací” povaze průvodních jevů. Na syndrom neumírají projekty, ale lidé. Ve chvili kdy dojde k rozkrytí situace se dostavují většinou rychlá, emoční a mnohny ne právě racionální vyhrocení. V rámci nich se buďto několik lidí zvedne a kolektivně odejde a nebo je naopak propuštěno.

Proč k tomu dochází jako blesk z čirého nebe? Je to dáno podstatou syndromu a podstatou člověka. Představte si manžela, který vidí, že s jeho ženou není něco v pořádku. Neví co. Nic nezanedbává, jen je jiná. Začne tušit, ale nenachází pro to argumenty a tak to možná hodí za hlavu. Ovšem jen do chvile kdy se vrátí ze služební cesty příliš neočekávaně a vrhne se do té nesprávné skříně…

Jistě víte kam mířím. Pak už se vše řeší poměrně rychle a dramaticky v obrovských vlnách emocí. A přesně tak do dopadá s dlouhodobě zanedbaným syndromem stoprocentního zadání.

Léčba je poměrně obtížná. V úvahu je třeba vzít, že se jedná pouze o syndrom jinak neviditelné choroby. Co je třeba rozkrýt jsou skutečné příčiny. Neznáteli přičiny, není co léčit.

Přímá léčba syndromu způsobuje mnohdy rozvinutí nemoci! Nejlepším lékem ve většině případů bývá schopný project manager s dostatkem pravomocí.