Masa rykova un iverz ita Ekonomicko-správní fakulta Studijní obor: Ekonomické informační systémy
IT PODPORA PROJEKTOVÉHO ŘÍZENÍ IT Support of Project Management Bakalářská práce
Vedoucí bakalářské práce: RNDr. Jaroslav Ráček, Ph.D.
Autor: Mgr. Pavel Šafář Brno, květen 2009
J mé no a p ř í j mení aut or a: Mgr. Pavel Šafář Ná z e v di pl omové pr áce: IT podpora projektového řízení Ná z e v pr ác e v angličt i ně: IT Support of Project Management Ka t e dr a: podnikového hospodářství Ve douc í di pl omové pr áce: RNDr. Jaroslav Ráček, Ph.D. Rok obha j oby: 2009
Anotace Předmětem bakalářské práce „IT podpora projektového řízení“ je problematika projektového řízení se zaměřením na informační technologie, plánování, stanovení milníků, podporu spolupráce a sdílení informací mezi členy projektu. První - teoretická část práce se zbývá různými aspekty projektového managementu. V druhé - praktické části je analyzován konkrétní projekt a navrţeno řešení, které by mělo přispět k podpoře projektového řízení a oblastem, které jsou popsány v teoretické části práce.
Annotation This bachelor paper “IT Support of Project Management” deals with a problem domain of project management with an emphasis on information technology, planning, milestones, collaboration and information sharing between project members. The first part addresses various aspects of project management. The second part is aimed to analyze a particular project and to propose a solution which should contribute to support project management and to other areas described at the theoretical part of this work.
Klíčová slova Projektové řízení, projekt, plánování, milníky, komunikace, IT, Portál, Liferay
Keywords Project management, project, planning, milestones, communication, IT, Portal, Liferay
Prohlášení Prohlašuji, ţe jsem bakalářskou práci IT podpora projektového řízení vypracoval samostatně pod vedením RNDr. Jaroslava Ráčka, Ph.D. a uvedl v ní všechny pouţité literární a jiné odborné zdroje v souladu s právními předpisy, vnitřními předpisy Masarykovy univerzity a vnitřními akty řízení Masarykovy univerzity a Ekonomicko-správní fakulty MU. V Brně dne 21. května 2009 vlastnoruční podpis autora
Poděkování Na tomto místě bych rád poděkoval RNDr. Jaroslavu Ráčkovi, Ph.D. za cenné připomínky a odborné rady, kterými přispěl k vypracování této bakalářské práce.
OBSAH ÚVOD .........................................................................................................................................6 1. PROJEKTOVÝ MANAGEMENT .....................................................................................7 1.1. Rámec ...........................................................................................................................7 1.2. Organizační struktura ..................................................................................................9 1.3. Projektová kancelář ...................................................................................................11 2. PROJEKT .........................................................................................................................12 2.1. Vlastnosti projektu .....................................................................................................12 2.2. Životní cyklus projektu ...............................................................................................13 2.3. Časový plán projektu..................................................................................................14 2.3.1. Definice a řazení aktivit ........................................................................................ 15 2.3.2. Odhad zdrojů a doby trvání .................................................................................. 15 2.3.3. Vytvoření a řízení časového plánu........................................................................ 16 2.4. Milníky........................................................................................................................16 2.5.1. Brooksův zákon .................................................................................................... 18 2.5.2. Rozdělení povinností ............................................................................................ 19 2.6. Komunikace v projektu ...............................................................................................19 2.6.1. Komunikační kanály ............................................................................................. 20 2.6.2. Produktivita ........................................................................................................... 21 2.7. Projektové dokumenty ................................................................................................23 2.7.1. Zakládací listina projektu...................................................................................... 23 2.7.2. Předběţná definice předmětu projektu ................................................................. 24 2.7.3. Plán projektu ......................................................................................................... 25 2.7.4. Uzavření projektu ................................................................................................. 25 3. PŘÍPADOVÁ STUDIE ....................................................................................................27 3.1. GS Soil ........................................................................................................................28 3.2. Plán projektu ..............................................................................................................28 3.3. Organizace projektu ...................................................................................................29 3.4. Podpora v projektu .....................................................................................................30 4. NÁVRH IT PODPORY ....................................................................................................32 4.1. Portál..........................................................................................................................33 4.2. Liferay ........................................................................................................................33 4.2.1. Organizace portálu ................................................................................................ 35 4.2.2. Portálové stránky .................................................................................................. 35 4.3. Implementace .............................................................................................................36 4.3.1. Organizace ............................................................................................................ 37 4.3.2. Komunita a role .................................................................................................... 37 4.3.3. Projektové prostředí .............................................................................................. 37 4.3.4. Zhodnocení ........................................................................................................... 39 ZÁVĚR .....................................................................................................................................42 SEZNAM PŘÍLOH...................................................................................................................43 SEZNAM POUŢITÉ LITERATURY ......................................................................................44
ÚVOD V dnešní turbulentní době, která je specifická obrovskými nároky společnosti, se postupně opouští klasické metody projektového řízení a přichází na řadu moderní přístupy v podobě řízení projektů. Při bliţším zkoumání činností jednotlivých společností bychom zjistili, ţe jejich aktivity jsou řešeny právě formou projektů, ať uţ malých či velkých. Zároveň se upouští od klasických a nepruţných organizačních struktur, jako je funkční, a přechází se ke strukturám maticovým, které ve spojení s projekty nabízejí silný nástroj, jak reagovat na dnešní uspěchanou dobu. Schopnost pruţně reagovat na změny se v dnešní době stala faktorem, který zajišťuje úspěch, prosperitu a konkurenceschopnost. Zejména v oblasti informačních technologií, která v posledních dvaceti letech zaznamenává rozmach, jako snad ţádná jiná technologie v naší historii. Samotný faktor pruţnosti by sám o sobě nestačil. Dnešní doba je také specifická specializací jednotlivých činností a oborů. Mnoho firem pracuje na principu tzv. outsourcingu, kdy nabízí své specialisty v různých oborech jiným společnostem. Tito lidé jsou tak zařazování do různých pracovních týmů se společným jmenovatelem, kterým je úspěšnost projektu. Té by nebylo moţné docílit bez týmové spolupráce, komunikace a sdílení informací společně s nadšením a motivací. Kritickým faktorem v projektových týmech jsou i jejich vedoucí, tedy projektoví manaţeři, kteří za projekt a jeho úspěšnost zodpovídají. Je velmi ţalostné, ţe pouhá hrstka projektů, alespoň podle průzkumu a zprávy společnosti Standish Group1, končí mimo tzv. projektový trojúhelník. Zjednodušeně řečeno, projekty nekončí včas, s dohodnutým rozsahem a ve sjednané kvalitě. Z toho důvodu jsou hledány cesty, jak úspěšnost projektů zvýšit a moţná jsou to právě informační technologie, které budou představovat onu „stříbrnou kulku“2. Tato práce se zaměřuje na projektové řízení, zejména v oblasti zmíněných informačních technologií, a podporu úspěšnosti projektů se zacílením na plánování, milníky, projektový tým a jeho potřeby. Cílem práce je navrhnout takové prostředí, které bude uţitečné při řízení projektů a bude faktorem zvyšujícím jejich úspěšné dokončení. Práce je rozdělena do dvou částí. V první - teoretické části jsou vysvětleny základní pojmy týkající se projektů a projektového řízení, nastíněny problémy typické pro prostředí informačních technologií, detailněji rozepsány oblasti plánování a komunikace. V druhé - praktické části je pak analyzován konkrétní projekt a navrţeno adekvátní řešení, které je v souladu s cílem této práce. V poslední části jsou pak zhodnoceny výsledky řešení se zaměřením na limity a moţná pokračování.
1 2
Project Smart: Project Management Templates, Articles, Books and PRINCE2 Training [online] Silver Bullet, více informací na Wikipedia, the free encyklopedia. [online]
6
1. PROJEKTOVÝ MANAGEMENT Projektový management není pojmem novým, existuje v podstatě tak dlouho, jako lidstvo samo. Jako příklad uveďme činnosti, které provázely lidstvo na svých počátcích, zejména hledání a sběr obţivy, přístřešku či tepla, coţ představovalo v té době jistou formu projektů, protoţe úspěchu by nebylo moţné dosáhnout bez cílevědomé koordinace jednotlivých lidských činností. V této práci se ale budeme spíše zabývat moderním pojetím projektového managementu, které sahá do dob průmyslové revoluce. Klíčovou osobou v této oblasti je Frederick Taylor3, který je povaţován za otce managementu, zejména díky své knize Principles of Scientific Management, která byla vydána na počátku 20. století. Od této doby se v podstatě pojem projektový management ustálil. Ovšem na velkém významu získal aţ s příchodem Henryho Gantta, který zavedl pojmy jako je Ganttův diagram, milník či odhad pracnosti. Jednotnou definici toho, co je to přesně projektový management, bychom hledali marně. Podíváme-li se do patřičné literatury či na Internet, najdeme v krátké době hned několik definic. Uveďme si pouze některé z nich. Uvidíme, ţe jednotlivé definice se od sebe odlišují, ale jejich podstata zůstává stejná. Řízení projektů neboli projektový management je podle PMI (Project Management Institute) „uplatnění veškerých poznatků, dovedností, nástrojů a technik na aktivity (činnosti) projektu takovým způsobem, aby byly splněny požadavky na projekt“4. Dle Svozilové je řízení projektů „krátkodobě vynaložené úsilí doprovázené aplikací znalostí a metod, jehož účelem je přeměna materiálních a nemateriálních zdrojů na soubor předmětů, služeb nebo jejich kombinace tak, aby bylo dosaženo vytyčených cílů“5.
1.1. Rámec Na níţe uvedeném obrázku je ilustrován rámec celého projektového řízení. Mezi klíčové prvky patří zejména účastníci, oblasti poznatků, nástroje, techniky a úspěchy předchozích projektů. Obrázek 1.1. Základní rámec řízení projektů
Zdroj: SCHWALBE, K. Řízení projektů v IT. s. 42 3
MURCH. R. Project Management, s. 5 Project Management Institute. A Guide to Project Management Body of Knowledge. s. 23 5 SVOZILOVÁ, A., Projektový management, s. 19 4
7
Všimněme si, ţe jednotlivé projekty jsou začleněny do tzv. portfolia projektů, které je definováno jako sada projektů nebo programů6, jeţ jsou seskupeny v jeden celek. V rámci portfolia pak organizace seskupuje, řídí projekt jako portfoliové investice, které společně přispívají k celkovému úspěchu firmy. Výraz účastníci projektu označuje osoby, které jsou zapojeny do řešení projektu a jeho aktivit, nebo jsou jimi ovlivněny. Mezi účastníky patří zejména zadavatel projektu, projektový manaţer, projektový tým, podpůrný personál, zákazníci, uţivatelé, dodavatelé a dokonce i oponenti projektu. Oblasti poznatků, jejichţ celkový počet je 9, popisují nejdůleţitější schopnosti či kvalifikace, které by si měl osvojit kaţdý projektový manaţer. Uveďme stručný popis jednotlivých oblastí: Řízení rozsahu projektu znamená definování a řízení veškerých prací, nezbytných k úspěšnému dokončení projektu. Řízení času představuje odhad doby potřebné k dokončení prací, navrţení plánu a zajištění včasného dokončení. Řízení nákladů zahrnuje přípravu rozpočtu a jeho řízení. Řízení kvality zajišťuje naplnění stanovené nebo předpokládané potřeby projektu. Řízení lidských zdrojů zahrnuje efektivní nasazení lidí. Řízení komunikace se zabývá generováním, shromaţďováním, distribucí a ukládání informací o projektu. Zejména na tuto oblast budou zaměřeny následující kapitoly práce. Řízení rizik se skládá z identifikace, analýzy a reakce na projektová rizika. Řízení obstarávání znamená zajišťování zboţí a sluţeb potřebných pro řešení projektu. Ve výše zmíněném výčtu účastníků projektu byl zmíněn jeden, který je pro projekt nepostradatelný. Jedná se o projektového manaţera, tedy o člověka, do jehoţ kompetence spadá celá řada různých činností, jejichţ přesný popis se často liší, a to podle podmínek konkrétní organizace a projektu. Podle závěrů různých studií bylo identifikováno několik důleţitých součástí profese projektového manaţera. Jak uvidíme v následujícím výčtu7, jedná se o velmi rozmanitý okruh dovedností a zodpovědností. 1. Definovat rozsah projektu 2. Identifikovat účastníky, rozhodovatele a eskalační postupy 3. Navrhnout podrobný seznam úkolů 4. Odhadnout časové požadavky 5. Navrhnout prvotní vývojové diagramy 6. Specifikovat zdroje a rozpočet 7. Posoudit projektové požadavky 8. Identifikovat a posoudit projektová rizika 9. Připravit nouzový plán 10. Identifikovat vzájemné závislosti 11. Identifikovat a sledovat kriticky důležité milníky 12. Účastnit se revizí projektových fází 13. Zajistit potřebné zdroje 6 7
Program je sada souvisejících projektů, jenţ jsou koordinovaně řízeny k dosaţení většího uţitku. Olayle Adelakun Ph.D. DEPAUL CTI. School of Computer Science, Telecommunications and Information Systems [online] – vlastní překlad autora
8
14. Kontrolovat proces řízení změn 15. Sestavovat zprávu o stavu projektu Cílem této práce je mimo jiné i poskytnout podporu pro snadné zvládnutí některých výše uvedených okruhů, zejména č. 2, 3 a 11. Důvodem je velká přetíţenost projektových manaţerů, kteří často řídí i několik projektů v jeden okamţik. Jistě si kaţdý dokáţe představit, jak nesmírně těţké je myslet na všechny různé úkoly, termíny, schůzky či další povinnosti a to v kontextu i několika projektů. Tato práce by měla přinést IT podporu těchto zmíněných oblastí a usnadnit tak projektové řízení, oprostit projektové manaţery o rutinní činnosti a dovolit jim, aby se věnovali tomu, co umí nejlépe, tedy řízení projektů. Konkrétní způsob podpory projektového řízení bude popsán v některé z následujících kapitol, pro tuto chvíli zmiňme, ţe se bude jednat o podporu v oblasti projektové i meziprojektové komunikace, sdílení projektových artefaktů8, udrţování historie projektů, správu lidí na projektu, společně s jejich zodpovědností a správu milníků.
1.2. Organizační struktura Současná „turbulentní“ doba v podstatě odstranila prostor pro klasické řízení, které je zaměřeno spíše na udrţování jiţ zaběhlých a optimalizovaných procesů. V době, kdy dochází k velkému mnoţství změn a tyto změny mohou přijít v podstatě kdykoli, je velmi důleţité, aby organizace měla patřičnou organizační strukturu, která jí dovolí na vzniklé změny rychle a efektivně reagovat. Organizační struktury pro řízení projektů dle Fialy9 zachycují vztahy mezi účastníky projektu s ohledem na jejich povinnosti a pravomoci. Organizační struktury se dají rozdělit do tří základních skupin, a sice funkční, projektová a maticová. Volba konkrétní organizační struktury závisí na mnoha faktorech, mezi základní dle Fialy10 patří: struktura a rozsah projektu, způsob zapojení organizační struktury a účastníků projektu, míra ochoty a schopnosti spolupráce účastníků projektu, úroveň informačního systému účastníků projektu, míra institucionalizace subjektu projektového řízení, právní, ekonomická a další omezení. Organizační struktura také velmi ovlivňuje způsob a mnoţství komunikace, která musí v rámci projektu proběhnout. Jak uţ bylo zmíněno, turbulentní doba přináší velké a časté změny v projektovém prostředí. Jestliţe např. musí dojít k tomu, ţe jeden člen projektového týmu musí být vyměněn za jiného, dochází k několika problémům, a to zejména v oblasti komunikace. Nový člen týmu bude muset v prvních dnech či týdnech, v závislosti na velikosti projektu, velmi intenzivně komunikovat s ostatními členy týmu. Jestliţe bude zvolena nevhodná organizační struktura, můţe velká míra komunikace ohrozit celý projekt a jeho úspěšnost. Tento jev popsal jiţ v roce 1975 Fred Brooks a nazývá se Brooksův zákon, více informací v subkapitole 2.5.1. (Brooksův zákon) Vraťme se ale k jednotlivým typům organizačních struktur, popišme je trochu detailněji. Funkční organizační struktura představuje tradiční organizační hierarchii s útvary podle 8
Artefakt je termín, který označuje libovolný objekt nebo proces, který vznikl lidskou aktivitou. Zdroj: Wikipedie, otevřená encyklopedie [online] 9 FIALA, P. Projektové řízení: modely, metody, analýzy, s. 16 10 tamtéţ. s. 16
9
jednotlivých funkcí. Nejvyššímu či výkonnému řediteli jsou podřízení funkční manaţeři, viceprezidenti či náměstci pro různá oddělení, jako je výroba, marketing, IT nebo finance. Tuto strukturu má například většina vysokých škol a fakult a je vhodná pro nepříliš časté realizace menších projektů. Jestliţe jednotlivé projekty přesahují funkční útvary, nastává problém s koordinací, protoţe neexistuje jediný odpovědný koordinátor. U rozsáhlejších projektů by to znamenalo velké začlenění nejvyššího managementu, který by se ale měl spíše věnovat problémům na strategické úrovni. Projektová organizační struktura je velmi podobná předchozí funkční struktuře. Celá struktura podléhá řediteli projektů a namísto náměstků či viceprezidentů podléhají projektovému řediteli jednotliví projektoví manaţeři. Pod nimi jsou pak zařazeni zaměstnanci pro zajištění nejrůznějších projektových činností. Tato organizační struktura je plně podřízena cílům jednotlivých projektů, je vhodná pro rozsáhlé a časově náročné projekty. Výhodou této struktury je plná koncentrace na projekt a silné ztotoţnění pracovníků s cíli projektu. Naopak k nevýhodám patří časté problémy s přeřazováním pracovníků. Vzhledem k dynamické závislosti na rozsahu a četnosti projektů můţe docházet k přetíţení či nevyuţití lidí při práci na projektech. Maticová organizační struktura je přechodem mezi funkční a projektovou strukturou. Zaměstnanci jsou v ní často podřízeni současně funkčnímu manaţerovi i jednomu nebo více projektovým manaţerům. Maticová organizační struktura můţe být silná, slabá nebo vyváţená, a to podle mnoţství kontroly či pravomoci příslušných projektových manaţerů. Tuto organizační strukturu mívají zpravidla oddělení informačních technologií. Je vhodná pro projektové firmy s velkou četností nových projektů. Výhodou je efektivní vyuţití lidí, pruţnost a vysoká kreativita. V níţe uvedené tabulce je znázorněn vliv organizační struktury na projekty a projektové manaţery. Tabulka 1.1. Vliv organizační struktury na řízení projektů Organizační struktura Projektová vlastnost
Silná maticová
Projektová
Nízká aţ střední
Střední aţ vysoká
Vysoká aţ téměř úplná
0-25%
15-60%
50-95%
85-100%
Funkční manaţer
Funkční manaţer
Obojí
Manaţer projektu
Manaţer projektu
Částečný úvazek
Částečný úvazek
Plný úvazek
Plný úvazek
Plný úvazek
Obvyklé označení funkce (role) manaţera projektu
Koordinátor/Vedou cí projektu
Koordinátor/Vedou cí projektu
Zapojení administrativních zaměstnanců do řízení projektu
Částečný úvazek
Částečný úvazek
Pravomoc projektového manaţera Procento výkonných pracovníků firmy, přidělených na plný prac. úvazek k řešení projektu Kdo kontroluje rozpočet projektu Role manaţera projektu
Funkční
Slabá maticová
Ţádná nebo téměř ţádná
Omezená
Prakticky nulové
Vyvážená maticová
Manaţer Manaţer Manaţer/Ředit projektu/Programov projektu/Programov el projektu ý manaţer ý manaţer
Plný úvazek
Plný úvazek
Zdroj: SCHWALBE, K. Řízení projektů v IT. s. 80
10
Plný úvazek
V příloze A – „Organizační struktura“ jsou graficky znázorněny klíčové vlastnosti jednotlivých organizačních struktur.
1.3. Projektová kancelář V některých organizacích, kde probíhá velké mnoţství projektů, hraje důleţitou organizační roli tzv. projektová kancelář neboli PMO11. Jedná se o jednotku, která koordinuje a napomáhá při řízení projektů v organizaci. Mívá rozmanitou strukturu a její role a povinnosti se často liší. Mezi moţné cíle projektové kanceláře patří dle Schwalbe12: Shromažďování, uspořádání a integrace dat o projektech za celou organizaci. Vývoj a udržování šablon pro projektové dokumenty. Rozvoj nebo koordinace školení k tématům souvisejícím s řízením projektů. Rozvoj a zajištění formálního kariérního postupu pro projektové manaţery. Poskytování konzultačních služeb k řízení projektů. Poskytování vhodné „domovské“ struktury pro projektové manaţery, kteří plní tyto role nebo jsou zařazeni do různých projektů.
11 12
Project Management Office SCHWALBE, K. Řízení projektů v IT. s. 60
11
2. PROJEKT V předchozí kapitole, zejména na jejím konci, byl několikrát zmíněn termín, který doposud nebyl vysvětlen, i kdyţ je pro obsah této práce zcela stěţejní. Jedná se o termín projekt. Podobně jako u pojmu „projektový management“, i zde existuje celá řada definic. Uveďme si pouze některé z nich. Uvidíme, ţe způsob popisu se opět liší, ale jejich význam je v podstatě stále stejný. Dle Mintzera je projekt „plán, návrh či schéma, které vyžaduje koordinované úsilí pro specifikovaný úsek času. Zahrnuje úlohy, které jsou vykonávány skupinou lidí, případně jednotlivci, jako je např. aktualizace aplikace, trénink zaměstnanců nebo případně výuka angličtiny“ 13. Podle jiţ zmiňované organizace PMI je projekt „časové ohraničená činnost, jejímž výsledkem je vytvoření jedinečného produktu, služby či jiného výsledku“14. Časovým ohraničením rozumíme fakt, ţe kaţdý projekt má jasně definovaný začátek i konec. Další definici projektu zmiňuje rovněţ Fiala, dle něhoţ „projekt je výsledek materiální nebo nemateriální povahy založený na strategickém plánu, navržený, organizovaný a realizovaný pod řízením někoho v zájmu vlastníka nebo zadavatele“15.
2.1. Vlastnosti projektu Kaţdý projekt je realizován pouze jednou a je charakteristický několika vlastnostmi, z nichţ některé vyplývají z výše uvedených definic. Výčet vlastností je převzat z díla Schwalbe16: Projekt má jednoznačně určený cíl. Projekt je dočasný. Řešení projektu se postupně vypracovává. Projekt vyţaduje určité zdroje, často z různých oblastí. Projekt by měl mít nějakého hlavního zákazníka nebo zadavatele. Součástí projektu je neurčitost. Zároveň je projekt definován třemi ukazateli, které se často znázorňují tzv. Ďáblovým trojúhelníkem. Na ukazatelích „náklady“ a „čas“ se v podstatě shodují všichni autoři, třetím parametrem je podle Svozilové „dostupnost zdrojů“17, Fialy „kvalita“18 a podle PMI „rozsah“19.
13
MINTZER, R. Project Management Book. s. 3 Project Management Institute. A Guide to Project Management Body of Knowledge. s. 20 15 FIALA, P. Projektové řízení: modely, metody, analýzy. s. 10 16 SCHWALBE, K. Řízení projektů v IT. s. 37 17 SVOZILOVÁ, A. Projektový management. s. 23 18 FIALA, P. Projektové řízení: modely, metody, analýzy. s. 11 19 Project Management Institute. A Guide to Project Management Body of Knowledge. s. 8 14
12
Obrázek 2.1. Ďáblův trojúhelník
Zdroj: Kolektiv autorů. Projektové řízeni Příručka manažera. s. 14
Jistě všichni by chtěli své projekty realizovat za minimální čas a náklady, společně s maximální kvalitou. Bohuţel to prakticky není moţné. Projektový manaţer musí vţdy uvést do souladu soupeřící zájmy a tím uspokojit jednotlivé zainteresované strany. Úkolem projektového manaţera je tedy najít vyváţený bod v zobrazeném trojúhelníku. V první kapitole bylo zmíněno, ţe se budeme soustředit spíše na projekty realizované v oblasti IT. Z obecného hlediska by se dalo říct, ţe projekt je jednoduše projekt a je jedno, ze které oblasti pochází. Ať uţ je to stavebnictví, vědecký výzkum či IT. Kaţdá z uvedených oblastí má ale svá jistá specifika, která si pro oblast IT v následujících řádcích popíšeme. Oblast informačních technologií je specifická značnou mírou různorodosti projektů, které se liší jednak svou velikostí a jednak pouţitou technologií. Existují malé projekty, pro jejichţ realizaci je potřeba pouze malý tým a úkolem je „nainstalovat“ specifický druh hardwaru do produkčního prostředí. Naopak mohou existovat dlouhodobé projekty, které vyţadují práci lidí z různých oborů. Takové projekty zahrnují např. analýzu podnikových procesů různých společností a následně vývoj software, který bude výsledným řešením. Rozdíly bychom ale našli i ve zmíněných malých hardwarově orientovaných projektech. Zde se můţe jednat o instalaci osobního počítače, síťového prvku nebo dokonce počítače mainframe. Všechny tyto druhy hardware vyţadují různé znalosti a zkušenosti. Samozřejmě bychom podobné rozdíly nalezli i v oblasti software, kde můţeme vyvinout program, který bude pracovat nad jednoduchou tabulkou vytvořenou v Microsoft Excelu či Accessu, anebo nad sloţitou strukturou uloţenou v relačních databázích. Je zřejmé, ţe IT projekty mají mnoho specifik a jak uţ bylo zmíněno dříve, kaţdý projekt je jedinečný. V oblasti IT toto pravidlo platí dvojnásob.
2.2. Životní cyklus projektu Pro pochopení fungování podstaty projektů a jejich řízení je velmi důleţité zastavit se u ţivotního cyklu projektu. Jak uţ bylo zmíněno v předchozí kapitole, kaţdý projekt je ohraničen svým začátkem a koncem. Mezi těmito dvěma body probíhá projekt a ten je zpravidla rozdělen do několika fází. Rozdělení projektu přináší řadu výhod, a to zejména z oblasti jeho řízení a kontroly. Zpravidla přechod z jedné fáze do druhé zahrnuje formální 13
kontrolu a převzetí výstupů předchozí fáze. Tento přístup představuje silný kontrolní mechanismus vedoucí k zajištění kvality koncových produktů projektu. Ţivotní cyklus projektu obvykle definuje:20 náplň (aktivity) jednotlivých fází ţivotního cyklu; výstupy jednotlivých fází; role zapojené do jednotlivých fází; způsob, jakým probíhá kontrola a formální odsouhlasení jednotlivých fází. Mezi jednotlivými fázemi projektu se vyskytují tzv. milníky, ty budou detailněji rozepsány v některé z dalších kapitol. Práce s milníky je jednou z oblastí, kam směřuje praktická část této práce. Nyní se podívejme, jaké jsou jednotlivé fáze a co představují. Obrázek 2.2. Fáze klasického životního cyklu řízení projektu
Zdroj: SCHWALBE, K. Řízení projektů v IT. s. 88
Jednotlivé fáze nejsou jednotně ustáleny a mohou se lišit v závislosti na různých faktorech organizace. My vycházíme z definice pouţité Schwalbe21, která je v podstatě shodná s tou, kterou ve své knize popisuje Fiala22. Instituce PMI v obecné rovině rozlišuje pouze tři hlavní fáze (počáteční, střední a závěrečnou). Koncepční fáze – vytvoření popisu projektu a jeho cíle, hrubého rámcového plánu, předběţného rozpisu nákladů, přehledu očekávaných výstupů, definice rozsahu projektu atd. Vývojová fáze – vytvoření projektového týmu, podrobnějšího plánu, přesnějšího odhadů nákladů, rozpisu prací apod. Implementační fáze – definitivní odhad nákladů, skutečný rozpis prací. Ukončovací fáze – dokončení díla, ponaučení a převzetí díla zákazníkem. Poznamenejme, ţe kaţdou z uvedených fází je moţné rozdělit na jednotlivé cykly, např. implementační fáze můţe probíhat ve třech cyklech, kde na konci kaţdého cyklu je provedena revize jak ze strany projektového manaţera, tak ze strany zákazníka. Na konci kaţdého cyklu tak existuje výše zmíněný milník projektu.
2.3. Časový plán projektu Časový projektový plán je artefakt, který vzniká uţ v počátečních fázích projektu. V prvních fázích má pouze orientační podobu, ale postupem času se zpřesňuje. Zahrnuje jednotlivé aspekty celého projektu jako je čas a zdroje (finanční, personální či materiální). Obecně se jedná o „seznam dílčích úkolů s přiřazenými zdroji (kdo bude úkol vykonávat) a časem (jak dlouho bude provedení trvat). Projektový plán kopíruje strukturu projektu. Má-li například
20
Kolektiv autorů. Projektové řízeni Příručka manažera. s. 25 SCHWALBE, K. Řízení projektů v IT. s. 88 22 FIALA, P. Projektové řízení: modely, metody, analýzy. s. 19 21
14
pět etap, očekáváme, že se v plánu objeví pět hlavních částí, kterou budou rozpadnuty na úkoly“23. Mimo jiné existuje celá řada dalších plánů, které jsou nezbytné pro úspěšné řízení projektů, jedná se např. o plán rizik, zodpovědností a pravomocí, řízení rozsahu, řízení nákladů atd. Tyto a další jiné plány přesahují rozsah této práce, a proto se jimi nebudeme blíţe zabývat. V následujících subkapitolách si popíšeme kroky, které jsou nezbytné pro vytvoření časového plánu projektu. Kroky probíhají v tom pořadí, v kterém jsou uvedeny24.
2.3.1. Definice a řazení aktivit Jedná se o krok identifikace konkrétních aktivit, které musí členové týmu a účastníci projektu vykonat, aby byly dokončeny všechny ucelené části díla. Aktivita je pak úsek práce, jeţ je obvykle definována ve struktuře rozpisu prací WBS25, neboli hierarchický rozpad projektu na etapy, milníky a aktivity. U jednotlivých aktivit by mělo být řešeno, jaké jsou jejich vztahy k ostatním aktivitám, jací jsou její předchůdci, následníci, logické vztahy, předstih či prodleva, poţadavky na zdroje, omezení a případně předpoklady. V zásadě existují čtyři způsoby (případně jejich kombinace), jak vytvořit WBS: výběr úkolů z existujícího seznamu, úprava a vyladění seznamu úkolů z podobného projektu, týmový brainstorming26, zapojení externích expertů. Jakmile jsou vymezeny všechny aktivity projektu, můţeme v plánování přistoupit k jejich seřazení. Při konstrukci WBS bychom se neměli snaţit být lineární a psát aktivity v pořadí, v jakém budou vykonávány. Při řazení aktivit musíme projít seznam aktivit společně s jejich atributy, milníky a odvodit závislosti mezi jednotlivými aktivitami. Hlavním výstupem ze seřazených aktivit je síťový diagram projektu. Tyto diagramy představují schématické znázornění logických vztahů mezi aktivitami. Jedná se o graf, jenţ se skládá z uzlů a orientovaných úseček. Základní podmínkou je, ţe tento graf musí být orientovaný, ohodnocený (uzlově či hranově), souvislý, acyklický a konečný. Více informací je k nalezení v knize P. Fialy : Projektové řízení: modely, metody, analýzy (viz Seznam pouţité literatury). V příloze B – „Diagramy“ je na obrázku B.1 – „Síťový diagram“ zobrazen příklad síťového diagramu.
2.3.2. Odhad zdrojů a doby trvání Před samotným odhadováním doby trvání jednotlivých aktivit musíme mít jasnou představu o počtu a typu prostředků neboli zdrojů přiřazených k řešení kaţdé z nich. V ideálním případě je vhodné vytvořit několik variant alokace zdrojů, jelikoţ právě zdroje jsou většinou nejvýraznější poloţkou nákladů projektu. Výstupem by měl být seznam poţadovaných zdrojů seřazených podle jednotlivých aktivit.
23
Kolektiv autorů. Projektové řízeni Příručka manažera. s. 71 SCHWALBE, K. Řízení projektů v IT. s. 235 25 Work Breakdown Structure 26 Brainstorming je skupinová technika zaměřená na generování co nejvíce nápadů na dané téma. Zdroj: Wikipedie, otevřená encyklopedie. [online] 24
15
Odhadování doby trvání jednotlivých aktivit je pravděpodobně nejproblematičtější oblastí vytváření časového plánu. Nutno poznamenat, ţe doba trvání je skutečné mnoţství času, stráveného prací na aktivitě, plus „volně“ uplynulý čas. To znamená, ţe jestliţe je potřeba k dokončení určité aktivity jeden týden (pět pracovních dní), můţe se doba trvání aktivity vyšplhat na dva týdny, protoţe k ní budeme muset například zjistit nějaké podkladové informace. Na odhad doby trvání má vliv také objem zdrojů, přiřazených na řešení aktivity. Je důleţité nezaměňovat dobu trvání s úsilím neboli pracností. Ta představuje skutečně odpracované úsilí, v jednom dni to můţe být i 80 hodin, jestliţe na aktivitě bude pracovat 10 lidí 8 hodin. Doba trvání aktivity je ale pouze jeden den.
2.3.3. Vytvoření a řízení časového plánu Pro vytvoření časového plánu existuje několik nástrojů a technik: Ganttův diagram – Henry Gantt byl zmíněn na začátku druhé kapitoly jako jedna ze stěţejních osob v oblasti moderního managementu. Jeho diagramy se pro svou jednoduchost pouţívají dodnes. Jedná se o formát pro grafické zobrazení informací o časovém plánu projektu. Někdy je tento diagram označován jako pruhový, jelikoţ aktivity jsou v něm označeny jako jednotlivé pruhy. Jednou z výhod Ganttova diagramu je jeho schopnost porovnat a znázornit plánovaný a skutečný průběh aktivit. Na základě Ganttova diagramu je moţné znázornit kritickou cestu celého projektu. Analýza kritické cesty – neboli metoda CPM27. Kritická cesta v projektu je „posloupnost aktivit, která určuje nejdříve možný okamžik dokončení projektu“28. Jedná se o cestu, na které nejsou ţádné časové rezervy a na které se jednotlivá zpoţdění promítnou do zpoţdění celého projektu. Plánování kritického řetězu – jedná se o techniku, která pracuje s platným omezením zdrojů a vychází z „Teorie omezení“, která byla vypracována Eliyahem M. Goldrattem. Metoda PERT29 – pouţívá se zejména v případech, kdy jsou odhady trvání jednotlivých aktivit zatíţeny vysokou mírou nejistoty. Tato metoda v podstatě aplikuje kritickou cestu na váţený průměr z odhadů dob trvání. Váţený průměr aplikuje na optimistický, pesimistický a nejpravděpodobnější odhad. Výhodou této metody je, ţe se snaţí zohlednit riziko spojené s odhadováním dob trvání jednotlivých aktivit. Důleţitou aktivitou v projektovém plánování je sledování a úprava plánu podle aktuální situace. Velmi jednoduchou metodou je srovnávání prací s plánem, zejména dodrţování termínů, plnění úkolu dle rozpisu aktivit a kontrola vyuţívání prostředků. Celou oblast sledování aktuálního stavu lze zahrnout do procesu monitorování projektu, která by měla být součástí implementační fáze, měla by tak rozšířit ţivotní cyklus projektu.
2.4. Milníky Jak bylo řečeno v úvodní kapitole, tato práce se z velké části zaměřuje na body v plánu zvané milníky (resp. milestones). Milník je významná událost, která v podstatě netrvá ţádnou dobu a většinou se jedná o jednorázový akt. V předchozí kapitole jsme zmínili, ţe na konci kaţdé fáze projektu by měl byt milník, stanovující kdy dojde k předání určitě části projektu. Můţe se ale jednat i o dokončení smlouvy, podepsání objednávky, odsouhlasení dokumentu 27
Critical Path Method SCHWALBE, K. Řízení projektů v IT. s. 59 29 Program Evaluation and Review Technique 28
16
poţadavků atd. Milníky vymezují významné události a slouţí ke zpřehlednění projektových plánů a ke snazšímu sledování postupu prací. „Milník v síťovém diagramu je čtverec, který definuje aktivitu nebo sadu aktivit, jež musí být dokončeny. Jsou to kontrolní body, které dokáží říci, jestli projekt pokračuje podle plánu nebo ne. Milniky mohou a také často zahrnují důležité projektové artefakty.“30 Milníků můţe být v projektu celá řada a v podstatě je nelze obecně kvantifikovat, vţdy záleţí na jednotlivém projektu. Určitě ale existují milníky, které jsou shodné pro většinu projektů, např. jiţ zmíněný podpis smlouvy, odsouhlasení dokumentu poţadavku atd. Jestliţe bychom chtěli nalézt něco, co je společné všem milníkům, mohli bychom pouţít oblíbenou metodu pro definování zásad milníku tzv. SMART kritéria: Specific – konkrétní Measurable – měřitelný Assignable – přiřaditelný Realistic – realistický Time-framed – časově ohraničený Velmi důleţitým kritériem je přiřaditelnost, za kaţdý milník by měla být zodpovědná právě jedna osoba podle pravidla, ţe kaţdá pravomoc a zodpovědnost můţe být přiřazena pouze jednomu subjektu v rámci projektové hierarchie.
2.5. Projektový tým Důleţitým aspektem, který můţe výrazně ovlivnit úspěšnost celého projektu, je tým lidí, kteří na projektu pracují. Osoba, která odpovídá za celý projekt je projektový manaţer. Základní okruh zodpovědností projektového manaţera byl popsán v subkapitole 1.1. (Rámec). Mezi ostatní osoby v projektovém týmu patří analytici, vývojáři, vedoucí vývoje, testeři, designéři, systémoví inţenýři, zástupci projektového manaţera apod. Jednotlivých rolí můţe být v projektu několik a jsou závislé na typu projektu. Abychom se dostali do kontextu milníků, připomeňme, ţe pro kaţdý milník musí být specifikovaná odpovědná osoba. Ne nutně to musí být vţdy projektový manaţer, např. milník dokončení dokumentu poţadavků bude dán na starost analytikovi, k němuţ bude přiřazen patřičný realizační tým, který bude pracovat na vyhotovení zmíněného dokumentu. Odpovědnost a pravomoc za přidělení zodpovědnosti má samozřejmě projektový manaţer, který (jak je výše uvedeno) odpovídá za výběr účastníku a definování jednotlivých aktivit. Faktorem, který opět ovlivňuje úspěšnost projektu a jeho včasné dokončení je velikost týmu. Rozhodně neplatí, čím větší tým, tím lépe. Ideální velikost týmu se dá jen velmi těţko odhadnout. Samozřejmě můţeme postupovat tak, ţe celkové úsilí vydělíme počtem dnů od začátku projektu do předpokládaného nebo poţadovaného konce (tzv. deadline), tím ale získáme pouze velikost týmu, nikoli jeho ideální velikost. Slovo ideální je velice vágní a jedním z podúkolů této práce je pokusit se velikost týmu změřit či hodnotit. Jedním z problémů, které vznikají ve velkých týmech, je velké mnoţství neproduktivní komunikace mezi jednotlivými členy. Problém také nastává v případě, ţe je přidán nový člen 30
Mintzer, R. Project Management Book .s. 105. Vlastní překlad autora
17
týmu. Představme si, ţe jsme před cílem projektu, ale výrazně za časovým plánem. Rozhodneme se proto přidat dalšího člověka, který pomůţe s dokončením. Podle Brooksova zákona tento člověk nejen, ţe nepomůţe, ale díky jeho přidání se celková doba projektu ještě více protáhne. Navíc jsou náklady na začlenění nového člověka do týmu zpravidla větší neţ jeho přínos.
2.5.1. Brooksův zákon Brooksův zákon je pravidlo platící při vývoji software, které říká, ţe „přidáním pracovní síly do zpožděného projektu projekt ještě více zpozdí“31. Podle Brookse existují dva základní faktory vysvětlující popsané chování. Trvá určitý čas, než se nový člen týmu stane produktivním. Softwarové projekty jsou velmi komplexní a nový pracovník na projektu musí nejprve získat patřičné znalosti o projektu a práci, která byla vykonána před tím, neţ na projekt nastoupil. Školení nového pracovníka zatěţuje zdroje, které na projektu jiţ pracují, a dočasně sniţuje jejich produktivitu. Samotný nový pracovník produktivní také není. Kaţdý nový člen se musí také zařadit mezi stávající členy týmu a musí se seznámit s tím, co ostatní členové dělají a jaké je jejich zaměření. Ve spojení se sniţováním produktivity, nový pracovník můţe mít i další negativní vliv na projekt a jeho dokončení, můţe do projektu např. zavést nové chyby, které dokončení projektu jen oddálí.32 Komunikační režie roste společně s rostoucím množstvím lidí na projektu. Počet různých komunikačních kanálů narůstá kvadraticky s narůstajícím počtem lidí. Zdvojnásobení počtu lidí vede ke zčtyřnásobení počtu konverzací. Kaţdý, kdo pracuje na stejné aktivitě, si musí udrţovat aktuální informace, takţe čím více lidí je přidáno k řešení aktivity, tím více času stráví zjišťováním toho, co dělají ostatní.33 Jak bylo zmíněno, Brooksův zákon platí na jiţ zpoţděné projekty. Poznat zpoţděný projekt je velmi obtíţné, asi málokdo dokáţe odpovědět na otázku, zdali je projekt opravdu zpoţděn nebo byl pouze časově podhodnocen. Časově podhodnocený projekt není zpoţděn díky Brooksovu zákonu, ale právě díky podhodnocení celého projektu. Jistě existují cesty pro zmírnění dopadu Brooksova zákona, citujme alespoň některé z nich: „Gordon a Lamb studovali Brooksův zákon a navrhli nejlepší řešení, jak se zotavit z opožděného projektu. Přidat více členů než je nutno a přidat je včas.“34 (Hsia, Hsu, Kung, 1999) „Brooksův zákon předpokládá, že všechna pracovní síla je si rovna, což není pravda. Kdybych měl šanci přidat dobrého programátora, který zná kód a je kamarád s polovinou týmu, zvažoval bych to.“35 (Berkun, 2006) My se v pozdějších kapitolách této práce zaměříme na zmírnění Brooksova zákona pomocí podpory komunikace, kooperace a sdílení informací. Tím by mělo dojít k rychlejšímu začlenění nového pracovníka do týmu a zaškolení do projektové problematiky.
31
Zdroj: Wikipedia, the free encyklopedia. [online] – vlastní překlad autora tamtéţ. vlastní překlad autora 33 tamtéţ. vlastní překlad autora 34 vlastní překlad autora 35 vlastní překlad autora 32
18
2.5.2. Rozdělení povinností Jedním z úkolů projektového manaţera je přiřadit povinnosti a odpovědnosti k jednotlivým aktivitám a zvláště milníkům. Jakmile je sloţen projektový tým, je moţné zkonstruovat tzv. OBS36, která můţe být nápomocna při sestavování matice rozdělení povinností či odpovědností. OBS je často podobná funkční organizační struktuře, je důleţité si neplést organizační strukturu podniku a projektu. „Matice přidělení povinností (Responsibility Assignment Matrix, RAM) je přitom matice, která promítá práce na projektu, popsané ve struktuře rozpisu prací (WBS), k jednotlivým lidem, již jsou za práci odpovědní, a to podle platné organizační struktury (OBS)“37. Na níţe uvedeném obrázku je v levé části vidět OBS projektu, v střední části RAM a v pravé pouze textová reprezentace RAM: Obrázek 2.3. Organizační struktura projektu a matice rozdělení povinností
Zdroj: Institute. A Guide to Project Management Body of Knowledge. s. 220
Organizační struktura projektu je zřejmá, co se týká matice přidělování povinností, tak zde by v prvním řádku měly být názvy jednotlivých aktivit z WBS a v prvním sloupci jednotky z OBS. Způsob vyplnění matice záleţí na úrovni detailu, který chceme zachytit. Pro tyto účely vznikla celá řada různých diagramů, zmiňme pouze nejznámější variantu, kterou je RACI38: Responsible – odpovědná jednotka za vykonání činnosti, Accountable – odpovědná jednotka za korektní splnění činnosti (věcně odpovědná), Consulted – s kým je činnost konzultována, Informed – kdo je informován o postupu činnosti. Zjednodušenou variantou je vynechání dvou jednotek z modelu RACI tak, aby zbyly pouze osoby odpovědné a věcně odpovědné.
2.6. Komunikace v projektu „Komunikace je jedním z klíčových faktorů úspěchu projektu. Může být formální, emocionální, nicméně utváří obraz o projektu, pomáhá motivovat, zkrátka je to okno, pomocí kterého se všichni na projekt dívají“39. Studie společnosti Stadish Group z roku 2001 uvedla, ţe čtyřmi nejvýznamnějšími faktory souvisejícími s úspěchem projektu v informačních 36
Organizational Breakdown Structure, přeloţeno jako organizační struktura projektu. SCHWALBE, K. Řízení projektů v IT. s. 397 38 Zdroj: Wikipedia, the free encyklopedia. [online] – vlastní překlad autora 39 Kolektiv autorů. Projektové řízeni Příručka manažera. s. 119 37
19
technologiích jsou podpora firemního vedení, zapojení uţivatelů, zkušený projektový manaţer a jasně stanovené podnikové cíle40. Jak uvádí Schwalbe41, všechny tyto faktory jsou přímo závislé na dobrých komunikačních schopnostech projektového manaţera i týmu, zejména pak při komunikaci se zaměstnanci mimo obor informačních technologií. Je tedy evidentní, ţe dobrá komunikace je klíčovou záleţitostí při práci na projektu. Komunikovat efektivně musíme jak interně v rámci projektu, tak externě s různými zájmovými skupinami. Projektoví manaţeři by tedy neměli mít pouze technické vzdělání, ale hlavně také dobré komunikační schopnosti a sociální dovednosti. Některé studie prokázaly, ţe u projektových manaţerů v oboru IT jsou sociální dovednosti minimálně stejně důleţité, jako ty technické. Podle Schwalbe42 je v rámci komunikace důleţité zajistit včasné a náleţité generování, shromaţďování, distribuci, ukládání a likvidaci informací o projektu, přičemţ do komunikace spadají následující čtyři procesy: Plánování komunikace – jedná se o plán sdělující, kdo bude kdy a v jaké formě dostávat které informace; Distribuce informací – zajišťuje, ţe se všechny potřebné informace dostanou na patřičná místa a včas k jednotlivým účastníkům. Distribucí informací se budeme zabývat později v textu práce. Podpora distribuce informací je jedením ze stěţejních bodů pro vytvoření podpory projektového řízení; Oznámení efektivity – shromaţďuje a třídí informace o efektivitě na projektu; Řízení účastníků – zaměřuje se na očekávání účastníků projektu a řešení problémů. Projekt by měl také obsahovat vhodnou komunikační infrastrukturu, čímţ rozumíme vhodné nástroje, techniky a principy, které jsou základem pro efektivní přenos informací mezi lidmi. Mezi takové nástroje patří elektronická pošta, software pro řízení projektů, software pro práci skupinách (groupware) či systém pro řízení dokumentů a obsahu. Cílem této práce je také podpořit budování komunikační infrastruktury v projektu a tím usnadnit a urychlit komunikaci mezi členy týmu.
2.6.1. Komunikační kanály Jak uţ bylo zmíněno v subkapitole o Brooksově zákoně, důleţitou sloţkou z hlediska distribuce informací je počet osob zapojených do řešení projektu či problému. Jakmile narůstá počet pracovníků projektu, narůstá současně i počet komunikačních kanálů, čím se zvyšuje sloţitost a náročnost komunikace. Počet kanálů se dá v závislosti na počtu osob vyjádřit pomocí níţe uvedeného vzorce (písmeno n představuje počet osob zapojených do komunikace). Rovnice 2.1. Vzorec pro získání počtu komunikačních kanálů
40
Zdroj: Small Footprint LLC: Winston-Salem, NC Application Development Outsorcing [online] SCHWALBE, K. Řízení projektů v IT. s. 425 42 SCHWALBE, K. Řízení projektů v IT. s 426 41
20
Je snadné vypočítat, ţe mezi dvěma osobami bude pouze jeden kanál, mezi třemi lidmi tři kanály, mezi čtyřmi uţ to bude šest kanálů a mezi pěti osobami celkem deset komunikačních kanálů. Na níţe uvedeném obrázku jsou tyto kanály zobrazeny graficky. Obrázek 2.4. Počet kanálů v závislosti na počtu osob
Zdroj: autor
Proto by se projektový manaţer měl snaţit o tvorbu co moţná nejmenších pracovních týmů a skupin, aby nedocházelo k velkému nárůstu počtu komunikačních kanálu. Na uvedeném příkladě došlo u skupiny tří a pěti osob k navýšení počtu o celých sedm kanálů. Mimo jiné existují tzv. virtuální projekty, kde se jednotliví členové týmu osobně nikdy nesetkají ani se zadavatelem projektu, ani s jinými členy týmu či s ostatními účastníky projektu. Právě v takovémto prostředí je velmi důleţité efektivně komunikovat, podpořit týmovou komunikace, kooperaci a sdílení znalostí. Podobné situace nemusí nastávat pouze u virtuálních projektů, ale i na projektech, do kterých je zapojeno více dodavatelů, projektových manaţerů a účastníků z jiných firem a oblastí. I zde můţe docházet, a reálně také dochází, k problémům v komunikaci.
2.6.2. Produktivita Je zřejmé, ţe počet komunikačních kanálů má vliv na celkovou produktivitu členů projektového týmu. Velmi zajímavou informací by bylo zjistit, jak velký má být tým či pracovní skupina, aby míra komunikace byla „ideální“. Tato práce si neklade ambice odpovědět na tuto otázku, pokud na ni ovšem nějaká odpověď či vzorec vůbec existuje. Pravděpodobně by do vzorce vstupovaly veličiny jako velikost týmu, jejich zkušenosti, sehranost apod. Vzorec by pravděpodobně nikdy nepřinesl přesný výsledek, jelikoţ by sám o sobě závisel na veličinách, které se dají jen těţko měřit. Mimo vzorce je také moţné pouţít metriku, která na základě vstupů bude vracet nic neříkající bezrozměrné číslo. Jistě se ptáte, k čemu by tato metrika byla dobrá. Rozhodně by se výsledky metriky nedaly pouţít hned, nicméně po dokončení několika desítek či stovek projektů by bylo moţné statisticky říct, v jakých mezích se má výsledek metriky pohybovat, aby bylo v projektu dosaţeno ideální míry komunikace. Jednou z metrik, která by se dala pouţít, je tzv. párování neboli propojení modulů. Na obrázku zobrazeném výše můţeme vidět provázanost jednotlivých osob. Metrika párování je 21
primárně určena pro získání závislosti softwarových modulů na jiných komponentách. Pravděpodobně by bylo moţné pouţít ji i v případě propojení osob. Vzorec pro výpočet metriky je uveden v následujícím odstavci. Rovnice 2.2. Metrika propojení
Parametry a, b, c a k jsou nastaveny na základě aktuálních dat (závislé na zkušenostech). Ostatními parametry jsou: di, do – vstupní a výstupní datové toky, ci, co – vstupní a výstupní řídící toky, gd, gc – globální datově a řídící proměnné, w – počet volaných modulů, r – počet modulů, které volají modul Další moţností, jak měřit produktivitu, je přes klasické veličiny jako je počet řádků zdrojového kódu či velikosti úsilí. Tyto veličiny jsou uţívány např. v modelem COCOMO43, který je uţíván pro výpočet úsilí k vytvoření softwaru v závislosti na jeho velikosti. Mezi základní veličiny patři: LOC – Lines of Code – velikost programu, E – Effort - úsilí (doba v měsících), PP – Programmer's Productivity - produktivita programátora, GPP – Group Programmer's Productivity - produktivita skupiny programátorů. Pro jednotlivé výpočty se pouţívají následující vzorce. Všimněme si, ţe pro výpočet produktivity je zohledněno mnoţství komunikace, jeţ bylo odvozeno v subkapitole 2.6.1 (Komunikační kanály). Rovnice 3.5. Vzorce pro výpočet produktivity
43
COnstructive COst MOdel, více informací viz: Wikipedia, the free encyklopedia. [online]
22
2.7. Projektové dokumenty V této kapitole se zaměříme na to, které projektové dokumenty by měly v průběhu projektu vzniknout, zejména v jeho prvních fázích, tedy ve fázi koncepce a vývoje (v těchto fázích dochází k tvorbě největšího počtu dokumentů, v následujících fázích jsou dokumenty spíše doplňovány a zpřesňovány). Nebudeme popisovat dokumenty jako je rámcová smlouva, smlouva o dílo, NDA44 dokument, SOW45 dokument, předávací protokol atd., ty v podstatě nepatří k projektu jako takovému, spíše upravují právní závazky mezi zadavatelem a zhotovitelem projektu. V kaţdém případě je ale jejich přítomnost nutná. Vţdy bychom se měli snaţit začínat projekt s podepsanou smlouvou, v praxi tomu tak ale mnohdy nebývá. Vyřešit právní stránku věci a připravit smlouvy k podpisu je mnohdy velmi sloţité. Postava Dicka Utopiana z Shakespearovy hry Jindřich IV. vyřkla velmi známou větu, „The first thing we do, let's kill all the lawyers.“46. Výklad citátu je ponechán na čtenáři47. Důleţitými dokumenty při vytváření koncepce projektu jsou dle Svozilové48:
zakládací listina projektu předběžná definice předmětu projektu (v dalších fázích Definice předmětu projektu) a plán projektu.
2.7.1. Zakládací listina projektu Jedná se o dokument, který formalizuje existenci projektu, přiděluje manaţerovi projektu autoritu pro pouţití zdrojů na plnění poţadavků spojených s realizací projektu. Dokument formálně zahajuje práce na projektu z pohledu podnikového řízení a má následující strukturu49: název projektu, přehled výchozích podmínek, které mají vztah k budoucímu projektu, cíle projektu a účel, který má být jeho realizací naplněn, organizační vztahy a prvotní přidělení autorit vzhledem k projektu (sponzorovi, projektovému manaţerovi a liniovým manaţerům projektu), nastavení vztahu mezi manažerem projektu a funkčními manažery, základní rámec pro vymezení finančních nebo jiných zdrojů krytí, základní časový rámec, např. k jakému datu by měl být projekt ukončen a jeho výstupy budou k dispozici jeho uţivatelům, výčet základních omezení a předpokladů, jiná strategická kritéria, která je nutno při tvorbě projektu brát v úvahu, pokud taková existují, závěrečná ustanovení a explicitní prohlášení managementu o schválení tohoto dokumentu.
44
Non-disclosure agreement. Dohoda vymezující důvěrné informace. Více informací viz: Wikipedia, the free encyklopedia. [online] 45 Statement of Work. Dokument vymezující rozsah práce, výsledek práce (produkt ať uţ hmotný nebo nehmotný) a časový přehled. Více informací viz: Wikipedia, the free encyklopedia. [online] 46 vlastní překlad autora: Nejprve je třeba pobít všechny právníky. 47 Více informací viz např. : ANIMA Forbína. [online] 48 SVOZILOVÁ, A. Projektový management. s. 75 49 tamtéţ. s. 76
23
Tento dokument by měl být zhotoven ještě před tím, neţ se přistoupí k samotnému plánování projektu.
2.7.2. Předběžná definice předmětu projektu Dokument s předmětem projektu je jedním z nejdůleţitějších artefaktů, které provázejí projekt ve všech jeho fázích. Měl by jasně definovat všechny cíle, kterých má projekt dosáhnout. V počátečních fázích není moţné sestavit kompletní dokument, proto se mluví o předběţné definici, která je v průběhu projektu doplněna a zpřesněna. Jakmile obsahuje všechny body, předběţný dokument přechází do Definice předmětu projektu. Dle Svozilové: „Předběžná definice projektu je dokument, který srozumitelně a jednoznačně definuje všechny požadované cíle projektu, a to ve stavu aktuálního poznání vzhledem k vývojovému stupni projektu.“50 „Definice předmětu projektu je dokument, který konstatuje, jaká práce má být vykonána a jaké vstupy mají být vytvořeny.“51 Předběţnou definicí předmětu projektu se formálně zahajuje práce z pohledu předmětu projektu a standardně obsahuje52: popis problému, požadavek zákazníka nebo tržní příležitost, která je příčinou vzniku poţadavku, globální cíl projektu – obvykle jediný hlavní cíl projektu, který určuje celkový směr projektu a jeho konečný výsledek, účel, který má být realizaci naplněn, konkrétní cíle projektu – podrobnější členění globálního cíle do komponent, které přesněji popíší rozsah řešeného tématu, jasný a jednoznačný popis vlastností předmětu, sluţby nebo jiného druhu výstupu, a to na úrovni poznání v okamţiku sestavení dokumentu, kritéria dosažení úspěchu – kvantifikovaná kritéria, jejichţ dosaţením budou naplněny cíle projektu, předpoklady, rizika a omezení – seznam a popis potenciálních problémů a známých omezení, jimiţ můţe být projekt zatíţen. Jak uţ jsme zmínili, na začátku projektu nemáme dostatek informací pro vyplnění kompletní Definice předmětu projektu, z předběţné verze by ale mělo být zřejmé, co má být vytvořeno, kdy a za jakých podmínek má být projekt realizován. Dokument Definice předmětu projektu říká, CO má být vytvořeno. V následující kapitole bude popsán dokument, který naopak říká, JAK budou práce na projektu probíhat. Spojovacím článkem mezi těmito dvěma dokumenty je podrobný rozpis prací (WBS). Ten můţe být v podobě samostatného dokumentu či jen části jednoho z výše uvedených a jeho struktura odpovídá rozpisu dílčích cílů projektu. Jeho prostřednictvím se převedou projektové cíle do rozpisu úseků prací, časového rozvrhu prací (harmonogram) a plánu čerpání nákladů projektu (rozpočtu).
50
SVOZILOVÁ, A. Projektový management. s. 77 tamtéţ s. 116. 52 tamtéţ s. 77. 51
24
2.7.3. Plán projektu Plán projektu je opět dokumentem, který provází projekt ve všech jeho fázích. Velké diskuse se vedou o tom, jak moc podrobný by měl plán být. Jistě si kaţdý dokáţe představit plusy a minusy podrobného a zběţného plánu. Celé věci nahrává tzv. První zákon modifikace plánu, který říká „Plánovač je uvědomen o nezbytnosti modifikace plánu přesně ve chvíli, kdy je plán hotov.“53 Volně by zákon mohl být přeloţen tak, ţe kaţdý plán je chybný uţ ve chvíli jeho vytvoření. To ale neznamená, ţe bychom neměli plánovat, to samozřejmě ano, ale zřejmě bychom neměli zacházet do příliš velkých detailů, protoţe situace se vţdy vyvine poněkud jinak. Plán je potřeba v průběhu projektu soustavně aktualizovat. Dokument plánu by se měl skládat z následujících dílčích částí54: Plán řízení projektu – seznam hlavních milníků, harmonogram, plán pro řízení změn harmonogramu, Plán řízení předmětu projektu – podrobný rozpis prací s odhady jejich trvání, plán řízení změn předmětu projektu, Plán řízení nákladů – rozpočet projektu, plán řízení změn na dodatečné poţadavky zdrojů, Plán obsazení projektu – organizační struktura projektu, popis rolí a odpovědností, kalendář zapojení lidských zdrojů, Plán řízení projektové dokumentace – popis komunikačních kanálů a médií, základní pravidla komunikace a doby odezvy, Plán řízení subdodávek – rozhodnutí o způsobu pořízení části projektu, základní technické a obchodní poţadavky pro nákup, základní pravidla a metody komunikace, koordinace a kontroly subdodávek, Plán řízení rizik – registr rizik a plán omezení jejich vzniku, dohody a kontrakty pro sníţení rizik, Plán řízení kvality – ukazatele kvality a obecné plány pro zlepšení procesů Samozřejmě vše záleţí na velikosti a sloţitosti projektu, který chceme plánovat. V případě jednoduchého projektu by plán mohl obsahovat pouze harmonogram, rozpočet a základní pravidla v oblasti komunikace a řízení změn. Ve velkých projektech by tyto tři zmíněné části jistě nestačily k pokrytí všech potřebných postupů. V příloze C – „Plánování“ je zobrazena kompletní technická i organizační příprava Plánu projektu.
2.7.4. Uzavření projektu Kaţdý projekt by měl být zakončen formální akceptací ze strany zadavatele či zákazníka projektu. K tomuto účelu slouţí tzv. akceptační protokoly, kde je stvrzeno, ţe dílo bylo zhotoveno, odpovídá zadávací dokumentaci a neobsahuje chyby, které by bránily jeho pouţití. Konkrétní podoba protokolu je opět různá od projektu k projektu. Velmi uţitečnou informací v těchto protokolech bývá vyjádření zákazníka nejen k předanému dílu, ale také k celému průběhu projektu. Mnoho projektů po svém dokončení přechází do další fáze ţivotního cyklu, která je spojena s dodávkou dalších sluţeb a to zejména:
53 54
Murphyho zákon. Zdroj: Murphyho zákony. [online] SVOZILOVÁ, A. Projektový management. s. 177
25
údržba projektu, další rozvoj a adaptace na měnící se okolní podmínky projektu. Předtím neţ je ale projekt úplně uzavřen, mělo by dojít k zdokumentování know-how, které bylo na projektu získáno a to zejména oblasti závěrečných a hodnotících interních dokumentů (hodnocení naplnění cílů, porovnání plánovaných a skutečných hodnot, naplnění plánu kvality, lessons learned55 atd.), hodnocení jednotlivých členů týmu a administrativnímu uzavření projektu (ověření a dokumentace výstupů projektu, uzavření interní administrativy, jako je např. účetní vypořádání a dále administrativní uspořádání a archivace závěrečné dokumentace).
55
Výraz nemá český ekvivalent. Zahrnuje znalosti, které byly získány v průběhu projektu a měly by být součástí historických dat organizace.
26
3. PŘÍPADOVÁ STUDIE Praktická část této práce se zabývá konkrétním projektem, na který se budeme snaţit uplatnit teoretické základy popsané v předchozích kapitolách a pro který bude v následující kapitole navrţeno řešení pro podporu projektového řízení, komunikace a sdílení informací a znalostí. Budeme se zabývat projektem GS Soil, na kterém se, mimo dalších 34 členů z různých států Evropy, podílí i Masarykova univerzita, konkrétně Fakulta informatiky. Masarykova univerzita je druhým zástupcem z České republiky, ostatní účastníci jsou ze zemí, jako je Německo, Rakousko, Velká Británie, Belgie, Finsko, Slovensko, atd. Celkový počet zemí, které se projektu účastní, je 17, viz následující obrázek (šedě a tmavě šedě zvýrazněné státy). Obrázek 4.1. Zapojené země do projektu GS Soil
Zdroj: projektová dokumentace viz níže
Fáze, ve které se projekt nachází, by se dala povaţovat za fázi koncepční. Zatím je znám pouze předběţný rozsah projektu, motivace k projektu, seznam partnerů, předběţný plán projektu a projektové výstupy. Začátek projektu je datován na počátek letošního roku, tedy na shodné datum, kdy byla započata tvorba textu této bakalářské práce. V následujícím textu vycházíme ze stavu projektové dokumentace56 k 1. 3. 2009, jakoţto data její poslední aktualizace. Je velmi pravděpodobné, ţe od té doby došlo k jistému posunu či změnám.
56
Kolektiv autorů. GS Soil, Assessment and strategic development of INSPIRE compliant Geodata-Services for European Soil Data
27
Vývojová fáze projektu by měla být odstartována na začátku července, tedy aţ po termínu odevzdání této práce. Ta by ve své praktické části měla připravit projektové prostředí pro sdílení informací mezi týmy z různých členských zemí, podporu komunikace, evidenci členů, zodpovědností, milníků, ale také podporu diskusí či projektového řízení.
3.1. GS Soil Projekt by bylo moţné zařadit mezi projekty, které se zabývají ekologií a ţivotním prostředím. Hlavní motivace pro jeho spuštění byla nedostatečná dostupnost dat o půdě napříč státy Evropské unie. V rámci EU existuje velké mnoţství těchto dat, ale ty nejsou bohuţel v mnoha případech obecně dostupné, je obtíţné je získat, porozumět jim a dále s nimi pracovat. V posledních letech se dostupnost těchto dat stala jednou z klíčových zájmů fyzických i právnických osob napříč celou EU, jelikoţ informace o půdě, jakoţto stěţejním subjektu ţivotního prostředí, jsou velmi důleţité v územním plánování, ochraně prostředí a v analýze různých rizik a dopadů. Zároveň je půda základem pro pěstování potravin pro výţivu člověka (stejně jako krmiva), a proto je její ochrana důleţitá nejen lidské zdraví. Z toho důvodu vznikl projekt GS Soil, který si klade za cíl vylepšit stávající neuspokojivý stav. Základními kroky by mělo být sjednocení a organizace dat o půdě, jak na jejich sémantické, tak technické bázi, a to napříč členskými státy, a dále pak vybudovat portál (Soil Portal), který umoţní data získávat, hledat, transformovat a stahovat. Mezi jednotlivé cíle patří zejména: sjednocení katalogů a rámcových standardů ohledně informací o půdě, poskytnutí profilů databází, dat a služeb, a to v kompatibilitě s direktivou INSPIRE57, vytvoření obecného schématu týkajícího se informací o půdě, vyvinutí webového portálu, který poskytne již zmíněné vlastnosti, vytvoření zásad a návodů pro vytváření a správu metadat o půdní databázi datové harmonizaci. Cílovými skupinami projektu jsou: veřejnost, zejména občané, studenti a zájmové skupiny, administrativy pro životní prostředí, výzkumné a vědecké ústavy, Evropská komise, parlament a jiné instituce, soukromý sektor, a další. Jak uţ bylo zmíněno, projektu se účastní celkem 17 členských zemí Evropské unie a rozsah projektu je odhadován přes 20000 „člověko-dní“. Jedná se tedy o velmi rozsáhlý projekt, do kterého je zahrnuto velké mnoţství účastníků. Je více neţ logické, ţe pro takovéto projekty je ţivotně nezbytná existence podpory pro projektové řízení, a to zejména pro sdílení informací, znalostí a pro podporu spolupráce a koordinace.
3.2. Plán projektu Projekt je zatím v přípravné fázi, nejsou proto známy všechny podklady, které by slouţily pro sestavení detailního plánu. V současné době je znám pouze předběţný plán, který je rozdělen do celkem sedmi jednotek. Jednotlivé jednotky jsou navzájem závislé, ale jejich závislost na úrovni plánování není zatím definována. Na níţe uvedeném obrázku je zobrazen plán 57
Více informací viz např.: INSPIRE [online].
28
vytvořený v programu Microsoft Project a zobrazuje základní sadu sedmi jednotek a detailněji zachycuje druhou jednotku, která obsahuje celkem čtyři milníky. Obrázek 4.2. Projektový plán se zaměřením na milníky
Zdroj: projektová dokumentace
Zároveň je u kaţdé jednotky zobrazena zodpovědná organizace. V praktickém řešení bude zodpovědnost mapována na konkrétní osobu v rámci organizace, ta bude většinou v roli projektového manaţera. Seznam účastníků na úrovni fyzických osob není součástí projektové dokumentace. Pravděpodobně to ani není nutné, co ale chybí a je nedostatkem, je nepřítomnost zodpovědných osob organizace. V plánu jsme se zaměřili na druhou jednotku, jejímţ cílem je zejména identifikovat současné a budoucí poţadavky pro popis půdních dat, sestavit katalogy a pomocné příručky obsahující různé zásady a postupy. Mezi důleţitý atribut patří závislost na výstupech a spolupráci s třetí, čtvrtou a šestou jednotkou. Tyto jednotky by tedy měly své činnosti patřičně koordinovat.
3.3. Organizace projektu Celková struktura projektu se skládá z následujících částí: projektový koordinátor (Project Coordinator), operativní řídící skupina (Operational Management Group), týmy jednotlivých funkčních jednotek (Work Package Team) a poradní výbor (Advisory Board). Mimo jiné je do projektu zahrnuta skupina pro zajištění kvality (Quality Management), týmy z jiných přidruţených projektů (Related Projects) a na nejvyšší úrovni projektová kancelář (eContentPlus Project Office). Celá struktura je znázorněna na obrázku níţe. Obrázek 4.3. Projektová organizační struktura
Zdroj: projektová dokumentace
29
Projektový koordinátor (ve smyslu jednotky) je na projektu zodpovědný za celkovou koordinaci a alokaci zdrojů pro různé úkoly. Tato role je zastávána koordinačním centrem PortalU Ministerstva ţivotního prostředí a ochrany klimatu Dolního Saska v Německu, kde je pro účely řízení koordinačního centra zajištěn projektový manaţer. Mezi další jeho zodpovědnosti patří zejména: jednání jako styčná osoba s Evropskou komisí, plánování a zajišťování kontaktů s organizacemi, plánování a předsedání různých jednání, zajišťování seminářů, vykonávání řídících činností, sestavování půlročních reportů, atp. Pro podporu projektového koordinátora a pro zajištění patřičné kvality je pro projekt vyčleněna jednotka pro řízení kvality, která má za úkol kontrolovat průběh prací a porovnávat výsledky s projektovými cíli. Operativní řídící skupina se skládá z projektového koordinátora a vedoucích jednotlivých pracovních jednotek (Work Package). Tato skupina slouţí jako centrální rozhodovací jednotka, kde rozhodnutí jsou schvalována pomocí většinového principu, a zároveň jako mezičlánek mezi pracovními jednotkami a projektovým koordinátorem. Pro zajištění odbornosti různých zájmových skupin, je na jednání a schůzky zván i poradní výbor skládající se z klíčových „hráčů“ v dané oblasti. Jednotlivé pracovní jednotky slouţí k vykonávání jejich úkolů, definovaných v projektovém plánu, a komunikují s ostatními jednotkami pro zajištění sdílení informací. Jistá provázanost úkolů, napříč pracovními skupinami, byla identifikována jiţ při předběţném plánování. Pro kaţdou pracovní jednotku je zvolen její vedoucí, jehoţ zodpovědností je: definování vhodné metodiky pro vykonávané úkoly, plánování, příprava a koordinace práce uvnitř jednotky, zajištění, že všechny úkoly budou dosaženy včas a v požadované kvalitě, udržování kontaktu s projektovým koordinátorem, zajištění spolupráce s dalšími stranami, reportování a poskytování výstupů projektovému manažerovi, uchovávání a poskytování finančních reportů projektovému koordinátorovi. Aktuální poţadavky a informace pro pracovní jednotky zajišťuje poradní výbor, jehoţ úkolem je také mimo jiné i zajištění kontinuálního zapojení evropských a národních institucí.
3.4. Podpora v projektu Jak velký počet zúčastněných zemí, tak popsaná organizační struktura projektu naznačují, ţe se jedná o velký projekt nejen z hlediska rozsahu, ale i náročnosti na komunikaci a koordinaci. Mít pod kontrolou všech 35 organizací bude pro organizační centrum jistě náročný úkol. Z popisu projektové organizační struktury je zřejmé, ţe při jejím návrhu byla brána v potaz jak velikost projektu, tak nároky na komunikaci mezi zúčastněnými stranami. Zjednodušeně by se dalo říci, ţe organizační struktura byla zvolena tak, aby i sama o sobě zajistila minimální mnoţství komunikace mezi samotnými organizačními jednotkami. Z tohoto důvodu jsou i všechny úkoly rozděleny do několika oddělených pracovních jednotek.
30
Komunikační toky mezi zmíněnými jednotkami budou vést přes vedoucí pracovních jednotek, tudíţ bude i niţší faktor párování popsaný v kapitole o efektivní komunikaci. Projektový manaţer komunikuje zejména s operativní řídící skupinou, která se skládá právě z vedoucích pracovních jednotek. Tím je téţ zajištěno efektivní řízení. Komunikaci s šesti vedoucími (nepočítáme ostatní zúčastněné strany, jako je poradní výbor, skupina pro zajištění kvality či projektová kancelář), by měl zvládnout kaţdý zkušený projektový manaţer. Bohuţel na úrovni současné dokumentace nejsme schopni detailněji popsat organizaci pracovních jednotek, zde budou kladeny pravděpodobně největší nároky na komunikaci a koordinaci, a to z důvodu, ţe právě do těchto jednotek budou začleněny týmy z členských zemí. Je dost dobře moţné, ţe právě vedoucí pracovní skupiny bude mít daleko více komunikačních kanálů neţ samotný projektový manaţer. Praktická část by se tedy měla spíše ubírat směrem pro podporu komunikace a sdílení právě na úrovni pracovních jednotek a mezi nimi. Samozřejmě sdílení na vyšší úrovni je také velmi významné a bude v řešení zohledněno se stejnou důleţitostí. Z časového hlediska je projekt zasazen do harmonogramu tří let a je i velmi pravděpodobné, ţe v rámci této doby dojde k organizačním změnám, jak na úrovni řídících pozic, tak zejména na úrovni jednotlivých pracovních týmů a jejich vedoucích. Za dobu tří let bude mnoţství shromáţděných informací tak veliké, ţe např. začlenění dalšího pracovníka v pokročilé fázi projektu můţe znamenat i několika týdenní studium aktuálního stavu projektu, a to samozřejmě pouze za předpokladu, ţe bude projekt dobře dokumentován. Jak bylo popsáno v kapitole o Brooksových zákonech, je velmi důleţité, aby nově začleněný pracovník neubíral efektivní čas ostatním členům týmu, to by totiţ mohlo způsobit různá zpoţdění. Z charakteru projektu je také zřejmé, ţe se jen málokdy stane, ţe bude více členů celého týmu v jedné místnosti. To vyplývá z mezinárodní povahy projektu, která klade na efektivní komunikaci ještě další nároky. Mimo konferenčních hovorů je nutná dokumentovaná komunikace, zejména kvůli sdílení znalostí, na úrovni diskusních fór, blogů či jiných médií podporující týmovou práci. Tyto média budou popsána v následující kapitole. Jak bylo zmíněno na začátku kapitoly, tato práce by měla být dokončena dříve, neţ začne výkonná část projektu GS Soil. Je to tedy ideální načasování pro vytvoření podpory pro budoucí projektovou práci na všech úrovních, od řízení po vykonávání. Výstupem by tedy měla být IT infrastruktura, která bude provázet projekt po celý jeho další ţivotní cyklus a bude umoţňovat efektivní projektové řízení se zaměřením právě na komunikaci, koordinaci, sdílení informací, plánování, stanovení milníků či zodpovědností.
31
4. NÁVRH IT PODPORY Problémová doména byla nastíněna v předchozí kapitole, tato kapitola by měla přinést řešení pro zmíněný projekt a připravit infrastrukturu pro projekty příští. V jednotlivých kapitolách byly uvedeny texty o tom, jak je důleţité efektivně komunikovat, sdílet informace a být ve své práci efektivní. Cílem kapitoly je přinést IT podporu projektovému řízení, stanovení milníků, řízení zodpovědností, sdílení projektových artefaktů a odlehčení stresující práce projektových manaţerů a jejich oproštění od rutinních záleţitostí jako periodická kontrola plnění úkolů, dotazování spolupracovníků na aktuální stav atp. Řešení, které tato práce přináší, je zaštítit vše pod jedno „pracovní místo“. Přinést projektovému manaţerovi moţnost mít všechny projekty na jednom místě, vědět, kdo v projektech figuruje, jaké jsou týmy, jaké jsou tam milníky, o čem se v projektu komunikuje, získat veškeré moţné informace o projektu, aniţ by někam volal či někoho se dotazoval. Řešením je přinést prostředí, které usnadní projektové řízení, společně s podporou komunikace a sdílení, a zavede do něj podporu dnešní IT. Rozhlédneme-li se ve světě softwaru po jiţ existujícím řešení, pravděpodobně „spláčeme nad výdělkem“. Netroufám si tvrdit, ţe ţádné takové řešení neexistuje, to jistě ano, ale pravděpodobně bude hodně drahé. Řešení, která by vše zaštiťovala, je pouze malá hrstka, zmiňme např. Microsoft Project Server. V tomto softwaru bychom opravdu asi nalezli vše, co se pokouší řešit tato práce. Bohuţel tomu odpovídá i cena zmíněného softwaru, která se pohybuje v desetitisících za licenci na uţivatele. Takováto cena můţe, a reálně i je, pro některé společnosti, zvláště SMB58, příliš vysoká. Proto mají tyto firmy implementovány zčásti své systémy a zčásti např. systémy uvolněné pod Open Source licencí59, kde nasazení takového softwaru nic nestojí. Samozřejmě tím společnosti ztrácejí jakoukoli záruku za software a mnohdy i produktovou podporu. I kdyţ uţ i zde najdeme výjimky, protoţe i ve světě open source je dnes mnoho řešení, která komerční podporu poskytují, a to v podstatě ve stejném rozsahu jako řešení komerční. Zmiňme např. CMS60 systém Alfresco, který se v mnoha firmách pouţívá pro správu firemních dokumentů. Bohuţel ani nastíněná moţnost pouţití jiných produktů není řešením, problém v takových případech je integrace samotných produktů. Jestliţe nemáte svoje softwarové oddělení, tak na integraci můţete v podstatě zapomenout, a i kdyţ ho máte, raději byste měli oddělení „investovat“ do zákaznických projektů neţ do interních. To samozřejmě předpokládá, ţe nemáte ţádné interní rezervy. Pro vybudování projektového prostředí, které by vyřešilo naše problémy, potřebujeme zhruba následující funkcionality (nemluvíme teď o evidenci projektů či pracovníků na nich, ale o funkcionalitách, které jsou důleţité, kdyţ uţ na projektu pracujete. Jedná se právě o podporu zmiňované komunikace a sdílení dat): prostředí s přehledem projektů a informací o nich, redakční systém pro úpravu projektových informací, CMS systém pro ukládání textů, DMS systém pro ukládání projektových artefaktů či obrázků, podporu elektronické pošty (E-mail), kalendář, oznámení, projektovou Wiki61 atd. Všechny tyto „aplikace“ jsou v projektovém prostředí nutností. Jak jinak by bylo moţné sdílet informace a spolupracovat s ostatními? Kdyţ k tomu přidáme, ţe všechny aplikace jsou na jednom místě, tak dostaneme ideální prostředí pro spolupráci, neboli Groupware. 58
Small and Middle Busienesses. Překlad autora: Malé a střední podniky. Programy s otevřeným zdrojovým kódem. Více informací viz: Wikipedia, the free encyklopedia. [online] 60 Content Management System. Systém pro správu obsahu (texty, dokumenty apod.) 61 Sada webových stránek, kde mohou uţivatelé libovolně přispívat, více informací viz: Wikipedia, the free encyklopedia. [online] 59
32
„Groupware je software umožňující lidem realizovat potřebné interakce a slouží jako základna pro následnou analýzu a archivaci. Umožňuje skupinám lidí zachytit a sdílet informace tak, aby byla práce snadná, rychlá a intuitivní.“62Jak uţ bylo zmíněno, řešení musí umoţňovat správu uţivatelů, skupin, projektů, přiřazovat uţivatele do skupin apod. Jako vhodná volba se zdá být portálová technologie, která v současné době zaţívá obrovský „boom“.
4.1. Portál Portál je technologie, která umoţňuje přístup k mnoha aplikacím, nástrojům a informacím z jediného místa. Jako příklad můţeme uvést portál veřejné správy63. Portály jsou v poslední době velmi oblíbenou platformou pro vývoj jak internetových, tak firemních aplikací, poskytují totiţ výhodu, která je při vývoji mimo portál těţko dostupnou. Velmi velké mnoţství funkcionality je uţ totiţ dodáváno přímo výrobcem portálu, mluvíme právě o přihlašování uţivatelů, správě uţivatelských účtů, webových stránek, aplikací atd. Jediné, co je nutné většinou upravit na míru konkrétnímu projektu, jsou tzv. portlety. Portlet je aplikace, kterou lze do portálu nainstalovat a tím rozšířit jeho vlastnosti či funkcionality. Velmi dobrým příkladem je např. portlet pro nákupní košík. Ten se vyskytuje v kaţdém elektronickém obchodě, ale oproti portletovému nákupnímu košíku má jednu podstatnou nevýhodu, a to ţe nebyl vytvořen oproti standardu. Absolutní většina elektronických obchodů pouţívá svou proprietární verzi, které jsou mezi sebou nekompatibilní. Nemůţeme vzít nákupní košík z jednoho obchodu a dát ho do druhého. Toto je za určitých podmínek v portálu moţné a také se tak reálně děje. Např. portlet s předpovědí počasí je druhou dobrou ukázkou znovupouţitelného kódu. Na jednotlivé portlety se dá nahlíţet jako na stavební kameny, jejich vhodným poskládáním se dá vytvořit potřebná funkcionalita. Jestliţe na jednu stránku umístíme seznam zboţí a nákupní košík, vznikne nám jednoduchý elektronický obchod. Máme-li např. restauraci, tak na první stránce portálu budeme vţdy kaţdý týden měnit portlet s obsahem poledního menu. Příkladů bychom našli nesmírné mnoţství. V současné době existuje několik hlavních „výrobců“ portálu. Mezi největší patří společnost IBM, Oracle a Microsoft. Nicméně ani svět open source softwaru na tom není nejhůře, mezi největší „hráče“ zde patří portál Liferay a JBoss.
4.2. Liferay Jak kapitola sama napovídá, vybrali jsme si Liferay jako implementaci portálu. Důvod je jednoduchý, jedná se o nejrozšířenější open source portál pouţívající nejnovější technologie jako je Java a Web 2.0. Svou funkcionalitou (sadou portletů) nabízí perfektní místo pro sdílení a kooperaci. Mezi základní funkcionality patří zejména. Wiki – nástroj pro vytváření webových stránek. Výhodou je velmi snadná editace, jednoduchá syntaxe zápisu a umoţňuje kaţdému oprávněnému přispívat. Jeví se jako dobrý nástroj pro psaní projektových informací, jako je stránka o projektovém týmu, vývojovém prostředí, přístupových údajích, znalostní bázi atd. Vyuţití bychom našli
62 63
Wikipedie, otevřená encyklopedie. [online] Portál veřejné správy České Republiky. [online]
33
opravdu mnoho. V praxi mnoho týmů pracujících na projektu instaluje Wiki jako nástroj pro sdílení znalostí. Blogy – slovo vzniklo spojením slov web a log, neboli webový zápisník. Tato forma komunikace je v dnešní době velmi populární. RSS – technologie, která umoţňuje publikaci novinek. Jednotliví uţivatelé mají moţnost se k odběrům přihlásit a tak být vţdy informováni o tom, co se děje. RSS můţe být generováno jak z Wiki stránek, blogů, tak diskusních vláken, článku, kalendářů atd. V podstatě vše, kde uţivatel můţe vyvinout aktivitu, můţe být vloţeno do RSS. Tato technologie zajistí, aby měl tým vţdy aktuální znalosti. Instant Messaging – hovorovým výrazem „chatování“. Umoţňuje uţivatelům v reálném čase vést diskuse. Velmi vhodná technologie např. pro pokládání upřesňujících dotazů či neformální komunikaci. Kalendář – funkcionalita tohoto nástroje je pravděpodobně zřejmá. Připomeňme, ţe kaţdý projekt můţe mít svůj vlastní kalendář, ale můţe obsahovat i sdílený. Např. organizace vede několik projektů a pro kaţdý existuje zvláštní kalendář, existuje ale i kalendář organizace, kde se řeší události na vyšší úrovni jako oslava narozenin generálního ředitele, výjezdní zasedání či jiné důleţité akce. WebMail – E-mail je asi jednou z nejrozšířenějších forem komunikace, která se pouţívá na všechny druhy zpráv, jak formální, tak neformální. Samozřejmě ne vţdy je E-mail tím vhodným komunikačním médiem a neměl by se pouţívat pro posílání takových druhů zpráv jako je osobní hodnocení, řešení negativního chování, přenos referenčního dokumentu atd. Spíše by měl být pouţíván pro posílání jednoduchých informací či poţadavků. CMS – neboli Content Management System umoţňuje snadnou editaci článků, jejich vytváření a publikování. Zároveň nabízí jednoduché schvalovací workflow64. Můţeme tak např. definovat editora a publicistu. Editor má oprávnění psát a modifikovat články, ale ty se nestanou veřejnými, dokud je publicista neschválí. DMS – nebo také Document Management System umoţňuje snadnou správu dokumentů. Tuto funkcionalitu si můţeme představit jako jednoduchou knihovnu, umoţňuje vkládání a čtení dokumentů různých formátů. Opět lze definovat knihovnu na několika úrovních, a to projektovou, organizační atd. Vyhledávání – podstatná a důleţitá funkce, která prohledává ve všech výše zmíněných nástrojích. Usnadňuje tak získávání informací. Upozornění a oznámení, ankety, formuláře atd. Jestliţe dojde ke spojení všech výše uvedených nástrojů a funkcionalit, vznikne nám velmi mocné pracovní prostředí, které umoţňuje právě posílení efektivity komunikace, sdílení znalostí a podpory spolupráce. Mimo jiné Liferay umoţňuje integraci s produktem OpenOffice, který se stal vhodným zástupcem produktu Office od společnosti Microsoft. Pomocí této integrace lze exportovat velké mnoţství obsahů do dokumentů typu Word, RTF, PDF a dalších. Jestliţe tedy máme v portálu uloţenu projektovou dokumentaci jako sadu článků, můţeme je jednoduše exportovat a poslat zákazníkovi na podpis. Společnosti, které jiţ pouţívají některé technologie společnosti Microsoft, tak uvítají propojení portálu s produktem SharePoint.
64
Workflow je schéma provádění nějaké komplexnější činnosti. Wikipedie, otevřená encyklopedie. [online]
34
4.2.1. Organizace portálu Na začátku této práce jsme popsali různé druhy organizačních struktur a zastavili se i nad organizací týmu. Velmi důleţité v informačních technologiích a nástrojích je najít to správné mapování mezi organizační strukturou, kterou pouţíváme a členěním uţivatelů v patřičném nástroji. Portál Liferay k tomuto účelu poskytuje členění, které zaručeně postačí pro nejrůznější druhy struktur. V ostatních případech je moţné členění upravit na úrovni zdrojového kódu, neboť se jedná o open source. Mezi základní členění patří: Organizace - slouţí k hierarchickému členění uţivatelů. Velmi snadný příklad organizačního členění je student. Ten je členem „organizace“ Ekonomicko-správní fakulta, ale také Masarykova Univerzita. Organizace můţe být také členěna na lokace, kdy např. společnost IBM má své kanceláře v České republice, Německu, Británií, USA atd. Komunita - umoţňuje členění uţivatelů podle jejich zájmu či zaměření. V našem případě bude komunita vhodným nástrojem proto, abychom do ní zařazovali členy jednotlivých týmů. Pro kaţdý projekt tak vznikne zvláštní komunita, která bude obsahovat všechny osoby, které se na projektu podílí. Uživatelská skupina - vytváří podobné členění jako komunita s tím rozdílem, ţe skupiny uţivatelů nemají své stránky (nemohou proto mít např. svou projektovou stránku) a nemohou být členy organizace. Uživatel - představuje samotného uţivatele portálu, který můţe patřit do všech výše zmíněných jednotek. Role - všechny výše zmíněné jednotky mohou nabývat různých rolí, mezi základní patří Uţivatel či Administrátor. Pomocí rolí lze v portálu definovat oprávnění. Můţeme tedy definovat, ţe skupina Diskuse bude mít oprávnění spravovat všechny diskuse v portálu, tedy mazat příspěvky, vytvářet vlákna, zamezovat uţivatelům v přístupu apod. Uţivatelská práva se dají v portálu přidělit v podstatě na jakoukoli funkcionalitu a jsou tak mocným nástrojem, jak řídit oprávnění. Mezi základní oprávnění patří čtení a modifikace. Kaţdá funkcionalita můţe ale obsahovat další oprávnění, jako je vytvářet sloţky, mazat diskusní vlákna apod. K snazšímu pochopení organizačních jednotek jsou v příloze D – „Liferay“ na obrázku D.1 – „Organizace, komunity, skupiny, role, uživatelé“ zobrazeny všechny zmíněné jednotky a způsob jejich propojení. Šipky můţeme číst jako „můţe být členem“. Zároveň na obrázku D.2 – „Organizační členění v portálu“ je znázorněno, jak je moţné jednotky hierarchicky členit. Protoţe celá problematika uţivatelských práv a organizačních jednotek je poměrně sloţitá a v této práci není prostor pro detailní popis, odkazujeme čtenáře proto na patřičnou literaturu65.
4.2.2. Portálové stránky Portálové stránky by se daly přirovnat k pracovním plochám, na něţ jsou vzápětí umisťovány jednotlivé portlety, na které lze nahlíţet jako na „kukátka“ do portálu. Stejně jako organizační jednotky i portálové stránky lze hierarchicky členit a vytvářet tak poměrně sloţitou mapu stránek. Liferay nabízí několik druhů portálových stánek. Jedná se o stránky komunitní, organizační a soukromé. Výchozí stránkou portálu je stránka v komunitě Guest, kam patří všichni uţivatelé, 65
SEZOV R. Liferay Administrator's Guide, 2nd Edition (viz Seznam pouţité literatury)
35
kteří stránky navštěvují. Tito uţivatelé ani nemusí být přihlášení, prakticky to můţe být kdokoli z Internetu. Mimo zmíněných druhů stránek existují stánky veřejné a privátní, např. kaţdý uţivatel, který má patřičná oprávnění (je-li mu přidělena komunita My Community), můţe mít jak své veřejné stránky, kam mohou nahlíţet všichni uţivatelé, tak soukromé, kam můţe přicházet pouze on. Na veřejných stránkách bude mít umístěn např. svůj blog, kdeţto na soukromých portlet pro přístup k svému E-mailovému účtu. Veřejné a soukromé stránky mají mimo jiné i komunity (mimo zmíněné komunity Guest) a organizace. Na obrázku D.3 – „Portálové stránky“ můţete vidět členění jednotlivých stránek. Jak uţ jsme si řekli, pro kaţdý projekt bude existovat komunita, to také znamená, ţe kaţdý projekt bude mít své veřejné a soukromé stránky. Na veřejných stránkách bude uvádět informace, které jsou obecné a nejsou utajené a na svých privátních stránkách seznamy milníků, diskusní fóra, knihovnu dokumentů atd. Toto je ale pouze jeden moţný scénář. Druhou moţností je vytvořit tzv. privátní komunitu, takţe ke všem stránkám bude mít přístup pouze člen dané komunity a nikdo jiný. Na portálové stránky lze také uplatňovat uţivatelská práva, tím je moţné dát uţivateli oprávnění pouze ke vstupu případně i k modifikaci. Dále je moţné aplikovat tzv. témata, která zajistí, ţe projekt má patřičný vzhled, např. investiční projekt můţe mít jiný vzhled neţ projekt komerční či interní. Totéţ pravidlo platí i pro různé komunity či organizace. Komunitní stránky Ekonomicko-správní fakulty by mohly vypadat přesně tak, jak na svých webových stránkách.
4.3. Implementace Jestliţe jsme popsali základní principy rozřazování uţivatelů do jednotek, přiřazování práv a princip portálových stránek, můţeme se podívat, jakým způsobem by mohlo být naimplementováno projektové prostředí. Připomeňme, ţe administrace portálu je vcelku sloţitou záleţitostí a vyţaduje určité znalosti a zkušenosti. Výše popsaná funkcionalita byla spíše nastíněna, neţ popsána. Portál nabízí daleko větší moţnosti, nicméně jejich detailní popis je nad rámec této práce a mnoho jeho vlastností bychom ani pro vytvoření projektového prostředí nepotřebovali. Důleţitým funkčním bodem bude pro nás tzv. kontrolní panel, kde můţe administrátor portálu vytvářet komunity, organizace, uţivatele, diskusní vlákna apod. V podstatě absolutní většinu toho, co administrátor potřebuje, lze vytvořit či vykonat v kontrolním panelu. Pro vytvoření projektového prostředí budeme tedy potřebovat administrátorská práva. V kaţdé společnosti by měl být člověk, který se stará o technické zajištění IT, stejného člověka bychom měli pouţít jako administrátora portálu. Tito lidé mají ve většině případů podepsaný dokument o mlčenlivosti, takţe jeho přístup k veškerému obsahu není na závadu. Jakmile administrátor vytvoří základ projektového prostředí, můţe pak některé operace delegovat, např. projektovému manaţerovi případně někomu, koho projektový manaţer či projektová kancelář navrhnou. Pro tyto důvody se bude jistě hodit vcelku flexibilní model uţivatelských práv. Ještě neţ přejdeme k samotnému vytváření projektové infrastruktury v portálu, je důleţité zmínit, ţe je nutné vytvořit struktury, které přesahují jednotlivé projekty. Jedná se zejména o management společnosti a projektovou kancelář. Pro náš případ pouţijeme pouze projektovou 36
kancelář, zřídíme roli OPM (Overall Project Management) a přiřadíme do ní RNDr. Jaroslava Ráčka, Ph.D., který je současně vedoucím této bakalářské práce. Tuto roli budeme pak přiřazovat ke kaţdé projektové komunitě, tak bude mít manaţer projektové kanceláře přístup ke všem projektům. Samozřejmě je moţné postupem času přidávat další a další členy OPM, kteří pomocí jednoduchého úkonu budou mít přehled o všech projektech a aktivitách na nich.
4.3.1. Organizace V úvodní kapitole jsme si stanovili, ţe praktická část této práce bude zaměřena na Fakultu informatiky Masarykovy univerzity, vytvoříme proto patřičnou organizaci i v portálu. Administrátorem této organizace stanovíme pro jednoduchost opět RNDr. Jaroslava Ráčka, Ph.D. Jelikoţ fakulta informatiky realizuje velké mnoţství projektů s různými společnostmi a partnery, je vhodné na stránky organizace umístit knihovnu, která bude obsahovat např. šablony některých projektových dokumentů, jako je zadávací dokumentace, status report, kostra WBS atd. Tím všechny projekty budou moci tyto dokumenty referencovat a pouţívat. Pro všeobecné dokumenty bude tedy jediné místo, a to knihovna organizace, ale pro konkrétní, dokumenty projektů bude jiţ projektová knihovna, která nebude sdílena nikým jiným, neţ členy týmu. Stejně tak je moţné vytvořit všech 35 organizací popsaných v předchozí kapitole týkající se projektu GS Soil.
4.3.2. Komunita a role Pro projekt popsaný v kapitole 4 (Případová studie) vytvoříme zvláštní komunitu, čímţ budou automaticky vytvořeny portálové stránky projektu. Do komunity přiřadíme uţivatele jednotlivých organizačních jednotek. V našem případě budeme muset pracovat s fiktivními osobami, jelikoţ projektová dokumentace v současném stavu neobsahuje ani hrubý seznam členů týmů či odpovědných osob k jednotlivým organizačním jednotkám. Projektovému manaţerovi je nutné přiřadit administrační práva na danou komunitu. Tím dosáhneme toho, ţe veškeré nutné úkony spojené s projektem bude uţ moci vykonávat projektový manaţer a ne administrátor portálu. Nyní podle projektové organizační struktury vytvoříme patřičné uţivatelské role, které budou definovat oprávnění k jednotlivým milníkům. Seznam milníků je moţné vyčíst z projektové dokumentace. Pro kaţdý milník vzniknou celkem dvě role, jedna pro odpovědnost a druhá pro participaci. Řekli jsme, ţe odpovědná osoba by měla byt vţdy jedna, zdálo by se tedy zbytečné vytvářet k tomuto účelu zvláštní roli. Liferay neumoţňuje přiřazování práv na úrovni uţivatele, vţdy je to na úrovni role, proto je nutné tuto roli vytvořit. Následně je nutné k rolím přiřadit uţivatele. Tímto krokem bychom měli mít hotovou kompletní organizační strukturu projektu.
4.3.3. Projektové prostředí V okamţiku, kdy jsou vytvoření uţivatelé, role, komunita a nastavena patřičná práva, můţe projektový manaţer zahájit vytváření projektového prostředí. Základem bude vytvoření několika projektových stránek: Milníky – tato portálová stránka bude obsahovat podstránky se všemi milníky, které v projektu existují. Kaţdé stránce projektový manaţer nastaví práva tak, ţe člen týmu s oprávněním O (odpovědný) bude moci stránky spravovat, umisťovat na ně portlety apod. Uţivateli, který je pro daný milník v roli P (participující) zadá pouze práva pro čtení. Tímto přiřazením definuje, ţe uţivatel s oprávněním O, je celkově zodpovědný 37
za milník společně s jeho portálovou stránkou. Jakmile uţivatel vstoupí na stránku s milníky, uvidí seznam pouze těch podstránek, ve kterých je veden pod rolí O či P. K zobrazení podstránek slouţí portlet s názvem Navigace, ten je vhodné umisťovat na kaţdou portálovou stránku, aby uţivatel mohl vţdy přejít k libovolné stránce v hierarchii. Diskuse – na tuto stránku projektový manaţer umístí a nastaví portlet pro vedení diskusí. Portlet bude slouţit pro celoprojektovou komunikaci. Kaţdý bude moci přispět a poloţit dotaz, případně odpovědět. Knihovna – na této projektové stránce projektový manaţer nastaví povolení přístupu pouze pro svou osobu, pro roli OPM a ty, kteří mají roli O na nějaký milník. Do knihovny budou jednotlivý uţivatelé v roli O odevzdávat své artefakty a bylo by neţádoucí, kdyby k těmto artefaktům měli přístup všichni. Zároveň projektový manaţer vytvoří pro kaţdý projekt jednu sloţku a nastaví právo zápisu a čtení pouze pro roli O daného milníku. Pomocí této stránky má projektový manaţer okamţitý přístup ke všem dokumentům, které se k projektu váţou. Jakmile odpovědná osoba vloţí dokument milníku do knihovny, projektový manaţer má moţnost se na dokument podívat a případně ho „připomínkovaný“ vrátit zpět do knihovny. Pro komunikaci s odpovědnou osobou můţe samozřejmě vyuţít diskusní fórum. Kalendář – na této stránce bude umístěn projektový kalendář, kam budou mít přístup všichni uţivatelé, ale pouze projektový manaţer bude mít pravomoc spravovat jednotlivé záznamy. Wiki – zde bude umístěn portlet pro projektovou Wiki, kde všichni členové týmu budou moci umisťovat své znalosti o projektu a sdílet tak informace s ostatními. Novinky – tato stránka bude slouţit pro oznamování nových událostí, bude zde umístěn portlet pro oznámení, čtení RSS kanálů a zobrazování aktivit. Vyhledávání – tato stránka slouţí k vyhledávání obsahu (článků, blogů, diskusních fór atd.). Zpětná vazba – na této stránce bude umístěn portlet s formulářem, kam mohou členové týmu posílat (i anonymní) návrhy. Formuláře lze libovolně měnit, můţe se z něj stát velmi lehce např. anketa na libovolné téma. Jakmile jsou hotovy základní stránky, je moţné přistoupit k tvorbě stránek pro jednotlivé milníky. Kaţdý taková stránka bude mít nastaven patřičný přístup a oprávnění a bude obsahovat následující portlety: Navigace – pro přístup ke stránce se seznamem milníků. Článek – ke kaţdému milníku by měl projektový manaţer vytvořit minimálně jeden článek, který bude zahrnovat informace ohledně termínu dokončení, artefaktu, který je potřeba vyhotovit, formě odevzdání, termínu odevzdání, dále by měl článek obsahovat popis a zodpovědné a participující osoby. Diskuse – tento portlet je shodný s tím, který je umístěn na portálovou stránku Diskuse pouze s tím rozdílem, ţe je nastaven pouze na patřičný milník. Diskuse se tak bude týkat pouze jednoho milníku a přístup k ní budou mít pouze lidé, kteří jsou k milníku přiřazení. Zobrazení knihovny – tento portlet slouţí pouze ke čtení knihovny, která byla umístěna na stránce Knihovna a je nastaven tak, ţe dokáţe číst pouze sloţku, která patří k danému milníku. Tak uţivatelé v roli O a P budou mít přístup k dokumentům, které se týkají daného milníku. Výše uvedené projektové stránky a portlety by měly být dostačujícím prostředím pro týmovou spolupráci a sdílení informací. Současně přináší i velmi mocný nástroj pro projektového 38
manaţera, a to moţnost mít veškeré projektové artefakty na jednom místě. Nemusí tak trávit čas hledáním věcí po různých místech či systémech, vše má přehledně před sebou na několika portálových stránkách. Zároveň má vţdy pod kontrolou celý projektový tým a můţe flexibilně reagovat na jakékoli změny například, přijde-li nový člen do týmu. Projektový manaţer pouze zajistí přidělení projektových rolí a nový spolupracovník má hned přístup všude, kam potřebuje. Nemusí tak „bombardovat“ své kolegy dotěrnými dotazy, které uţ jsou zodpovězeny na projektové Wiki či na diskusním fóru. Touto podporou projektového řízení a komunikace v projektovém týmu by jistě mohlo být dosaţeno toho, ţe by Brooksův zákon neplatil, případně, ţe by se jeho účinky minimalizovaly na skutečné minimum. Dále je nutno říci, ţe jsme zdaleka nevyčerpali veškerý potenciál, který v portálu Liferay je. Můţeme tvrdit, ţe jsme vyuţili jeho nabízených funkcionalit z poměrně velké části, ale jeho mocná síla pramení i ze zmíněných standardů pro vývoj portletů. Druhým krokem k budování projektového prostředí by mohlo být napojení portálu na ostatní firemní aplikace, ať uţ jsou z oblasti marketingu a obchodu (různé CRM66 systémy) nebo z oblasti financí (účetní software) případně z oblasti výroby a zásobování (ERP67 systémy) či oblasti jiných oddělení. Moţností je opravdu nepřeberné mnoţství a jejich vyuţití záleţí zejména na společnosti, která se portál rozhodla do své firemní infrastruktury implementovat.
4.3.4. Zhodnocení Pomocí výše uvedených postupů a funkcionalit je moţné vybudovat IT podporu pro projektové řízení se zaměřením na plánování, stanovení milníků, zodpovědností a poskytnutí podpory pro projektové dokumenty. Mezi výhody navrţeného řešení patří zejména: Řešení je postaveno na standardech a open source řešení – tyto dva aspekty mohou v některých případech hrát i klíčovou roli, a to zejména v ceně nasazení, rozšiřitelnosti a přenositelnosti. Snadná rozšiřitelnost – tento aspekt vychází z předchozího bodu. Otevřené zdrojové kódy zaručují, ţe lze řešení modifikovat. Standardy v tomto hledisku zase znamenají jakousi jistotu do budoucna. Při pouţívání standardizovaných řešení existuje jistota, ţe se technologie, na nich postavená, bude pouţívat i několik let a cena vývoje pro tyto technologie zůstane na přijatelné úrovni. Pravděpodobně by bylo hodně drahé hledat vývojáře jisté proprietární technologie, která se jiţ několik let nevyvíjí, nepouţívá a nebyla standardizována. Snadná použitelnost – portál přichází s velmi intuitivním a atraktivním uţivatelským rozhraním, které je uţivatelsky velmi přátelské. Zvládnutí několika portálových principů zvládne pravděpodobně kaţdý během týdenního tréninku. Malé náklady na implementaci a případné další změny – řešení vychází ze standardních funkcionalit, které portálový server nabízí, není proto potřeba investovat do dalšího vývoje. Nasazení portálového serveru samozřejmě přináší investice do hardwaru a administrace, ale to je asi přijatelná cena oproti přidané hodnotě, kterou portál nabízí. Velká použitelnost a potenciál – portály jsou v IT fenoménem dnešní doby, jsou hojně pouţívány a nejnovější prognózy ukazují, ţe se i pouţívat budou. Není to technologie, která by byla na vrcholu Hype křivky68. Stávající řešení je vhodné jak pro malý, tak i 66
Customer relationship management, téţ také systém pro řízení vztahů se zákazníky. Více informací viz: Wikipedie, otevřená encyklopedie. [online] 67 Enterprise Resource Planning, téţ také systém pro plánování podnikových zdrojů. Více informací viz: Wikipedie, otevřená encyklopedie. [online] 68 Ilustrační Hype křivka viz: SAP Design Guild – Usability, User Interface design &Visual Design. [online]
39
velký počet projektů, v tomto ohledu není řešení nikterak omezující. Navíc je moţné řešení moţné pouţít i na jiné druhy pracovních činností, kde je důleţitá spolupráce a sdílení informací. Podpora komunikace, spolupráce a sdílení informací – členové týmu mají na výběr velké mnoţství komunikačních kanálů, zároveň mají přístup k nejrůznějším aplikacím podporujícím sdílení znalostí. Projektoví manaţeři mají snadný přístup ke všem projektovým artefaktům. Jednotné prostředí pro projekty a projektové artefakty. Uchování historie projektů – veškeré nastavení, komunikace, artefakty, články, atd. jsou archivovány, takţe je lze pouţít i v příštích projektech. Správa projektového týmu – velmi snadno lze spravovat členy projektových týmů. Současně lze u kaţdého člena jednoduše nadefinovat případně odebrat uţivatelská práva. Ve stávajícím řešení je moţné najít jisté nedostatky a v návaznosti na to lze navrhnout cesty, kterými by se mohl portál a vytvořené prostředí ubírat dále. Autor vidí moţné cesty zejména v těchto oblastech: Snazší vytváření projektů – v současné chvíli je nutné udělat poměrně velké mnoţství administrativních kroků k tomu, aby byl projekt vytvořen. Ideální by bylo vytvořit podporu pro vytváření projektů na základě určitých projektových dokumentů, jako je WBS, OBS, RAM atd. Na základě seznamu milníků či WBS by bylo moţné vytvořit portálové stránky a uţivatelské role. Dokument s OBS by mohl slouţit k vytvoření patřičných uţivatelů a matice zodpovědností RAM by slouţila k automatickému mapování mezi uţivateli a milníky. Uţivatelská práva by byla nastavena na základě dodaných dokumentů. S tímto bodem souvisí i úprava stávajících projektů např. štěpení milníků. I v současném řešení lze částečně této funkcionality dosáhnout, ale za cenu dodatečného úsilí, jelikoţ jednotlivé portlety nejsou mezi sebou provázány do takové míry, aby tuto funkcionalitu umoţňovaly. Zjednodušeně by se dalo říct, ţe portlet s diskusním fórem „neví nic“ o milníku či knihovně dokumentů. Napojení na MS Project – vylepšit podporu pro plánování zdrojů a časového harmonogramu projektu. Dokumenty tvořené pomocí MS Project by mohly být vstupem pro předchozí bod. Napojení na Issue Tracking System (ITS) – tyto systémy slouţí pro zadávání a evidenci práce jednotlivých členů týmu na projektu, mezi nejznámější patří pravděpodobně systém JIRA69 a Trac70. V tomto případě by dalším moţným pokračováním mohlo být přenesení uţivatelského rozhraní ITS systému do portálu. V současné době se pracuje na vytvoření portletu pro propojení se zmíněným systémem JIRA. Tyto portlety by bylo samozřejmě moţné vzít a do portálu nainstalovat. Připojení dalších podnikových systémů – jedná se o jiţ zmíněné CRM, ERP, CMS a další systémy, které se v dnešní době v podnikovém prostředí pouţívají. Portál by se tak stal nejen místem pro vývojáře a projektové manaţery, ale i pro ostatní spolupracovníky, kteří se přímo nepodílí na nějakém projektu. Upomínky – kaţdý milník má definován čas splnění a zodpovědnou osobu. Z hlediska projektového managementu by byla k dispozici funkce, která by připomínala projektovému manaţerovi a odpovědné osobě, ţe se blíţí termín plnění. Právě takovéto funkcionality by projektovým manaţerům přinesly další uţitek, protoţe by nemuseli na všechny moţné termíny myslet a mohli by se soustředit více na koncepční projektovou práci. 69 70
JIRA – Bug tracking, issue tracking and project management software. [online]. The Trac Project. [online]
40
Neotestování v „ostrém“ provozu – toto není návrh na vylepšení, ale spíše nedostatek. Další cesty, případně nápady, co vylepšit jistě vzniknou, aţ se produkt začne reálně pouţívat. Vedle nejrůznějších nápadů na vylepšení celého systému existují ještě určité limitující aspekty. Ty lze samozřejmě, po dalších analýzách a vylepšeních, postupně odstranit. K nejvýraznějším limitům patří: milníky nelze snadno štěpit a slučovat, omezené sdílení diskusí napříč milníky, existence projektu je závislá na existenci komunity, nepříliš vhodné pro projekty s velkým množstvím milníků, a to z důvodu časové náročnosti jejich případné administrace. Na velikost týmu nejsou kladena žádná omezení. Dále je k práci přiloţeno CD, které obsahuje předinstalovaný a plně nastavený portálový server, který zahrnuje vytvořené projektové prostředí přesně v takové míře, jak bylo v této kapitole popsáno. Obsahuje všechny uţivatele OBS, milníky, mapuje matici zodpovědností atd. Na portálu je moţné vyzkoušet si práci v simulovaném prostředí, případně lze portál snadno pouţít pro konkrétní projekt. Více informací o instalaci je k nalezení v souboru README.TXT, uloţeného na zmiňovaném CD.
41
ZÁVĚR Cílem této práce bylo navrhnout prostředí, které by podpořilo projektové řízení, zejména v oblastech plánování, stanovení milníků, řízení zodpovědností a podpoření komunikace a sdílení informací. V prvních kapitolách byl detailně popsán projektový management a projekt jako takový. Text práce se zaměřil na základní vlastnosti projektu, jeho ţivotní cyklus, plánování a realizační tým. Byl kladen důraz na známé Brooksovy zákony, které stanovují určitá pravidla v oblasti týmové práce a měření efektivity týmu. Zároveň byly popsány základní projektové artefakty, které by měly být součástí kaţdého projektu. V praktické části se práce zabývala konkrétním projektem v kontextu Fakulty informatiky Masarykovy univerzity. Byly popsány základní údaje o projektu, jeho organizační struktura, plán, milníky, cíle a zodpovědnosti. Zároveň byl projekt analyzován z hlediska efektivního členění, sdílení informací a komunikace. V návaznosti na zmíněný projekt bylo v další části navrţeno softwarové řešení, které by mělo přispět projektovému řízení a všem oblastem, kterými se práce zbývala v teoretické části. Navrţené řešení je uloţeno na CD, jenţ je přiloţeno k výtisku této práce. V předposlední kapitole této práce, kde je popsán samotný návrh a způsob řešení problémové oblasti, je rozepsáno zhodnocení finálního řešení s důrazem na klady, zápory a limity. Zároveň je zmíněna řada věcí, jeţ byly mimo rozsah této práce, a které by bylo moţné do finálního řešení dopracovat. Byl tak naznačen určitý směr, kterým by se mohly ubírat další bakalářské a diplomové práce, snaţící se vytvoření o navrţení podpory pro projektové řízení pomocí informačních technologií. Mezi hlavní přínosy této práce bych zařadil zejména zanalyzovanou teoretickou oblast a problémovou doménu, propojení teoretických znalostí do konkrétního praktického řešení a také funkční projektovou infrastrukturu, která by měla slouţit účelům popsaným v první části této práce.
42
SEZNAM PŘÍLOH Příloha A. Organizační struktura………………………………………………………. Obrázek A.1. Funkční organizační struktura………………………….………….. Obrázek A.2. Slabá maticová organizační struktura……………………….….….. Obrázek A.3. Vyváţená maticová organizační struktura……………….……..….. Obrázek A.4. Silná maticová organizační struktura…………………….………… Obrázek A.5. Projektová organizační struktura…………………………………... Příloha B. Diagramy…………………………………………………………………….. Obrázek B.1. Síťový diagram…………………………………………………….. Obrázek B.2. Ganttův diagram…………………………………………………… Příloha C. Plánování…………………………………………………………………….. Obrázek C.1. Technická a organizační příprava Plánu projektu…………………. Příloha D. Liferay……………………………………………………………………….. Obrázek D.1. Organizace, komunity, skupiny, role, uţivatelé…………………… Obrázek D.2. Organizační členění v portálu……………………………………… Obrázek D.3. Portálové stránky…………………………………………………...
43
47 47 47 48 48 48 49 49 49 50 50 51 51 51 51
SEZNAM POUŽITÉ LITERATURY Monografie: [1]
FIALA, P. Projektové řízení: modely, metody, analýzy, 1. vyd., Professional Publishing, Praha, 2008, s. 186, ISBN 978-80-245-1414-0.
[2]
MINTZER, R. Project Management Book, 1st edition, Adams Media Corporation, Massachusetts, 2002, p. 289, ISBN 1-58062-583-5.
[3]
MURCH. R. Project Management, 1st edition, Prentice Hall, NJ, 2001, p. 247, ISBN 0-13-021914-2.
[4]
Project Management Institute. A Guide to Project Management Body of Knowledge, 3rd edition, Project Management Institute, 2006, p. 388, ISBN 1-930699-45-X.
[5]
Kolektiv autorů. Projektové řízeni Příručka manažera, 1. vyd., TATE International s.r.o., 2005, s. 200, ISBN 80-86813-06-1.
[6]
SEZOV R. Liferay Administrator's Guide, 2nd Edition, Liferay Press, 2008, p. 272, ISBN 978-0-615-24733-5.
[7]
SCHWALBE, K. Řízení projektů v IT, 1. vyd., Computer Press, a.s., Brno, 2007, s. 720, ISBN 978-80-251-1526-8.
[8]
SVOZILOVÁ, A. Projektový management, 1. vyd., Grada Publishing, Praha, 2006, s. 353, ISBN 80-247-1501-5.
Internetové odkazy: [1]
ANIMA Forbína. [online]. [citováno 2009-05-09]. Dostupný z WWW: < http://www.anima.cz/forbina/?p=119>.
[2]
Česká zemědělská Univerzita v Praze. [online]. [citováno 2009-05-01]. Dostupný z WWW:
.
[3]
INSPIRE. [online]. [citováno 2009-05-12] Dostupný z WWW:
[4]
JIRA – Bug tracking, issue tracking and project management software. [online]. [citováno 2009-05-02]. Dostupný z WWW: < http://www.atlassian.com/software/jira/>.
[5]
Murphyho zákony. [online]. [citováno 2009-05-16]. Dostupný z WWW: < http://www.disc-group.cz/misc/murphy.htm>.
[6]
Olayle Adelakun Ph.D. DEPAUL CTI. School of Computer Science, Telecommunications and Information Systéme. [online]. [citováno 2009-04-20]. Dostupný z WWW: . 44
[7]
Portál veřejné správy České Republiky. [online]. [citováno 2009-05-12]. Dostupný z WWW: < http://portal.gov.cz>.
[8]
Project Smart: Project Management Templates, Articles, Books and PRINCE2 Training. [online]. [citováno 2009-04-01]. Dostupný z WWW: < http://www.projectsmart.co.uk/docs/chaos-report.pdf>.
[9]
SAP Design Guild – Usability, User Interface design &Visual Design. [online]. [citováno 2009-05-16]. Dostupný z WWW: .
[10]
The Trac Project. [online]. [citováno 2009-05-01]. Dostupný z WWW: .
[11]
Wikipedie, otevřená encyklopedie. [online]. [citováno 2009-04-01]. Dostupný z WWW: < http://cs.wikipedia.org/wiki/Artefakt>.
[12]
Wikipedie, otevřená encyklopedie. [online]. [citováno 2009-04-06]. Dostupný z WWW: < http://cs.wikipedia.org/wiki/Brainstorming>.
[13]
Wikipedie, otevřená encyklopedie. [online]. [citováno 2009-05-04]. Dostupný z WWW: < http://cs.wikipedia.org/wiki/Customer_relationship_management>.
[14]
Wikipedie, otevřená encyklopedie. [online]. [citováno 2009-05-04]. Dostupný z WWW: < http://cs.wikipedia.org/wiki/Enterprise_resource_planning>.
[15]
Wikipedie, otevřená encyklopedie. [online]. [citováno 2009-05-12]. Dostupný z WWW: < http://cs.wikipedia.org/wiki/Groupware>.
[16]
Wikipedie, otevřená encyklopedie. [online]. [citováno 2009-05-10]. Dostupný z WWW: < http://cs.wikipedia.org/wiki/Workflow>.
[17]
Wikipedia, the free encyklopedia. [online]. [citováno 2009-04-20]. Dostupný z WWW: < http://en.wikipedia.org/wiki/Brooks%27_law>.
[18]
Wikipedia, the free encyklopedia. [online]. [citováno 2009-05-02]. Dostupný z WWW: < http://en.wikipedia.org/wiki/COCOMO>.
[19]
Wikipedia, the free encyklopedia. [online]. [citováno 2009-05-07]. Dostupný z WWW: < http://en.wikipedia.org/wiki/Non-disclosure_agreement>.
[20]
Wikipedia, the free encyklopedia. [online]. [citováno 2009-05-13]. Dostupný z WWW: < http://cs.wikipedia.org/wiki/Open_source>.
[21]
Wikipedia, the free encyklopedia. [online]. [citováno 2009-04-29]. Dostupný z WWW: < http://en.wikipedia.org/wiki/Responsibility_assignment_matrix>.
[22]
Wikipedia, the free encyklopedia. [online]. [citováno 2009-05-07]. Dostupný z WWW: < http://en.wikipedia.org/wiki/Statement_of_work>.
45
[23]
Wikipedia, the free encyklopedia. [online]. [citováno 2009-05-17]. Dostupný z WWW: < http://en.wikipedia.org/wiki/Wiki>.
[24]
Wikipedia, the free encyklopedia. [online]. [citováno 2009-05-02]. Dostupný z WWW: < http://en.wikipedia.org/wiki/Silver_bullet>.
[25]
Small Footprint LLC: Winston-Salem, NC Application Development Outsorcing. [online]. [citováno 2009-05-02]. Dostupný z WWW: .
Ostatní: Kolektiv autorů. GS Soil, Assessment and strategic development of INSPIRE compliant Geodata-Services for European Soil Data, 2009, s. 33
46
Příloha A. Organizační struktura Obrázek A.1. Funkční organizační struktura
Zdroj: Project Management Institute. A Guide to Project Management Body of Knowledge. s. 44
Obrázek A.2. Slabá maticová organizační struktura
Zdroj: Project Management Institute. A Guide to Project Management Body of Knowledge. s. 45
Obrázek A.3. Vyvážená maticová organizační struktura
Zdroj: Project Management Institute. A Guide to Project Management Body of Knowledge. s. 45
47
Obrázek A.4. Silná maticová organizační struktura
Zdroj: Project Management Institute. A Guide to Project Management Body of Knowledge. s. 46
Obrázek A.5. Projektová organizační struktura
Zdroj: Project Management Institute. A Guide to Project Management Body of Knowledge. s. 44
48
Příloha B. Diagramy Obrázek B.1. Síťový diagram
Zdroj: Česká zemědělská Univerzita v Praze. [online]
Obrázek B.2. Ganttův diagram
Zdroj: Česká zemědělská Univerzita v Praze. [online]
49
Příloha C. Plánování Obrázek C.1. Technická a organizační příprava Plánu projektu
Zdroj: SVOZILOVÁ, A. Projektový management, s. 122
50
Příloha D. Liferay Obrázek D.1. Organizace, komunity, skupiny, role, uživatelé
Zdroj: SEZOV R. Liferay Administrator's Guide. s. 96
Obrázek D.2. Organizační členění v portálu
Zdroj: autor
Obrázek D.3. Portálové stránky
Zdroj: autor
51
