Metodika řízení projektů střední velikosti

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Metodika řízení projektů střední velikosti (se zaměřením na oblast vývoje software) Bakalářská práce

Autor:

Jiří Krůta Informační technologie, Manažer projektů informačních systémů

Vedoucí práce:

Praha

Ing. Václav Šebek, CSc.

červen 2009

Prohlášení Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené literatury.

V Praze dne

Poděkování Na tomto místě bych rád poděkoval vedoucímu mé práce Ing. Václavu Šebkovi za jeho trpělivost, ochotu, odborné rady a podnětné připomínky při tvorbě práce.

Anotace Metodiky pro řízení projektů jsou silným nástrojem pro efektivní řízení projektů. Metodik existuje velké množství včetně těch, které jsou zaměřeny na konkrétní úlohy a problémy. Výběr a použití vhodné metodiky není jednoduchou záležitostí. Práce popisuje vybrané metodiky pro řízení projektů a pro vývoj software a jejich srovnání. Na konkrétním projektu je pak dokumentováno použití různých metodik pro vývoj software včetně diskuse parametrů a okolností, které výběr konkrétní metodiky ovlivňují. V závěru práce je pak na tomto projektu poukázáno na problémy, které bylo nutné v průběhu projektu řešit a které jsou použitím zvolených metod vývoje a řízení přímo či nepřímo ovlivněny. Tento souhrn je doplněn diskusí možných dalších řešení a vhodnosti použití metodik v projektovém řízení a vývoji software.

Annotation Project management methodologies are a powerful tool for effectively managing projects. Different methodologies are specifically suited for various professional fields. Choosing the right methodology can prove difficult. This paper describes and compares selected project management and software development methodologies. My work describes a practical project undertaken by our company during which different software development methodologies were chosen for different purposes. The main body of work describes and analysis these choice and includes a discussion of parameters which influences our choice of methodology. The last chapter of the main body describes practical issues which arose during the projects due to use of the chosen methodologies. The Conclusions include an analysis of our results and suggestions for improvement. Based on our results this paper tries to determine which methodology is optimal for the different situations which could be encountered during software development.

Obsah Úvod

8

1.

9

2.

3.

4.

5.

6.

Definice projektu, projekt střední velikosti 1.1.

Klasifikace projektu dle velikosti

1.2.

Projektové řízení

9 10

Přehled metodik řízení projektu

11

2.1.

PMBOK

11

2.2.

PRINCE2

14

2.3.

Srovnání PMBOK a PRINCE2

16

Parametry projektu

18

3.1.

Kvalita, kvantita, termín a rozpočet

18

3.2.

Úspěšnost projektů

18

3.3.

Metriky

19

Přehled metodik vývoje software a metodiky řízení projektů

20

4.1.

Vodopádový model vývoje software

22

4.2.

Iterační modely

23

4.3.

Agilní metodiky

23

Životní fáze projektu

26

5.1.

Inicializační procesy

26

5.2.

Plánovací procesy

27

5.3.

Kontrolní procesy

28

5.4.

Realizační procesy

28

5.5.

Ukončovací procesy

29

Popis konkrétního projektu 6.1.

30

Příprava projektu (inicializační fáze)

6

31

6.1.1. 6.2.

Zhodnocení fáze

32

Návrh systému a plánování (plánovací procesy)

32

6.2.1.

Rozfázování projektu

33

6.2.2.

Plánování kapacit, harmonogram

34

6.2.3.

Struktura projektového týmu a role

35

6.2.4.

Zhodnocení fáze

36

6.3.

Vývoj systému (realizační procesy)

37

6.3.1.

Technologie

40

6.3.2.

Zhodnocení fáze

40

6.4.

Řízení vývojového cyklu (kontrolní procesy)

6.4.1. 6.5.

43

Uvádění do provozu, předávání (ukončovací procesy)

6.5.1. 6.6.

Zhodnocení fáze

42

Zhodnocení fáze

43 45

Zhodnocení projektu, úspěchy a neúspěchy, reflexe

46

Závěr

50

Seznam použité literatury

51

Seznam použitých zkratek

53

Seznam obrázků

54

Seznam tabulek

54

7

Úvod Velké množství projektů končí neúspěchem, jehož důvodem je nedostatečný nebo chybný projektový management. Projektový management je disciplína poměrně složitá, kterou se nelze naučit z rychlokurzu, z jedné knihy nebo za několik dní. Projektový management je soubor znalostí a dovedností, který umožňuje zkvalitnit výsledky a průběh projektů, umožňuje vnést do prvotního chaosu řád a organizaci. Stejně tak, jak je rozsáhlý obor projektového managementu, je rozsáhlé množství informací a literatury o tomto tématu. Informace jsou dostupné formou nejrůznějších pojednání, odborných článků, příkladů, rad - a v neposlední řadě - metodik. Vyznat se v tomto množství informací nemusí být jednoduché. Pozorný čtenář navíc po čase zjistí, že se většina informací opakuje. To však není dáno nedostatkem inspirace autorů, ale jednoduchým faktem, že určité informace z této oblasti jsou důležité a obecně platné. Tato práce je zaměřena na vybrané metodiky pro řízení projektů – PMBOK a PRINCE2 – a jejich srovnání. Tyto metodiky pro řízení projektů jsou pak doplněny popisem vybraných metodik pro vývoj software jakožto dalšího stavebního kamene, o který se lze opřít při realizaci a řízení projektů, jejichž cílem je vývoj a dodávka software. Dalším cílem práce je na konkrétním projektu ukázat šíři podmínek, které o použití metodiky mohou rozhodovat, a naopak prezentovat vlastnosti, které jsou výběrem metodiky zpětně ovlivněny. V závěru práce se nevyhnu ani subjektivnímu hodnocení vhodnosti použití jednotlivých metodik a jejich důležitosti pro samotný projekt a způsobu jejich volby.

8

1.

Definice projektu, projekt střední velikosti

Projekt [1] je činnost, v rámci níž dochází k jedinečnému organizování lidských, finančních a materiálních zdrojů, realizaci určitých činností a prací, v rámci vymezeného času a financí, při dodržení standardních postupů, s cílem dosažení definovaných kvalitativních a kvantitativních parametrů výsledného produktu, služby, díla. Projekt je definován časem, zdroji a cílem. Tyto tři veličiny tvoří tzv. projektový trojimperativ – označení značí skutečnost, že při změně jedné z veličin je nutné přehodnotit ostatní dvě. Projektem však není jakákoli činnost, u které by se mohlo zdát splnění výše definovaných podmínek. Omezení časem a jedinečnost výstupů projekt odlišuje od procesu. Projekt tedy vždy musí být časově ohraničen. Projektem rovněž nejsou činnosti, které nenaplňuje zmíněnou jedinečnost, tedy činnosti prováděné opakovaně a dle ověřeného a popsaného postupu.

1.1.

Klasifikace projektu dle velikosti

Klasifikace projektu dle jeho velikosti je vždy relativní a závisí na oboru a typu projektu, který je realizován. Za střed pak lze považovat projekty, u nichž rozsah zdrojů a času či cíl odpovídá jakémusi průměru běžně realizovaných projektů. Je jasné, že středně velký projekt výstavby business centra výrazně překonává i ten největší projekt rekonstrukce rodinné vily. Velikost projektu lze rovněž hodnotit z několika pohledů – času, financí, množství lidské práce, počtu subjektů v projektu zapojených. Z toho vyplývá, že jeden unikátní projekt může být klasifikován ze dvou různých pohledů zcela odlišně. Pro účely této práce je tak nutné definovat podobu středně velkého projektu v oblasti vývoje software. Jako nejvhodnější parametr se jeví v této oblasti často používaná veličina – člověkoden (ČD). Člověkoden představuje jeden pracovní den specialisty, který na projektu pracuje. Projekty střední velikosti začínají okolo 500 ČD a mohou končit u hodnot několikrát vyšších, řádově okolo 5 tis. ČD. Důležité pro klasifikaci projektu je i to, kolik jednotlivých osob se projektu účastní. O projektech střední velikosti můžeme hovořit při současném zapojení zhruba 5 až 15 osob dedikovaných alespoň z 50% jejich kapacity pro projekt (nezahrnujeme tedy lidské zdroje dodávající projektu pouze specifické a krátkodobé činnosti). 9

Výše definovaný rozsah středního projektu však ani v oblasti vývoje software nemusí platit bezpodmínečně. Je jisté, že jinak budeme nahlížet na středně velký projekt korporátních webových stránek, jinak na středně velký projekt workflow systému a jinak samozřejmě na středně velký projekt ERP systému pro celou společnost. Měřítko je vždy, jak už bylo uvedeno výše, závislé na určitém vzorku běžně realizovaných projektů. Z tohoto tvrzení pak je nutné odvodit doplnění uvedené klasifikace středního projektu, které je relevantní pro vývoj a implementace korporátních informačních systémů a jejich modulů.

1.2.

Projektové řízení

Projektové řízení [2] je aplikace znalostí, dovedností, nástrojů a technik na projektové aktivity, které vedou ke splnění požadavků projektu. Cílem projektového řízení je efektivní dosažení stanovených cílů ve stanoveném čase, rozpočtu a rozsahu. Dle [1] jsou příčinami neúspěšnosti softwarových projektů především nedokonalá správa požadavků, nejasná komunikace, křehká architektura systému, podcenění složitosti řešené úlohy, skryté nesrovnalosti mezi požadavky, návrhem a implementací, neadekvátní testování, subjektivní odhad stavu projektu, nepředcházení rizikům, nekontrolované provádění změn, nedostatečná automatizace a další. Tvorba software je natolik složitým procesem, že je pro zajištění úspěchu nezbytné, aby týmy zabývající se tvorbou software používaly nějakou metodiku – soubor pravidel, principů a postupů, které ve výsledku ovlivňují efektivnost celé tvorby a napomáhají k zlepšení organizace práce a vedou k dosažení vytyčeného cíle – úspěšnému dokončení projektu.

10

Přehled metodik řízení projektu

2.

Metodik pro řízení projektů je velké množství, jsou nejčastěji vydávány organizacemi a sdruženími, které se zabývají podporou a rozvojem projektového řízení a jeho kontinuálním zlepšováním. Z nejznámějších můžeme jmenovat Project Management Institute (PMI) nebo International Project Management Association. Tyto organizace vydávají své metodiky, mají členskou základnu a nabízejí i certifikaci na různé stupně. Mezi nejrozšířenější a neznámější metodiky projektového řízení patří: •

PMBOK – Project Management Body Of Knowledge (vydaná PMI)

•

PRINCE2 – Projects IN a Controlled Environement (zaměřena na IT projekty)

•

RUP – Rational Unified Process (zaměřena na projektové řízení obecně i vývoj software)

•

ISO 10006 (zaměřena na kontrolu kvality)

•

CMM - Capability Maturity Model

V tomto dokumentu se zaměříme pouze na základní vlastnosti PMBOK a PRINCE2 a jejich stručné srovnání. Obě tyto metodiky jsou vhodné pro řízení projektů střední velikosti.

2.1.

PMBOK

PMBOK [2] je metodika vytvořená PMI a dnes dostupná již ve své čtvrté revizi. Metodika je placená a lze ji objednat na www.pmi.org. PMBOK je rozděleno na 9 znalostních bází, které tvoří dohromady model projektového řízení v podání této metodiky. Metodika rovněž poměrně podrobně definuje životní cyklus projektu a jeho fáze, popisuje vazby mezi těmi těmito fázemi – přípravou, plánováním, realizací, kontrolou, ukončením.

11

Příprava

Plánování

Realizace

Kontrola

Ukončení

Obrázek 1: Životní cyklus projektu dle PMBOK

Dále PMBOK [12] definuje dalších několik desítek procesů, které jsou napojeny na jednotlivé životní fáze projektu. Procesy jsou děleny do procesních skupin, v každé pak jsou procesy hlavní a pomocné. Skupiny obsahují inicializační, plánovací, realizační, kontrolní, ukončovací procesy. Obrázek 2 zobrazuje rozložení aktivit souvisejících

Úroveň aktivity

s jednotlivými skupinami v čase.

Obrázek 2: Aktivita jednotlivých skupin procesů v čase

Jednotlivé procesy jsou standardem definovány podrobněji v přesné struktuře, která obsahuje: •

Cíle (popis procesu, jeho cíle a smysl)

•

Vstupy (obsahují požadavky, které jsou pro realizaci procesu třeba)

12

•

Výstupy (definují výstupy pro ostatní procesy nebo okolí projektu)

•

Nástroje a techniky (rozšiřují proces a metody dosažení cíle, stanovují nároky na osoby zapojené do projektu)

•

Metriky (umožňují měřitelnost a určují jak vyhodnocovat daný proces)

Jak bylo uvedeno, metodika definuje 9 znalostních oblastí, které je potřeba v každém projektu realizovat. Pro tyto oblasti pak jsou opět definovány procesy a každá znalostní báze je rozdělena na další části. Těmito znalostními bázemi jsou: •

Project integration management (integrace projektu a její řízení) Obsahuje metody pro koordinování a plánování projektu, změny a změnová řízení a jejich zpracování v projektu, změny plánu času, zdrojů, rozpočtu a obsahu projektu (scope).

•

Project scope management (řízení obsahu a rozsahu projektu) Obsahuje

procesy

pro

stanovení

a plánování

rozsahu

projektu,

tvorby

harmonogramu, validace rozsahu a to v různých fázích a etapách projektu. •

Project time management (řízení času) Obsahuje procesy pro plánování času ve vztahu k ostatním atributům projektu (zdroje, finance, rozsah), odkazuje na nástroje pro plánování času projektu, metody pro časové odhady náročnosti.

•

Project cost management (řízení nákladů a financí) Procesy zaměřené na odhadování a plánování nákladů a zdrojů, odhadování nákladů, jejich kontrolu a vazby na další atributy projektu.

•

Project quality management (řízení kvality) Obsahuje procesy s důrazem na řízení a kontrolu kvality projektu, nikoli produktu samotného (to je předmětem první znalostní oblasti).

•

Project human resource management (řízení lidských zdrojů) Obsahuje procesy zaměřené na organizování lidských zdrojů, jejich získávání, rozvoj a motivování.

•

Project communications management (řízení komunikace)

13

Definuje procesy pro plánování komunikace, distribuci informací. Nastavuje podobu reportingu a dalších administrativních úkolů s vazbou na všechny subjekty do projektu zapojené. •

Project risk management (řízení rizik) Risk management zahrnuje procesy pro hledání, klasifikaci a kvantifikaci rizik, jejich sledování, definování zodpovědností a identifikaci nových rizik.

•

Project procurement management (řízení dodávky) Procesy pro řízení dodávky spočívají v dokumentaci dodávky (produktu), procesech směrem k dodavatelům, výběrových řízeních, sledování dodávek, uzavírání a správě smluv.

Jak je vidět ze stručného přehledu vlastností metodiky, obsahuje všechny důležité prvky pro řízení všech oblastí projektu. Jejími výhodami jsou navíc velmi dobrá přehlednost, návaznost na ISO 10006, propojení všech životních fází projektu s oblastmi řízení a jednotlivými etapami projektů. Někteří kritici této metodice vytýkají přílišnou univerzálnost a malou konkrétnost v některých částech. Metodika nenabízí vzory a šablony a její implementace je tak velmi otevřená směrem k uživatelům.

2.2.

PRINCE2

PRINCE2 [3], [4] je metodika více zaměřená na ICT projekty. Jak napovídá název, jedná se o druhou revizi. Tato metodika vznikla ve Velké Británii a je zde také používána jako standard pro projekty ve státní správě. Metodika poskytuje pouze určitý rámec, který je primárně zaměřen na definování správných procesů, rolí, odpovědností a životního cyklu projektu, nicméně již příliš neakcentuje manažerské dovednosti, řízení lidí, vyjednávání, řešení konfliktů. Životní cyklus je v kontrastu k PMBOK definován trochu odlišně, což je dáno trochu odlišným navázáním procesů a komponent (viz Obrázek 3).

14

Obrázek 3: Životní cyklus PRINCE2 a návaznost jeho částí

Struktura metodiky staví na procesech, kterých je stejně jako v případě PMBOK také několik desítek. Dále je v metodice několik komponent, které ohraničují jednotlivé oblasti projektového řízení a jsou velmi blízké znalostním oblastem z PMBOK. Procesy jsou definovány velmi podrobně a každý proces obsahuje: •

Základní informace (popis procesu, jeho cíle a smysl)

•

Definice procesu a jeho popis

•

Škálovatelnost (varianty procesu dle různé projekty)

•

Role, odpovědnosti

•

Vstupy (obsahují požadavky, které jsou pro realizaci procesu třeba)

•

Výstupy (definují výstupy pro ostatní procesy nebo okolí projektu)

•

Metriky (jak vyhodnocovat daný proces)

•

Návody (doporučení a techniky k danému procesu)

Komponenty jsou rozčleněny na: •

Organization (organizace) Komponenta se zaměřuje na vymezení vztahů mezi subjekty, jednotlivými členy týmů.

•

Plan (plánování)

15

Obsahuje techniky a metody pro plánování projektů včetně všech vazeb s plánem souvisejících a komplexně pokrývá celým životní cyklus projektu. •

Control (řízení a kontrola projektu) Komponenta obsahuje procesy pro řízení a monitoring projektu, včetně reportingu.

•

Business case (obchodní případ) Prolíná životní cyklus projektu s obchodním pohledem na projekt, obsahuje procesy pro rozfázování projektu, správu fází a dohled nad životním cyklem projektu.

•

Management of Risk (řízení rizik) Stejně jako v PMBOK se komponenta zaměřuje na řízení rizik, jejich sledování, vyhodnocování a ošetření.

•

Configuration management (řízení konfigurace) Definuje procesy pro kontrolu konfigurace – výsledného produktu. Obsahuje vazbu na další procesy, které se týkají ostatních oddělení, jako např. marketing, logistika, výroba, finance.

•

Change control (řízení změn) Obsahuje procesy zaměřené na identifikaci a řízení změn, jejich vazbu na plánování.

Metodika PRINCE2 navíc obsahuje poměrně rozsáhlé přílohy, které se dělí na 5 částí a popisují detailně všechny procesy, role, rizika, šablony dokumentů a další doporučení pro samotné zpracování projektů.

2.3.

Srovnání PMBOK a PRINCE2

Z popisu obou metodik vyplývá, že jsou velmi komplexní. Každá má své zastánce i odpůrce. Následující srovnání je tedy spíše průřezem častých výtek nebo pozitiv uváděných v odborné literatuře a článcích [2], [12], [13].

16

PMBOK

PRINCE2

Pozitiva:

Pozitiva:

Širší rozsah záběru pro více typů projektů.

Hlubší záběr v oblasti rolí, kompetencí.

Slouží jako stavební kámen pro firemní Zaměření na produkt, zákazníka, uživatele. metodiku. Přehlednost, struktura.

Šablony a vzory dokumentů. řízení

Kvalitní

změn,

životní

cyklus

Vhodně propojuje životní fáze projektu projektu. s řídícími strukturami. Podporuje ISO 10006. Negativa:

Negativa:

Neexistence šablon.

Někdy

Částečně obecnost.

svázanost (pro čtenáře bez zkušeností

přílišná

složitost,

provázanost,

s metodikami). Názvosloví

úplně

neodpovídá

standardům v projektovém řízení. Nevhodný pro menší projekty. Tabulka 1: Srovnání metodik PMBOK a PRINCE2

17

běžným

3.

Parametry projektu

3.1.

Kvalita, kvantita, termín a rozpočet

Hlavní parametry projektu jsou: •

Kvalita

•

Kvantita

•

Termín

•

Rozpočet

Kvalita představuje splnění stanovených parametrů výsledného produktu. Pro vyhodnocení kvality je nutné zavést metriky, pomocí nichž bude kvalita vyhodnocována. Vyhodnocování kvality však musí probíhat v projektu kontinuálně, jinak nelze nikdy zajistit její naplnění. Kvantita definuje rozsah produktu, díla. Definice kvantity je většinou jednodušší, nicméně v projektech často narážíme na fakt, kdy kvantita není na začátku projektu vlastně známa. Termín určuje jasný časový milník, ke kterému mají být projekt nebo jeho části v definované kvalitě a kvantitě dokončené. Rozpočet představuje finanční omezení projektu, vztažené vždy ke kvalitě, kvantitě a termínu. Pro tyto 4 pojmy se též používá zkratka KKTR [9].

3.2.

Úspěšnost projektů

Úspěšnost projektu velmi úzce navazuje na KKTR. Kritéria úspěšnosti projektu jsou [1]: •

Poskytuje svoji funkčnost a naplňuje definované cíle

•

Splňuje definované požadavky (z hlediska termínů, nákladů a kvality)

•

Je ziskový pro zhotovitele

•

Uspokojuje potřeby a zájmy všech zainteresovaných stran

Nepřímá kritéria úspěšnosti projektu (i když vysoce kritická) jsou:

18

•

Kvalifikace projektového týmu

•

Způsob řešení konfliktů

•

Motivace

•

Styl managementu a způsob řízení projektu

3.3.

Metriky

Metriky [6], [10] úzce souvisí s kvalitou díla a cílem díla. Pro obě tyto veličiny je nutné definovat metriky, které budou v průběhu projektu vyhodnocovány a které budou v případě změny požadavků na kvalitu nebo cíl projektu revidovány. Metriky pomáhají vyjádřit aktuální stav projektu, tzn., ve které fázi projekt je, co je hotovo, co zbývá dokončit, v jaké fázi jsou které úkoly. Velmi často jsou tak navázány na plán projektu. Metriky musí být objektivně vyhodnotitelné, jinak ztrácejí svoji cenu. Použití konkrétních metrik je otázkou konkrétní metodiky, nicméně principielně lze hovořit o metrikách sledujících: •

Hotovost díla, jednotlivých úloh

•

Počet chyb z testů, úspěšnost odstraňování chyb

•

Doba odezvy opravy chyb

•

Produktivita personálu

•

Změny a změnová řízení, doba odezvy na požadavek změny, počet změn v iteračních cyklech, množství měněných funkcí

•

Počty nových požadavků mimo scope projektu, vliv na plán a vývoj

19

4.

Přehled metodik vývoje software a metodiky řízení projektů

Je jasné, že neexistuje univerzální metodika použitelná pro všechny softwarové projekty a vyhovující každému vývojovému týmu. Vzhledem k rozdílnosti projektů, jejich technologické odlišnosti, nárokům na ně, zapojení rozdílných osobností s rozdílnou znalostí a zkušeností neexistuje univerzálně použitelná a nejlepší metodika. I nadále se tak bude možné setkávat s mnoha metodikami, které sice budou stavět na stejných principech a částečně se překrývat, nabídnou však své specifické vlastnosti. Metodiky pro vývoj software se z principu zaměřují na samotný vývojový proces se všemi jeho etapami, je vhodné je doplňovat dalšími metodikami pro řízení projektů, které na druhé straně postihují širší problematiku řešenou projektovým vedoucím. Z klasických metodik vývoje SW projektů můžeme jmenovat např.: •

Vodopádový model životního cyklu

•

Spirálový model životního cyklu

•

Metodika Rational Unified Process

•

Metodika Unified Software Development Process

Mezi agilní metodiky patří [6], [8], [10]: •

Extrémní programování

•

SCRUM Development Process

•

Microsoft Solutions Framework

•

Lean Development

•

Feature Driven Development

•

Test Driven Development

•

Metodika Crystal

•

Adaptive Software Development

•

Dynamic Software Development Method

20

Hlavními rysy všech těchto metodik jsou: •

Důraz na pokrytí celého životního cyklu softwarového projektu.

•

Využívání vizuálního a datového modelování.

•

Organizovanost a systematičnost při tvorbě software.

•

Variabilitu pro různé typy projektů.

•

Snaha o automatizaci procesů.

•

Využívání podpůrných nástrojů pro tvorbu software.

•

Objektově orientovaná terminologie.

Klasické metodiky tyto vlastnosti navíc doplňují o důraz na dokumentaci požadavků a vývoje. Agilní metodiky [6], [8], [10] naopak kladou důraz na iterační proces, verifikování díla po malých částech a flexibilitu při změnách zadání. Důraz je kladen na komunikaci a souhru týmu a všech jeho členů. Agilní metodiky jsou dnes poměrně moderní a hojně používané. Důvodem pro to je poskytování lepších výsledků při vývoji software, nicméně za předpokladu dodržení dvou hlavních pravidel. Prvním z nich je správné uchopení metodik a jejich naplňování - nelze očekávat, že tyto metodiky samy o sobě zlepší výsledný produkt. Dalším pravidlem je aplikování na projekty, které jsou pro tyto metodiky vhodné. Jedná se o projekty, kde interakce s uživatelem vytváří konečné dílo (typicky uživatelský aplikační software a IS). Naopak nevhodné jsem agilní metodiky pro díla, která musí být silně dokumentována, mají dopředu jasně definovaná zadání, kladou vysoký důraz na bezpečnost (typicky interface systémů, matematické výpočty, řídící programy hardware, šifrovací metody). Co samozřejmě použití agilních metodik nahrává je i přístup zadavatelů vývoje software, kteří nejsou často schopni dopředně definovat finální podobu software nebo ji navrhnout s analytikem a vyhovuje jim iterační postup při definování požadavků na software a jeho vývoji. Ve stručnosti se zaměřme na hlavní rysy vodopádového modelu vývoje sw a extrémní programování, jako vybrané reprezentanty dvou hlavních kategorií.

21

4.1.

Vodopádový model vývoje software

Vodopádový model má několik podob a modifikací, nicméně základní varianta vychází z hlavního předpokladu – všechny etapy vývoje následují lineárně za sebou. Systémové požadavky Softwarové požadavky

Analýza

Návrh

Kódování

Testování

Spuštění

Obrázek 4: Schéma vodopádového modelu vývoje

Síla tohoto modelu v jeho jednoduchosti. Negativ je však příliš mnoho – nemožnost činit změny v průběhu projektu, a pokud ano, znamená taková změna velmi vysokou cenu. Navíc na prvních třech resp. čtyřech fázích modelu velmi výrazně závisí úspěch projektu – zavlečená chyba se opravuje již velmi těžko. Model však přináší i určité výhody – díky rozsáhlé dokumentaci přináší výhody při často se měnícím týmu, nutnosti předat projekt jinému dodavateli nebo na projekt navázat další etapou. V takovéto podobě se však vodopádový model téměř nepoužívá, daleko vhodnější je použít v nějaké z modifikací. Některé modifikace např. sdružují dvě sousední části, takže lze zpětně opravovat a revidovat předchozí část, jiné zase přidávají zpětnou vazbu mezi některými částmi modelu, které rozšiřují projekt o požadavky na systém, předběžný design, návrh rozhraní, plán testování a další. Jedna z modifikací rozděluje vodopádový model na meziprojekty, což ve své podstatě znamená dekompozici a realizaci některých částí odlišně. Výhodou je, že části, u kterých se předpokládá vliv na ostatní, se realizují nejdříve a poté je přistoupeno k návrhovým fázím dalších meziprojektů. To zajistí zpětnou vazbu, nicméně klade poměrně vysoké nároky na správu celého projektu.

22

4.2.

Iterační modely

Jakýmsi mezičlánkem mezi vodopádovým modelem a agilními metodikami jsou iterační modely vývoje software. Typickým reprezentantem je spirálový model [11]. Implementace Plánování další fáze

Vývoj, Implementace

Návrh Hodnocení

Cíl Analýza

Obrázek 5: Fáze spirálového modelu

Software je v tomto modelu vyvíjen v iteracích – krocích, které se opakují a mohou tak stavět na poznatcích z fází předchozích, popř. je revidovat. Výhodou tohoto modelu je možnost spuštění implementačních fází v době, kdy je specifikována a navržena část systému a funkcí, navíc již v prvních iteracích modelu je směřován důraz na finální používání systému. Velkou váhu klade metodika na důslednou analýzu rizik a její revizi.

4.3.

Agilní metodiky

Agilních metodik je celá řada. Jako zástupce agilních metodik je zde vybrána úmyslně metodika Extrémní programování (XP) [6], [8], [11] – je nejznámější metodou a také některé její postupy jsou natolik extrémní, že XP vytvořily množství příznivců i zapřisáhlých odpůrců. Na zásadní vlastnosti bych rád upozornil i v tomto stručném přehledu. Metodika obsahuje několik stavebních kamenů, které ji charakterizují a odlišují od i metodik klasických a částečně i od ostatních agilních metodik: •

KKRT definováno pouze na úrovni tří veličin

23

Zadavatel projektu definuje vždy pouze tři z těchto atributů, vývojový tým pak čtvrtý. Model tak předpokládá, že pokud si zákazník vybere např. čas, kvantitu, rozpočet, vývojový tým nadefinuje k těmto atributům kvalitu, kterou je schopen za daného termínu, rozpočtu a rozsahu schopen dodržet. •

Komunikace Metodika dává na komunikaci velký důraz, považuje ji za důležitější než dokumentaci. K efektivní komunikaci je v metodice směřováno vše – doporučená velikost týmu, jeho zázemí, způsob práce týmu.

•

Jednoduchost Dalším hlavním principem je vytváření jednoduchých zadání, jednoduchého kódu, jednoduchých řešení. Pokud něco bude potřebovat složitější řešení, bude se dle metodiky řešit v dalších iteracích. Cílem je nedělat nic zbytečně, do zásoby nebo s nejistým výsledkem. Úspěch je hlavní cíl.

•

Zpětná vazba Důraz je kladen na zpětnou vazbu. Iterace vznikají v rozmezí 1 až 4 týdnů, zákazník je součástí týmu, vše vytvořené se ihned testuje, prezentuje, implementuje.

•

Odvaha Odvaha je v tomto modelu předpokládána u většiny kroků – přijmout zadání, zahodit napsaný kód, prezentovat zákazníkovi iteraci. Zvyšování odvahy by mělo probíhat úspěšnými testy, rychlými funkčními iteracemi, komunikací s ostatními členy týmu.

•

Kvalita práce Model je zaměřen na vysokou kvalitu práce, důraz je kladen na motivaci lidí, velmi dobré pracovní prostředí, zapojení všech členů týmu do kreativních činností v projektu, samostatném přijímání úkolů.

•

Plánování Plánování probíhá už od počátku projektu, nicméně, jako vše v XP modelu, přírůstkově, protože požadavky se mohou měnit, plán se může měnit, vnější i vnitřní vlivy se mohou měnit. XP model klade do popředí funkce, jejichž

24

důležitost je vyšší, které mohou práci někam posunout a v iteraci pomohou ověřit správnou cestu a definovat další zadání. •

Párové programování, společný kód, refactoring Párové programování zavádí programování ve dvou lidech u jednoho počítače, kdy jeden tvoří kód a druhý jej kontroluje, přemýšlí nad testováním, vymýšlí další postup. Intervaly výměny dvojic lze definovat libovolně. Společný kód představuje kód, který je aktualizován libovolně členy týmu, důležitým faktorem je akceptování přes všechny testy a zlepšení funkcionality. Refactoring představuje neustálé revize kódu tak, aby byl kód vyvinut k dokonalosti, velmi nutně však potřebuje kvalitní testování.

•

Řízení projektu Pomocí metrik je sledován projekt, jeho úspěšnost, plnění cílů. V týmu jsou definovány různé role, které zajišťují důležité funkce v projektu. Kouč je technický expert, jakýsi hlavní programátor, který však zajišťuje i vhodné motivování lidí, jejich zapojení do projektu, zájem přijímat zadání, zapojuje všechny členy týmu do komunikace a integruje procesy v týmu. Stopař je pak funkce převážně plánovací, má na starosti definici dalších postupů, vyhodnocování projektu dle metrik. Manažeři pak stojí mimo tým a kontrolují jej pouze zvnějšku a zasahují, pokud se projekt nevyvíjí optimálně, v případě nekvalitní práce, nedodržení metrik atd. U všech těchto rolí je opět kladen velký důraz na odvahu zasáhnout, přijmout rozhodnutí rychle a včas.

25

5.

Životní fáze projektu

Každý projekt prochází dle PMBOK [2] fázemi, které se z časového pohledu vzájemně prolínají, avšak každá fáze má jasně definované činností, které jí přísluší. Z tohoto pohledu je dělíme na: •

Inicializační procesy

•

Plánovací procesy

•

Kontrolní procesy

•

Realizační procesy

•

Ukončovací procesy

Obecně u všech projektů platí vysoká důležitost prvních dvou zde uvedených fází projektu. Všechny metodiky a doporučení věnují těmto oblastem velkou váhu. Důvod je jednoduchý. Chyba učiněná v těchto fázích projektu, ovlivňuje negativně celý další proces a v důsledku může vést k neúspěchu projektu, pokud se s těmito chybami PM v průběhu projektu nevypořádá. Často to znamená návrat zpět k výchozímu bodu projektu a revizi všeho, co již bylo uděláno. Bohužel někdy jsou již napáchané škody tak vysoké, že nelze problém s rozumnými náklady odstranit. Problémy mohou vzniknout na jakékoli úrovni projektu, počínaje nedostatečně nebo chybně nadefinovaným cílem, chybným návrhem a plánem realizace, špatnou komunikací, mezilidskými vztahy a ztrátou motivace účastníků přes špatný vývoj a neodbornou realizaci či nenaplnění harmonogramu. Je nutné si uvědomit, že promrhané zdroje a prostředky v projektu stojí ve výsledku další finance nepřímo tím, že produkt nebo služba jsou pozdě nasazeny, společnost ztrácí konkurenční výhodu, nezavádí včas ekonomičtější a efektivnější řešení, musí odkládat projekty navazující a nemůže využívat kapacity blokované na problematickém projektu.

5.1.

Inicializační procesy

Zahájení projektu většinou předcházejí kroky, které souvisí s vlastním posuzováním výhodnosti projektu jako takového, jedná se např. o: •

Předprojektovou analýzu

•

Studii proveditelnosti

26

•

Obchodní hodnocení

•

Kontraktační fázi, pokud se nejedná o interní projekt financovaný vlastními zdroji

U větších projektů předchází projektu realizace samostatný projekt přípravy, nicméně u střední velikosti projektů se přípravná fáze samostatným projektem většinou neřeší. Za samotné zahájení projektu je většinou považováno jeho formální spuštění, tzv. kick-offmeeting. Jedná se o formální schůzku hlavních aktérů projektu s nastavením veškerých pravidel, které budou v projektu dodržovány. Jedná se např. o: •

Kompetence a zodpovědnosti jednotlivých stran, určení projektového manažera (PM) resp. manažerů ve všech zúčastněných subjektech

•

Způsoby dokumentace, vedení porad, dokumentování vývoje projektu, způsoby a pravidla komunikace

•

Definice a prezentace hlavních požadavků na projekt kladených

•

Odsouhlasení prvotního konceptu a plánu projektu, vytvoření společných představ a cílů, které budou v rámci projektu naplňovány

•

5.2.

Zaměření na cíl projektu a stanovení způsobů, jak cíle dosáhnout

Plánovací procesy

Plánovací procesy začínají již inicializační fázi, naplno se však rozbíhají poté, co byly inicializační procesy z velké části naplněny. S plánováním projektu úzce souvisí specifikace obsahu projektu. Plánování musí být postaveno nad reálnými skutečnostmi – obsahem. Obsah musí být při svém návrhu neustále konfrontován alespoň s prvotním plánem – časovým a finančním rámcem projektu. Pokud by došlo k návrhu obsahu projektu bez zohlednění omezení projektu (časové, finanční), projekt by jednoduše nebylo možné realizovat (což by mělo být zjištěno ve fázi plánování) a muselo by dojít k revizi specifikace obsahu projektu. Tato cesta je také možná – pro projekty, kde je obsah vším a časové a finanční omezení je možné upravovat, nicméně v praxi takových projektů mnoho není. Proto se v praxi u středních projektů tyto činnosti neřeší odděleně. To přináší vyšší efektivitu, jak z pohledu pracnosti, tak i času potřebného pro tyto fáze.

27

Plánování projektů je velmi komplexní činnost, jejímž cílem je stanovení takového postupu prací, aby byly naplněny výchozí požadavky na cenu, čas, zdroje, s případným akcentem nebo omezením některé z uvedených veličin. Plánování projektů v širším rozsahu chápeme i jako velmi kreativní činnost, jejímž cílem není pouze sestavení harmonogramu, ale především nalezení vhodných cest a způsobů řešení pro úspěšnou realizaci projektu. Ve své podstatě je plánování činností, která proti sobě staví požadavky na projekt (tj. specifikaci obsahu projektu) a způsob realizace jednotlivých úloh tak, aby byl naplněn cíl projektu a požadované parametry projektu. Metodiky pro plánování projektů obsahují velké množství nástrojů pro naplánování projektu, nicméně silně akcentují výstup plánování – harmonogram prací. Nalezení vhodných možností a způsobů řešení je prací pro projektový tým (samozřejmě pod vedením projektového manažera) a lze jej považovat za daleko důležitější než fyzické vytvoření harmonogramu.

5.3.

Kontrolní procesy

Obrázek 2 zobrazuje přítomnost kontrolních procesů v průběhu celého životního cyklu projektu. Tyto procesy pak vrcholí v realizační fázi, kdy krom samotných prací souvisejících s realizací projektu probíhají činnosti, jejichž cílem je koordinace prací dle plánu, vyhodnocování aktuálního postupu a stavu, revize plánu a reakce na očekávané i neočekávané situace, které v průběhu realizace nastávají. Kontrolní procesy sledují i ostatní fáze projektu, kde jsou zásahy a korekce také nutné, nicméně z logiky věci je jejich přítomnost dominantní ve fázi realizace.

5.4.

Realizační procesy

Těmito procesy se poměrně detailně zabývají všechny metodiky vývoje SW, které zde byly uváděny a z jejich popisu jsou patrné odlišnosti ve formě přístupu k této problematice. Je to samozřejmě dáno i tím, že realizační procesy spotřebovávají nejvíce zdrojů a času. Na realizační procesy však nelze nahlížet odděleně – i ze schématu rozdělení procesů v čase je patrné, že realizační procesy jsou v přímé vazbě na procesy plánovací, řídící a ukončovací.

28

5.5.

Ukončovací procesy

Ukončovací procesy je možné detailněji rozdělit na mnoho dalších částí – první činnosti ukončovací fáze se v projektech mohou objevovat i paralelně s ostatními fázemi, pokud je například projekt rozdělen na jednotlivé etapy. Důležitosti ukončovací procesů není často věnována patřičná pozornost. Jejich důležitost však narůstá s projekty, kdy jsou na tyto procesy navázány další činnosti nebo události – účetní operace, spuštění servisních smluv, start dalších návazných projektů atd. U klasických metodik vývoje software stojí na pomezí mezi realizačními a ukončovacími procesy nasazování projektu. Opakem jsou agilní metodiky vývoje software, kde k nasazování dochází již průběžně. Nasazení projektu spočívá v jeho uvedení a začlenění do běžných provozních procesů organizace, pro kterou je projekt vytvářen. Během této fáze se naplno ukazuje vhodnost nebo nevhodnost použití konkrétní metodiky vývoje a řízení projektu. Ukončení projektu a předání jsou sady spíše formálních kroků, které následují po nasazení projektu a jsou jakýmsi protipólem inicializačních procesů. Těmto procesům se naopak více věnují metodiky řízení projektů a detailněji definují jednotlivé akce, dokumenty, role a zodpovědnosti pro správné zvládnutí těchto kroků.

29

6.

Popis konkrétního projektu

Předmětem konkrétního popisu je projekt vývoje informačního systému pro společnost Mediclinic a.s.1 Společnost Mediclinic vznikla v roce 2007 a zabývá se poskytováním služeb praktických lékařů a specialistů nejširší veřejnosti. Celý obchodní model je postaven na sdružení těchto lékařů do jedné sítě a zefektivnění procesů týkajících se účtování pojišťovnám, zásobování, provozu a technické správy. Součástí obchodních aktivit je i nabízení speciálního programu pro pacienty, v rámci něhož mohou čerpat výhody v celé síti, poskytování závodní zdravotní péče atd. K březnu 2009 již uzavřelo se společností smlouvu více než 100 lékařů. Informační systém pro společnost Mediclinic pokrývá všechny tyto oblasti: •

Klinický software (kartotéka pacientů, vyšetření, recepty, tisky, …)

•

Rezervační systém

•

Personální agenda pro lékařský personál i backoffice (HR)

•

Provoz a zásobování

•

Účtování pojišťovnám

•

Bonusový program pro klienty (pacienty)

•

Call centrum a Helpdesk

•

CRM systém pro partnery zapojené do bonusového programu

•

CRM systém pro závodní zdravotní péči

•

CRM systém pro oddělení akvizic

•

Manažerský informační systém (reporting)

Naše společnost Apollo servis s.r.o. byla vybrána jako dodavatel celého informačního systému. Osobně jsem byl projektu zapojen již od kontraktační fáze a zastával roli projektového manažera. Do projektu je zapojeno 8 dalších osob z naší společnosti a jeho

1

Pro účely této práce byl uzavřen dodatek ke smlouvě o mlčenlivosti se společností Mediclinic a.s., který

dovoluje publikování zde uvedených informací. Informace zde prezentované nenarušují obchodní tajemství společnosti Mediclinic a.s. nebo jsou veřejně přístupné.

30

odhadovaná náročnost je v řádu tisíce člověkodnů2. Spadá tedy do výše uvedené klasifikace projektu střední velikosti.

6.1.

Příprava projektu (inicializační fáze)

Přípravná fáze projektu byla spuštěna na jaře roku 2008, kdy společnost Mediclinic začínala fyzicky fungovat, zaměstnávala klíčové osoby pro start společnosti a budovala back-office. Společně s top managementem společnosti byl připraven základní rozsah projektu (project scope3). Tento scope vznikl na základě vize obchodního fungování, obchodní strategie společnosti, rámcových požadavků na agendu jednotlivých oddělení, kterou musí informační systém pokrývat, organizační struktury společnosti a působnosti jednotlivých oddělení. Scope projektu zahrnoval funkční i nefunkční požadavky. Účast top managementu při definování project scope považuji za klíčový pro budoucí úspěšné řešení projektu. S odstupem času dnes víme, že tento scope pokryl zhruba 80% všech požadavků, nicméně základní strukturu a funkce systému pokryl velmi přesně. Tento přístup nám umožnil navrhovat systém jako velmi logicky postavený celek a všechny dílčí požadavky na tento celek navazovat bez ovlivnění základních pilířů systému. Na začátku projektu byly jasně nastaveny zodpovědnosti a povinnosti jednotlivých stran, organizační a komunikační pravidla, jmenovány klíčové osoby zodpovědné za jednotlivé části a fáze díla. Na straně zákazníka byly tyto odpovědnosti přeneseny na střední management zodpovědný za řízení jednotlivých oddělení (tj. za HR modul zodpovídal HR ředitel, za modul výkaznictví a účtování finanční ředitel atd.). Za celkovou koordinaci projektu na straně zákazníka byl pak jmenován IT ředitel, který zodpovídal za veškeré projektové činnosti tj. organizaci schůzek, komunikaci priorit uvnitř společnosti, technické záležitosti a byl hlavní komunikační osobou veškeré smluvní a projektové záležitosti.

2

Z důvodu smlouvy o mlčenlivosti se společností Mediclinic a.s. není možné uvádět konkrétní kontraktovaný

objem, a to jak z pohledu finančního, tak i z pohledu pracnosti v člověkodnech. 3

Termín project scope je používán v anglické literatuře pro rozsah projektu.

31

6.1.1. Zhodnocení fáze Důkladnost při inicializační fázi, nastavení rolí a odpovědností, kvalitní nastavení cílů a postupů v projektu velmi výrazně ovlivňují celkový postup projektu. Částečně jde i o nastavení stupně „byrokracie“ v projektu, ať už z jedné či druhé strany. Příliš zevrubné nastavení přinese v projektu problémy s vymahatelností povinností a zodpovědností a logicky projekt zkomplikuje. Naopak příliš přísné nastavení těchto procesů projekt zpomalí a zvýší objem administrativy s projektem spojené, navíc s rizikem určité křečovitosti při některých situacích. V tomto projektu byla inicializační fáze lehce podceněna, jak je popsáno dále. Narazili jsme tak na slabé zapojení zákazníka, navíc s velmi špatnou vynutitelností – pokud zákazník nemá kapacity, možnosti, know-how, je veškerý tlak marný. Na druhou stranu zákazník si tuto inkompetenci musí uvědomovat a být o ní informován, aby nebylo zpoždění projektu či další návazné problémy přikládány za vinu jen dodavateli. Některá zaváhání z inicializační fáze je možné napravit i v průběhu projektu, nicméně již to stojí více sil.

6.2.

Návrh systému a plánování (plánovací procesy)

Ve fázi návrhu systému jsme narazili na první zásadní problém. Top management již samozřejmě nebyl schopen ani ochoten se dílčích analýz a návrhů účastnit, avšak střední management společnosti byl v svých funkcích velmi krátce, znal vize společnosti na stejné úrovni jako my, avšak nebyl schopen definovat patřičný detail. Veškeré dotazy při pokusech o návrh systému byly formulovány ve smyslu „jak budete řešit…“, „jak má fungovat...“, „kdo bude zodpovědný…“. Střední management nebyl logicky schopen tyto otázky odpovídat. Reálné spuštění takových procesů mělo následovat až v horizontu několika měsíců a jejich ustálení spíše v horizontu jednoho roku. Na tuto situaci, která byla diametrálně odlišná od vývoje systémů pro existující a zavedené společnosti, bylo potřeba adekvátně reagovat. Avšak reakcí nemohlo být odsunutí všech analýz do doby, až budou tyto procesy zavedeny – v tu chvíli již reálně bude nastávat potřeba informační systém (IS) používat a vývojový cyklus od návrhu, přes implementaci až po pilot a nasazení se v takových případech neodehrává v časech kratších než 3-6 měsíců. Navíc nebylo možné použít ani „best practices“ či popis fungování procesů

32

z jiných společností, protože Mediclinic vytváří naprosto nový typ business procesů, nový typ služeb, nový typ fungování v oblastech, které má IS pokrývat.

6.2.1. Rozfázování projektu Projekt byl rozdělen na několik etap a modulů. Jednotlivé moduly víceméně pokrývají části definované v kapitole 6. Rozfázování projektu bylo další komplikací, kterou bylo nutné v průběhu projektu řešit. Přestože existoval prvotní plán nasazování a vývoje jednotlivých modulů daný prioritami spuštění těchto modulů, bylo nutné tento plán velmi často měnit a revidovat. To bylo způsobeno dvěma hlavními faktory: •

Analytické práce postupovaly různým tempem Rozdíl v postupu analytických prací oproti plánu byl dán postupným navrhováním business procesů na základě jejich reálné aplikace, postupným vznikem nových požadavků a potřeb. Teprve se zprovozněním jednotlivých oddělení byli jejich vedoucí pracovníci schopni definovat obsah své agendy, způsob jejího řešení a společně s námi i způsob realizace v informačním systému. Některé analytické práce bylo tedy nutné odsouvat, jinak by hrozilo velké riziko, že až budou navržené procesy a funkce nasazeny do praxe, nebudou fungovat nebo pokryjí pouze minoritní část potřeb. Pak by veškerá práce přišla v niveč

a muselo by dojít

k návratu do startovacích fází. To bylo vzhledem ke kapacitním (na obou stranách) i finančním (na straně zákazníka) omezením nepřípustné. Na druhou stranu nebylo možné paušálně posunout celý projekt – naše volné kapacity nemohly být nevytížené. •

Měnila se priorita spuštění jednotlivých částí systému, objevovaly se nové skutečnosti, které ovlivňovaly požadavky na jednotlivé moduly a funkce Změnu priorit na dokončení jednotlivých modulů ovlivňovalo mnoho faktorů, které nebylo možné příliš predikovat a tudíž s nimi plánovat. Mezi nejdůležitější patřily: o Personální obsazení oddělení a kapacity (tj. zda je schopno oddělení plnit své funkce bez IS v dlouhodobějším horizontu a naproti tomu zda bylo oddělení schopno v krátkodobém horizontu vyčlenit významnou část kapacit pro analýzy a návrh IS)

33

o Vnější vlivy, legislativa (vstupy a požadavky na oddělení, se kterými se oddělení seznámila až v průběhu fungování) o Přidaná hodnota IS (zvýšenou prioritu měly moduly a jejich funkce, kde IS mohlo přinést výrazné zvýšení efektivity a kde nebylo ani možné bez IS fungovat tj. v oblastech hromadného zpracování dat) Na základě těchto skutečností a díky rozdělení projektu na jednotlivé moduly bylo možné pružně na tyto změny reagovat, nicméně plánování jednotlivých dílčích činností, revize projektových prací, plánování návazných akcí (implementace, školení, pilotní provoz, …) v kontextu ke změnám priorit rozhodně nebyly jednoduchou záležitostí. Vše znesnadňoval i obecný tlak na co nejrychlejší dokončení systému.

6.2.2. Plánování kapacit, harmonogram Na začátku projektu existoval rámcový časový plán realizace jednotlivých modulů. Později se však ukázalo, že plánování časovosti projektu bude jednou z nejnáročnějších činností na projektu. Často docházelo ke změně priorit projektu a objevovaly se nové skutečnosti či komplikace, na základě bylo nutné harmonogramů měnit. Byl vytvořen samostatný harmonogram analýz a návrhů a až na základě dokončení těchto činností byly dále plánovány další práce v kontextu k ostatním činnostem ve stejném čase. Nevýhodou tohoto modelu byl fakt, že nebylo možné časovost celého projektu naplánovat dopředně. Byly pouze rámcově stanoveny časové odhady trvání jednotlivých fází, nicméně zákazník toto akceptoval. Jednalo se o startup nové společnosti a stejně jako nebylo možné precizně plánovat vývoj software, nedařilo se plánovat ani ostatní činnosti – nábor lidí, akviziční proces, zavádění procesů – vše bylo velmi rychlé a obsahovalo velké množství neznámých. Dlouhodobé plány tak byly pouze rámcové a detailně byly plánovány popsané a dekomponované

akce.

Právě

nemožnost

kompletní

dekompozice

znemožnila

kvalifikované dlouhodobé plánování. Plánování kapacit bylo jednodušší záležitostí. Na jednotlivé moduly byli přidělováni konkrétní vývojáři – některé moduly realizoval jeden vývojář, některé byly vytvářeny dvěma vývojáři, u některých bylo využíváno navíc externistů. Paralelně tak byly v jeden čas vyvíjeny 2 až 4 moduly. Vzhledem k problémům s analýzami docházelo i k pozastavení vývoje tam, kde byla nasazena iterační metodika vývoje. Tyto prodlevy byly využívány buď k doplnění analýz, nebo přípravným pracím na dalších modulech. Přesné 34

plánování kapacit a jejich přidělení k jednotlivým modulům probíhalo zhruba v jedno- až dvouměsíčním předstihu s postupným zpřesňováním dle toho, jak se měnila připravenost modulu nebo jeho částí k realizaci. V přípravných fázích projektu jsme analyzovali potřebu rozšíření know-how pro realizaci některých činností a projektových prací, se kterými tým neměl zkušenost a které bylo v průběhu projektu potřeba zvládnout. V průběhu návrhu a analýz tak došlo i na určitou technologickou přípravu – nastudování technologií, jejichž principy umožnily efektivnější řešení problémů, nastudování metodik vykazování zdravotnické péče a poskytování péče, komunikace s pojišťovnami atd.

6.2.3. Struktura projektového týmu a role Do návrhu modulů se ze strany zákazníka zapojovalo od 2 do 5 osob, osoby z dalších oddělení vznášely pouze faktické připomínky nebo doplňující požadavky. Za podobu modulu byl však finálně zodpovědný jeho garant – vedoucí oddělení. Na pravidelných schůzkách bylo všem analytickým týmům prezentováno navržené řešení všech modulů. Tyto schůzky pomohly rychlejšímu návrhu všech modulů a návrh IS se stal pro všechny analytické týmy daleko uchopitelnější, protože byly schopny dohlédnout celkový koncept IS. Na straně naší společnosti se projektu plně věnovalo 8 osob. Struktura týmu byla následující: •

PM (project manager)

•

Hlavní vývojář

•

Vývojáři (4)

•

Externí vývojáři (2)

•

Tester, správce dokumentace a příruček

Oproti běžné skladbě týmu je možné všimnout si neobsazených resp. chybějících pozic analytika popř. konzultanta. To je dáno specifikou našeho projektového týmu, kdy vývojáři nejsou programátory tj. kodery, ale aktivně se podílejí na řešení projektu. Vzhledem k rozsahu projektu jsem krom funkce PM zajišťoval podstatnou část návrhu systému. I když se toto může jevit jako zásadní chyba a mohli bychom se setkat s názorem, že

35

project manager má řídit projekt a analytik resp. designer navrhovat systém, bylo toto složení dle mého názoru ve prospěch projektu. Jako PM a osoba, která se od počátku účastnila veškerých diskusí o koncepci systému, jsem byl schopen tyto elementární požadavky přenášet do dílčích diskusí a návrhů systému, mohl jsem okamžitě a adekvátně řídit rozsah systému v kontextu ke konceptu a kontraktu a být jakýmsi nositelem všech hlavních myšlenek a koncepcí systému. Samozřejmě tato role by nebyla naplnitelná za předpokladu, že by rozsah těchto činností převyšoval osobní kapacity jednoho člověka nebo daný člověk odborně nepokrýval řešené oblasti. Jednotliví vývojáři se pak také podíleli na návrhu modulů, které posléze vytvářeli. Hlavní vývojář pak zasahoval do oblastí týkajících se návrhu systému v technické rovině, koordinoval vývojové činnosti, nesl zodpovědnost za jádro systému a styčné body jednotlivých modulů, stejně tak za konzistenci systému po stránce datového modelu a kódu. Externí programátoři byli jakousi pomocnou silou pro programátory, tj. výsledky jejich práce odevzdávali programátorům zodpovědným za tyto moduly a ti tyto části implementovali do svých modulů. Vznikla tak určitým způsobem hierarchická struktura, nicméně velmi neformální. Tester a správce dokumentace zajišťoval interní testování jednotlivých modulů a kontroloval tak funkčnost předtím, než byly části systému prezentovány nebo uvolněny pro zákazníka. Navíc, díky know-how získanému při tomto testování, tvořil veškerou uživatelskou dokumentaci systému a podílel se na školení systému a aktuálně zajišťuje i uživatelskou podporu.

6.2.4. Zhodnocení fáze Při návrhu systému docházelo k prvním komplikacím v projektu. Ty bylo nutné operativně řešit s ohledem na všechny vlivy – potřeby zákazníka, kontrakt, kapacity projektového týmu, schopnosti obou stran. Na naší straně jsme se mohli výrazným způsobem opřít o stabilitu týmu (nedocházelo k personálním změnám, polovina týmu společně pracuje již zhruba 4 roky) a zkušenosti s návrhem a realizací podobných systémů. Velkou výzvou samozřejmě byla nová oblast – zdravotnictví, stejně tak realizace projektu pro nově vznikající společnost, což projekt poměrně zásadně odlišilo od předchozích řešení.

36

6.3.

Vývoj systému (realizační procesy)

Jednotlivé moduly jsou v určitých částech provázané a používají stejné datové struktury, které např. jeden modul plní (kmenová data) a další moduly z nich čerpají (např. HR modul, objednávání materiálů, vykazování péče, atd.). Při návrhu systému a realizaci tedy bylo nutné postupovat tak, aby mezi těmito moduly byla zachována jasná hranice, systém byl konzistentní a nedocházelo k duplikování nebo naopak protichůdnosti požadavků. Navíc i postup vývoje musel odpovídat provázanosti jednotlivých modulů. Pro jednotlivé moduly systému byla zvolena odlišná metodika vývoje. To bylo způsobeno komplikacemi při návrhu a verifikaci správnosti požadavků, obtížnému přístupu k informacím a komplikacím při přesném plánování projektu. Kombinován byl vodopádový model vývoje, iterační metody vývoje a agilní metodiky. Vodopádový model vývoje byl použit pro části, které bylo možné vytvořit bez úzké spolupráce se zákazníkem. Typickým příkladem takové programové části byl modul účtování pojišťovnám. Zde bylo možné vyjít z jasného popisu metodikami VZP (Všeobecná Zdravotní Pojišťovna), které definují veškerá pravidla pro účtování, formát dat a souborů, hodnoty bodů jednotlivých lékařských výkonů atd. Po vytvoření modulu a během pilotní fáze přešel vývoj na metodiky agilní z důvodu úzké komunikace se zákazníkem, krátkým iteračním cyklům a co nejrychlejšímu doladění funkcí a zapracování požadavků vzniklých na základě používání modulu a vzešlých z nových vnějších podnětů a obchodních procesů. Dva modulu, konkrétně HR (personální) a rezervační modul pro pacienty byly vyvíjeny metodikou blízkou extrémnímu programování. Volba metodiky byla spíše subjektivní záležitostí danou převážně osobností HR manažera, jeho schopností pracovat operativně s vývojovým týmem, definovat přesně své požadavky na pravidelných setkáních a motivovat svůj tým ke spolupráci tímto dynamickým způsobem. Určitou roli samozřejmě sehrála i oblast, která byla modulem pokrývána – s oblastí personální agendy měl i náš tým velké zkušenosti a popisované procesy byly pro obě strany dostatečně uchopitelné. V průběhu vývoje modulů bylo vytvořeno jen velmi malé množství dokumentace. Jednalo se spíše o zápisy z jednání, dílčí návrhy funkcionality, skici obrazovek atd. Verifikace správného návrhu, doladění a vyjasnění detailů probíhalo vždy na společných schůzkách, které se odehrávaly v širším týmu a měly podobu brainstormingu a workshopu. Použitá

37

metodika je úmyslně označena jako blízká extrémnímu programování. Náš tým chápe tyto metodiky vždy jako určitý vzor, nicméně jejich striktní naplnění není důležité díky zkušenostem týmu, který je schopen aplikovat již prověřené modely fungování, nastavovat vlastní cesty, kombinovat metodiky či operativně měnit model fungování v závislosti na okolnostech. Pro modul provozu a zásobování byla použita spirálová metoda vývoje. Návrh a vývoj modulu se potýkal s problémy již při prvotních diskusích nad samotným konceptem modulu a následně pak při detailnějších analýzách a návrzích tohoto modulu. Bylo zřejmé vysoké riziko neúspěšné implementace, kterou mohlo způsobit jak špatné pochopení potřeb zákazníka, nepochopení návrhu a konceptu IS zákazníkem, tak např. i špatný návrh procesů a funkcí ze strany zákazníka nebo našeho týmu. Opět byl zvolen individuální postup, který spočíval ve vytvoření velmi důkladného návrhu systému, vytvoření datového modelu, návrhu jednotlivých obrazovek, uživatelských popisů funkcí. Zákazník byl podrobněji zasvěcen do podoby datového modelu (doménového modelu) a bylo realizováno několik workshopů, které sloužily k verifikaci analýzy a návrhu a jejímu odsouhlasení zákazníkem. Pro vývoj modulu byl nastaven harmonogram vývoje jednotlivých funkcí tak, aby realizace jednotlivých funkcí kopírovala návrh od základních dat a funkcí a poté byly postupně nad těmito elementy vytvářeny složitější funkce a formy. V průběhu vývoje pak byly realizovány velmi časté schůzky, kde byly jednotlivé části prezentovány a bylo opět verifikované, že návrh systému a jeho realizace pokrývá potřeby zákazníka. Tyto časté schůzky včas zachytily případné další požadavky, umožnily vyjasnit sporné body nebo nepochopení návrhu a v konečném důsledku zabránily nutnosti měnit velké části díla zpětně. U agendy, jejíž know-how jsme znali z ostatních projektů nebo bylo know-how dostupné v písemné formě (metodiky VZP a další), byly návrh a realizace systému výrazně jednodušší než u částí, kde byly navrhovány unikátní procesy. U částí systému, kde bylo možné řešení navrhnout z naší strany a to poté dolaďovat na schůzkách nebo na základě dotazování dospět k ideálnímu řešení, byl postup logicky výrazně snazší a rychlejší. Navíc i pravděpodobnost chyby v návrhu nebo nutnost předělávat velké části díla či jeho logiku byla výrazně snížena. Taková situace nastala pro moduly účtování, HR, rezervačního systému, helpdesku a call centra.

38

Nejnáročnější byly návrh a realizace bonusového systému a lékařského software. Zatímco ostatní moduly byly navrhovány ve spolupráci s klíčovými uživateli zákazníka, do těch modulů vstoupily další subjekty. V případě bonusového systému probíhal návrh systému čtyřstranně – do jednání vstupovala navíc banka, která poskytovala bankovní produkt kreditní karty upravený pro potřeby sbírání bonusových bodů, a společnost provozující předplacené karty, které měly být doplňkem karet kreditních. Provozovatel předplacených karet navíc dodával řešení svého amerického partnera a zde poskytoval pouze obchodní přípravu a procesní přípravu, zatímco spuštění produktu probíhalo již v USA. Návrh systému tak postupoval v poměrně pomalých iteracích, protože veškeré výstupy jednání bylo nutné komunikovat na čtyřstranné úrovni. Během návrhu systému docházelo k poměrně zásadním změnám konceptu celého produktu a návrh systému se tak protáhl na více než 4 měsíce a jednotlivé verze návrhu doznaly výrazných změn, často i znovuobnovení již opuštěných myšlenek nebo odvolání již dohodnutých změn a návraty k původním částem konceptu. Realizace již byla výrazně jednodušší – díky přesné dokumentaci a návrhu proběhl vývoj vodopádovým modelem a konečným doladěním iteračními metodami. Návrh lékařské software byl poměrně komplikovaný, protože chyběl na straně zákazníka subjekt, který by byl garantem dané funkcionality tj. subjekt, se kterým by byl komunikován rozsah funkcí, jejich podoba a vůbec celková koncepce software. Zákazník nebyl schopen najít nikoho, kdo by tuto pozici zastoupil. Po určitém čase jsme tedy přes veškerá rizika tuto iniciativu převzali my a návrh software se rozhodli složit na základě analýzy funkcionality na trhu dostupných programů pro ambulance a konzultací s jednotlivými lékaři sítě Mediclinic. Nikdo z našeho týmu neměl know-how, jakou agendu lékaři řeší, a pro většinu lékařů byl problém analyticky popisovat a chápat své požadavky a postupy, které provádějí rutinně. Navíc návrh software vždy probíhá v určité virtuální rovinně, kdy jsou pomocí schémat, dat, obrazovek, slovních popisů a dalších prostředků popisované funkce, které teprve budou vznikat. Později jsme zjišťovali, že v návrhu chyběly funkce, které lékaři považovali za automatické, ale nehovořili o nich a při návrhu se na ně nikdo neptal, protože o jejich existenci nevěděl. Hlavními riziky tak bylo výrazné protažení fáze návrhu i vývoje, pomalá implementace a provedení velké množství iteračních cyklů nutných do vytvoření první použitelné verze software. V prvních fázích projektu bylo zvažováno i použití již existujícího lékařského software. To však bylo

39

zamítnuto z důvodu extrémní ceny řešení při použití pro celkový počet ordinací, které byly v business plánu určeny k začlenění do sítě. Dalším negativem by byla velmi komplikované napojení tohoto software do dalších modulů (personálního, rezervačního, účtovacího, …). Návrh a vývoj tak opět probíhal iteračními metodami, nicméně již z počátku bylo zřejmé, že iterací bude velké množství a celková doba vývoje bude poměrně dlouhá. To se ve výsledku také potvrdilo.

6.3.1. Technologie Zvolená technologie realizace vycházela z prvotních požadavků na snadnost údržby, maximální dostupnost, jednoduchost obsluhy celé sítě, tedy v důsledku s akcentem na co nevyšší poměr cena/výkon. Celý systém kromě lékařské aplikace byl navržen jako online aplikace provozovaná přes webový prohlížeč. Důvodem pro tuto koncepci je právě jednodušší správa a zavádění nových verzí, stejně tak garance shodné funkčnosti na všech klientských stanicích. Pouze samotná lékařská aplikace byla navržena jako Windows aplikace. Důvodem byla nutnost rychlých reakcí aplikace, možnost použití klávesových zkratek, přímé komunikace s tiskárnami a speciálním HW. Pro lékařskou aplikaci byl navíc vytvořen speciální systém synchronizace. Aplikace tak může pracovat online ale i offline. Je zajištěno centrální uložení všech dat, takže na klientských stanicích nejsou uchovávána žádná jedinečná data a při havárii PC lze veškerý obsah automaticky rekonstruovat na jiném PC z centrálního serveru a obnovit tak plně funkčnost v řádu desítek minut. Za celým systémem samozřejmě běží celá řada webových služeb a replikačních služeb mezi databázemi. Technologicky je systém postaven na MS SQL serverech a .NET Frameworku (C#), reporting je pak realizován technologií Crystal Reports. Na klientských stanicích pak funguje pro tisk šablonový systém postavený na OpenOffice s ohledem na minimalizaci nákladů za licence pro desítky či stovky ordinací.

6.3.2. Zhodnocení fáze Díky různé podobě a hloubce návrhu modulů, osobnostem garantů těchto modulů a zkušenostem našeho týmu byly voleny různé modely vývoje software – vodopádový, spirálový (iterační) model nebo agilní metodiky. Volba vhodné metodiky byla vždy subjektivním rozhodnutím. Toto rozhodnutí nebylo nikdy učiněno na počátku návrhu nebo

40

vývoje, ale mezi jednotlivými modely bylo volně přecházeno, tak jak je jejich použití jevilo jako vhodné a jak byly naplňovány podmínky pro jejich použití. Následující tabulka shrnuje podmínky, které ovlivňovaly mé rozhodnutí pro použití jednotlivých modelů. Vodopádový model

Spirálový model

Agilní metodiky

Podmínky pro výběr:

Podmínky pro výběr:

Podmínky pro výběr:

Jasný zdroj informací pro

Nedostatečné informace pro

Snadno uchopitelná

návrh systému

kompletní návrh

problematika, jasný koncept

Vysoká jistota správného

Vysoké riziko nepochopení a

Oboustranné

návrhu a popisu

budoucího konfliktu

porozumění při návrhu

Malý rozsah dolaďování

Nejasný rozsah, velká potřeba

Pouze drobné

dolaďování či změn zadání

dolaďování bez razantnějších zásahů do hlavních konceptů

Pozitiva:

Pozitiva:

Pozitiva:

Rychlost a přesnost vývoje,

Předcházení konfliktům

Rychlost vývoje

Dobrá uchopitelnost pro obě

Snadné dolaďování,

strany

zpětná vazba

Negativa:

Negativa:

Negativa:

Nemožnost průběžné zpětné

Problematické plánování

Nutnost přijetí

pokud je návrh správný

vazby

Nejasný počet cyklů

oboustranné

Neúspěch v případě chyby,

zodpovědnosti

složitá náprava chyb návrhu

Neúspěch v případě popření dohod (nejsou písemné záznamy)

Tabulka 2: Podmínky ovlivňující výběr modelu vývoje software

41

6.4.

Řízení vývojového cyklu (kontrolní procesy)

Jak bylo popsáno v kapitolách 6.2 a 6.2.4, návrh a vývoj jednotlivých modulů probíhal různými metodikami. Uvádění do provozu bylo logicky rychlejší u modulů vyvíjených iteračními metodami – do provozu byly moduly nasazovány co nejdříve a pilotní provoz zároveň sloužil k jejich verifikaci a zákaznickému testování. Samotný návrh a vývoj systému se výrazně lišil od projektů pro společnosti, kde již jsou zavedeny fungující procesy a informační systém již nahrazoval či rozšiřoval existující řešení nebo prováděnou agendu. Příprava projektu „na zelené louce“ přinesla výrazně složitější analytické práce a návrh, doplněné o riziko častých změn, avšak implementace znamenala jisté výhody, protože budování IT prostředí společnosti postupovalo současně s návrhem IS a bylo jím masivně ovlivněno. Implementace pak umožnila postupný přechod procesů (nebo až jejich vytvoření) novým IS. Tento přechod nebyl doprovázen obvyklým tlakem a časovou krizí způsobenou nutností vypnutí jednoho systému, migrace, akceptačních testů atd. Řídícími procesy projektu byly velmi silně sledovány parametry, které v projektu tohoto typu hrály klíčovou roli: •

vztah návrhu s reálným stavem vývoje a implementace tj. požadavky na změny analýzy či vyvinutého díla

•

měnící se priority

•

nové vstupy vznikající v průběhu projektu a projekt ovlivňující

•

návaznost všech souvisejících činností (napříč odděleními) dotýkajících se IS

S postupem projektu nabýval na důležitosti change management (změnová řízení). Pro zvládnutí všech požadavků, jejich koordinaci, evidenci a odsouhlasování řešení ze strany zákazníka byl použit helpdeskový systém. Technickému zvládnutí napomohly i časté – týdenní – schůzky a porady se zákazníkem a jeho zodpovědnými osobami. Požadavky na změny nelze vnímat u iteračních metod vývoje negativně – jsou chtěné a je nutné s nimi počítat. Díky specifiku tohoto projektu – měnícím se podmínkám, novým vstupům – nebylo možné predikovat množství požadavků. To se v čase měnilo na základě aktivity zákazníka a jeho přístupu k pilotnímu provozu jednotlivých modulů, na základě vstupů zvnějšku, na základě nových skutečností nebo interakcí mezi oddělení. Komplikací byly

42

tyto požadavky pro časové plánování dalšího vývoje, protože jejich měnící se objem ovlivňoval volné kapacity pro nový vývoj a bylo nutné rozhodovat, zda síly věnovat na vývoj nových funkcí nebo modifikaci a rozvoj existujících. Při přesunu kapacit na implementaci změn pak logicky docházelo k nabourání plánovaných termínů pro vývoj nových funkcí. Při změnových řízení jsme kladli důraz na přesné definování požadavků na změny, návrh a popis změn, což mělo v důsledku minimalizovat „dolaďovací“ fáze a vyhnout se problémům s chybnou implementací. Dalším efektem pak bylo, že zákazník si daleko více uvědomoval nutnost sebemenší změny dobře domýšlet a nerealizovat každý dílčí požadavek živelně.

6.4.1. Zhodnocení fáze Během projektu bylo řešeno velké množství nerůznějších změn a požadavků, které projekt doplňovaly nebo dolaďovaly jednotlivé funkce. Tyto změny byly prováděny paralelně s vývojem nových funkcí a bylo tak neustále nutné kontrolovat postup prací vzhledem k vazbám jednotlivých modulů, funkcí, ale i v kontextu k harmonogramu, který byl dohodnut. Pro vyhodnocení a sledování klíčových parametrů byly používány metriky, které sledovaly např. hotovost jednotlivých funkcí a modulů, počet změn, dodržení harmonogramu, hotovost návrhů jednotlivých funkcí atd.

6.5.

Uvádění do provozu, předávání (ukončovací procesy)

Uvádění systému do provozu probíhalo po jednotlivých modulech, často i po částech těchto modulů. V závislosti na použité metodě návrhu a vývoje se pak i lišila fáze uvádění do provozu. Uvádění do provozu probíhalo v následujících krocích – ty odpovídají a vycházejí z metodik, a to nejenom proto, že by je náš tým musel úzkostlivě dodržovat, ale především proto, že tento sled událostí a procesů přináší efektivní výsledky, které jsou v této fázi více než žádoucí – ukončovací procesy se vyznačují vždy zvýšeným časovým tlakem. •

Spuštění v testovacím prostředí Testovací prostředí bylo kopií produkčního prostředí, navíc rozšířené o funkce a moduly, které byly předmětem uvádění do provozu.

•

Akceptace obsahu funkcí a iterace k doladění

43

Během testování zákazníka nad testovacím prostředím byly vznášeny dotazy k fungování a definovány další doplňující požadavky. To probíhalo především ve fázi vývoje, pokud byl systém vyvíjen iteračními modely. Nicméně tyto situace bylo nutné řešit i ve fázi uvádění do provozu. U jednotlivých bodů bylo rozhodováno, zda budou opravovány, měněny nebo doplňovány tzn. zda mají zásadní vliv na spuštění nebo zda budou změny řešeny až po spouštění systému a pro jeho spuštění nejsou kritické. •

Školení, předání zodpovědným osobám za provoz modulu Ze strany zákazníka byly vždy nadefinovány osoby, které byly zodpovědné za používání modulu (byly jeho správcem, garantem) a které komunikovaly s ostatními uživateli během pilotní a ostrého provozu. Tyto osoby pak byly zodpovědné za komunikaci napříč společností, proškolení dalších uživatelů, změnu procesů, interní tlak na používání systému atd.

•

Přesunutí do produkčního prostředí, naplnění daty Po přesunu do produkčního prostředí již systém nepracoval nad testovacími daty, ale naopak byl naplněn reálnými daty tak, aby jej mohli vybraní uživatelé začít používat v pilotním provozu.

•

Pilotní provoz V pilotním provozu systém používalo vždy několik vybraných uživatelů tak, aby pokryli pokud možno celý záběr modulu a situací, avšak aby případná dysfunkce neovlivnila chod celé společnosti. V pilotním provozu se opět objevovaly požadavky a problémy, které bylo nutné řešit velmi podobným způsobem jako ve fázi testovací tj. buď opravou a úpravou nebo přesunutím do pozdějších fází – změnových řízení, které postihovaly najednou více požadavků najednou.

•

Spuštění do ostrého provozu Po úspěšném pilotním provozu došlo k nasazení modulů pro všechny uživatele. I to se dělo s ohledem na kapacity či proškolení v několika krocích. Samozřejmě, dle kvality pilotní fáze a správného výběru uživatelů pro pilotní fázi se i zde objevovalo větší či menší množství provozních problémů či požadavků.

•

Změnová řízení

44

Změnová řízení probíhala před i po uvedení do provozu. Každé změně předcházela její přesná definice a návrh změny v kontextu k celému IS. Po realizaci pak standardní testování a akceptace až poté spuštění na provozní verzi. Pro hlášení veškerých požadavků a chyb byl používán interní systém Helpdesk, který umožnil kompletní workflow těchto požadavků.

Předávání díla probíhalo samozřejmě i na úrovni protokolární, tj. jednotlivé etapy a fáze byly oboustranně odsouhlasovány a potvrzovány. V této souvislosti bylo operováno s termíny předání, převzetí a akceptace. Předání probíhalo vždy při spuštění modulů či částí na provozním systému, převzetí a akceptace pak ve smluvně definované lhůtě, kterou měl zákazník k dispozici pro další připomínky a vyjadřování se k funkcionalitě. Převzetím díla zároveň počínala běžet záruční lhůta a servis, který smluvně definoval tzv. SLA (Service Level Agreement), tj. parametry servisní smlouvy, které musí obě strany dodržovat – např. procesní náležitosti a zodpovědné osoby pro hlášení a řešení problému, reakční doby a garance zprovoznění systému při chybě či výpadku, objem služeb v rámci paušálního poplatku atd. Po předání každého modulu byl dotazníkovým způsobem s garantem či klíčovými uživateli vyhodnocován průběh vývoje daného modulu – spokojenost zákazníka s mnoha parametry, vyjádření se k problematickým bodům atd. Při tomto vyhodnocování bylo používáno metrik, které byly nadefinovány na začátku projektu nebo i v průběhu projektu dle změny priorit modifikovány. V dalším osobním vyhodnocení dotazníku pak byly hledány důvody vzniklých problémů, případných časových skluzů, možnosti ovlivnit tyto stavy na obou stranách, potenciál odlišných řešení apod. Díky této zpětné vazbě byl schopen náš tým zlepšovat a zkvalitňovat svoji práci, ale také nám tato zpětná vazba umožnila „vyříkat“ si se zákazníkem problémy, jejichž pravá příčina či důsledky nemusí být na první pohled patrné a mohou vnášet do další práce zbytečné napětí.

6.5.1. Zhodnocení fáze Uvádění projektu do provozu vykazovalo několik specifik – díky vytváření projektu jako prvního IS pro společnost i použití různých modelů vývoje a návrhu software. I tak byly zachovány standardní postupy pro uvádění IS do provozu, které odpovídají nejběžnějším

45

postupům definovaných v metodikách pro vývoj software. Odpadly však např. složité migrační procedury a spouštění jednotlivých modulů do pilotního a ostrého provozu bylo jednodušší a nepodléhalo běžnému časovému tlaku.

6.6.

Zhodnocení projektu, úspěchy a neúspěchy, reflexe

V kapitole 3.2 jsem se zaměřil na kritéria úspěšnosti projektu. Tato kritéria, krom jediného, projekt splnil. Tím nenaplněným kritériem projektu byl termín. Původní požadavek a plán se v průběhu projektu ukázal jako nereálný a v kontextu dalších rozšiřujících požadavků, změn a vstupů byl revidován a měněn. Co však z pohledu termínu splněno bylo, je fakt, že zákazník dostal požadovanou funkcionalitu v čase, který výrazně neomezil jeho fungování a umožnil na IS navázat další procesy a služby na něm závislé. Konečný termín byl revidován společně se zákazníkem na reálná data odpovídající celkové situaci a požadavkům, tudíž i z tohoto pohledu se můžeme na kritérium splnění termínu dívat jako na úspěšné nebo spíše akceptovatelné. V průběhu projektu samozřejmě bylo řešeno mnoho stavů a situací, které nebyly plánované a očekávané a jejich zvládnutí nebylo častokrát lehké. Opětovně jsme se přesvědčili o tom, že body, které nejsou pokryty návrhem a analýzou, stojí při řešení v průběhu projektu několikanásobek zdrojů – lidských, produkčních či finančních. Na druhou stranu je nutné tyto situace posuzovat individuálně – ne vše lze v takto složitém a individuálním projektu postihnout při analýze a návrhu a nutnost řešit takovéto události byla předpokládána. Za selhání a vážnou chybu by bylo možné považovat pouze události, jejichž výskyt bylo možné s rozumným úsilím popsat a predikovat již ve fázích příprav a návrhu. Způsob řešení těchto neočekávaných událostí pak velkou měrou prověří kvalitu projektového týmu, jeho zkušenosti a schopnosti. Osobně považuji za velmi důležité zpětné monitorování těchto událostí a využití této zkušenosti pro další projekty, ať už pro projekty podobného zaměření, kde lze využít i určité technické či technologické know-how, či projekty svoji podstatou odlišné, kde je využitelná alespoň organizačně-projektová zkušenost. I přes úspěšnou realizaci celého projektu je potřeba najít a analyzovat body a situace, které znamenaly v projektu dílčí neúspěch, komplikaci či způsobily zbytečné plýtvání energií a zdroji. Identifikování těchto oblastí je věc jedna, nalezení lepšího řešení je však daleko

46

složitější, protože takové řešení již nelze zpětně ověřit a ubezpečit se o jeho výhodách. V průběhu projektu jsme jako slabá místa identifikovali tyto oblasti: •

Očekávání uživatelů byla příliš vysoká Jednotliví klíčoví uživatelé (tj. garanti modulů) v průběhu projektu přicházeli s požadavky, které nebyly součástí kontraktu a konceptu IS. Cílem těchto uživatelů bylo často pokrýt veškerou agendu oddělení. Identifikování důležitosti požadavků zabralo poměrně velké množství času, často bylo nutné zajít analyticky do hloubky, aby byla identifikována smysluplnost těchto požadavků. Určitou dobu zabrala identifikace tohoto problému jako takového. Možným řešením mohl být méně proaktivní přístup a přísnější trvání na řešení pouze oblastí, které byly „hlavní agendou“. Jistě by pomohla i častější komunikace s top managementem a informování o rozsahu, nicméně to by bylo hůře realizovatelné s ohledem na mandát, který byl projektovému týmu v této oblasti udělen.

•

Nedostatečné zapojení zákazníka, slabé nasazení a malá priorita Další komplikací bylo přikládání nedostatečné priority ze strany některých garantů a jejich oddělení. Docházelo k protahování analytických prací, odsouvání schůzek, nedostatečné přípravě na schůzky či studiu materiálů. Někteří uživatelé se domnívali, že celý IS vznikne bez jejich přičinění a že projektový tým přesně ví, jak má IS vypadat i bez jejich zapojení do projektu. V tomto ohledu je poměrně důležité prvotní nastavení zodpovědností jednotlivých stran, požadavků na ně kladených, komunikačních pravidel atd. S odstupem času vnímáme toto nastavení jako nedostatečné a měl na něj být z naší strany kladen větší důraz. Pravidla měla být zachycena v písemné podobě a zařazena do inicializačních dokumentů, abychom se na ně průběhu projektu mohli odvolávat a důrazně vyžadovat patřičnou součinnost. Celou situaci navíc zkomplikovaly personální výměny na postup IT manažera, tedy hlavní komunikační osoby pro projekt na straně zákazníka.

•

Chybějící kapacity pro pilotní provoz

47

Podobná situace jako v předchozím bodu se opakovala při uvádění systému do pilotního provozu – na straně zákazníka nebyl vyvíjen dostatečný tlak na kontinuální práci při zavádění některých částí systémů a vše bylo řešeno až při vyhrocení situace. I když jsme za tuto situaci nebyli zodpovědní, dotýkala se nás právě díky vnímání projektu jako celku, tj. i problém na straně zákazníka byl vnímán jako problém v projektu. Při projektových poradách tak byl vytvářen tlak na zavádění systému u zákazníka, navrhovány činnosti a úkoly, které by měly být realizovány, a poskytovány konzultační kapacity pro řešení pilotního provozu. I přesto nedocházelo k velkému posunu. Vzhledem k vytíženosti našeho projektového týmu nebylo možné přenést více činností na naši stranu, navíc by toto bylo prováděno nad rámec projektu. •

Problémy s plánováním kapacit a dodržením termínů Díky iteračním metodám vývoje bylo velmi náročné plánování kapacit, protože do existujících úkolů vstupovaly nové požadavky a nebyl dopředu přesně znám rozsah činností nad jednotlivými moduly jako v případě vývoje pomocí vodopádových modelů. Plánování tak vycházelo z odhadů, které bylo možné zpřesňovat. Obtížné bylo i definování termínů, které zákazník logicky požadoval, protože nebylo možné přesně určit počet iteračních cyklů a jejich délku.

•

Správa verzí a testování Pro projekt existovalo několik verzí, které pokrývaly: o Provozní systém o Testovací verzi pro zákazníka o Interní testovací verzi o Prezentační verzi Nejnovější verze systému obsahovala vždy interní testovací verze nebo prezentační verze. Po otestování a prezentaci byly části systému zprovozňovány pro zákazníka na jeho testovací verzi, kde probíhala akceptace a poté byl systém překlápěn na provozní verzi. Komplikace samozřejmě způsobuje fakt, že je nutné udržovat více verzí najednou – na testovací verzi zákazníka a provozní verzi není možné nahrávat

48

nejnovější verzi, ale verzi, která vzniká postupně z interní testovací verze jejím dolaďováním. Už samotné dolaďování testovací verze je komplikované, protože v době dolaďování testovací verze jsou vyvinuty nové části systému a přitom je třeba opravovat chyby ve verzi, která je starší. Je tak nutné udržovat nejnovější kód napříč týmem (k tomu slouží nástroje pro týmovou synchronizaci kódu) a ještě publikovat verze, které jsou stabilní a odladěné. Tyto cykly a změny se mohou odehrávat v řádu dnů i týdnů, tudíž je třeba nastavit jasný a průhledný systém, který toto s minimálním úsilím pokryje. Finální zodpovědnost za tuto činnost má však vedoucí vývoje, neboť on sám je zodpovědný za to, že budou publikovány a maximálně stabilní verze a testování bude efektivní.

Již v průběhu dokončování a předávání systému byly spouštěny nové projekty na rozšíření IS o funkce, které nebyly v prvním konceptu a kontraktu a byly spuštěny servisní smlouvy na předané moduly. Stejně jako se dynamicky mění potřeby společnosti a každá společnost se i vyvíjí, je nutné na tyto změny reagovat a upravovat a modifikovat IS, doplňovat jej o další funkce či reporty. Úspěšná realizace prvního projektu je tak základní podmínkou pro tuto další spolupráci. Projekt, i když byl poměrně jedinečný, nám umožnil využít velkou část našeho know-how a zkušeností. Stejně tak jsme stáli před problémy a výzvami, jejichž řešení nám nové poznatky a zkušenosti přineslo. Krom úspěšného řešení projektu považuji za velmi důležité nově získané know-how, které umožní kvalitnější řešení dalších projektů a realizaci nových, větších a komplikovanějších projektů.

49

Závěr V této práci jsem se zaměřil na metodiky řízení projektů s akcentem na metodiky vývoje software. Jak je z prvních kapitol patrné, metodiky pro projektové řízení i vývoj software poskytují obecný rámec a know-how, které lze při realizaci projektů využít. Tyto metodiky však operují v určité obecné rovině a jejich hloubka nemůže pokrýt konkrétní situace – pak by ztrácely svůj význam a technicky to ani není možné. Jejich hodnota spočívá i ve zkušenostech autorů, které se do metodik promítají a kteří je již téměř několik desítek let rozšiřují a upravují. Díky poměrně logické konstrukci, která odpovídá reálným projektům, je většina metodik snadno použitelné a mohou se stát vzorem pro vlastní metodickou implementaci v organizaci. Na konkrétním projektu jsem se pokusil ukázat zásadní vlastnost projektů – každý projekt je individuální, potýká se s vlastními problémy a vlastním vývojem. Velmi často se mění podmínky a situace v průběhu projektu a na to je potřeba reagovat. Tak, jak je projekt individuální, je nutné vhodně vybrat metodiky a metody pro jeho řízení. Volba vhodné metodiky je závislá na mnoha faktorech – projektovém vedoucím, know-how projektového týmu, požadavcích zákazníka, typu projektu či zvyklostech organizací, které na projektu spolupracují. Metodiky tak nelze aplikovat bezhlavě a hlavně – aplikace metodik projekt sama o sobě neučiní kvalitním a úspěšným. Teprve práce a zkušenosti celého projektového týmu a projektového vedoucího rozhoduje o úspěchu celého projektu. Metodiky jsou mocným nástrojem, který může týmu pomoci fungovat efektivněji, avšak samy o sobě kvalitní projekt nezajistí. I nejkvalitnější metodika popisující celý životní cyklus projektu nedokáže popsat všechny situace – jejich zvládnutí závisí na schopnostech projektového vedoucího, jeho citu pro řízení a zvládání těchto situací. O metodiky se však může při své práci výraznou měrou opřít. Stejně jako neexistuje dokonalý a stoprocentně úspěšný projekt bez chyb, neexistuje ani dokonalá metodika pro řízení projektů nebo vývoj software. Stejně jako se vyvíjí projekty, projektové týmy a projektoví manažeři, vyvíjí se i metodiky, vznikají nové, mění se jejich obliba. Tyto trendy je vhodné sledovat pro dosažení co nejlepšího výsledku celého projektu.

50

Seznam použité literatury 1. Kolektiv autorů pod vedením Ing. Václava Müllera. Projektové řízení (standard ČR dle IPMA). 2. vyd. Praha, Společnost pro projektové řízení, 2005. 2. Project Management body of knowledge, 3rd edition. USA, Project Management Insitute, 2004. 3. IT Governance Ltd., Webové stránky Prince 2, [cit. 2009-04-23], Dostupný z WWW: http://www.itgovernance.co.uk/prince2.aspx 4. ILX Group plc, Webové stránky Prince 2, [cit. 2009-04-23], Dostupný z WWW: http://www.prince2.com/what-is-prince2.asp 5. ICB – IPMA Competence Baseline, Version 3.0. Nizozemí, International Project Management Association, 2006. ISBN 0-9553213-0-1 6. Basili V., Zelkowitz. Analyzing Medium Scale Software Development. Proc. 3rd Intl. Conf. Software Engineering, IEEE 1978 7. Kolektiv autorů: Beck, Kent; Beedle, Mike; van Bennekum, Arie; Cockburn, Alistair; Cunningham, Ward; Fowler, Martin; Highsmith, Jim; Hunt, Andrew; Jeffries, Ron; Kern, Jon; Marick, Brian; Mellor, Steve; Schwaber, Ken; Sutherland, Jeff; Thomas, Dave; Grenning, James; Martin, Robert C.; Agile Manifesto. [cit. 2009-01-26], Dostupný z WWW: www.agilemanifesto.org 8. Beck, Kent. Extrémní programování. 1. vyd. Praha. Grada Publishing, 2002. ISBN 80247-0300-9 9. Beránek, Marek; Slabý, Antonín. Řízení projektu dle RUP využívající principy KKTR, [cit. 2009-01-25], Dostupný z WWW: objekty.pef.czu.cz/2004/sbornik/31_Beranek.pdf 10. Gilb, T. Principles of Software Project Mangement. Addison-Wesley, 1988 11. Kadlec, Václav. Agilní programování. 1. vyd. Praha. Computer Press, 2002. ISBN 80251-0342-0 12. Maule, Pavel. Project Management body of knowledge. Systémová integrace. Vydává: Česká společnost pro systémovou integraci, roč. 2004, č. 3.

51

13. Maule, Pavel. Porovnání PRINCE2 a PMBOK. Systémová integrace. Vydává: Česká společnost pro systémovou integraci, roč. 2004, č. 4.

52

Seznam použitých zkratek PM

Project manager (projektový vedoucí)

ČD

Člověkoden

IS

Informační systém

ERP

Enterprise Resource Planning – IS integrující procesy a informace napříč odděleními, např. logistika, plánování, výroba, fakturace, obchod

SW

Software

KKTR

Kvalita, Kvantita, Termín, Rozpočet

PMI

Project Management Institute

IPMA

Internation Project Managemetn Associtation

PMBOK

Project Management Body Of Knowledge

PRINCE2

Projects IN a Controlled Environement, 2. revize

XP

Extreme Programming (extrémní programování)

SLA

Service Level Agreement (dohoda o úrovni poskytovaných služeb)

53

Seznam obrázků Obrázek 1: Životní cyklus projektu dle PMBOK ................................................................ 12 Obrázek 2: Aktivita jednotlivých skupin procesů v čase..................................................... 12 Obrázek 3: Životní cyklus PRINCE2 a návaznost jeho částí .............................................. 15 Obrázek 4: Schéma vodopádového modelu vývoje............................................................. 22 Obrázek 5: Fáze spirálového modelu .................................................................................. 23

Seznam tabulek Tabulka 1: Srovnání metodik PMBOK a PRINCE2 ........................................................... 17 Tabulka 2: Podmínky ovlivňující výběr modelu vývoje software ....................................... 41

54