Jak se udržet naživu při řízení projektů

Funguje chaos?

Pokud budete studenti teoretické matematiky, tak vás různé aplikace chaotického chování budou zajímat a uvědomíte si, že pro dnešní vědu mají zcela zásadní význam. I přes nepopiratelný význam chaosu, se naše společnost snaží o co nejvíce deterministické uspořádání a tuto snahu promítá do svých činností. Klasickým příkladem nám budiž sportovní utkání třeba v tolik populárním hokeji.

Pokud bychom sestavili nějaký amatérský tým složený z hráčů, kteří spolu nikdy nehráli a neznají se, viděli bychom na hřišti komickou ukázku chaotického chování. Každý by po kluzišti jezdil zcela náhodně, chování hráčů by v každé herní situaci (třeba i stejné) bylo obvykle jiné a o nějaké týmové spolupráci by se nedalo vůbec mluvit. Prosadili by se pouze nadaní jednotlivci, kteří by uspěli hlavně v sólovém hraní. Je jasné, že úspěch takového týmu by záležel na těchto skvělých hráčích a s odhodem talentů by se pravděpodobně tým úplně propadl v pomyslném turnajovém žebříčku.

Opakem k tomu si představme tým již sehraných hráčů, kteří se řídí podle pravidel, co se naučili od svého trenéra. Každý ví, kde je jeho místo a každý si zapamatoval co má dělat v určité situaci a komu má nahrát. Pochopitelně i pro takový tým jsou talenty velkou posilou. Ale existence a úspěch týmu na nich není životně závislý a s jejich odchodem dochází k rychlému nahrazení z řad jiných hráčů. Druhý tým se také schází a diskutuje o herní strategii, připravuje se společně na jednotlivé zápasy a řeší, jaké hráče nejlépe nasadit.

Asi je zřejmé, že první tým, by proti tomuto druhému měl pouze málo šancí, které by byli založené především na štěstí. I první tým může uspět, může excelentně vyhrát, ale pravděpodobnost, že dokáže svůj úspěch trvale opakovat a udržet, je minimální.

Myslím si, že paralela týkající se řízení nějaké činnosti, kde chceme uspět je zřejmá. Není to nic objevného a již dlouhou dobu se lidé snaží standardizovat a optimalizovat různé lidské činnosti. Vznikají standardy týkající se řízení projektů, metodologie jak trénovat hráče hokeje a metodologie, jak psát aplikace a jak řídit jejich vývoj.

Proto se již v polovině 80. let objevily první návrhy na projektové standardy. Asi nejdůležitější byl rok 1987, kdy byla uvolněna úvodní verze ISO9001 společně s prvním návrhem SW-CMM (dnes de facto standard pro řízení vývoje software, jeho první označení bylo SEI-87-TR-24).

Kromě této normy byly zavedeny i další, které patří do rodiny CMM:

• SA-CMM (Software Acquisition CMM) - věnuje se hlavně odběratelům a to s ohledem na nákup, nasazení a správu software
• SE-CMM (System Engineering CMM) – věnuje se správné organizaci práce při vývoji software
• IPD-CMM (Integrated Product Development CMM) - definuje životní cyklus vývoje produktu a jeho další vývoj
• P-CMM (People CMM) - definuje kroky k správnému vedení pracovních sil

Všechny modely se vzájemně doplňují a jsou synergické a jeden doplňuje druhý, pokud jak klient, tak jeho dodavatel používají odpovídající modely řízení.

Postupem času se tyto návrhy a specifikace upřesňovaly až do dnešní podoby, o které bych se rád zmínil.

Co je vlastně CMM? Capability Maturity Model je framework popisující klíčové části nutné pro efektivní vývoj software. Jde o popis přechodu pomocí postupných evolučních vylepšení od ad hoc neoptimalizovaného řízení procesů až po plně optimalizovaný vývoj s průběžným zaváděním dalších zlepšení. CMM je založena na 5 stupních hodnocení a zahrnuje praktiky pro plánování, navrhování a řízení vývoje a údržby software. CMM je založena na současných postupech (praxi) reflektuje nejlepší zkušenosti z praxe reflektuje potřeby jednotlivců provádějících zlepšení softwarových procesů a jejich hodnocení je plně dokumentované je veřejně dostupné

Od neoptimalizované k optimalizované společnosti

V „nezdokonalené“ společnosti je vývoj software v zásadě improvizovaný vývojáři a jejich managery během celé životnosti projektu. Byly-li procesy pro vývoj software definovány (což často nejsou), nejsou dodržovány či uplatňovány. Jednotliví manažeři tráví čas převážně řešením různých krizi a průšvihů (hezký termín na to má angličtina „fire fighting“ – hašení požáru). Běžně bývá překročen jak termín tak i rozpočet a to často několikanásobně, protože původní odhady a předpoklady byly nereálné.

„Zdokonalená“ firma má po celou dobu projektu přesnou znalost aktuálního stavu a po celou dobu jsou aplikovány procesy pro dosažení kvality, termínu a požadované funkčnosti. Dále pak dodává všechny potřebné informace jak existujícím členům teamu tak i nováčkům. Vyžadované procesy jsou dokumentovány, použitelné a odpovídající současným potřebám a stavu věcí. Definice procesů jsou aktualizovány a vylepšovány dle potřeby. Manažeři monitorují kvalitu softwarových produktů a procesů, podle kterých jsou produkty vyvíjeny. Obecně řečeno: optimalizované organizace používají dobře definované procesy, protože si všichni uvědomují jejich přínos a existuje potřebná infrastruktura k jejich plné.

Čím se řídit?

Pokud vlastníte softwarovou firmu a nebo působíte jako projektový manažer, tak jste určitě zažil, jak se projekt neodvíjí podle vašich představ. Jak se váš „hokejový“ tým rozjíždí bezhlavě po ledě a čím víc se blíží konec zápasu, tím víc začínají hráči šílet ze stále viditelnějšího nedostatečného výsledku. Pro manažera projektu to mohou být těžké chvíle a hodně bezesných nocí, a proto je pochopitelné, že každý takový „trenér“ se snaží před tímto peklem uchránit. Naštěstí pro nás, již touto situací prošlo hodně lidí před námi a pokud to tito lidé přežili, tak si uvědomili, že situace se až modelově opakují a že by se dalo před nimi uchránit pomocí určitých metodik. Díky tomu se objevila již zmíněná první specifikace SW-CMM, která dávala souhrn kroků a podmínek pro rozvoj firmy a její výchovu k lepším organizačním modelům. Není to pouze obecný standard, týkající se kvality výroby (jako modely ISO), ale specielně připravená metodika právě pro IT průmysl.

Asi nejdůležitějším faktorem pro vznik SW-CMM metodologie byla motivace vývojových týmů, aby co nejlépe zajistily a zpracovaly požadavky zákazníků a podle nich co nejpřesněji odhadly časovou a finanční náročnost projektu. To jen ukazuje, že využívání SW-CMM není nějaký módní výstřelek, ale že se zde jedná o to nejpodstatnější – o peníze. Díky SW-CMM je možné výrazně zefektivnit vývoj software a lépe uspokojovat potřeby klientů a zároveň rovnoměrně rozložit pracovní zátěž zaměstnanců a zvýšit jejich efektivitu.

Co tedy lze po aplikaci SW-CMM očekávat?

• Zpřehlednění celého projektu a jeho řízení
• Lepší časování v důsledku rozboru jednotlivých kroků vývoje
• Upřesnění rolí účastníků projektu
• Vylepšená dokumentace
• Zlepšení kvality
• Kontinuální snižování nákladů a zvyšování efektivity
• Měřitelnost výsledků

Úrovně CMM

Při zavádění CMM modelu je nutné si uvědomit, že jde o postupný evoluční proces, kdy celá firma se po jednotlivých krocích přetváří a vyvíjí. Každý stupeň CMM definuje cíle, které je nutné splnit, aby se naplnily podmínky dané úrovně. To má za následek plynulý přerod firmy v organizačně lepší instituci, aniž by se dělaly nějaké skoky. Pravě takové rychlé až hektické posuny v organizaci firmy mohou vést i ke zhoršení stavu a v důsledku poškození jak firmy, tak i klientů. Proto je časový harmonogram nasazení CMM dosti náročný a důležitý a velmi se nedoporučuje jej urychlit či cokoliv vynechat.

První (initial) úroveň

První úroveň si vyznačuje poměrně velkou dávkou neuspořádanosti a hektičnosti, které postupně vedou k tomu, že vedení projektu se snaží stále více o ušetření času a díky tomu se víc a víc omezují podpůrné, organizační a analytické činnosti. Nakonec projekt sestává jen z programování a testování, které již nelze vypustit a které se prostě musí udělat.

Výsledkem ale je, že úspěch či neúspěch projektu závisí na štěstí a na skoro až otrocké práci zaměstnanců, kteří musí plnit někdy až nereálné termíny. V důsledku toho není vývoj dlouhodobě udržitelný (obvykle z důvodu velké psychické a časové zátěže na pracovníky, kteří po krátké době odcházejí). Firma pak utrpí mnohem větší ztráty (díky odchodů důležitých lidí), než by bylo dodržováním alespoň minimálních projektových zásad a v důsledku uklidněním projektové atmosféry a snížení pracovního stresu.

Také kvalita produktů takto vzniklých je velmi nízká a obvykle se jedná o verze, které jsou typu „rychle nasadit, zahodit a předělat“.

Charakteristika této fáze spočívá v absenci rozfázování projektu, spoléháním se na tzv. osobnosti, absence přesně definovaných kroků, které se dále štěpí v jednotlivých úrovních řízení. Protože projekt nemá definované fáze a pro vedení se stává neprůhledným (v projektu se orientují pouze určití zaměstnanci a to obvykle jen v omezené části), je nemožné jej řídit a jeho vývoj se ubírá jakoby vlastní živelnou cestou. V důsledku pak nelze garantovat, jak projekt dopadne, nelze ani pořádně zjistit v jakém stavu se nachází a tak případně klienta informovat o možném zpoždění případně o jiných událostech.

V dnešní době je žel poměrně velké množství firem na této úrovni (a nebo na druhé úrovni, které je pořád pokračováním této „černé schránky“). Díky tomu se stále znovu a znovu potýkají se stejnými problémy, které se snaží řešit personálními změnami případně výměnou dodavatelů a partnerů. Přesto tyhle kroky obvykle vedou pouze k uklidnění zvířených vod, obvykle po nějakém problémovém projektu, které takovéto subjekty mají prakticky neustále. Základem je uvědomit si chybu ve vlastní organizaci a snaha o skutečnou změnu. A jednou z možností, jak snížit své vlastní ztráty (přímé i nepřímé) je nasazení SW-CMM.

Druhá (repeatable) úroveň

Tato úroveň se dá označit jako pokročilejší verze první úrovně. Existují zde již základní manažerské procesy, které určitým způsobem projekt vedou a řídí jej na základě zkušeností získaných z předchozích projektů. Kromě toho se v projektu objevuje více kontrolních a zabezpečujících mechanizmů, jako je kontrola použití investic, kontrola termínů a kvality a v případě problémů existuje okamžitá zpětná vazba, která informuje o možných problémech.

Hlavním důsledkem těchto kroků jsou potom realističtější odhady pracnosti a časové náročnosti, finanční odhady, přesnější specifikace jednotlivých milníků a také lepší provázanost spolupráce pracovníků na jednotlivých úrovních řízení (již není takový efekt „zatmění“ mezi různými stupni řízení).

Pro vedení projektu, a případně pro klienta, je již možné do projektu v určitých fázích zasahovat a to v době jednotlivých milníků. Klient si může zkontrolovat co bylo provedeno, v jakém stavu se projekt nachází a podle toho se dohodnout s dodavatelem na dalších krocích. Přesto ale projekt je stále silně uzavřen a průběžná kontrola není možná.

SW-CMM definuje pro každou úroveň (kromě první úrovně) klíčové procesní oblasti (Key Process Areas), které mají být splněny aby mohla být daná úroveň splněna. Pochopitelně kromě těchto oblastí mohou firmy mít i své vlastní a nebo oblasti určené pro jinou úroveň. SW-CMM pouze určuje minimum, které je nutné pro uznání zvládnuté té které úrovně.

Procesní oblasti nutné ke splnění druhé úrovně jsou:

• Řízení požadavků (RM)
  • Určení požadavků, které má klient a vyjasnění, že dodavatel jim správně rozumí.
• Plánování softwarových projektů (PP)
  • Sestavení realizovatelného plánu, kde je vyhodnocena náročnost implementace a také projektového řízení. Asi každý, kdo někdy navrhoval nějaký projekt moc dobře ví, že tento bod je zcela zásadní a bez jeho kvalifikovaného zpracování nelze projekt úspěšně řídit.
• Sledování a vyhodnocování projektů (PT)
  • Vytvoří mechanizmů, které projekt zpřehlední tak, že v případě, že projekt se zásadní odchýlí od projektových plánů, je možné patřičně zasáhnout.
• Řízení subdodavatelů (SM)
  • Tomuto bodu se věnuje zvláštní pozornost v CMM, nebude zde popsán vzhledem ke složitosti.
• Ověřování kvality (QA)
  • Tento bod je úzce spojen s PT, kdy zde je kladen především důraz na ověřování kvality, „code-review“, testování atd. Pochopitelně vedení projektu je informováno o všech výsledcích díky zde získaným.
• Konfigurační řízení (CM)
  • Jeho cílem je vytvořit a udržovat integritu vyvíjených produktů v průběhu celého životního cyklu projektu.

Třetí (Defined) úroveň

Ve třetí úrovni jsou manažerské procesy dále rozvinuty a vylepšeny a především jsou dobře integrovány s dalšími procesy, především s vývojovými (sem patří hlavně analytická činnost). Všechny procesy jak manažerské tak vývojové jsou dobře zdokumentovány, řídí se podle standardů vývoje software, který je také definován v balíku CMM.

Organizace patřící do této úrovně jsou již poměrně sofistikovaně řízeny a zjednodušeně řečeno jsou srovnatelné s ISO9001 organizacemi. Důležitá je v tomto případě snaha o komplexní řízení vývojového procesu jako celku, tedy s ohledem na inženýrské činnosti, kontinuální vzdělávání zaměstnanců, koordinaci procesů atd. Projekt jako takový je stále méně závislý na jednotlivcích a spíše se jeví jako komplexní proces, kde ztráta určitého zaměstnance či dodavatele není problémem a minimalizuje problémy s tím spojené (tímto se již začíná zabývat úroveň 2 v bodě klíčové oblasti SM).

Třetí úroveň klientům garantuje již poměrně vysokou kvalitu produktů. I proto se na trhu můžeme setkat s požadavkem, kdy se od výherců konkurzů velkých a nebo hodně důležitých projektů vyžaduje smluvní závazek, že jejich subdodavatelé budou mít minimálně SW-CMM úroveň 3 nebo budou mít certifikaci ISO9001.

Podobně jako v předchozí úrovni, i pro třetí úroveň jsou v CMM určeny oblasti, které musí být splněny:

• Definování organizačních procesů (PD)
  • Vytvoření přehledu aktivit, které jsou přínosem pro celý proces vývoje.
• Vzdělávací program (TP)
  • Vytvoření přehledu znalostí i s ohledem na předpokládaný budoucí rozvoj společnosti a podle něj vést zaměstnance k dalšímu vzdělávání.
• Integrované řízení vývoje (IM)
  • Integrace vývoje software společně s projektovým řízení, na základě definovaných standardních procesů organizace.
• Vývoj softwarových produktů (PE)
  • Tento proces se snaží o korektní vedení vývoje softwarových produktů. V něm se definují a popisují všechny technické aktivity, jako je technická analýza, návrh řešení, kódování a testování.
• Koordinace projektových týmů (IC)
  • Cílem koordinace projektových týmů je vzájemně integrovat činnost různých vývojových skupin a t nejen inženýrských, ale i ostatních (definujících implementované procesy, kontrolních atd.). Cílem je co nejlépe uspokojit zákazníky, a proto se snažit o nejefektivnější propojení jednotlivých aktivit a v důsledku zrychlení jejich práce a zvýšení efektivity (snížení redundantních aktivit, optimální časové provázání atd.).
• Interní kontroly (PR)
  • Jedná se o velmi důležitou součást vývoje software, snažící se o odstranění chyb hned v nejranějším stádiu. Existuje mnoho různých metodologií, jak tyto kontroly provádět, ale to není předmětem tohoto článku (viz. např. „Handbook of Walkthroughs, Inspections, and Technical Reviews“, 3. vydání, 1990).

Čtvrtá úroveň

V případě čtvrté úrovně organizace definuje a určí kvantitativní kritéria, která slouží k ohodnocení kvality softwarových procesů a produktů. Cílem je vytvoření celopodnikové databáze, kde jsou shromažďovány z realizovaných projektů. Tyto data pak slouží k další analýze a na jejich základě lze předvídat vývoj projektů a počítat s možnými odchylkami. Manažeři potom mohou dělat korektní rozhodnutí podle skutečného stavu projektu, který mohou v každém okamžiku zjistit.

Procesy organizací na tomto stupni se dají označit jako předvídatelné a to právě z důvodu měřitelnosti stavu projektu. Proto je i snadné zjistit, zda a nakolik se jednotlivé fáze projektu liší od očekávání a podle toho provést korekční kroky a napravit případné odchylky. Společnosti, které pracují na této úrovni se vyznačují vysokou mírou kvality. I z tohoto důvodu je pouze velmi málo firem celosvětově certifikováno pro 4. a 5. úroveň.

Země	Počet organizací na 4. stupni	Počet organizací na 5. stupni
Austrálie	2	0
Kanada	0	1
Čína	0	2
Francie	1	0
Indie	28	46
Irsko	1	0
Izrael	1	0
Rusko	0	1
Singapur	1	0
USA	39	19

Přehled je platný pro květen roku 2002.

Pro zvládnutí čtvrté úrovně jsou definované tyto klíčové oblasti:

• Kvantitativní řízení procesů
  • Účelem je kvantitativní sledování projektů a vyhodnocování, jak jsou projekty plněny. Především se kvantitativní řízení procesů soustředí na sledování a měření procesů IM (Integrované řízení vývoje), IC (Koordinace projektových týmů) a PR (Interní kontroly).
• Řízení kvality (QM)
  • Řízení kvality se soustředí na stanovení kvantitativních cílů, které slouží pro měření kvality vyvíjených produktů. Tato měření se aplikují na činnosti provádění v PE (Vývoj softwarových produktů)

Pátá (Optimized) úroveň

Pátá, nebo optimalizovaná úroveň, se vyznačuje soustředěním se organizace na plynulé zlepšování dosavadních procesů. Snahou je identifikovat slabosti jednotlivých činností a proaktivně se snažit je odstranit. Je možné např. na základě analýz zjistit místa, kde lze snížit náklady použitím nových technologií, nebo např. rozhodnout i investicích do vzdělání a tím dále zlepšit efektivitu ostatních procesů.

Pro tuto poslední a nejvyšší úroveň jsou určeny následující klíčové oblasti:

• Prevence vad (DP)
  • Prevence vad si klade za cíl najít možné vady, při implementaci projektu, analyzovat tyto vady a zjistit jejich příčiny a ty se následně snažit odstranit.
• Řízení inovace technologií (TC)
  • Jak již název napovídá, účelem této klíčové oblasti je průběžně monitorovat technický pokrok a snažit se uplatit nové trendy, technologie a metodologie do vývojových procesů organizace. Tyto technologie pak nasazovat do organizace za účelem neustálého zlepšování procesů, snižování nákladů a zvyšování efektivity
• Řízení zdokonalování procesů (PC)
  • Zdokonalování procesů je se snaží o zajištění kontinuálního rozvoje všech procesů, zlepšování kvality a zkracování vývojového cyklu softwarových projektů. Přitom využívá poznatky získané z DP a TC a navzájem je koordinuje a prosazuje do celé organizace.

Závěr

V tomto úvodu jsem se pokusil uvést pouze základní seznámení s metodologií SW-CMM. Jistě chápu, že se asi pro mnoho čtenářů jedná o často jen abstraktní pojmy, které bych ale rád v dalších článcích rozšířil o konkrétní příklady nasazení a uplatnění CMM. Pak by mělo být zcela jasné, co jednotlivé (zatím jen abstraktní) body znamenají konkrétně v praxi a jak jasně a pevně mají definovaný svůj obsah i strukturu.

Kromě toho bych rád uvedl i srovnání mezi ISO9001 a SW-CMM či jinými protokoly a metodologiemi, na řízení kvality.

Metodologie SW-CMM je dnes nejmodernější a nejprogresivnější v porovnání s ostatními metodologiemi na řízení kvality v softwarovém průmyslu. Nejedná se ani zdaleka o obyčejné poučky pro manažery, ale o poznatky, jejichž uplatnění v praxi v důsledku šetří mnoho nákladů a především vedou k vývoji kvalitních softwarových produktů. Kromě toho i pro firmy, co se zabývají jen službami (jako je například naše firma), je tato oblast zcela zásadní, protože zahraniční klienti se orientují podle dvou hlavních kritérií – cena a kvalita. A zde pak rozhoduje právě potvrzení, že dodavatel (třeba i „outsourcingový“) je certifikován podle některé z uznávaných metodologií. Investice do nasazení takové metodologie (jako je např. CMM) se určitě vyplatí, protože pro klienti dostanou „hmatatelné“ důkazy kvality, kterou daná firma může nabídnout. A pak se vynaložené peníze do zlepšení kvality našich firem určitě vyplatí a nakonec z nich může těžit nejen samotná firma, ale především její klienti.