Řízení rizik vám často řekne víc pravdy než chcete. [Mike Evans]
Dnes budu psát o další pěkné knize. Jmenuje se „Waltzing with Bears“ a jejími autory jsou Tom DeMarco a Timothy Lister. Kniha je o řízení rizik na softwarových projektech – risk managementu. Pro mě, který o tématu dosud nic netušil to je naprosto úžasná kniha, nicméně bych ji doporučil i zkušenějším projekťákům. Cítil bych se lépe, kdyby projekty na kterých pracuji, vedl člověk, který tuto knihu četl.
Nemá cenu pokoušet se tu popsat celou knihu, doporučuji vám přečíst si ji. Dostane se vám opravdu zevrubného úvodu do správy rizik. Vypíchnu jen pár částí, které mě opravdu zaujaly.
Velká část knihy se točí kolem diagramů rizika (risk diagrams). Vypadají takto
V tomto diagramu je na vodorovné ose vyobrazen čas a na svislé pravděpodobnost dodání hotového software. Tzn. termín dodání není pevné číslo, ale rozložení pravděpodobnosti. Prostě se nedá říci kdy bude software hotov, je možné to říci jenom s nějakou pravděpodobností. Na našem grafu je zajímavé datum 1. ledna – místo kde se pravděpodobnost dodání odlepuje od nuly. Co to je za datum? To je datum dané těmi úplně nejoptimističtějšími odhady. Často je to bohužel také datum, které je vybráno jako termín dodávky. Jaká je pravděpodobnost jeho splnění? Skoro nula. Proto ho také autoři označují jako N – nano-percent date. Co tahle 1. dubna, datum, kde je křivka na svém maximu? Protože má naše křivka těžký konec, pravděpodobnost dodání do 1. dubna se pohybuje kolem 33%. Nic moc. Pokud chceme mít alespoň padesátiprocentní šanci dodržení termínu, musíme ho určit na 1. května. Stoprocentní jistotu dodání budeme mít až 31. prosince! Samozřejmě záleží na tvaru a šířce té křivky. Pro IT se šířka onoho okna údajně pohybuje mezi 150% a 200% data N.
Dále mě zaujalo pět rizik, které se týkají každého softwarového projektu. Pokud s těmito riziky váš projekt nepočítá, je jisté, že o správu rizik ani nezavadil.
- Chyba plánování – Chybný plán je často důvodem svého vlastního nedodržení. Obzvlášť postupuje-li se odzadu a plán se určuje podle předem daného termínu.
- Nafukování požadavků – Jasné riziko, požadavky se mění a přidávají se což nepříznivě ovlivňuje pravděpodobnost splnění plánu.
- Fluktulace – Zkušení zaměstnanci odcházejí, nezkušení přicházejí, k tomu asi není co dodat.
- Zhroucení specifikace – Prostě a jednoduše najednou zjistíme, že se vůbec nedaří produkt naspecifikovat. Zákazník se nedokáže vyjádřit co vlasntě chce, jednotlivá oddělení mají protichůdné požadavky atp. Problém se pozná podle toho, že se specifikace problémových bodů odkládá až na později. Často do doby kdy se to všechno zhroutí.
- Nedostatečná výkonnost – Věc kterou můžeme ovlivnit my vývojáři. Buď jsme výkonní nebo ne.
Co s riziky dělat se podrobně dočtete v knize, kterou vřele doporučuji. No a abych nebyl přehnaně pozitivní, něco bych jí přeci jen vytkl – je napsána složitější angličtinou, než na jakou jsme z odborné literatury zvyklí, takže si člověk pěkně prohloubí slovní zásobu. Rozloučím se citátem, který stojí za zamyšlení
Není-li v projektu riziko, nedělejte ho.
Tu knížku jsem nečetl, ale graf mě zaujal, především to, že jeho šířka se dá hrubě odhadnout na 150% – 200% N. Kdybych byl “projekťákem” já, tak bych asi zvolil trochu jiný přístup. Tato křivka by se podle mě dala velmi dobře modelovat pomocí Gamma rozdělení (viz: http://en.wikipedia.org/wiki/Gamma_distribution). A jako taková by se tedy dala zkonstruovat na základě parametrů. Tyto parametry by se daly odhadovat na základě historických dat (slíbené a reálné termíny předchozích projektů). Pokud by pak i nový projekt měl přibližně stejné složení teamu, používaly se podobné technologie .. atd, tak by takový odhad mohl být přesnější, než oněch hrubých 150-200%. A pokud by nebyl, tak by se možná dalo jednodušeji (přesněji?) ukázat, který faktor na to měl největší vliv (team měl příliš jiné složení, použíta nová technologie…) a zároveně bychom se dozvěděli, jak velkou variabilitu tento faktor vnáší do modelu… (např: jeden nový člověk v teamu představuje v průměru 10% riziko zpoždění termínu…).
Ale takového “projekťáka” jsem ještě nikdy nepotkal…
Přesně to je v knize posáno. Člověk tam najde i diagramy rizika pro pět zmíněných hlavních rizik (platné pro průměrnou IT firmu v Americe). Hodilo by se mít historická data pro firmu, v které člověk pracuje. Bohužel tato data se moc nesledují (často z politických důvodů). Lidé obvykle moc nechtějí slyšet nepříjemnou pravdu.
Jsou v té knížce také popsány nějaké konkrétní success stories po zavedení navrhovaných metodik řízení rizik (nejlépe v Americké IT firmě) a to takovým způsobem, aby to bylo přijatelné pro střední a vysoký management?
Žádné success stories si nevybavuji. Ona ta kniha nepřináší nic co by člověk už nevěděl. Jenom si to tak nějak neuvědomuje. Řízení rizik v podstatě znamená následující: zamyslete se nad riziky, která vám hrozí a sepište vše co vás napadne. Poté si uvědomte příznaky, které vás upozorní na to, že riziko nastává. Ujasnětě si co dělat, když riziko nastane a co dělat aby jeho dopad byl menší (nebo vůbec nenastalo). Takže žádná raketová věda, věci které by člověka normálně napadly. V knize se člověk doví na co dát pozor, proč je řízení rizik nepopulární, proč se ta největší rizika ignorují a místo nich se řídí ta bezvýznamná atp.
Když nad tím přemýšlím tak je tam pro ilustraci uveden jeden pěkný odstrašující příklad, který by nenastal, kdyby bylo použito řízení rizik.
Kdybych já chtěl přesvědčit management pro řízení rizik, tak bych se jich zeptal, jestli vědí co budou dělat, když (nebo až) jim odejde tento důležitý člověk, co budou dělat až selže subdodavatel, co budou dělat, když zákazník nebude schopen (nebo ochoten) dokončit specifikaci…
Me to pripada takhle: pri urceni terminu se automaticky pocita se zdrzenim respektive s nedodrzenim terminu. V prikladu se stanovi dodani na Jan.1 a “odbornik” ukaze, ze skutecna 50% sance je az v May 1. Takze se termin Jan.1 zrusi a misto nej se nastavi May 1 a tim se vlastne cela krivka posune a stane se tim May 1 vlastne zase naprosto nesplnitelny.
BTW: prijde mi ten vyklad grafu nejak nesrozumitelny a prijde mi, ze Jan1 je nesplnitelny a pak April 1 jako nejpravdepodobnejsi termin odevzdani a cim dele smerem k Dec. tim uz mensi pravdepodobnost, ze se projekt vubec dokonci. Tvuj vyklad (a asi i ten v knize) je jiny a oznacuje Dec.1 jako 100% jistota splneni, coz IMHO podle grafu neni. Je tam neco co prehlizim ?
Pravdepodobnost je oblast pod krivkou (integral). Tzn. kdyz chci zjistit pravdepodobnost dokonceni k 1. dubnu, vybarvim oblast pod krivkou az k prvnimu dubnu. Se vzrusajicim casem pravdepodobnost splneni samozrejme roste.
Pingback: Java crumbs » Blog Archive » Pochod smrti