Faktory úspěchu řízení IT projektů v kostce

Největší umění při řízení softwarových projektů spočívá v hledání rovnováhy mezi mnoha vzájemně se vylučuj...


Největší umění při řízení softwarových projektů spočívá v hledání rovnováhy
mezi mnoha vzájemně se vylučujícími cíli a riziky tak, aby byly v maximální
míře uspokojeny požadavky zákazníka a koncových uživatelů. Z toho, že pouze
malé procento projektů je dokončeno se stoprocentním úspěchem, lze usoudit, že
to pro jejich ředitele není tak docela lehký úkol.
Ačkoli mají IT projekty své specifické vlastnosti, které jsou důvodem jejich
určité výlučnosti, stále lze na každý z nich pohlížet očima metodiky. Ta říká,
co musí být pro úspěch projektu manažerovi, ale i zbytku týmu vždy zřejmé:
Výstupy projektu: Již na základě smlouvy je možno stanovit finální výstupy
projektu. Někdy je třeba pro jejich vytvoření použít i dočasné mezivýstupy.
Stanovení nezbytných kroků k dosažení cílových výstupů tvoří základ
projektového plánu.
Termín: Termín dodání finálních výstupů bývá zakotven ve smlouvě. Z hlediska
bezpečnosti je dobré projekt rozdělit na několik menších částí (fáze, iterace),
které se dají snáze řídit. Části projektu jsou odděleny pomocí milníků, které
umožňují ověřit postup prací na projektu k pevně danému datu, a řídit tak úsilí
nezbytné k dosažení cíle. Ze splnění nebo nesplnění termínu a cíle milníku lze
posoudit aktuální stav projektu.
Složení a kapacita týmu: Definice výstupů a termínů jsou dobrým podkladem pro
projektový plán. K dokončení plánu je třeba navíc operovat s kapacitou a
znalostmi členů projektového týmu, na jejichž základě často dochází k
podstatným změnám v projektovém plánu. Znalosti a zkušenosti jednotlivých členů
týmu tak podstatným způsobem ovlivňují úspěch celého projektu.
Pracovní postup, nástroje: Každý člen týmu musí vědět, jakým způsobem se
podílejí výsledky jeho práce na celkovém výstupu projektu. Musí mít přehled o
tom, jak má využívat výstupy svých kolegů, jaké mají mít náležitosti a jak s
nimi má dál nakládat. Efektivitu práce v této fázi ovlivňuje podpora všech
disciplín softwarového vývoje pomocí odpovídajících nástrojů.

Nezbytná metodika
Řízení jakéhokoli procesu postrádá řád bez robustní, konzistentní a komplexní
metodiky. Ta popisuje veškeré činnosti v průběhu procesu vývoje nového
softwaru, určuje jednotlivé fáze tohoto procesu a výstupy, které signalizují
jejich úspěšné ukončení. Tím umožňuje průběžnou kontrolu softwarového vývoje z
hlediska dodržení kvality, kvantity, termínu a rozpočtu.
Jednou z nejznámějších metodik je Rational Unified Process (RUP), která
poskytuje flexibilní rámec pro metodický popis organizační struktury,
pracovních procesů a postupů, které daná organizace vykonává. Softwarový vývoj
stojí podle RUP na čtyřech základních pilířích pracovníci (Workers), činnosti
(Activities), pracovní procesy (Workflows) a výstupy (Artifacts). Definuje také
šest nejlepších praktik softwarového vývoje: iterativní vývoj softwaru, správu
a řízení požadavků, použití komponentové architektury, vizuální modelování,
průběžné ověřování kvality a řízení změn. Je to komplexní sada konceptů,
postupů, nástrojů a technik používaných v softwarovém inženýrství.
Na podobných principech jako RUP stojí i metodika společnosti LBMS. Existují
ale i další možnosti přístupu k řízení softwarových projektů například Critical
Chain, která je založena na principu plánování činností s co nejzazším termínem
počátku. Critical Path je zase metodou, která hledá a popisuje vztahy mezi
jednotlivými činnostmi, jež na sobě vzájemně závisejí. Pouze změna délky trvání
činnosti, která je na kritické cestě, ovlivňuje délku trvání projektu.
Metodologie COBIT (Control Objectives for Information and Related Technology)
zahrnuje obecně použitelný a všestranně aplikovatelný standard pro řízení
celého životního cyklu softwaru, který dělí do několika základních domén
(plánování a organizace, akvizice a implementace, dodávka a podpora,
monitorování). Pro každou takovou oblast definuje řídící procesy i odpovídající
kontrolní cíle.
Přes různost existujících metodik pro řízení softwarových projektů lze
konstatovat, že v současné době téměř všechny stojí na podobných základech jako
Rational Unified Process a liší se jen v drobnostech či použitém názvosloví.
Velké rozdíly mezi metodikami lze vypozorovat v míře jejich podpory pomocí
dalších nástrojů, a to jak v oblasti managementu, tak v oblasti vývoje a
provozu.

Nástroje pro řízení projektů
Téměř všechny metody řízení projektů jsou dnes podporovány počítačovými
programy s vysokým stupněm uživatelské přívětivosti, s relativně snadnou
obsluhou a s rozsáhlými možnostmi rozličných reportovacích nástrojů pro potřeby
pracovníků projektového týmu nebo managementu. Pokusím se některé z nich
stručně přiblížit.
Microsoft Project: Prostředí Project od Microsoftu podporuje plánování
jednotlivých úkolů na projektu i jejich definici. Vzniká tak mapa projektu
(tzv. WBS, Workbreakdown Structure), která zobrazuje dosažení projektových cílů
pomocí přijatých standardů a metodických postupů. Microsoft Project patří v
České republice k nejrozšířenějším systémům pro řízení projektů.
Primavera Project Planner: Tento nástroj firmy Primavera se svými vlastnostmi
do značné míry podobá webovému Microsoft Projectu. K výhodám tohoto systému
patří snadné zaškolení obsluhy díky předdefinování nejpoužívanějších funkcí,
možnost sumarizovat činnosti do balíků podle libovolného kritéria či vysoká
grafická hodnota výstupních sestav. Pro řízení a koordinaci všech projektů ve
firmě vyvinula Primavera produkt Primavera Enterprise.
Select Process Director a metodika Select Perspective: Select Process Director
společnosti Select Business Solutions přináší koncepci praktického uplatnění
standardizovaných postupů v rámci životního cyklu vývoje softwarových aplikací.
Pomocí repositories (knihovny projektových postupů) s XML rozhraním na
internetový prohlížeč usnadňuje sdílení znalostí v týmu, nabízí šablony, odhady
pracnosti atd. Tyto nástroje jsou využitelné pro opakovanou úspěšnou realizaci
podobných prací.
Metodika Select Perspective, standardně dodávaná s tímto produktem, představuje
moderní přístup pro vývoj a údržbu aplikací založených na komponentách.
Obsahuje množství procesních vzorů (patterns) určených pro různé typy projektů.
V současné době jsou podporovány tyto procesní vzory: reengineering ICT
(vybudování ICT týmu) včetně podpory práce na realizovaném systému; vývoj
webových řešení a inovace stávajících systémů.
UES (Unicorn Enterprise System): UES je intranetové řešení pro komplexní
podporu řízení týmů vyvinutý společností Unicorn. Svým uživatelům umožňuje
přehledně popsat organizační strukturu a definovat typické role a odpovědnosti
za tvorbu dokumentů v rámci týmů, metodicky popisovat různé kategorie dokumentů
včetně jejich životních cyklů i typických pracovních postupů. Každá informace
uložená v systému má přiřazeného svého vlastníka, který za ni zodpovídá.
Nadřízeným pracovníkům umožňuje delegovat úkoly a sledovat stav jejich plnění
nebo sledovat průběh a aktuální stav projektu. Všechny důležité úkoly, termíny
nebo akce systém sám sleduje a připomíná je odpovědným rolím. UES neodděluje
řídící a věcnou informaci, tzn. že přehledně zobrazuje úkol, jeho řešitele i
stav splnění.

Metodika a nástroje nestačí
Klíčovým faktorem pro úspěšnou realizaci a řízení projektů již dávno nejsou
pouze znalosti a zkušenosti projektového manažera, případně aplikace ověřených
pracovních postupů (metodika). Úspěch nezaručí ani podpora pracovních postupů
pomocí nástrojů. Skutečnost stále více ukazuje, že v současné době závisí
úspěch projektů na následujících oblastech:
schopnost sdílet informace v týmu
schopnost sdílet znalosti v týmu
průběžné ověřování kvality
měření kvality a postupu na projektu

Sdílení informací
Psát o sdílení informací v projektovém týmu se může zdát neefektivní, avšak
realita je bohužel poměrně neutěšená. Mnoho společností funguje na principu
plánování projektů v Microsoft Projectu nebo jiném nástroji, členové týmu
používají pro komunikaci a zadávání úkolů e-mail, přičemž finální výstup
produkují v textovém editoru. Někdy je pro informování členů o stavu projektu
či dalším postupu ještě používán projektový portál.
Toto pojetí řízení projektu chápe výstupy projektu a stav jejich řešení jako
dvě zcela odlišné a oddělené záležitosti. Výhodou takového řešení může být jeho
rychlost i schopnost pružně reagovat na změny, velkou nevýhodou do budoucna
naopak neschopnost provázat výstup projektu a aktuální stav v jednom systému,
nulová možnost provazovat informace mezi sebou (např. formou odkazů),
nejednoznačné kompetence, nejednoznačné umístění nebo problém se správou verzí.
Tuto problematiku lze vyřešit informačním systémem, který neodděluje výstup
projektu a řídící informaci o něm.

Sdílení znalostí
Ještě důležitější než sdílení informací je sdílení znalostí. Na začátku (v
ideálním případě) vzniká projekt poskládáním různých odborníků z různých
oblastí do jednoho týmu, který má za úkol vyřešit stanovené problémy. Často se
záměrně stává, že je tým rozšířen i o několik nováčků aby se zaučili, případně
si i rozšířili své znalosti. Ne vždy s tím bohužel rozpočet a termíny projektu
počítají. Zaučení nových členů týmu se děje převážně ze strategických důvodů.
Sdílení informací má svá úskalí zkušenější členové týmu se musejí oprostit od
rivality a obavy ze ztráty výlučného postavení na základě svých znalostí.
Efektivitu zaškolení či průběžného vzdělávání pracovníků lze zvýšit informačním
systémem na principu intranetové báze znalostí, kde jsou znalosti i důležité
informace přehledně uspořádané.
Je velmi těžké přinutit pracovníky takovou bázi vyrobit a udržovat, nicméně ve
svém výsledku tato báze podporuje sdílení znalostí a dovedností napříč
projekty, prohledávání již realizovaných projektů a v neposlední řadě omezuje
zbytečné vynalézání již vynalezeného.

Ověřování kvality
O důležitosti ověřování kvality výstupů již bylo napsáno mnohé, ale v řadě
případů stále nedochází k jejímu důkladnému prozkoumání. Proces ověřování
kvality by měl fungovat tak, že existuje role (nejčastěji konfigurační manažer
nebo integrátor) zodpovědná za definici struktury a kvality výstupů. Tato role
stanoví například jmenné konvence, adresářovou strukturu, požadavky na
dokumentaci, množství a kategorii přípustných a známých chyb.
Kvalitu výstupu nelze ověřovat až na konci projektu, ale je nutno ji provádět
průběžně. Proto by již v průběhu vývojového procesu mělo docházet k tvorbě
pravidelných buildů, které ověří kvalitu a stabilitu vývojářské práce (jde tedy
o testovatelné buildy).

Měření úspěšnosti
Za úspěšný projekt lze považovat takový, u něhož byly vytvořeny a dodány
všechny výstupy kvalitně, včas a v rozpočtu. K tomu, aby se manažer zorientoval
v aktuálním stavu projektu, používá různé metriky, jež mohou mít číselný,
slovní či subjektivní charakter. Za základní metriky projektového řízení lze
považovat:
Kvalitu zabezpečení maximální použitelnosti výstupů.
Kvantitu vytvoření předem dohodnutého množství výstupů.
Termín předání výstupů v souladu se stanoveným termínem.
Rozpočet vytvoření výstupů v požadovaném rozpočtu.
Správná aplikace výše uvedených metrik pomáhá manažerovi zhodnotit aktuální
stav projektu. Je přípustné a samozřejmě i správné tuto množinu rozšířit o
další metriky například kategorii a počet chyb aplikace atd. Metriky pak
neslouží pouze projektovému manažerovi pro poskytování informací svým
nadřízeným, ale i pro prezentaci průběhu projektu zákazníkovi. Zde je na
zvážení, zda reportovat všechny měřené a sbírané metriky na projektu, nebo je
rozdělit na interní a externí což je v praxi častější případ.
Pro úspěšné řízení projektů již dávno nestačí metodika a nástroje, ale je třeba
se mnohem více orientovat na sdílení informací, ověřování kvality, měření
aktuálního stavu a zaškolování lidí. Nacházíme se v období, kdy mnoho
společností sleduje pouze návratnost vložených investic a při honbě za
maximální výší zisku se odvrací od svých zaměstnanců. To je ovšem zásadní
chyba, neboť vzdělaní, loajální a dobře motivovaní odborníci jsou jedním ze
základních předpokladů pro úspěch v podnikání.
Autor pracuje jako ředitel realizační divize Unicorn Consulting.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.