Masarykova univerzita. Fakulta informatiky

Transkript

1 Masarykova univerzita Fakulta informatiky Diplomová práce Metodiky řízení a koordinace prací při vývoji software Vypracovala: Bc. Jitka Daňková Vedoucí: doc. Ing. Michal Brandejs, CSc. 2011

2

3 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používala nebo z nich čerpala, v práci řádně cituji s uvedením odkazu na příslušný zdroj. Jitka Daňková V Brně, dne i

4 Poděkování Mé poděkování patří vedoucímu práce, doc. Ing. Michalovi Brandejsovi, CSc., za cenné rady, podporu v mé práci a možnost vyzkoušet a vyhodnotit vybraný postup koordinace na reálném projektu. Dále bych chtěla poděkovat týmu pracovníků Servisního střediska pro podporu e-learningu na MU, kteří se mnou měli trpělivost, nebáli se zavádění nových postupů a byli otevření diskusi. Na závěr děkuji mému manželovi za podporu, povzbuzení i rady pro psaní mé diplomové práce. ii

5 Shrnutí Multiprojektové prostředí v kombinaci s velkou mírou tvůrčí činnosti vnáší do projektového řízení potíže, při jejichž řešení standardní metody projektového řízení selhávají. Jedná se o oblast málo prozkoumanou, otázek se vynořuje více než odpovědí. Protože tvůrčí činnost je jednou ze stěžejních vlastností projektů vývoje software, potýká se s problémy nejeden koordinátor malých IT firem, pro něž je právě multiprojektové prostředí typické. Tato práce čtenáři ukazuje metafory, přes které lze multiprojektové prostředí chápat, a zaměřuje se na rozbor dvou identifikovaných problematických oblastí: kontrola výkonu pracovníků a plánování (s důrazem na odhadování doby trvání činností). Autorka na základě studia odborné literatury, článků a dle zkušeností s multiprojektovým prostředím v praxi popisuje nejen potíže a negativní vlivy, ale navrhuje i samostatná řešení ve formě jednoduchých nástrojů a technik. Přínosem pro začínající koordinátory jsou sepsané postupy krok za krokem dvou vybraných metodik reprezentujících dva ze tří hlavních směrů v projektovém řízení. Autorka je na základě poznatků získaných studiem literatury upravila a přizpůsobila pro potřeby multiprojektového prostředí. Případová studie nasazení jednoho postupu v praxi hodnotí přínosy metodiky. Klíčová slova Multiprojektové prostředí, plánování, kontrola výkonu, koordinace pracovníků, kritický řetěz, projektové řízení, Scrum. iii

6 Obsah 1 Úvod Obsah jednotlivých kapitol Způsob psaní textu Základní pojmy Metodika Projekt WBS Kritická cesta TOC Multitasking Agilní metodiky, manifest, pravidla a principy Studentský syndrom Parkinsonův zákon Vyčlenění problematiky Jeden projekt versus multiprojektové prostředí Metafory pro pochopení multiprojektového prostředí Problém převahy tvůrčí činnosti v oblasti vývoje software Modelové příklady firem Kontrola výkonu pracovníků Výkon Identifikované problémy ovlivňující výkony pracovníků Multitasking Vyrušování Problém Skoro hotovo Prokrastinace Navržené techniky řešení jednotlivých problémů ToDo list a omezení WIP Prověrka firemních pravidel Týdenní úkoly Správná otázka SMART metoda Hledání nejbližšího kroku Pět minut Polykání žab Systematická kontrola výkonu Plánování a odhadování času Plány projektu Identifikované problémy stanovení časového odhadu činností Vliv nejistoty na odhadování Vliv osoby odhadující činnost Problém časových rezerv iv

7 5.3 Nástroje a techniky odhadování času Zkušenost, analogie Expertní posudky PROBE PERT LOC FPA COCOMO II Technika Delfské věštírny Plánovací hra Pravidla pro práci s časovými rezervami Sestavení harmonogramu projektu Dodržování termínů Možnosti koordinace Synchronizace projektů pomocí front a omezení FCFS MinSLK ConPIP ConTIP QSC Koordinace vycházející z Projektového managementu kritickým řetězem Základní problémy projektového řízení a jejich řešení dle Goldratta CCPM v prostředí několika IT projektů Postup plánování Postup koordinace Kontrola výkonu Jak začít? Koordinace vycházející z agilní metodiky Scrum Princip metodiky Scrum Pojmy v metodice Scrum Přizpůsobení metodiky Scrum pro více projektů Postup plánování Kontrola výkonu v metodice Scrum Postup koordinace Jak začít? Srovnání Využití vybrané možnosti v praxi Představení projektu a týmu Stav před nasazením metodiky a očekávané přínosy Nasazení postupu Vyhodnocení Závěr Literatura Přílohy v

8 1 Úvod Projektové řízení je oblast, které byly na poli vědecké i populární literatury věnovány tisíce stran. V knihách naleznou čtenáři informace, jak projekty řídit, jak zajistit úspěch, dodržet termíny, plánovat i zvažovat rizika. Byly již vynalezeny rozličné techniky, nástroje, postupy i software, byly založeny společnosti pro projektové řízení, konzultantské firmy i magisterské obory na vysokých školách. Začínající projektový manažer tedy může zajásat, chopit se knih a postupovat podle nich jako podle kuchařek. Bohužel, situace není tak jednoduchá, jak se na první pohled může zdát. Pozorný čtenář objeví, že velmi dobře je prozkoumána oblast jednoho projektu, v malé míře ovšem tzv. multiprojektové prostředí. V oblasti informačních technologií a vývoje software vstupuje do hry ještě aspekt tvůrčí činnosti a neustálých změn, ať již v požadavcích či technologiích. Turbulentní a dynamické prostředí projektů, typické pro začátek 21. století, je nyní pod drobnohledem vědců a nové metody, nápady, směry či problémy se objevují rychleji, než stačí být důkladně podrobeny kritice a vyzkoušeny v reálné praxi. Celá oblast připomíná mnoha dílkové puzzle, v němž jsou jednotlivé dílky rozesety po ploše samostatně či spojeny jen do malých celků, aniž by vypovídaly o celém obraze. Můžeme doufat, že se jednoho dne objeví průlomová myšlenka, jakou byla například Goldrattova Teorie omezení pro průmyslové odvětví, která by odkryla obraz multiprojektového prostředí najednou a bez skládání. Anebo můžeme postupně přidávat dílek po dílku a přispět tak k sestavení obrazu sami, tak jako si to klade za cíl tato práce. Obrázek 1.1: Metafora problematiky projektového řízení v multiprojektovém prostředí. (Zdroj:stock.xchng) Na základě studia odborné literatury, článků i na základě svých zkušeností s projektovým řízením vedením týmu a koordinací prací jsem identifikovala dvě podstatné a nejvíce problematické oblasti řízení projektů v multiprojektovém prostředí: kontrola výkonu pracovníků a plánování 1

9 (s důrazem na odhadování doby trvání činností). Popisuji nejen samotné potíže a negativní vlivy, ale také navrhuji řešení ve formě jednoduchých nástrojů a technik. Přínosem této práce má být především pomoci začínajícím projektovým manažerům a koordinátorům pochopit multiprojektové prostředí i s jeho problémy a nabídnout jim nejen samotné nástroje a techniky, ale i ucelené postupy koordinace. Nevynalézám postup zcela nový, ale na základě získaných poznatků upravuji a přizpůsobuji postupy určené pro projektové řízení jednoho projektu. Nakonec je vybraný postup použit v praxi, aby byl ověřen jeho přínos. 1.1 Obsah jednotlivých kapitol Zbývající část úvodní kapitoly čtenáře seznámí s orientací v textu. Druhá kapitola objasňuje základní pojmy, na které je z textu často odkazováno a třetí kapitola představuje čtenáři zkoumanou oblast multiprojektové prostředí popisně i v metaforách, včetně stručného nastínění problému převahy tvůrčí činnosti při vývoji software. Čtvrtá a pátá kapitola pojednávají o oblastech kontroly výkonu pracovníků a plánování. V obou jsou identifikovány problémy a uvedeny nástroje a techniky pro řešení. Nejrozsáhlejší šestá kapitola seznamuje čtenáře s vybranými postupy koordinace. Důraz je kladen na popis krok za krokem v případě postupu inspirovaného metodikou CCPM a metodikou Scrum, včetně doplnění drobných praktických tipů a také obrázků a schémat v přílohách. Méně prostoru je věnováno synchronizaci projektů pomocí front a omezení. Sedmá kapitola představuje použití získaných teoretických poznatků a jejich přenesení do praxe. Popisuje přínos i problémy zavedení vybrané možnosti koordinace v rámci projektu Centra výpočetní techniky na Fakultě informatiky. Osmá kapitola shrnuje v závěru získané poznatky a devátá a desátá kapitola jsou vyhrazeny literatuře, informačním zdrojům a přílohám. 1.2 Způsob psaní textu Text je obvyklým způsobem strukturován a číslován. Citace jsou uváděny v odděleném zúženém odstavci kurzívou s označením zdroje. Kurzíva v textu slouží pro vyznačení odborných termínů, použita je pouze pro první označení daného termínu. Dále v textu z důvodu přehlednosti a dobré čitelnosti je od použití kurzívy v již představených pojmech upuštěno. Obrázky a schémata jsou zpracovány autorkou práce, pokud není uvedeno jinak. Informační rámečky V rámečcích jsou uvedené konkrétní příklady, rozšiřující příklady či definice, upřesnění nebo zajímavosti k tématu. Jsou odděleny, neboť nemají přímou návaznost k textu, ale pouze doplňující a rozšiřující charakter. 2

10 2 Základní pojmy V následující kapitole je objasněno několik základních pojmů, na které se později v textu často odkazuji. Čtenář znalý problematiky projektového řízení, teorie omezení a agilních metodik může kapitolu přeskočit. 2.1 Metodika Protože pojem metodika prostupuje celou prací, je nezbytné objasnit, jak je v rámci práci užíván. V obecném chápaní je metodika v podstatě předepsaný pracovní postup či návod: Metodika nauka o metodě vyučování určitého oboru, pracovní postup. (internetové slovníky cizích slov, např. [1]) Metodiku v obecném pojetí chápeme jako pracovní návod, který nám předepisuje, jak postupovat při určitém úkonu (práci, výuce, vývoji a jiných). [2] Ovšem v oblasti vývoje software a vůbec v oblasti IT se různé zdroje snaží o více či méně přesnou definici a snaží se stanovit pravidla, co se s metodikou smí a nesmí dělat. Tyto definice nejsou ve velkém měřítku přijímány a jako metodiky jsou označovány například agilní metodiky, byť dle definic níže se o metodiku nejedná. Ve vývoji software metodika představuje souhrn doporučených praktik a postupů, pokrývajících celý životní cyklus vytvářené aplikace. [3] Metodiku můžeme definovat jako úplný formální popis celého vývojového procesu nebo jeho části z metodiky nemůžete libovolně vybírat, co použijete. [4] Metodika je předepisující, i když je nutné ji nejdříve upravit pro potřeby daného projektu, adoptujeme ji většinou jako celek a neprovádíme zásadní změny. [5] Metodika je framework, který se používá k uspořádání, plánování a řízení procesů při vývoji informačního systému. [3] Vedle pojmu metodika se proto objevily další pojmy, jako Best practices, procesní framework, metodický framework, metodický přístup či jen obyčejné spojení soubor pravidel. Ze špatného překladu z angličtiny je také často užíván pojem metodologie 1 namísto metodika. V této práci používám pojem metodika: 1) pro označení postupu koordinace prací na projektu; 2) tak, jako jej často používají jiní autoři (agilní metodiky, metodika Scrum). 1 Metodologie je nauka či vědní disciplína o metodikách. 3

11 2.2 Projekt Definice projektu se od sebe opět jako v případě metodiky liší: Projekt dle IPMA: Projekt je časově, nákladově a zdrojově omezený proces realizovaný za účelem vytvoření definovaných výstupu (rámec naplnění projektových cílů) co do kvality, standardu a požadavků. Projekt dle ISO : Projekt je jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosažení předem stanoveného cíle, který vyhovuje specifikovaným požadavkům, včetně omezení daných časem, náklady a zdroji. Projekt dle PMI: A project is a temporary endeavor undertaken to create a unique product, service, or result. [6] Osobně považuji za zdařilou následující definici: Projekt je jedinečná sekvence činností mající jeden začátek a jeden konec, přidělené zdroje a směřující k vytvoření určitých produktů. [6] Právě jedinečnost odlišuje projekt od ostatních rutinních procesů v podniku. Každý projekt musí mít stanovený cíl, obvykle bývá vyjádřen pomocí tzv. trojimperativu, tedy vyjádření cíle ve třech dimensích. První dimense je věcná co se má vytvořit, druhá dimense je časová kdy se to má udělat, a třetí dimense je dimense nákladů za kolik se to má udělat (podle [6]). 2.3 WBS Work breakdown structure (WBS), česky označovaná jako hierarchická struktura činností, je metoda používaná pro rozdělení projektu do jednotlivých činností a úkolů. Při rozkladu se postupuje systematicky od nejvyšší úrovně projektu, což je definice jednotlivých komponent, až po rozklad jednotlivých komponent na další jednotky a podjednotky. Správně vytvořená WBS projektu zajistí, že žádná činnost není opomenuta a rozdělení projektu na malé, lépe uchopitelné celky pomůže v přípravě plánů projektu. Více o metodě WBS a postupu tvorby je napsáno v knize [7]. 2.4 Kritická cesta Metoda kritické cesty (anglicky Critical path Method, zkratkou CPM) byla vyvinuta již v 50. letech minulého století. Jedná se o matematickou metodu používanou pro řízení projektů, vystavěna je na základech tzv. síťových grafů činností. V těchto síťových grafech je rozpoznána časově nejdelší možná cesta z počátečního bodu grafu do koncového a je označena jako kritická cesta. Na základě délky kritické cesty je pak možné určit dobu trvání projektu. CPM dále metodicky stanovuje, jak vytvořit časový plán všech činností v projektu. Více o metodě Kritické cesty je napsáno v knize [7]. Při řízení projektu pomocí CPM ovšem roste objem rozpracovaných činností jako důsledek plánovací strategie zacílené na započetí činností v nejkratším možném termínu (anglicky as soon as posible, zkratkou ASAP). Velmi rychle může dojít ke stavu, ve kterém projektový manažer ztratí nadhled a začne zmatkovat. Právě nárůst objemu rozpracovaných činností bývá zmiňován jako nevýhoda metody (například v textu [8]). 4

12 2.5 TOC Svoji převratnou filosofii nazvanou Teorie omezení (anglicky Theory Of Constraints, zkratkou TOC) poprvé zveřejnil Eliyahu M. Goldratt v roce 1984 ve své knize Cíl [9]. Goldratt tvrdí, že v každém systému existuje omezení, které mu brání dosahovat maximálního výkonu. Na základě tohoto poznání stanovil pět kroků, které systému umožní zvýšit výkon a ve svém důsledku, vztaženo na komerční sféru, zvýší zisk podniku. Pět základních kroků Teorie omezení: 1. Identifikace omezení systému. 2. Rozhodnutí, jak maximálně využít nalezené omezení. 3. Podřízení ostatních činností tomuto rozhodnutí. 4. Zlepšení omezení. 5. Opakování celého procesu. Iterativním opakování celého procesu ve svém důsledku vede k trvalému procesu zlepšování systému. Více o Teorii omezení je napsáno v knize [9] a v textu [8]. 2.6 Multitasking Multitasking je v případě projektového řízení označení pro situaci, kdy pracovník přebíhá či přeskakuje z jedné činnosti na druhou v krátkých časových úsecích. Jedno takové přeskočení bývá nazýváno změnou kontextu, je totiž nutné, aby pracovník přestal přemýšlet nad pravidly, kontextem, prostředím, souvislostmi jedné činnosti a připravil si prostředí, vzpomněl na pravidla a kontext činnosti druhé. Definice multitaskingu dle IPMA: Způsob plánování a vykonávání práce, ve kterém jeden zdroj v jeden časový interval pracuje na více úkolech. V tomto způsobu práce se preferuje začít s úkolem hned, jak je to jen možné. [10] Na obrázku 2.1 jsou znázorněny tři na sobě nezávislé činnosti jednoho projektu. V první variantě pracovník plní činnosti postupně, ve druhé vždy po dvou dnech činnost střídá. Ve druhé variantě má koordinátor či projektový manažer ze začátku dobrý pocit, že se pracuje na všech činnostech, že všechny činnosti postupují. Ovšem teprve po 14 dnech je jedna z činností hotova, zatímco v prvním případě jsou po 14 dnech hotové činnosti dvě. 5

13 Obrázek 2.1: Ukázka vlivu multitaskingu na délku trvání činností na jednom projektu. Představme si situaci v prostředí více projektů, mějme projekt A s logickým uspořádáním činností (viz obrázek 2.2), doba činnosti X je odhadnuta na 20 dní. Pokud zdroj vykonávající činnost X pracuje zároveň i na dvou dalších činnostech z jiných projektů, činnost X bude hotova až po 48 dnech, což je více než dvojnásobek původní odhadované doby. Přitom reálná doba, kterou zdroj strávil na činnosti X bylo opravdu 20 dní. Ovšem pokud projektový manažer projektu A s multitaskingem nepočítá, může jeho projekt nabrat velké zpoždění oproti plánu. Obrázek 2.2: Ukázka vlivu multitaskingu na délku trvání činností v případě více projektů. Multitasking nelze vždy označit za špatný přístup, například bez tzv. conscious multitasking (více v textu [11]), který je nám lidem vlastní, bychom nebyli schopni řídit auto, sledovat vozovku a ještě u toho poslouchat rádio. Na poli psychologie se odborníci zabývají tzv. multitasking generation 6

14 (například v článku [12]), tedy generací dětí, pro které je díky novým technologiím multitasking přirozený. Ze zkušenosti vím, že existují pracovníci, kteří multitasking preferují a jsou spokojeni, pokud mají zadáno více úkolů a mohou si přepínáním kontextu přerušit monotónnost a šeď rutinní práce. Potom lze u takových pracovníků vysledovat i vyšší produktivitu. Na koordinátora však tato situace klade větší nároky na plánování a kontrolu práce takového pracovníka. Z druhé strany jsem se setkala s pracovníky, kteří striktně preferují monotasking (tj. pracovat na jedné činnosti dokud není dokončena bez přerušení jinou činností), jsou spokojeni, když se mohou plně soustředit na jednu činnost a efektivně ji vykonávat. Právě činnosti, které vyžadují velkou míru soustředěnosti programování či analýza nebo třeba psaní článku do odborného časopisu je ideální vykonávat formou monotaskingu. Existují i situace, kdy je multitasking velice vhodným nástrojem pro řízení prací v týmu. Představme si tým pracovníků, který zpracovává webové publikace pro akademiky. Na akademické půdě bývá obvyklé, že na jakoukoliv odezvu zákazníka akademika pracovníci čekají různě dlouhou dobu. Dále je časté, že brzy po započetí prací pracovníci potřebují od zákazníka upřesňující informace. Potom v případě multitaskingu pracovníci zjistí možné problémy a nesrovnalosti mnohem dříve než v případě monotaskingu a dříve položí zákazníkům potřebné dotazy. Navíc je mnohem snazší zákazníkovi sdělit, že na jeho publikaci pracuji, než že jsem ještě nezačala. V době, kdy potom pracovníci čekají na odezvu zákazníka, mohou zpracovávat jinou webovou publikaci. V případě monotaskingu by čekání na odezvu neměli čím vyplnit a pouze by čekali tento stav se nazývá downtime. Downtime je typický například pro zpracování videa. Pokud chce pracovník vidět výsledek svého nastavení či střihu, musí vyčkat na konverzi video souboru, která zaměstná procesor jeho počítače po dobu několika minut i hodin. pro tvorbu 3D animací. Pokud chce pracovník zjistit, zda má vytvořený pohyb správně načasován, musí si animaci či část animace vykreslit (mezi 3D animátory se užívá termín vyrenderovat), toto vykreslení také vyžaduje určitý výpočetní výkon a čas procesoru. pro práci s databázemi. Na některé komplexní dotazy nad rozsáhlou databází musí pracovník také čekat. 2.7 Agilní metodiky, manifest, pravidla a principy Agilní metodiky jsou iterativní, volně popsané procesy a postupy určené pro oblast vývoje software. Jejich společným cílem je zajistit, aby projekty byly co nejúspěšnější. V mnoha případech jej jim vlastní i snaha o zrychlení a zkrácení celého vývoje software. Čtyři základní pravidla agilních metodik jsou sepsána v tzv. Agilním manifestu [13] a více je rozvádí dvanáct agilních principů. Níže jsou uvedeny v českém překladu (volně přeloženo z [13]). Základní pravidla agilních metodik 1. pravidlo: Individuality a komunikace mají přednost před procesy a nástroji. 2. pravidlo: Fungující software je důležitější než vyčerpávající dokumentace. 3. pravidlo: Spolupráce se zákazníkem má přednost před vyjednáváním nad smlouvami. 4. pravidlo: Reakce na změnu je důležitější než striktní dodržování plánu 7

15 Rozšiřující principy agilních metodik 1. princip: Naší nejvyšší prioritou je uspokojit zákazníka brzkými a neustálými dodávkami hodnotného software. 2. princip: Změny požadavků jsou vítány, dokonce i v pozdějších fázích vývoje. Agilní procesy prezentují změny jako konkurenční výhodu zákazníka. 3. princip: Dodáváme fungující software často, v intervalech týdnů až měsíců, se snahou o kratší intervaly mezi dodávkami. 4. princip: Lidé z byznysu (business people) a vývojáři musí pracovat společně a denně po celou dobu projektu. 5. princip: Stavíme projekt na motivovaných lidech. Poskytujeme jim pracovní prostředí a podporu, jakou potřebují, a důvěru, že svoji práci zvládnou. 6. princip: Nejúčinnější cesta k efektivnímu sdílení informací při vývoji je osobní komunikace. 7. princip: Fungující software je hlavním měřítkem postupu. 8. princip: Agilní procesy podporují udržitelný vývoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo po neomezenou dobu. 9. princip: Neustálé věnování pozornosti na výbornou technickou kvalitu a dobrý návrh posiluje agilní přístup. 10. princip: Jednoduchost umění navýšit na nejvyšší míru množství práce, která nemusí být provedena je základem. 11. princip: Nejlepší architektury, požadavky a návrhy vznikají v samostatně řízených týmech (tzv. self-managed teams). 12. princip: Tým pravidelně zvažuje, jak se stát efektivnějším, následně vylepší své postupy a přizpůsobí tomu své chování. Dezinterpretace pravidel i principů Za deset let od sepsání Agilního manifestu se objevila spousta chybných názorů a nepravd o agilním přístupu a metodikách z něj odvozených. Tyto dezinterpretace v České republice v mnoha případech vznikly z důvodu špatného překladu pravidel a principů do češtiny. Bohužel jsou nepravdy a chybné názory uváděny i v odborné literatuře (dle článku [5]). Pravidlo č. 2 si nelze vysvětlovat jako absenci jakékoliv dokumentace. Dokumentace je nutnou součástí vývoje software, ovšem v agilních metodikách získává jinou podobu. Pravidlo pouze zdůrazňuje, že by neměla být kladena nejvyšší priorita na dokumentaci, ale spíše na fungující software. Princip č. 1 neznamená zásobit po týdnu zákazníka zbrklými dodávkami částí software, nad kterými nebyla provedena analýza. Analýza stále zůstává důležitou součástí procesu, jen v případě agilních metodik nepočítá s tím, že zákazník zná na začátku projektu všechny požadavky. Klasický proces vývoje software, tedy analýza návrh implementace integrace testování instalace se v mnoha agilních metodikách provádí ve zjednodušené formě krok za krokem pro každý požadavek (ve smyslu anglického feature). Právě časté dodávky fungujícího software (kde ne všechny součásti jsou již funkční) mají napomoci tomu, aby se zákazník vyjádřil a sdělil nové požadavky či přehodnotil požadavky, které chtěl na začátku. Ve výsledku by měl zákazník dostat produkt, který opravdu chce a potřebuje. Princip č. 2 a č. 10 souvisí s tzv. refaktorováním tedy snahou při programování oddělit externí a vnitřní funkce tak, aby se budoucí úpravy daly provádět bez narušení klíčových a rizikových částí. 8

16 Ne vždy lze ale refaktorování uplatnit, například při změnách v databázovém schématu. Další příklady dezinterpretace pravidel a principů naleznete v článku [5]. Přínosy agilních metodik Agilní metodiky by měly především umožnit reakce na změny v požadavcích, které často při vývoji od zákazníka přicházejí. Neměla by potom nastat situace, že by zákazník dostal něco jiného, než co požadoval (nedorozumění a dezinterpretace by měly být eliminovány). Iterativní přístup snižuje rizika projektu. Zajímavé přínosy nastávají v oblasti motivace vývojového týmu, neboť agilní metodiky představují především změnu myšlení a v důsledku přinesou změnu kultury v podniku. Iterativní přístup ruku v ruce s neustálými viditelnými průběžnými výsledky působí pozitivně na jednotlivé pracovníky. Velká část metodik dává týmu větší pravomoci, zodpovědnost a především možnost rozhodování. Někdy bývá jako přínos uváděn i fakt, že agilní metodiky jsou zábavné. 2.8 Studentský syndrom Eliyahu M. Goldratt si všiml zajímavé skutečnosti: činnost či etapa v projektu je zahájena ve většině případů na poslední chvíli. Nezáleží na termínu, kdy daná činnost mohla začít ani na tom, jaký čas na ni byl plánován. Pojmenování Studentský syndrom vzniklo na základě obvyklého chování studentů, tedy situace, kdy se začnou učit na zkoušku v lepším případě týden před termínem, v tom horším v předvečer termínu zkoušky. Důvodem tohoto jednání bývá lidská pohodlnost, ale také nedostatečná motivace (nízká odměna či malá penalizace za nesplnění úkolu). Na obrázku 2.3 je znázorněn obvyklý průběh činnosti při působení Studentského syndromu. Studentskému syndromu lze dle [13] například zabránit tak, že zaměstnanci neví o časových rezervách, které byly pro činnost stanoveny nebo jsou rezervy viditelně akumulovány až na konec projektu, tudíž pracovníci pracují bez rezerv. 2.9 Parkinsonův zákon Obrázek 2.3: Průběh činnosti při působení Studentského syndromu. (Zdroj:autorka, překresleno z obrázku v textu [14], strana 32) Každá práce trvá tak dlouho, kolik je na ni k dispozici času takto začínal článek v časopise Economist vydaném v roce 1955 a pro tuto větu se vžil název Parkinsonův zákon. Pan Cyril Northcote 9

17 Parkinson jednoduchými větami a bez přesných dat vystihuje jevy ve společnosti. Na důležitosti nabývá tato věta právě v souvislosti s projektovým řízením a koordinací prací. Pokud je zaměstnanci přidělena činnost, která má plánovou dobu trvání t, a zaměstnanec ji zvládne vykonat za dobu 2/3 t, využije zbývající 1/3 t pro jinou, často osobní činnost nebo pro odpočinek. Pravděpodobnost, že se takto zaměstnanec zachová, zvyšuje nevhodně navržený systém odměňování, ve kterém je například výše mzdy odvozená z počtu odpracovaných hodin. Někdy ovšem nemusí jít o cílené zneužití časové rezervy či úmyslné snížení výkonu pracovníka. Například pokud programátor ví, že má určitou činnost 5 dní, rozvrhne si svoji práci na 5 dní a v důsledku bude pracovat důkladněji a pečlivěji, než kdyby měl na stejnou činnost jen 4 dny. Napíše pečlivěji a srozumitelněji komentáře do zdrojového kódu či věnuje více času jednotkovým testům. Na obrázku 2.4 je znázorněn obvyklý průběh činnosti při působení Parkinsonova zákona. Obrázek 2.4: Průběh činnosti při působení Parkinsonova zákona. (Zdroj:autorka, překresleno z obrázku v textu [14], strana 32) 10

18 3 Vyčlenění problematiky I když historie znala projekty již z doby římského architekta Marcuse Vitruviuse Pollia, systematický nástup projektového řízení včetně výzkumů v této oblasti začal až v 50 letech minulého století. 90. léta minulého století byla ve znaku velkého nástupu projektů a projektové řízení je doposud považováno za důležitý nástroj, kterým snad jediným lze zvládnout turbulentní prostředí plné změn. Projekty provází víra, že jen v jejich pojetí lze flexibilně reagovat na požadavky trhu, zavádět nové technologie i reagovat na krizová období. Vždyť sám život je snadné vidět jako jeden velký projekt (dle článku [15]) a projektově lze pohlížet i na dovolenou, svatbu či nákup vánočních dárků. Bohužel projekty, především ty z oblasti IT, provází nepříjemné statistiky. Příkladem uvedu často citovanou statistiku Gartner Group z roku 1990, kdy pouze 12 % softwarových projektů splnilo svůj cíl v plánovaném čase, aniž by byl překročen plánovaný rozpočet. Další statistika, tentokrát od Standish Group, ukazuje jen malý pokrok v úspěšnosti projektů v rozmezí deseti let (viz příloha A). Faktorů neúspěchu projektů je mnoho od špatného plánování, nevhodného personálního obsazení, absence strategie projektu až po nezvládnutí řízení a komplexnosti projektu. Mnoho těchto faktorů pramení z nezvládnutí role projektového manažera, nedostatku znalostí a zkušeností člověka na této pozici. 3.1 Jeden projekt versus multiprojektové prostředí Velká část literatury, textů a článků se věnuje řízení jednoho projektu a veškerým aspektům s touto situací spojeným. Jeden projektový manažer má na starosti jeden projekt. Sestaví tým lidí, kteří budou projekt realizovat, vše pečlivě naplánuje a následně řídí. Při správné volbě metodiky a nástrojů by měl být projektový manažer schopen dovést projekt do zdárného konce. Velký podnik může mít více takových týmů a projektů, obvyklé je například rozdělení dle produktů. Produkt A realizuje tým A s projektovým manažerem A, produkt B realizuje tým B s projektovým manažerem B apod. Dokud jednotlivé projekty nesdílí společné zdroje, lze aplikovat obvyklé nástroje pro řízení projektů. Situace se začne komplikovat v případě sdílení zdrojů, zdrojem může být například databázový specialista, kterého v určité fázi potřebuje každý projekt v podniku. Projekty o jeho čas začnou soupeřit, vyhrává často ten projektový manažer, který je více slyšet. U ostatních projektů dochází ke zpoždění a problémům s překročením termínů a rozpočtu, standardní postupy uváděné v literatuře selhávají. Pro tento stav se zavádí pojem soustava projektů, označení multiprojektové prostředí, slovní spojení řízení ve velkém či program projektů a portfolio projektů. Nadále bude v této práci pro jednotnost použito označení multiprojektové prostředí. O soustavě projektů obecně mluvíme tehdy, když více projektů sdílí zdroje nebo více projektů sdílí tzv. globální produkty, nebo když více projektů sdílí vyšší cíl. [15] Program se sestává ze souboru přidružených projektů a požadovaných změn v organizaci, které jsou potřeba k tomu, aby bylo dosaženo strategického cíle a definovaných obchodních přínosů. 11

19 Portfolio lze definovat jako soubor projektů a programů, které nemusejí být nutně spojeny a které byly sloučeny z důvodu řízení, koordinace a optimalizace portfolia jako celku. [10] Na základě článků a literatury čtenář může čtenář získat pocit, že firmy realizují po většinu času jen jeden projekt a v malé míře více projektů. Opak je pravdou. Dle článku [16] již v roce 1995 naznačovaly indikátory, že více než 90 % všech projektů je realizováno v multiprojektovém prostředí. Pro malé a střední firmy je luxusem mít vyhrazené zdroje zvlášť pro každý projekt. Často tedy dochází k situaci, kdy jeden tým má na starosti více menších projektů pro různé zákazníky a dochází ve velké míře ke sdílení zdrojů. 3.2 Metafory pro pochopení multiprojektového prostředí Multiprojektové prostředí je velmi komplikovaný systém. Nové projekty přicházejí dynamicky, rozpracované projekty mohou být přerušeny, odloženy, zrušeny. Především v oblasti IT a vývoje software provází projekty změny v požadavcích zákazníka na software, dále změny technologií, prostředí (nové verze operačních systémů, internetových prohlížečů), až se často setkáváme s tvrzením, že jediné jisté na IT projektech je fakt, že přijde změna. Byznys prostředí vyvíjí nátlak na zrychlení vývoje, firmy již nechtějí čekat na vývoj informačního systému tři roky, ale žádají nasazení do šesti měsíců. Mnoho problémů řízení projektů v multiprojektovém prostředí pramení z nepochopení. Projektoví manažeři si neuvědomují komplikovanost celého systému a nedokážou se na problematiku multiprojektového prostředí podívat z nadhledu. Z nepochopení následně pramení i špatná volba či použití nástrojů a špatný přístup. Proto zde budou představeny metafory, přes které lze složitost multiprojektového prostředí pochopit. Pernille Eskerod ve svém článku Meaning and action in a multiproject environment [17] začala nejprve popisovat multiprojektové prostředí jako stavbu Velké čínské zdi, tak jak to odpovídalo chápání multiprojektového prostředí na konci 80. let minulého století. Obrázek 3.1: Metafora multiprojektového prostředí jako stavba Velké čínské zdi. (Zdroj:stock.xchng) 12

20 Rozličně velké kameny v této metafoře představují projekty. Kameník, přeneseně chápaný jako manažer projektu, kameny opracuje do správné čtvercové či obdélníkové podoby, tak, aby z nich mohla být vytvořena zeď. Zeď lze z kamenů sestavit jen za určitých pravidel kameny klademe postupně odspodu, nové pokládáme vedle nebo nad již uložené kameny. Pro vytvoření zdi je potřeba strategický plán s výhledem na několik let dopředu, aby byla zeď stavěna správným směrem ve správné výšce a tloušťce. Zde je potom analogie s potřebou strategického plánu pro portfolio projektů. Ze studie několika dánských podniků následně Pernille Eskerod odvozuje špatné předpoklady provázející tuto metaforu: projekty jsou vykonávány ve stabilním prostředí, úlohy jsou předvídatelné jak v obsahu, tak v délce trvání, projekty tvoří uzavřený systém proces rozhodování směřuje od nejvyššího vedení směrem dolů. Manažeři, kteří si multiprojektové prostředí představují pod metaforou Velké čínské zdi, plánují celou soustavu projektů najednou s jedním trojimperativem, plánem a v několikastupňovém řízení. V případě změn přeplánovávají všechny plány nebo se snaží jakýmkoliv změnám bránit (odsouhlasením analýzy požadavků a trváním na těchto požadavcích po celou dobu projektu apod.). Jak by tedy na multiprojektové prostředí mělo být nahlíženo? Pernille Eskerod dává odpověď pomocí jiné metafory, opět vycházející z čínské historie či spíše mytologie, a představuje metaforu Čínského draka. Obrázek 3.2: Metafora multiprojektového prostředí jako Čínský drak. (Zdroj: 13

21 Navazuje na myšlenku Kristian Kreinera, který samotný projekt popsal jako živoucí organismus, a konkretizuje ji. Svaly draka v této metafoře představují jednotlivé projekty. Umožňují drakovi pohyb celého těla a mění vztahy mezi sebou. Některé svaly jsou malé, některé velké. Mění svůj směr v krátkém čase, zkracují se a prodlužují. Drak, který představuje celé multiprojektové prostředí, se může hýbat kterýmkoliv směrem a je velmi nepředvídatelný. Možná napne svůj krk, možná se stočí do klubka či jen udělá úkrok stranou a v nejméně očekávaném okamžiku začne chrlit oheň. Vzápětí však může ustrnout a stát nehybně jako zeď a pouze očima sledovat situaci. Každý sval potřebuje ke své práci živiny, zde můžeme vidět analogii s potřebou zdrojů na projektech. I když tato metafora ještě nebyla dostatečně podrobena kritice a diskusi od projektových manažerů, domnívám se, že pochopení multiprojektové prostředí přes metaforu Čínského draka napomůže lepšímu řízení projektů v multiprojektovém prostředí. Jak zapadá souboj projektů do metafory Čínského draka? Pernille Eskerod se ve svém článku [17] zabývá také konceptem souboje projektů. Z interview dánských podniků vyplynulo, že projekty mezi sebou ve firmě soupeří o zdroje, prioritu, pozornost vedení. Tato bitva je přitom vedením podporována, neboť je považováno za přínosné nechat slabé projekty padnout a ty silné s ostrými lokty zvítězit. Důsledkem ale je, že jednotlivé týmy a pracovníci mezi sebou nesdílí informace a například opakují stejné chyby. Pokud si promítneme soupeření do metafory Čínského draka, nezapadá sem. Kdyby svaly draka bez rozmyslu sváděly bitvu o živiny, omezilo by to jeho pohyb. Některé málo používané svaly by zakrněly a jiné svaly by zmohutněly a z draka by se mohl stát obyčejný slepýš. Naopak, pokud je zvažována priorita projektů v daném čase a živiny jsou přidělovány v závislosti na tom, co potřebuje celý drak například k pohybu kupředu, teprve potom k danému pohybu opravdu dojde. 3.3 Problém převahy tvůrčí činnosti v oblasti vývoje software Vývoj software je především o tvůrčí a kreativní práci. Tato stěžejní vlastnost odlišuje projekty zaměřené na vývoj aplikací a informačních systémů od stavby domu či zprovoznění nové pobočky nebo přidělení úvěru v bance. Petr Paleta ve své knize [4] uvádí i příčinu této převahy: ve vývoji software nezbývá žádné místo pro mechanické činnosti, neboť jakoukoliv automatizovanou činnost provádí počítač. Za oblasti podobné vývoji software označil Petr Paleta jen aplikovaný výzkum, projektování (automobilu, mrakodrapu) a filmový průmysl. Není tedy možné na řízení IT projektů uplatňovat stejné postupy, jak ve stavebnictví či bankovnictví. Převahu tvůrčí činnosti totiž doprovází následující problémy: Bývá obtížné odhadnout dobu trvání činnosti. Není snadné kontrolovat výkon pracovníků. Zvýšená aktivita, přesčasy ani práce pod tlakem nevedou ke zvýšení produktivity či urychlení práce. Produktivita programátorů a IT pracovníků v jednom týmu se může výrazně lišit (až 1:10), velmi záleží na typu projektu, konkrétním úkolu i zkušenostech jedince. Protože se jedná o tvůrčí práci, hraje zde roli i talent na řešení problémů, pochopení zákazníka a nalezení kreativních řešení. Na pro- 14

22 gramátory neplatí sankce (například pokud dnes do 16:00 nevyřešíš ten problém, nedostaneš prémie ), naopak ve stresu se nedokážou plně soustředit na řešení daného problému. Specifika programátorské profese Petr Paleta ve své knize [4] popisuje vlastnosti typické pro programátory. Nemají rádi administrativní úkony, vyplňování papírů a formulářů. Preferují kreativní práci před rutinou, kterou pro ně představují pracovní výkazy, nudné porady, formální oblečení. Rádi řeší problémy, hříčky, hlavolamy a někdy nedokážou přestat, dokud daný problém nevyřeší. Pokud je však řešení nad jejich síly, začnou po nějaké době problém odkládat a práci na něm oddalovat. Vývoj software je často vývoj řešení určitého problému zákazníka. On vyžaduje informační systém, protože potřebuje vyřešit problém s velkými náklady na papírování. Vyžaduje aplikaci, která dá jeho produktům nový rozměr (například software ovládající frézu v kombinaci s 3D modelovacím nástroje dá nový rozměr sochařství a sochařským dílům). Jiný zákazník v nové webové aplikaci spatřuje nástroj pro přilákání zákazníků ke svým výrobkům. Určitě bychom našli mnoho dalších příkladů. Tak jako u filmového průmyslu vyžaduje tvorba filmu neustálou komunikaci mezi režisérem, kameramany, scénáristou, produkčním i samotnými herci, tak vývoj software vyžaduje častou komunikaci vývojového týmu se zákazníkem. Zákazník upřesňuje svoji představu řešení pomocí požadavků a je třeba, aby obě strany chápaly tyto požadavky stejně. 3.4 Modelové příklady firem Pro konkretizaci výše popsaného multiprojektového prostředí s aspektem převažující tvůrčí činnosti uvádím ve stručnosti šest modelových příkladů firem z různých odvětví. Středisko pro tvorbu multimediálních výukových pomůcek v univerzitním prostředí Tým osmi lidí je financován díky projektu z evropských dotačních fondů. Cílem projektu je vytvoření určitého množství multimediálních výukových pomůcek, každá pro inovaci jiného předmětu. Pracovníci, říkejme jim multimediální technici, jednají se zákazníky učiteli a snaží se naplnit jejich představy výukových pomůcek. Protože každá fakulta univerzitního prostředí je jiná, vznikají webové publikace, animace, videa, interaktivní tutoriály, slovníky i aplikace, pomůcky a nástroje. Požadavky na multimediální pomůcky přicházejí nepravidelně a rozsah prací se výrazně liší (interaktivní slovník o pojmech versus desetistránková publikace s malým slovníkem o třiceti pojmech). Vyučující reagují na dotazy a upřesnění se zpožděním, 10 % výukových pomůcek není kvůli nezájmu vyučujícího dokončeno. Délka trvání vývoje jednotlivých multimediálních výukových pomůcek se liší od intervalu dvou dnů po dobu vývoje v délce jednoho roku. Na tvorbě jedné multimediální pomůcky se podílí více pracovníků. Změna v termínech dodání, v obsahu a rozsahu i v počtu jednotlivých pomůcek zpracovávaných v jednom čase je častá. Vývojový tým outsourcovaného informačního systému Informační systém je provozován v několika firmách způsobem outsourcingu. Pokrývá potřeby více subjektů a na základě požadavků uživatelů je neustále vylepšován a doplňován. Ve vývojovém týmu má každý programátor na starosti několik agend systému, z nichž některé nově vytváří a některé jen opravuje a vylepšuje. Každé zpracování či přepracování nové agendy je považováno za projekt. Opravy jsou řešeny v samostatném projektu. Termíny vytvoření nových agend a vylepšení stávají- 15

23 cích jsou stanoveny jen interně a nemusí být striktně dodrženy. Naopak opravy je třeba řešit ihned a v co nejkratším možném čase. Požadavky na vylepšení jednotlivých agend přicházejí nepravidelně, rozsah prací se výrazně liší. Firma zajišťující tvorbu webů, drobných aplikací a internetových reklamních řešení Firma o 15 zaměstnancích se zaměřuje na následující služby: návrh a tvorba webových prezentací a obchodů, webové aplikace podle přání zákazníka, komplexní řešení reklamy a SEO služeb na internetu, databázová řešení. Zakázky přicházejí nepravidelně a v různém rozsahu, cena a termín dokončení se stanovují pro každou zakázku individuálně. Je potřeba pravidelně komunikovat se zákazníkem o jeho požadavcích, představách. Na zakázkách často pracuje více pracovníků v týmu. Menší společnost zabývající se vývojem počítačových her Velké herní společnosti si mohou dovolit vyčlenit pro každý nový herní titul samostatný tým čítající scénáristu, programátory, grafiky, modeláře a testery. Menší společnost, která zpracovává menší a levnější hry, může mít k dispozici vývojový tým o jednom scénáristovi, třech programátorech, jednom testerovi a dvou graficích. Vytváří tzv. design dokumenty (hlavní herní dokumenty) a žádá vydavatelské společnosti o financování vývoje. Paralelně je vytvářeno několik her, u kterých si vydavatelská společnost udává termíny, aby mohla hru včas propagovat a reklamovat. Po vydání hry ještě v některých případech probíhají opravy a vydávání záplat, tedy tzv. patches. Animátorské studio Tým 2D i 3D grafiků, modelářů, animátorů a programátorů zpracovává převážně animace, reklamní práce a vizualizace, vše formou projektů. Projekty jsou velmi rozmanité: od zpracování herní intro animace, televizní reklamy, triků a filmových efektů pro filmový průmysl, videoklipů, 3D technologických simulací či vizualizací budov po animované webové struktury i online hry a aplikace. Firma je řízena projektově a na jednom projektu se podílí více pracovníků. Velmi často dochází ke sdílení zdrojů na projektech a pro firmu je důležité dodržení daných termínů. Častá komunikace se zákazníkem je nutná, neboť je třeba projednávat jeho představu a požadavky, změny jsou na denním pořádku. Firma zajišťující propojení svého informačního systému na aplikace zákazníka Firma vyvíjí informační systém a ve svých projektech se zabývá nasazením a upravením systému pro zákazníka. Součástí nasazení je především napojení na stávající systémy zákazníka (účetní, prodejní i rezervační systémy). Tým pracovníků zpracovává jednotlivé zakázky projektově, zdroje jsou sdíleny. 16

24 4 Kontrola výkonu pracovníků Ve vývoji software převažuje tvůrčí činnost, proto na rozdíl od činností typu přidělení úvěru klientovi v bance či opracování šesti kovových matic nelze jednoduše kontrolovat výkon. Průměrná doba přidělení úvěru lze změřit, postup lze sepsat do jednotlivých kroků, postup mechanika v opracovávání matic lze vidět v reálném čase a opět pomocí vhodných metrik číselně vyjádřit a pracovníky porovnávat. Tvůrčí činnost však tak jednoduše metrikám nepodléhá. Programátor, který se s nohama na stole jen dívá na obrazovku se zdrojovým kódem, může být výkonnější než jeho kolega, který neustále píše a přepisuje stovky řádků zdrojového kódu. Ten první totiž problém analyzuje, přemýšlí o něm a následně napíše 3 řádky, které jej elegantně vyřeší. Druhý programátor psaním bez rozmyslu jen marní čas a většinu doby opravuje chyby, překlepy a výsledek se nedostavuje žádný. V prostředí plném tvůrčího myšlení je tedy obtížné kontrolovat výkon pracovníků. Předpokládám, že pochopením a rozpoznáním problémů, které výkony pracovníků ovlivňují, dokáže koordinátor připravit prostředí plně podporující výkon pracovníků. Systematickou a vhodnou kontrolou pracovníků odliší ty pracovníky, kteří opravdu pracují, od těch, kteří se jen vymlouvají a s koordinátorem manipulují. Užitím vhodných nástrojů a technik eliminuje negativní faktory, které na výkon působí. 4.1 Výkon Pracovní výkon je výsledek pracovní činnosti vykonané v určitém čase za určitých podmínek (definice dle [18]). Protože výkony pracovníka se značně liší podle jeho nálady, zdravotního stavu, vlivů okolí, sleduje se často výkonnost pracovníka. Výkonnost je schopnost jedince vykonávat určitou pohybovou, intelektuální či kombinovanou činnost (učení, sport, práce), hodnocenou jejím množstvím (rychlost v čase), přesností (množství chyb) a mírou únavy. [18] V rámci této práce se zaměřuji především na kontrolu jednotlivých výkonů pracovníků, aneb jak může koordinátor poznat, že pracovníci opravdu pracují a nevymlouvají se jen na složitost úkolu. Dále objasňuji vliv multitaskingu na výkonnost pracovníku i vliv tzv. prokrastinace a na konci kapitoly je popsáno řešení dílčích problémů a postup systematické kontroly výkonu pracovníků. 4.2 Identifikované problémy ovlivňující výkony pracovníků Studiem odborné literatury a získanými zkušenostmi během praxe s koordinací týmu pracovníků jsem identifikovala několik opakujících se problémů, které ovlivňují výkon pracovníků, především v oblasti IT, kde je často třeba plné soustředění na zvládnutí (programování) náročného zadání Multitasking Vliv multitaskingu na délku trvání činností je již popsán v kapitole 2.6. Vliv na výkonnost pracovníka souvisí především se změnou kontextu. Čas potřebný pro změnu kontextu, byť je krátký, může ve svém důsledku způsobit nejen zpoždění projektu, ale při časté změně kontextu pracovník spotřebuje více úsilí a narůstá možnost, že udělá chybu (podle článku [11]). Může dojít i k situaci, kdy je čas potřebný pro neustále změny kontextu v součtu větší než čas na samotnou práci. Potom výkonnost 17

25 pracovníka prudce klesá a tento stav bývá označován jako thrashing (v obdobném smyslu je užíván i pro stav při přepínání mezi procesy v operačním systému). Multitasking v omezené a kontrolované míře může výkonnost pracovníka zvýšit, neboť mu poskytuje změnu, mírné nadšení z přerušení rutiny, monotónnosti práce. Jakmile je však překročená určitá mez, jedinečná a vlastní každému pracovníkovi, působí na něj multitasking jako stresový faktor (dochází k vyplavování stresových hormonů a zhoršení krátkodobé paměti). Dle [19] se práce pracovníka zpomaluje, neboť mozek vydává příliš mnoho energie na rozhodnutí, čemu se věnovat Vyrušování Určitou formou multitaskingu je obyčejné vyrušení. Například v kanceláři zazvoní telefon či přijde e- mail s nadpisem urgentní. Nejen, že pracovník přeruší svoji práci a dojde ke změně kontextu, problematický je i návrat k původní činnosti. Dle zdroje [20] trvá průměrně 25 minut, než je pracovník schopen se opět plně soustředit na původní práci a vykonávat ji rychle a efektivně jako před přerušením. Přerušení činnosti a přepínání kontextu si může pracovník způsobovat sám špatným osobním tzv. time managementem, tedy neefektivním využíváním pracovního i osobního času. Například když při práci (programování účetního modulu) diskutuje s kolegy o jejich problému přes ICQ, sleduje, co je nového na programátorských diskusních fórech, a přitom ještě tiskne podklady schůzky. Mnoho koordinátorů již ale nenapadne, jak často své pracovníky přerušují oni sami. Pokud má pracovník za povinnost okamžitě reagovat na každý příchozí pro případ, že by byl důležitý, potom každý způsobuje přerušení a změnu kontextu. Pracovník si jej musí přečíst, pochopit, věnovat mu pozornost, aby zjistil, zda jej má řešit ihned nebo jej může odložit a vrátit se zpět ke své práci. Stejně tak telefonáty a očekávání či nařízení, že se pracovník bude věnovat každému, kdo přijde do jeho kanceláře. Navíc mnoho požadavků koordinátorů či manažerů je nepodstatných. Statistika chybovosti v programech za poslední 2 roky, doplnění pracovního výkazu či oprava chyb v případové studii ve většině případů není třeba vyřešit do 10 minut od zadání úkolu, tak jak od manažera bývá vyžadováno Problém Skoro hotovo Prvních 90 % úkolu potřebuje 90 % času a posledních 10 % úkolu potřebuje dalších 90 % času. (z Murphyho zákonů, [21]) Murphyho zákon uvozuje další identifikovaný problém. V týmu se mohou objevit pracovníci s jednou z následujících dvou vlastností: Pracovník nedokáže dobře odhadnout dobu trvání úkolu a především, kolik zbývá času k jeho dokončení. Při každém dotazu na postup na úkolu tvrdí, že je skoro či téměř hotov, i když reálně může být teprve v polovině zpracování úkolu. Pracovník již zpracoval velkou a významnou část úkolu, například již naprogramoval a otestoval modul a zbývá jen napsat dokumentaci či více rozvést komentáře v kódu. Přestože se již z pohledu koordinátora jedná o krátkou činnost a pracovník to potvrzuje označením práce už je skoro hotová, plynou dny a úkol stále není odevzdán. Pracovník se vymlouvá, dokonce může tvrdit, že je přetížen jinými úkoly, přitom se jedná o prokrastinaci (viz níže). Je velmi obtížné koordinovat tyto pracovníky, neboť při každém dotazu na postup na činnosti je koordinátor uklidněn stavem skoro hotovo případně odhadnutím času bude to ještě dnes. 18

26 4.2.4 Prokrastinace Prokrastinace je výrazná a chronická tendence odkládat plnění povinností a úkolů (zejména těch nepříjemných) na pozdější dobu. [3] Prokrastinace (v anglicky mluvících zemích je známá pod označením LOBO Lifestyle of Bad Organisation) byla jako fenomén označena v 60. letech minulého století a následně na ni proběhla a probíhá řada výzkumů, především s důrazem na vysokoškolské prostředí a prokrastinaci studentů. To ale neznamená, že by s obdržením diplomu u budoucích pracovníků prokrastinace vymizela. Naopak, může se stát jedním z faktorů nižší výkonnosti pracovníka. Koordinátor u pracovníka nemusí prokrastinaci rozpoznat, neboť prokrastinace neznamená nedělat vůbec nic. Naopak prokrastinující pracovníci jsou velmi činorodí, aktivní a tvořiví, vše na úkor úkolů, které je potřeba, aby udělali. Tudíž jejich výkonnost a opravdový přínos pro firmu je malý. Mezi hlavní psychologické příčiny studie a knihy ([22], [23], [24]) uvádějí: strach z neúspěchu, strach z úspěchu (protože úspěch vede k dalšímu úkolu a to i k úkolu ještě náročnějšímu), strach z neznáma, podceňování se, strach z hodnocení. Jako spouštěcí faktory prokrastinace rozpoznané na jednotlivých úkolech bývají zmiňovány tyto vlastnosti úkolů: úkol vyžaduje od pracovníka velkou míru abstraktního myšlení, není stanovena priorita jednotlivých úkolů, velký a náročný úkol je zadán jen v obrysech, u úkolu není zřejmé, jak začít, pracovník nemá dostatek informací ke zdárnému vyřešení úkolu, úkol není pro pracovníka zajímavý. K prokrastinaci jsou náchylnější pracovníci, kteří pracují z domu a ve větší míře si organizují svůj čas sami a dále pracovníci, jež mají dánu větší volnost ve výběru pracovních úkolů a činností a na něž není vyvíjen nátlak na co nejrychlejší vyřešení úkolů. Facebook a webové hry Komunikace s přáteli přes sociální síť Facebook a hraní webových her může být jednou z možností, jak pracovník tráví svůj čas ve snaze odkládat nepříjemný úkol. Nepoučený manažer může reagovat například prostým zákazem navštěvování sociálních sítí v pracovní době. Řeší tak ovšem jen příznaky problému a ne příčiny. Pokud nedojde k řešení problému prokrastinace, ať již pohovorem s pracovníkem, změnou systému přidělování úkolů či obdobně, pracovník si najde jinou činnost, například přerovnávání a ořezávání tužek, úklid kanceláře, přesazování květin apod. Bohužel neexistuje univerzální řešení pro překonání prokrastinace, neboť odkládání činností má pro každého pracovníka v pozadí jiné příčiny. 19

27 4.3 Navržené techniky řešení jednotlivých problémů Navržené techniky jsou ve své podstatě drobnými, snadno zapamatovatelnými tipy, jejichž síla je v jejich jednoduchosti. Vhodnou kombinací několika technik lze významně snížit riziko nízké výkonnosti pracovníků. Rozdělení technik dle problému, na jehož řešení jsou zacílené: Multitasking: ToDo list a omezení WIP Vyrušování: Prověrka firemních pravidel, Týdenní úkoly Problém Skoro hotovo : Správná otázka Prokrastinace: SMART metoda, Hledání nejbližšího kroku, Pět minut, Polykání žab ToDo list a omezení WIP Po popisu a pochopení problémů multitaskingu, jak z pohledu délky trvání činnost, tak i vlivu na výkonnost, se nabízí jediné řešení: eliminace multitaskingu. Pracovník se musí zaměřit v jednom okamžiku jen na jednu činnost a zároveň nepřecházet v průběhu času na jinou, dokud není daná činnost dokončena. Aby nemusel myslet na všechny další činnosti, které jej čekají, a pomatovat si je, sestavuje si (nebo je mu vybranou metodikou koordinace sestaven) tzv. ToDo list. Jedná se o uspořádaný seznam všech zadaných činností řazený dle priority či logické návaznosti. Vnější podmínky si v některých případech vyžádají přerušení právě prováděné činnosti (čekání na odezvu zákazníka, podklady nebyly doručeny včas, objevil se problém, který vyřeší pouze kolega po návratu z dovolené apod.) a pracovník začne pracovat na činnosti jiné. V případě nárůstu množství tzv. WIP činností (zkratka z anglického Work in Progress), tedy činností, které již byly započaty, ale ještě nedokončeny, se pracovník po vymizení vnější podmínek přerušení opět dostává do problému multitaskingu. Některé metodiky tedy doporučují stanovit jasné maximální omezení WIP činnosti například na 2, 3 nebo 4 na jednoho pracovníka Prověrka firemních pravidel Prověrka firemních pravidel jedno po druhém může pomoci vyřešit problém vyrušování. Kriticky může pravidla zhodnotit koordinátor sám, nejlépe však dojde k identifikaci problematických míst konzultací v týmu. Při hodnocení je třeba vzít v potaz i nepsaná pravidla, kterými se pracovníci řídí, často ze strachu. Pokud jednou byl jeden pracovník pokárán za to, že nezareagoval na důležitý do 20 minut, potom se celý tým může řídit pravidlem odpověz na každý do 20 minut, jinak bude zle a toto pravidlo není nikde explicitně sepsáno. Zjistit jej lze pouze vhodným dotazováním se pracovníků. I jednoduchým dotazem: Co vás často vyrušuje při práci? lze bez návaznosti na firemní pravidla identifikovat problémy. Celá prověrka firemních pravidel a jejich následná změna je o kompromisech. Opravdu je nutné, aby pracovník musel číst poštu či být na telefonu plně 8 hodin své pracovní doby? Nebo stačí, aby se vyřešení pošty či alespoň přečtení věnoval 1 hodinu ráno, 1 hodinu po obědové přestávce a 30 minut před odchodem domů? Zvážit lze i formu pracovní doby, zákoník práce (Zákon č. 262/2006 Sb. [25]) v České republice umožňuje tzv. pružné rozvržení pracovní doby (část IV., hlava II: Rozvržení pracovní doby, Díl 3), ve kterém si pracovník sám volí začátek, případně i konec pracovní doby v jednotlivých dnech. Zaměstnavatel pouze určí časový úsek, ve kterém je zaměstnanec povinen být na pracovišti, tzv. základní pracovní doba. Potom lze například vymezit dobu 12:00 15:00 jako základní pracovní dobu a umožnit pracovníkům, aby si pracovní dobu lépe přizpůsobili svému chronotypu (dle chronobiologie, vědní disciplíny zkoumající biologické rytmy živých organismů [3]). Tzv. ranní ptáčata budou 20

28 v době své nejvyšší bdělosti a výkonnosti, třeba v 7 hodin ráno, efektivně řešit programování náročného modulu a spokojeně v 15:00 odejdou domů, zatímco tzv. noční sovy přijdou na pracoviště v 11 hodin čilí, bdělí, dobře vyspaní a v plném pracovním nasazení, odcházet budou až za soumraku Týdenní úkoly Koordinátor sám může vyrušovat pracovníky od soustředěné práce drobnými úkoly, žádostmi a požadavky, často administrativního charakteru. Příkladem mohou být: oprava chyby v pracovním výkazu, podpis pracovního výkazu za minulý měsíc, vyplnění plánu dovolené, sepsání případové studie zakázky či statistika počtu zakázek za poslední dva roky. Přitom při podrobnější analýze koordinátor zjistí, že pouze malé procento těchto žádostí je opravdu třeba vyřešit ihned nebo do druhého dne, pro zbytek žádostí je dostačujícím termínem týden či dva. Týdenní úkoly jsou jednoduchá metoda, založená na odkladu administrativních a drobných požadavků. V momentě, kdy koordinátor identifikuje administrativní požadavek, rozmyslí si, zda je opravdu nutné, aby jej pracovník vykonal ihned. Pokud ne, napíše si tento požadavek bokem (do souboru, na papír). Všechny požadavky, které se za týden nashromáždí, zasílá pracovníkovi najednou v domluvený den a žádá vyřešení do týdne od zadání. Pracovník si tyto administrativní úkoly začlení do svého pracovního plánu na nejvhodnější dobu místo toho, aby jej vyrušovaly od soustředěné práce v průběhu týdne. Metoda může být libovolně obměňována, například může koordinátor žádat vyřešení zaslaných úkolů do druhého dne, či zasílat tyto administrativní úkoly dvakrát do týdne. Podstatou je, že pracovník dostane několik drobných rušivých úkolů pravidelně v předem domluvený čas a s určeným termínem, do kdy je má vyřešit. Potom zbude jen několik málo úkolů, které koordinátor vyhodnotí jako opravdu důležité a s nutností expresního vyřešení a tím pádem i vyrušení pracovníka od soustředěné práce se všemi důsledky, které přináší Správná otázka Jednou z možností reakce na problém skoro hotovo je pokládání správných otázek. Není vhodné se ptát Kdy budeš hotov?, neboť jako odpověď se nabízí Zítra., Brzy., V pět odpoledne. a po uplynutí termínu následuje množství výmluv, proč se úkol nepodařilo dokončit a stanovení nového nesmyslného termínu. Bohužel, mnohdy nepomáhají ani restrikce a tresty v podobě snížení odměn. Pracovník se nenaučí dobu dokončení lépe odhadovat, nýbrž vždy řekne co nejdelší možný časový úsek, který mu poslouží jako obrana před odebráním odměny. Správnou otázkou v této technice je dotaz na počátek a nejbližší hmatatelný průběžný výsledek. Problémem pracovníka totiž může být nikoliv dokončení činnosti, ale její zahájení (dle [23]). Kdy pošleš první hrubý náčrt?, Kdy nahraješ do systému počáteční návrh grafického rozhraní?, Kdy uvidím první jednotkový test?, Kdy začneš psát dokumentaci? to vše jsou správné otázky SMART metoda Jedním ze spouštěcích faktorů prokrastinace je špatné zadání úkolu (je zadán jen v obrysech, není zřejmé, jak začít, chybí informace ke zdárnému vyřešení), proto by koordinátor neměl zadávání úkolů podceňovat. Úkol by měl mít jasně a srozumitelně formulované zadání, stanovené priority a požadavky. Neškodí si o zadání několikrát v průběhu realizace s pracovníkem pohovořit, neboť čím více nejasné zadání, nesmyslný cíl a protichůdné priority, tím intenzivnější prokrastinace může dle [23] nastat. SMART metoda je mnemotechnická pomůcka pro koordinátory a manažery. Ve slově SMART jsou první písmena vlastností, které by mělo mít každé zadání úkolu (viz tabulka 4.1). 21

29 S Specific konkrétní M Measurable měřitelný A Attainable dosažitelný R Relevant odpovídající T Time-bound ohraničený v čase Tabulka 4.1: Význam písmen metody SMART dle [3]. V různých textech nepanuje shoda na názvech vlastností a často se objevují další návrhy (například Realistic, Motivational, Action-oriented apod.). Stejně tak výklad vlastností se liší. Neubírá to ovšem na efektu metody, neboť díky ní si koordinátor problém zadávání úkolů uvědomuje a snaží se jej řešit. Někdy bývá doporučováno zadávat úlohy spíše jako tzv. deliverables. Popsat, co má být výsledkem a zkonkretizovat cíle místo popisu, co se má udělat Hledání nejbližšího kroku David Allen, autor knihy Getting Things Done, poprvé představil tuto jednoduchou pomůcku. Pokud manažer či koordinátor rozpozná u pracovníka prokrastinaci a zjistí, že důvodem je příliš náročný úkol, měl by se ptát: Co je nejbližší činnost, která tě posune o krok dále k vyřešení úkolu? U příliš náročných úkolů popadají pracovníka pocity strachu, nejistoty, neví, odkud začít, jak se pustit do řešení. I když se to může zdát zvláštní, mnoho pracovníků si neumí rozdělit velký úkol do malých jednoduchých úkonů, které mu umožní postupné přibližování se k cíli. Koordinátor by měl v této chvíli být především koučem. Cílem této techniky není říct pracovníkovi, co má v následující hodině přesně udělat, ale naučit jej, aby na to přišel sám. Je to pracovník, kdo by měl úkol analyzovat a zamyslet se. I když je koordinátorovi jasné, že nejbližším vhodným krokem úkolu může být například rešerše a dohledání, jaké nástroje je možné využít, musí to být pracovník, kdo tento krok vysloví. Koordinátor pouze pokládá vhodné otázky, podněcuje, motivuje a směřuje pracovníka správným směrem Pět minut Technika Pět minut patří do rodiny tzv. Timeboxing metod plánování času (osobního i při plánování projektů). Základem v osobním plánování času je natočit si kuchyňskou minutku či alternativní softwarovou pomůcku na pět minut času a těchto pět minut věnovat neoblíbené či náročné činnosti. Buď se člověk do činnosti natolik ponoří, že po zazvonění minutky dále pokračuje a činnost dokončí, nebo po pěti minutách přestane, ale s pocitem, že se opět přiblížil dokončení nepříjemné činnosti. Stejný princip může uplatňovat koordinátor při vedení pracovníků. V případě náročných a nepříjemných úkolů požádá pracovníka, aby činnosti věnoval jen krátký časový úsek. Protože se jedná o manipulativní techniku, která díky představě krátkého a malého úseku překonává nechuť a obavy z velkého úkolu, v mnoha případech pracovníka činnost pohltí natolik, že ji úspěšně dokončí Polykání žab Každé ráno snězte žábu. Nic horšího už vás ten den nepotká (Mark Twain) Metafory, citáty a aforismy jsou velmi vhodnou pomůckou pro zapamatování a osvojení pravidel. Technika polykání žab založená na citátu Marka Twaina v sobě obsahuje jediné poselství: vyberte si každý den ten nejhorší a nejtěžší úkol či činnost a vykonejte jej jako první. 22

30 Není třeba striktně dodržovat interval jednoho dne. Koordinátor může například v případě metodiky Scrum (kapitola 6.3) vyžadovat, aby pracovníci vždy v každém cyklu (1 až 4 týdny) začínali nejtěžším úkolem. Nejen, že tak včas zjistí případné překážky, problémy a obtíže, ale všechny další úkoly a činnosti se jim budou mnohem lépe zpracovávat, neboť již před nimi nebude těžký úkol jako stresový faktor. 4.4 Systematická kontrola výkonu Systematicky lze kontrolovat výkon pomocí dvou na sobě závislých kroků: 1. Úkoly rozložit na krátké činnosti či úkony. 2. Zavést krátké denní schůzky. Krok 1: Úkoly rozložit na krátké činnosti či úkony. Koordinátor, který již zkoušel sledovat postup na projektu pomocí procentuálního vyjádření, velmi brzy zjistil, že je zavádějící. Pracovník odhaduje postup v programování náročného modulu po týdnu na 10 % a druhý den předá celý modul hotový. Na druhé straně se objevuje problém skoro hotovo a Murphyho posledních 10 % úkolu potřebuje 90 % času. Některé metodiky a články doporučují rozdělit úkoly na malé části, u kterých lze jednoznačně říct, zda jsou hotovy či ne. Potom postup na projektu lze vyjádřit odškrtáváním jednotlivých malých částí. Krok 2: Zavést krátké denní schůzky. Metodika Scrum zavádí tzv. denní schůzky (v termínech metodiky je denní schůzka označovaná jako Stand-up meeting či The Daily Scrum Meeting). Každý den ve stejnou dobu se sejdou všichni členové týmu. Schůzka probíhá vestoje a neměla by být delší nežli 15 minut (přiměřeně počtu pracovníků). Koordinátor každému pracovníkovi postupně klade tři dotazy: Co jsi udělal od minulé schůzky? Co budeš dělat do další schůzky? Blokuje Tě něco v práci? (problémy, potíže, překážky) Problém a překážky by měly být stručně sděleny, prostoru na jejich řešení je dostatek po schůzce. Důvěra, přátelské prostředí a otevřenost jsou základní principy pro to, aby se pracovníci nebáli s problémy ihned svěřit. Právě včasné upozornění na potíže by mělo být oceňováno a zapírání a mlžení ohledně problémů by mělo být postihováno. Pro prolomení napětí a uvolnění atmosféry se doporučuje začít schůzku vtipem či krátkou historkou. Koordinátor jako moderátor schůzek je musí udržovat krátké, věcné a vhodně a jemně zakročit, pokud pracovník odbočuje od dotazů a příliš zabíhá do podrobností. Jakmile všichni pracovníci domluví, nastává prostor pro řešení problémů, rady. Toho už se mohou účastnit třeba jen někteří pracovníci a ostatní se v klidu věnovat své práci. Rozdělení úkolů na jednotlivé malé úkony umožňuje získat opravdové informace o postupu. Bez něj by pracovník mohl měsíc na každé schůzce jen opakovat včera jsem pracoval na elektronické publikaci Optika, zítra budu pracovat na elektronické publikaci Optika a ze schůzek by se staly zbytečné, nudné povinnosti, které pracovníky jen zatěžují. Malé úkony o dvou stavech hotovo/nehotovo mohou být prezentovány pouze jako hotové nebo nehotové a žádná možnost mezi tím není přípustná. Pokud pracovník nedokončil žádný úkon či činnost, měl by být schopen říct, co vlastně dělal. Například neúspěšně vyzkoušel tři způsoby provedení cyklu v programu či několik hodin hledal chybu v databázovém příkladu. V případě dokončení úkolu může být vhodné, aby pracovník program, aplikaci nebo animaci po skončení schůzky koordinátorovi předvedl a ukázal. 23

31 Psychologické aspekty denních schůzek Pravidelná kontrola postupu je nutná, české přísloví důvěřuj, ale prověřuj má na paměti každý koordinátor, který již prožil zklamání ze zneužití důvěry v pracovníka. Důležitá je forma kontroly. Pokud koordinátor doslova vpadne do kanceláře pracovníka a v minutě chce slyšet a vidět, na čem pracovník právě pracuje, právem se pracovník cítí dotčen, vnímá akt kontroly jako velký projev nedůvěry. Naopak pravidelný (a opravdový) zájem koordinátora o práci pracovníků na předem domluvené schůzce je vnímán pozitivně. Pracovníci, především extroverti, se rádi pochlubí svou prací a výsledky, potěší je pochvala a uznání kolegů i koordinátora (dle [4]). Složitou situací se stává případ, kdy se pracovník celý den snažil vyřešit složitý problém a nebyl úspěšný. Přiznání neúspěchu před kolegy vyvolává stres a nepříjemné pocity a je na kvalitách a schopnostech koordinátora, aby pracovníka nezesměšnil, ale naopak povzbudil a motivoval k intenzivní práci na vyřešení problému. Pracovník introvert je také ovlivněn svým strachem ze setkání s lidmi, z prezentace své práce před ostatními. Je na zvážení koordinátora, zda je pracovník s povahou introverta tím pravým pro projekty vyžadující týmovou práci. Autor textu [2] uvádí, že vývojáři denní schůzky odmítají a považují je za ztrátu času, neboť jsou spolu celý den v kanceláři, o problémech si řeknou a postup svých kolegů vnímají. Denní schůzky mají opravdu největší význam pro koordinátora a takto by měly být prezentovány. Kontrola a zvýšení výkonu Ačkoliv se zdají být denní schůzky spíše nástrojem sledování postupu na projektu, s výkonem pracovníků úzce souvisí. Pravidelnost a krátký časový interval mezi schůzkami nutí pracovníka věnovat se opravdu své práci a úkolům, kterým má, neboť by jinak neměl co nahlásit na schůzce. Vyhýbá se multitaskingu, neboť pokud šest činností jen začal, ale žádnou z nich nedokončil, nebude mít co prezentovat. Odpadají výmluvy, neboť je nemožné vymýšlet na každý den jinou uvěřitelnou výmluvu, proč není úkon, úkol či činnost hotová. Některé webové stránky či manažeři v diskusích a blozích uvádějí, že pracovníci jsou více motivováni k práci a k vysokým výkonům jen faktem, že se o jejich práci někdo (manažer, koordinátor, kolegové) opravdově a pravidelně zajímá. Toto tvrzení o zvýšení výkonu však zatím není podloženo výzkumem. 24

32 5. Plánování a odhadování času Následující kapitola představuje jednotlivé plány projektu s hlavním důrazem na časový plán, odhady doby trvání činnosti a dodržování stanovených termínů. 5.1 Plány projektu Pokud má projektový manažer realizovat projekt, musí si nejprve dle článku Řízení projektů pana dr. Zdenko Staníčka [15] zodpovědět na správě položené otázky : CO se má udělat? JAK to udělat? S KÝM to udělat? KDY se to udělá? ZA KOLIK se to udělá? [15] Jako odpověď na otázku vznikne jeden plán projektu: plán CO, plán JAK, plán S KÝM, plán KDY, plán ZA KOLIK. Dle plánovací strategie pana dr. Zdenko Staníčka mají plány vznikat postupně a ve stanoveném pořadí. Pokud projektový manažer začne plánovat projekt a rovnou vytváří komplexní Ganttův diagram, nejen, že se mu takový diagram velmi těžko tvoří, ale navíc je velká pravděpodobnost, že v plánu budou opomenuty důležité činnosti či návaznosti. Ganttův diagram je druh diagramu, používá se v oblasti projektového řízení pro grafické znázornění posloupnosti činností v čase. Činnosti dle WBS (viz kapitola 2.3) jsou seřazeny pod sebou a jsou znázorněny jako obdélníky, šířka určuje dobu trvání činnosti, časté je konkrétní časové usazení plánu, tedy na horizontální ose mohou být reálná časová data a měsíce. Rozšířená verze obsahuje také logickou posloupnost činnosti znázorněnou pomocí šipek mezi obdélníky. V podstatě jsou v jednom (rozšířeném) diagramu koncentrovány plány CO, KDY a JAK. Plán CO Tento plán definuje, co se má udělat, tedy výsledné produkty, ať již z věcného podhledu (komponenty systému) nebo procesního pohledu (funkce, které bude systém zprostředkovávat). Nejčastěji je vytvořen pomocí metody WBS a reprezentován právě hierarchickým rozpadem jednotlivých položek. K vytvoření plánu CO lze také využít například metodu brainstormingu a pro výsledné znázornění použít mind mapu (postup doporučený v textu [26]). Vždy je nutné se při tvorbě plánu CO odprostit od toho, jak produkty budou vytvořeny. Plán JAK Plán JAK logicky rozebírá projekt na jednotlivé činnosti (tedy zpodrobní WBS), uspořádá je a přidává vztahy a závislosti mezi nimi. Nejčastější znázornění plánu JAK je pomocí síťového diagramu. Je důležité do plánu nezanášet hledisko času ani disponibility zdrojů (dle prezentace [6]). 25

33 Doporučený postup, jak plán JAK vytvořit v případě, že projektový manažer tápe, je tzv. postup odzadu. Klade si otázky počínaje koncem projektu: Co je potřeba udělat před tím, než bude aplikace hotová? Odpověď: Je třeba aplikaci otestovat. Iterativně si opět pokládá otázku: Co je potřeba udělat před tím, než aplikaci otestujeme? Odpověď: Je třeba aplikaci zkompilovat. atd. Takto je provedena iterace z věcného pohledu a poté je vhodné doplnit organizační kroky. (Tento postup byl prezentován v prezentaci [6]). Plán S KÝM Vstupem pro vytvoření plánu S KÝM je hotový logický plán činností. K jednotlivým činnostem jsou určeny potřebné zdroje (role, specialisté, technika, stroje, pronajaté služby, konzultanti) a do logického plánu činností je následně doplněno, jak budou zdroje obsazeny jednotlivými pracovníky. Plán S KÝM také často obsahuje rozpis osob do jednotlivých týmů (řešitelský tým, pracovní tým, vedení projektu, řídicí komise). Plán KDY Na základě předchozích tří plánů již lze provést časové odhady činností (podrobněji v následující kapitole). Určit nejvhodnější začátek projektu, stanovit termín dokončení a sestavit harmonogram projektu například do podoby Ganttova diagramu. Plán ZA KOLIK Plán ZA KOLIK v sobě obsahuje finanční stránku projektu, tedy stanovení rozpočtu a plánu financování. 5.2 Identifikované problémy stanovení časového odhadu činností Stanovení časového odhadu je vždy provázeno nejistotou a na jejím základě jsou do odhadu vkládány časové rezervy. Samotný odhad a velikost časové rezervy se velmi proměňuje v závislosti na osobě, která odhady provádí. V následujícím textu jsou podrobně popsány vlivy nejistoty, osoby a problém časových rezerv Vliv nejistoty na odhadování Podstatná součást plánování je časový odhad činnosti, nejen že se na základě časového odhadu všech činností určuje celková doba trvání projektu, ale také rozpočet. Zároveň je to činnost, která do projektu vnáší míru nejistoty a podcenění stanovení časových odhadů může vést k zásadním problémům na projektu. Eliyahu M. Goldratt ve své knize Kritický řetěz [27] vysvětluje chování lidí při tvorbě časových odhadů a ilustruje je pravděpodobnostní křivkou. Mějme na projektu činnost a, proměnlivou veličinu čas označme jako t. Je možné stanovit pravděpodobnost, že činnost a skončí v čase x, nechť je tato pravděpodobnost popsána funkcí p(t). Dále řekněme, že činnost nelze stihnout dříve než za 5 dní (tedy p(4) = 0) a naopak v případě velmi nepříznivých okolností se může doba prodloužit i na 50 dní (tedy p(50) ještě není nulová). Potom graf rozdělení pravděpodobnosti může (dle statického průzkumu z praxe) vypadat následovně: 26

34 Obrázek 5.1: Graf rozdělení pravděpodobnosti ukončení činnosti a v čase t (odlišnost grafu od Gaussovy křivky způsobuje lidský faktor v kombinaci s velkou složitostí projektů [dle 27]). (Zdroj obrázku: autorka, překresleno z obrázku v textu [27], strana 40) Pravděpodobnost, že činnost skončí nejpozději v určitém času x lze vyjádřit pomocí poměru obsahu ploch (více v [8]). Potom pravděpodobnost, že činnost skončí nejpozději v mediánu je rovna 50 %. Jen málo pracovníků si troufá odhadnout práci a říct termín, u kterého hrozí na padesát procent nesplnění. Ve většině případů se odhady pohybují v rozmezí % pravděpodobnosti dokončení činnosti nejpozději v daném termínu. Potom rozdíl mezi mediánem a skutečným odhadem pracovníků je časová rezerva, kterou k odhadu pracovníci přidávají. Všimněme si, že abychom zajistili termín splnění činnosti na 90 % místo 50 %, musíme dobu prodloužit několika násobně. Podrobněji bude rezervám věnována kapitola Obrázek 5.2: Graf rozdělení pravděpodobnosti ukončení činnost a v čase t, doplněn odhad času od pracovníků. (Zdroj obrázku: autorka, překresleno z obrázku v textu [27], strana 40) 27

35 5.2.2 Vliv osoby odhadující činnost Časové odhady činností mohou stanovit: projektový manažer či koordinátor nebo specialista, odborník, senior pracovník či jiná pověřená osoba, která ovšem činnost následně neprovádí, nebo osoba, která ve výsledku danou činnost opravdu provádí, nebo tým pracovníků. Každá z výše uvedených možností má svou světlou i stinnou stránku. V případě, že časový odhad činnosti odhaduje projektový manažer, může jednoduše dojít k podcenění situace. Projektový manažer nezná všechny technické aspekty či možné překážky ze strany použitých technologií (nedokáže zhodnotit, zda nebude potřeba vyvinout některé velmi náročné moduly, například pro konverzi dat mezi různými systémy). Pokud již má za sebou několik úspěšných projektů, snadno sklouzne k pocitu, že když to programátoři zvládli v minulých projektech, zvládnou to stejně rychle i tentokrát. Výhodou je pouze fakt, že pokud stanoví čas projektový manažer, pracovníci nevědí, zda a jak velké rezervy byly k odhadu přidány a může tak být zabráněno Studentskému syndromu (viz kapitola 2.8). Stanovením odhadu času může být pověřen odborník v týmu či osoba, která je v týmu již velmi dlouho, má spoustu zkušeností a bývá označována jako tzv. senior pracovník. Pokud je však jisté, že odhadovanou činnost následně nebude mít na starosti, nic jej nenutí věnovat odhadu času dostatečnou pozornost, neboť v důsledku neponese následky. Navíc v odhadech může promítnout až příliš své vlastní schopnosti a zkušenosti a uvést krátký časový interval, méně zkušený pracovník by na stejnou činnost potřeboval 2x až 3x tolik času. Jako jedna z nejlepších možných variant se jeví situace, ve které časový odhad stanoví právě ta osoba, která bude danou činnost vykonávat. Nejen že může přistupovat zodpovědně k odhadu, ale potom i k samotné činnosti, neboť možnost rozhodnout sám o svém osudu namísto přihlížení a smíření se s daným číslem může být velmi motivující. Problémem může být věk či povaha pracovníka. Mladý nezkušený programátor si může myslet, že daná činnost je učebnicový příklad a zvládne ji v obědové přestávce. Zkušený starší programátor přidá k odhadu velkou míru rezervy, neboť cituji Goldratta: Lidé skutečně dělají realistické odhady podle svých nejhorších zkušeností z minula. (citace z knihy Kritický řetěz [27]). Jak bude z následujícího textu patrné, v poslední době bývá vyzdvihována poslední možnost. V několika článcích se autoři přiklání k variantě, kdy se na odhadování časů podílí celý tým pracovníků. Výhody jsou nasnadě: jeden z týmu bude danou činnost opravdu vykonávat, tedy bude při vyjednávání bojovat za to, aby odhad byl realistický a zvládnutelný. Projektový manažer se při vyjednávání bude snažit argumentovat pro nižší odhady a odborníci budou zdůvodňovat, co za problémy se může vyskytnout a proč je potřeba na danou činnost více času. Použila jsem sice slovo vyjednávat, ale stanovení termínů nemusí probíhat v diskusi, jsou i jiné techniky, které budou uvedeny níže Problém časových rezerv V úvodu kapitoly 5.2 je nastíněno přidávání časové rezervy do odhadu doby trvání dané činnosti. Níže na obrázku 5.3 například odpovídá odhad času od pracovníků hodnotě 90 % jistoty dokončení činnosti nejpozději v čase y. 28

36 Obrázek 5.3: Graf rozdělení pravděpodobnosti ukončení činnosti a v čase t, doplněn o vizualizaci rezervy. (Zdroj obrázku: autorka, překresleno z obrázku v textu [27], strana 40) Rozdíl mezi mediánem a odhadem pracovníků na obrázku 5.3 je rezerva vložená do odhadu, je to zbývajících 40 %. Nenechme se ovšem zmást zjednodušujícím nákresem a čísly, v žádném případě rezerva netvoří 40 % celkové doby y, kterou pracovník uvedl jako svůj odhad doby trvání. Na obrázku 5.3 tvoří rezerva 1,5 násobek doby x. Obvyklé jsou i rezervy rovny dvojnásobku i trojnásobku času v mediánu. Rezervy jsou důležité pro kompenzaci rizik projektu. Bohužel tato vytvořená rezerva bývá často potom v důsledku Studentského syndromu (viz kapitola 2.7) a Parkinsonova zákona (viz kapitola 2.8) promarněna. 5.3 Nástroje a techniky odhadování času V následující kapitole jsou uvedeny známé nástroje nebo techniky odhadování, ovšem nekladu si za cíl stanovit úplný výčet všech. Největší důraz je kladen na techniky odhadování pomocí týmu lidí, neboť je osobně považuji za nejvhodnější pro užití v metodikách koordinace projektů v multiprojektovém prostředí. Nástroje a techniky, které může užívat jediná osoba: zkušenost, analogie expertní posudky PROBE PERT LOC FPA COCOMO II Nástroje a techniky vyžadující skupinu lidí: Technika Delfské věštírny Plánovací hra 29

37 Pozor, v případě softwarových metrik (LOC, FPA, COCOMO II) může nezkušený projektový manažer dojít ke zjednodušení, že odhadovaná práce na projektu rovná se jen programování a následně opomene odhadnout a připočítat čas dalších činností (testování, návrh grafického rozhraní, psaní výkazu, dokumentace, schůzky se zákazníkem, zaškolení nového pracovníka), které pomocí softwarových metrik určit nelze. Některé softwarové metriky je ovšem mohou mít obsaženy ve svém algoritmu v některém z násobících koeficientů Zkušenost, analogie Pokud čas činnosti odhaduje sám projektový manažer, často využívá svých minulých zkušeností z projektů ( testování takového modulu trvalo minule 3 týdny, teď to budou opět 3 týdny ). Případně hledá analogie s jinými činnostmi na jiných projektech ( propojení dvou systémů zákazníka X nám trvalo 2 měsíce, pokud teď budeme propojovat dva systémy ještě s účetním systémem zákazníka Y, bude to trvat více času, řekněme 3 měsíce ) Expertní posudky Expert na danou oblast odhaduje čas pomocí intuice. Nevýhody jsou popsány výše v kapitole PROBE PROBE (PROxy-Based Estimation) je technika v českém jazyce označovaná jako Odhadování pomocí zástupce. Zástupcem zde není myšlena osoba, ale (v tomto případě) činnost, jejíž doba je přímo úměrná době činnosti odhadované. Vhodný zástupce je především měřitelný, je známa historie již měřených hodnot. Pokud v minulosti trvala činnost tvorba webové publikace 42 hodin a vstupem byl dokument o 134 stranách, lze analogicky odvodit, jak dlouho bude trvat tvorba jiné webové publikace, jejímž vstupem je dokument o x stranách PERT PERT je zkratkou anglického Program (or Project) Evaluation and Review Technique a jedná se o metodu pro odhadování doby trvání činnosti přes kalkulaci tří expertních odhadů. Doba trvání činnost se v PERT chápe jako náhodná proměnná s určitým rozložením pravděpodobnosti (nejčastěji Beta rozdělení pravděpodobnosti podle [3]). Pokud chce projektový manažer využívat techniku PERT, musí on nebo zvolený expert nejprve určit tři časové odhady: optimistický odhad, který určuje dobu trvání za příznivých podmínek, často se jedná o nejkratší dobu trvání, pravděpodobný odhad, který určuje nejvíce pravděpodobnou dobu trvání činnosti, v podstatě se jedná o statistický modus, pesimistický odhad, který určuje dobu trvání za nepříznivých podmínek, často se jedná o nejdelší dobu trvání činnosti. Mějme optimistický odhad a, pravděpodobný odhad b a pesimistický odhad c. Potom očekávaný odhad T e lze vyjádřit pomocí vztahu: a + 4b + c T e = (dle [8]) 6 30

38 Pokud by byl určen pouze optimistický odhad a a pesimistický odhad c, lze očekávaný odhad T e vyjádřit pomoc vztahu: 3a + 2c T e = (dle [3]) 5 Výhodou PERT je možnost vyjádřit si optimistický či pesimistický průběh celého projektu pomocí vhodného software, který u každé činnosti uchovává hodnoty a, c a T e. Nevýhodou PERT je fakt, že se projektový manažer či expert musí na činnost dívat ze tří pohledů (optimistický, pesimistický, pravděpodobný), přitom právě stanovení optimistického a pesimistického odhadu bývá podceňováno. Nakonec může projektový manažer tíhnout jen k užívání samotného pravděpodobného odhadu bez zbývajících dvou a výpočtu LOC LOC (Lines Of Code) či upřesněné SLOC (Source lines of code) jsou softwarové metriky založené na počtu řádků zdrojového kódu. Na základě počtu řádků určuje velikost aplikace a následně je možné odvodit i množství potřebné práce pro její vytvoření. Samozřejmě záleží na zvoleném programovacím jazyku, na faktu, zda započítáváme komentáře a zda bereme v potaz možnost znovu používání částí kódu FPA FPA (Function Point Analysis), česky označovaná jako Metoda funkčních bodů, byla vyvinuta v roce 1979 Allanem Albrechtem a jedná se o metriku software, která měří aplikační funkce namísto zdrojového kódu. Díky tomu je nezávislá na použitých vývojových nástrojích. Probíhá v několika krocích: určení typu výpočtu, stanovení rozsahu výpočtu a hranic aplikace, výpočet datových funkcí a jejich složitosti, výpočet transakčních funkcí a jejich složitosti, výpočet neupravených funkčních bodů, určení vlivu obecných charakteristik systému, výpočet upravených funkčních bodů a následně stanovení pracnosti a ceny jednoho funkčního bodu. Podrobnější výpočet je popsán v textu [28] COCOMO II COCOMO (anglicky The Constructive Cost Model) je softwarová metrika, kterou vynalezl pan Barry Boehm na základě studie 63 projektů vývoje software (kolem roku 1981) a statistické analýzy jejich výsledků. Následné COCOMO II bylo publikováno až v roce 2000 a lépe odpovídá moderním projektům vývoje software (především je uzpůsobena objektově orientovanému programování). Technika COCOMO II je založena na několika rovnicích a výběru správných hodnot proměnných dle parametrů daného projektu. Výsledkem výpočtu je pracnost (nejčastěji v tzv. člověkoměsících) a odhad doby zpracování (nejčastěji v měsících). Jednotlivé proměnné v sobě obsahují například míru podobnosti s předchozími projekty, složení týmu, kvalitu lidí i jejich zkušenosti. 31

39 5.3.8 Technika Delfské věštírny Techniku Delfské věštírny (anglicky Delphi technique) vytvořil pan Norman Dalkey, je používána především v oblasti kvalitativní analýzy rizik a také jako podpora provádění kvantitativní analýzy rizik. Své použití má i jako technika pro generování nápadů (obdobně jako Brainstorming technika) a je vhodná pro expertní odhadování. V případě projektů nás však zajímá především jako technika vhodná pro stanovení časových odhadů. Z techniky Delfské věštírny je odvozena řada upravených technik, mezi nimi minidelphi technika, TeamDelphi technika, Wideband Delphi Process či The nominal group technique (NGT), někdy označovaná jako Estimate-Talk-Estimate (ETE) procedura. Jednotícím prvkem všech těchto upravených technik je víra, že konsenzu bude dosaženo až nad správným řešením. Stejně tak je ale pojí vyšší nároky na čas potřebný k odhadování i na samotnou organizaci setkání lidí. Tým lidí by měl být nejlépe tvořen nejen pracovníky vývojového týmu, ale také experty z různých oblastí a osoby, které se nějakým způsobem na projektu podílí (finanční ředitel a zástupci zákazníka) a mohou tak poskytnout širší pohled na věc. Z praktického hlediska však bývá často tvořen jen vývojovým týmem a projektovým manažerem či koordinátorem. I v tomto složení dává tato technika velmi dobré časové odhady. Estimate-Talk-Estimate (ETE) procedura Postup: 1. Je sestaven a sezván tým lidí do jedné místnosti. V místnosti by měl být flipchart, tabule či projektor. 2. Projektový manažer nastíní a popíše činnost, jejíž čas má tým odhadnout, a okolnosti projektu. 3. Projektový manažer položí dotaz na dobu trvání činnosti, určí jednotku času a požádá účastníky, aby napsali svůj odhad na papír. Nepodepisují se kvůli zachování anonymity. 4. Papíry jsou vysbírány a vyvěšeny na flipchart či přepsány na tabuli. 5. Odhady jsou vyhodnoceny a je napsán aritmetický průměr. Pro případ zabránění vlivu hodnot extrémních odpovědí lze vyškrtnout odpověď s minimální a s maximální hodnotou a aritmetický průměr určit ze zbývajících hodnot. Případně lze použít medián. 6. Diskutuje se nad extrémními hodnotami a zdůvodněním těch hodnot. 7. Projektový manažer odpovídá na dotazy účastníků a zpřesňuje a doplňuje informace o situaci, činnosti, projektu. 8. Projektový manažer požádá účastníky, aby po zvážení těchto nových či doplněných informací znovu napsali na papír svůj odhad ve stanovené časové jednotce. 9. Papíry jsou opět vysbírány, vyvěšeny či přepsány a je vypočítán průměr či medián. 10. Podle změny hodnot může proběhnout další iterace či se tým již může shodnout na konečném časovém odhadu. Výhodou postupu ETE je stále zachování anonymity oproti jiným technikám. Dle [3] je ETE je v důsledku o 30 % přesnější než obyčejná diskuse nad dobou trvání činnosti ve stejné skupině. Wideband Delphi Process Postup této techniky je popsán v textu [3] a obvykle je při ní na začátku generována WBS (viz kapitola 2.3). Pokud techniku zjednodušíme pouze na odhad času, obměnou od předchozího postupu bude fakt, že účastníci dostanou před schůzkou informace o celém projektu a také celou WBS, respektive 32

40 seznam všech činností na projektu. Tedy v klidu v kanceláři či doma vše nastudují a stanoví ke každé činnosti WBS časový odhad. Tyto odhady slouží jako podklad první iterace na schůzce. Další iterace již probíhají po diskusi na dané schůzce jako v postupu ETE. Metoda Team Delphi Metoda Team Delphi je velmi podobná ETE, rozdíl je pouze v první iteraci. Projektový manažer sezve pracovníky na schůzku, nastíní a popíše činnost, která se má odhadovat. Položí dotaz na dobu trvání, určí časovou jednotku a pracovníci napíšou své časové odhady na papíry, které jsou následně vysbírány. Odhady jsou vypsány či vyvěšeny na flipchart, je určen průměr či medián. Ovšem oproti ETE v první iteraci neprobíhá diskuse ani žádné upřesnění činnosti. Pracovníci pouze vidí odhady ostatních a nechají nebo nenechají se jimi ovlivnit. Proběhne druhá iterace a v té se již o odhadech diskutuje, tak jako v ETE. Upravená technika Delfské věštírny dle dr. Zdenko Staníčka Postup byl představen v prezentaci v předmětu PV098 Řízení implementace IS na Fakultě informatiky Masarykovy univerzity, přednášejícím byl pan RNDr. Zdenko Staníček, Ph.D. Probíhá v následujících krocích: 1. Je sestaven a sezván tým lidí do jedné místnosti. V místnosti by měl být flipchart, tabule či projektor. 2. Lidé jsou rozdělení do několika skupin (3 4), ideální stav je, aby spolu ve skupině nebyli lidé, kteří se velmi dobře znají a jsou blízcí přátelé. 3. Projektový manažer nastíní a popíše činnost, jejíž čas mají týmy odhadnout, a doplní okolnosti projektu. 4. Projektový manažer položí dotaz na dobu trvání činnosti, určí jednotku času a požádá účastníky, aby ve skupině diskutovali o době trvání a po stanovené době (5 minut, 10 minut, 30 minut, závisí na složitosti činnosti či projektu) přednesla každá skupina jeden odhad, na kterém se shodnou. 5. Po uplynutí stanovené doby skupiny sdělí své odhady a probíhá diskuse, pokud jsou rozdílné. Projektový manažer upřesní detaily projektu, zodpoví dotazy. 6. Následně probíhá další iterace, kdy skupiny ovlivněna diskusí a dalšími informacemi znovu stanoví odhad. 7. Iterace pokračují, dokud všechny skupiny nedojdou k jednomu odhadu Plánovací hra Metoda Plánovací hry, někdy známá také pod označením Plánovací poker [29], je typická pro agilní metodiky. Vychází z principu č. 11 (viz kapitola 2.7), v mnoha agilních metodikách je největší důraz kladen na tým. Stanovení odhadů času tedy přirozeně také probíhá v týmu. Vznikla v metodice Extrémní programování (XP) a stejně jako samotné agilní metodiky je založena na iteracích. Na plánovací hře by se měl podílet celý tým, ne jen vývojáři, ale i testeři, databázový specialista, designér, analytik. Měl by být přizván i tzv. Product Owner (zákazník nebo zadavatel projektu v případě interních projektů), který dle agilních metodik nehodnotí, nýbrž jen zodpovídá dotazy a doplňuje informace. Postup probíhá v následujících krocích: 1. Moderátor sezve tým do jedné místnosti, každý hodnotitel dostane kartičky s hodnotami, číslice na kartičkách by měly být velké a dostatečně čitelné pro celou místnost. 33

41 2. Pro každou činnost (v agilní metodice obvykle pro celé tzv. Story) moderátor přečte popis. Následuje prostor pro dotazy v týmu, zodpovídá je Product Owner. 3. Moderátor se zeptá na odhad a každý hodnotitel vybere kartu, která reprezentuje jeho odhad. Tak jako v karetních hrách, vybírá tak, aby jeho výběr neviděli ostatní. 4. Jakmile mají všichni hodnotitelé zvolenou kartu, ukážou ji tak, aby ji všichni v místnosti mohli vidět. 5. Hodnotitelé s nejvyšším a nejnižším hodnocením vysvětlí své odhady. Nad důvody může proběhnout diskuse. 6. Po diskusi moderátor hodnotitele požádá, aby znovu zvážili svůj odhad a opět vybrali kartu, která jej bude reprezentovat (mohou samozřejmě vybrat stejnou jako předtím). 7. Jakmile mají všichni hodnotitelé zvolenou kartu, opět ji ukážou tak, aby ji všichni v místnosti mohli vidět. 8. Pokud nekonvergují odhady k jednomu číslu, opět proběhne vysvětlení, diskuse a nový výběr karty. Cílem je, aby tým došel k jednomu odhadu. Role moderátora V postupu tentokrát není uveden projektový manažer, ale moderátor. V mnoha agilních metodikách totiž osoba projektového manažera či koordinátora týmu nemusí existovat či je náhodně volena a mění se v čase. Moderátor by si měl dát v postupu pozor, aby žádost o vysvětlení odhadu v bodě č. 5 nevyzněla jako útok na hodnotitele. Při diskusi (bod č. 5) je užitečné, pokud si moderátor píše poznámky, mohou být potom použity při samotném vývoji. Často totiž odlišné časové odhady pramení z toho, že pracovníci chtějí použít odlišné technologie (databáze versus XML, 2D animace namísto 3D). Z diskuse tedy může plynout i výběr nejvhodnější technologie pro danou činnost. Moderátor by měl také udržet diskuse krátké a tím i efektivní, v některých textech se doporučuje použít kuchyňskou minutku nastavenou na 2 minuty. Pořád jsou to jen odhady, není efektivní jim věnovat příliš mnoho času. Hodnoty na kartičkách Hodnoty, které jsou uvedeny na hracích kartách, jsou pevně dané. Před samotnou plánovací hrou by se tým měl dohodnout, co pro ně jednotlivé hodnoty znamenají, zda dny, týdny, hodiny nebo jen plánovací body. V agilních metodikách je obvyklé, že nemá smysl rozlišovat mezi odhadem 65 hodin a odhadem 68 hodin, protože rozdíl 3 hodin v kontextu těch desítek hodin je velmi malý. Také čím vyšší je odhad, tím větší míru nejistoty obsahuje a tím větší potom může být odchylka plánované hodnoty od skutečné. Z těchto důvodů se často používá Fibonnaciho posloupnost vyjma nuly. Pro některé projekty však může být výhodnější používat třeba jen řadu násobků (1,2,4,8,16,32 nebo 1,2,4,8,32,256). Lze používat i řadu násobenou deseti: 10, 20, 30, 50, 80, 130 (doporučení z knihy [30]). Nula bývá záměrně vynechávána. I když existují na projektu činnosti, které trvají velmi malou časovou jednotku (například 2 hodiny), pokud by pro ně pracovníci používali kartičku s nulou, Product Owner by předpokládal základní matematické pravidlo: 13x0 = 0 a očekával by, že třináct malých činností nebude trvat žádnou časovou jednotku. V případě potřeby je vhodné zařadit kartičku s textem small či malé namísto nulové hodnoty. Na závěr k plánovací hře jen uvedu citaci pana Mike Cohna z jeho knihy [30]: Finally, planning poker works because it s fun. 34

42 5.4 Pravidla pro práci s časovými rezervami Ze špatného zacházení s časovými rezervami pramení několik problémů, nejvýznačnějším je nesplnění termínů. Proto je nutné, aby byla stanovena pravidla pro práci s rezervami a aby si pracovníci uvědomovali, jak velké rezervy do odhadů zanáší, případně aby si vedli jejich evidenci. V každé z výše uvedených technik odhadování doby trvání činností by mělo být na začátku stanoveno: Bude do odhadu vkládána rezerva? Pokud ano, bude rezerva viditelně vyznačena? Pokud ne, je určena metoda následného výpočtu času pro rezervu? Dále záleží také na jednotlivých metodikách koordinace, zda s rezervami dále pracují (např. CCPM) nebo ne (např. Scrum). Rezerva je součástí odhadu V případě skupinových plánovacích technik by měl každý pracovník v týmu dopředu vědět, zda má do svého odhadu vnášet rezervu a jak velkou (byť u skupinových odhadů je hodnota velikosti rezervy spíše subjektivním pocitem každého jedince než srovnatelnou a měřitelnou veličinou). V případě, že odhady stanovuje sám projektový manažer, měl by vědět, zda jím zvolená technika rezervy do odhadů již vnáší či nikoliv. Rezerva není součástí odhadu Přesvědčit pracovníky, aby do svých odhadů nevkládali žádné časové rezervy a určovali své časové odhady co nejblíže mediánu pravděpodobnostní křivky (tedy odhadovali dobu činnosti s 50% pravděpodobností na úspěch), není lehké. Pracovníci mají obavu z trestu, který často při překročení termínu přichází. Dále mají obavy, že budou považování za nezkušené či dokonce neschopné, pokud nesprávně odhadnou dobu trvání činnosti. Všechny tyto obavy musí vedoucí pracovníci rozptýlit. Pracovníci musí mít garantováno, že nebudou trestáni za mírné překročení plánu a že bude tolerováno i větší zpoždění při podání vysvětlení komplikací. Naplánovat projekt bez rezerv pro krytí rizik projektu by ovšem bylo velmi nezodpovědné. Jakmile má projektový manažer určeny doby trvání činností bez rezerv, je jeho úkolem sestavit časový harmonogram projektu a do něj viditelně rezervy přidat a začlenit. Způsoby určení rezervy Paušální pro celý projekt lze paušálně určit hodnotu rezerv jednotlivých činnosti v procentech (například rezerva činnosti x o odhadu doby trvání t bude tvořit 10 % nebo 20 % z t). Tento postup ignoruje podstatu činností a navíc je například 10 % nebo 20 % velmi málo a nemusí činnost dostatečně ochránit před riziky. E. M. Goldratt doporučuje ve své knize Kritický řetěz [27] hodnotu 50 % 2, ovšem v případě použití metodiky CCPM (vysvětleno v následující kapitole). Všimněte si, že pracovníci často přidávají do svých odhadů rezervu 150 % až 200 %, aby zajistili 80% pravděpodobnost, že se činnost ve stanoveném termínu stihne. Individuální pracovníci určí hodnotu rezervy individuálně pro každou činnost. 2 E. M. Goldratt vychází ze skutečnosti, že projektové činnosti jsou odhadovány se spolehlivostí 50 % tedy medián křivky v kapitole tudíž příslušný nárazník o délce poloviny větve by měl být dostatečný. Jsou autoři (například Lawrence P. Leach), kteří doporučují jiné vzorce pro výpočet. Vhodné je především vycházet ze zkušeností na podobných projektech. 35

43 Způsoby začlenění rezerv do harmonogramu Rezervy jsou začleněné přímo za každou činnost projektový manažer při sledování postupu projektu v každý okamžik ví, zda již daná činnost čerpá svou rezervu či nikoliv. Odpovídá to situaci, kdy jsou rezervy součástí odhadu, jen s tím rozdílem, že projektový manažer o nich ví a může na základě jejich sledování lépe činit důležitá rozhodnutí a kroky v projektu. Rezervy jsou akumulovány na konci jako jedna velká rezerva tímto způsobem dojde nejlépe k eliminaci Studentského syndromu i Parkinsonova zákonu. Aby rezerva dostatečně kryla rizika projektu, je velká a umístěna na konci je velmi dobře viditelná. I když odpovídá součtu rezerv, které by jinak byly začleněny za každou jednotlivou činnost, může mít projektový manažer mnohem větší nutkání rezervu zmenšit ( přece musí stačit jen 20 % této rezervy ) a neuváženě tím ohrozit úspěch projektu. Jak akumulovanou rezervu prezentovat zákazníkovi? Nejčastěji se mu tato rezerva zamlčí a do projektu na konec místo rezervy vloží tzv. důvěryhodná činnost či činnosti, které fakticky nejsou potřebné a ve finále nebudou vůbec provedeny. Rezervy jsou rozmístěny na strategická místa dle CCPM Eliyahu M. Goldratt ve svém Projektovém managementu kritickým řetězem (anglicky Critical Chain Project Management, zkratkou CCPM) akumuloval v prvním kroku rezervy na konec projektu jako jednu velkou rezervu. Ovšem přišla mu příliš velká a tak na základě své teorie TOC (viz kapitola 2.5) vytvořil postup, jak a kam efektivně umístit menší rezervy tak, aby přitom nebyl projekt ohrožen. Původní postup dle Eliyahu M. Goldratta je podrobněji popsán v knize [27], pozměněný postup pro potřeby projektů popsaných v multiprojektovém prostředí je podrobněji rozepsán v kapitole Sestavení harmonogramu projektu Jakmile získá koordinátor časové odhady činností a časové odhady rezerv, může již sestavit harmonogram projektu. Zvolená metodika by měla pracovníkovi určit postup, kterým stanoví začátky činností. V tomto okamžiku se stává, že nezkušený projektový manažer či koordinátor opomene do harmonogramu začlenit mimo činnosti na projektu i další podstatné události: státní svátky a dny pracovního volna, dovolené pracovníků, školení BOZP, vzdělávací semináře a workshopy, zaškolení nových pracovníků. Pokud má pracovník určit, jak dlouho projekt bude trvat právě s přihlédnutím na svátky, dovolené i zdržení administrativními činnostmi (vyplňování výkazů práce, porady, schůzky a další) lze použít jednoduchý přepočet: 1 rok = 10 měsíců = 200 dní 1 kvartál = 50 dní 1 měsíc = 20 dní (z prezentace [6]) 36

44 5.6 Dodržování termínů Základem zajištění dodržování termínů dokončení činností či přímo projektů je: 1. stanovení realistické doby trvání činnosti (kapitola 5.3), 2. zvolení vhodné metodiky koordinace (kapitola 6), 3. kontrola postupu činnosti (kapitola 4.4) a včasné řešení problémů. Realistická doba trvání činnosti je základním stavebním kamenem, na kterém lze úspěšné dodržování termínů stavět. Nelze se snažit dokončit práce v nesmyslně stanoveném termínu. Vhodná volba metodiky potom může pomoci eliminovat vliv Studentského i Parkinsonova zákonu, stejně jako například prokrastinaci. Poslední faktor, který má na dodržování termínů vliv, je včasné řešení problémů. Koordinátor by měl být proaktivní, kontrolovat a sledovat postup na projektech a při zjištění problému včas zasáhnout. Spoléhat se, že žádný problém nenastane, je naivní, stejně jako snaha tvářit se, že problém není či že se vyřeší sám. V týmu, kde je pracovník veden k včasnému oznámení problému, nemusejí mít problémy na dodržení stanoveného termínu vliv, často s řešením problému pomůže kolega či tým společně najde řešení v rámci pravidelné schůzky nebo porady. 37

45 6 Možnosti koordinace Počátkem 21. století se začíná oblast koordinace a projektového řízení orientovat třemi hlavními směry: automatická synchronizace projektů pomocí front, omezení, pravidel, aplikace a rozvíjení stěžejních myšlenek Eliyahu M. Goldratta, agilní metodiky a koordinace zaměřená na tým a samotné pracovníky. Rozvoj IT i snazší dostupnost podnikových informačních systémů středním a především malým firmám umožňuje automatizaci procesu koordinace. Inspirace průmyslovým odvětvím posazuje pracovníky do role výkonných strojů, které se další činnost, na které mají pracovat, dozví ze systému. Výzkum v této oblasti je zaměřen na hledání efektivních algoritmů přidělování činností zdrojům, konkrétně v oblasti multiprojektového prostředí se problém rozvrhování činností řadí to třídy problémů NP-hard (z anglického Non-deterministic Polynomial-time hard). Opačný přístup nabízejí agilní metodiky. Tým, jednotliví pracovníci a dobrá komunikace a spolupráce se zákazníkem mají přednost před procesy, nástroji, algoritmy. Agilní metodiky jsou silně zaměřené na sledování cíle, úspěchu, důraz je v oblasti IT kladen více na fungující software než vyčerpávající dokumentaci, změny jsou vítané. Postupy a procesy agilních metodik jsou sepsány volně, je na koordinátorovi a týmu pracovníků, jak je aplikují. Podporována je zpětná vazba, celé možnosti koordinace jsou zaměřené na potenciál pracovníků. Středním směrem mezi těmito zmíněnými extrémy je aplikace a rozvíjení myšlenek pana Eliyahu M. Goldratta. Přeneseně řečeno, jedná se o aplikaci zdravého rozumu na projektovém řízení. Myšlenky prezentované panem Goldrattem jsou jednoduché a srozumitelné, jejich aplikace mnohdy vyžaduje algoritmická řešení a potřebu řešení pomocí počítačových systémů. V následujícím textu je důraz kladen především na myšlenky pana Goldratta, jeho metodiku CCPM a dále na agilní metodiku Scrum. Postupy koordinace jsou popsány krok za krokem a doplněny názornými obrázky, schématy v přílohách i drobnými praktickými tipy. Metody synchronizace projektů pomocí front a omezení jsou představeny jen stručně a krátce. V podkapitolách záměrně nejsou zmíněna existující softwarová řešení (ať již vhodná či méně vhodná) či drobné softwarové plánovací pomůcky a programy. Pokud koordinátoři či projektoví manažeři plně chápou pravidla a principy metodiky i na základě slovního popisu a schémat kreslených na obyčejný papír, potom jsou schopni sami vybrat nejvhodnější software či si nechat naprogramovat modul do podnikového informačního systému na míru jejich potřebám. Je bez pochyby, že právě software i drobné programy mnoho kroků plánování a koordinace usnadní a celý proces zefektivní. Pokud je však koordinátor závislý na software (příkladem budiž MS Project) a dokáže koordinovat pouze v mezích, které mu software umožňuje, nepovažuji to za vhodný přístup. 6.1 Synchronizace projektů pomocí front a omezení V multiprojektovém prostředí lze projekty synchronizovat mezi sebou pomocí front, priorit, pravidel a omezení. Počínaje jednoduchým řazením dle lidového rčení kdo dřív přijde, ten dřív mele až po synchronizaci založenou na kontrole množství procesního času. Bez synchronizace by docházelo ke zdrojovým kolizím a přetěžování zdrojů. 38

46 Ke koordinaci jsou částečně využívány i metody CPM a WBS, projekty jsou rozloženy na jednotlivé činnosti a provázány pomocí logických návazností. Pan Paul S. Adler ve svém článku [32] identifikoval, že v každou chvíli je každá činnost ve stavu: přijímá službu od zdroje nebo čeká na přístup ke zdroji nebo čeká na dokončení jiné činnosti, která je zpracovávána či zpožděna. Potom každý zdroj má svoji frontu, do které jsou zařazovány jednotlivé činnosti a dle zvolené metody synchronizace existuje jedna či více dalších front na samotné projekty. Snahou mnoha autorů je přidělování činností zdrojům automatizovat, některé metody se podobají plánovacím algoritmům operačních systému, které každému procesu přidělují určitý čas procesoru. Role koordinátora je více či méně potlačena a pracovníkům je po dokončení činnosti systémem vybrána činnost další. Některé články a výzkumy, mezi nimi i [33], se zaměřují na srovnání synchronizace pomocí front a jiných metod a metodik koordinace, například CCPM, z hlediska průměrné doby zpracování. Protože jsem neobjevila výzkum, který by byl směrován na oblast projektů s velkou mírou tvůrčí činnosti a dynamiky změn, neuvádím zde jejich výsledky z jiných oblastí. Metod a postupů synchronizace existuje mnoho, v následujících podkapitolách jsou stručně uvedeny jen často zmiňované metody FCFS Metoda FCFS (zkratka anglického First come, first served), byla popsána pány Avishai Manelbaumem a Yonit Barronem v roce Principem je tzv. push systém, nově příchozí projekty jsou přidávány do systému a řešeny v pořadí, ve kterém přišly. Prakticky při použití metody WBS a dále CPM je projekt rozdělen na jednotlivé činnosti a ty jsou přidány do front jednotlivých zdrojů. Obvykle pomocí jednoho ze dvou algoritmů: první z nich přidává jednu aktivitu za druhou, tzv. schéma sekvenčního plánování, druhý z nich přidává skupiny aktivit, tzv. schéma paralelního plánování. Synchronizace projektů je pasivní, nemění se v čase. FCFS je jednoduchý na pochopení a realizaci, ovšem vykazuje vysoké výkyvy a nejistotu. Pasivní synchronizace neumožňuje reakci na změny. Některé zdroje mohou mít příliš dlouhou frontu aktivit či činností a po nátlaku koordinátora či jednotlivých projektových manažerů přechází na multitasking (dle [31]) MinSLK Metodu MinSLK (z anglického Minimum Slack Activity) popsali pánové Douglas B. Bock a James H. Patterson v roce 1990 a následně ji později vylepšovali a přidávali pravidla priorit. Ve své prvotní podobě užívá metodu CPM znovu vyhodnocovanou po dokončení každé aktivity, tzv. slack zde znamená rozdíl mezi brzkým startem a pozdním startem při využití CPM. Jakmile zdroj dokončí jednu aktivitu, v systému se znovu vyhodnotí kritické cesty všech projektů a z fronty daného zdroje se mu nabídne ta aktivita, která vykazuje nejmenší slack. Na té začne pracovník pracovat. Jedná se o aktivní synchronizaci, neboť přidělování činností zdrojům a jejich pozice ve frontě se s časem mění. Důsledkem MinSLK je vysoká priorita činností na zpožděném projektu. Systém však musí počítat s tím, že se slack hodnota na zpožděném projektu dostává i do záporných čísel. Bez dodatečných pravidel priorit a pravidel přidávání nových projektů může metoda vykazovat problémy a řetězové zpoždění několika projektů, například v případě, kdy pracovník pracuje na velmi dlouhé činnosti a hromadí se mu mezitím ve frontě činnosti, kterým se hodnota slack velmi rychle snižuje. 39

47 6.1.3 ConPIP Metoda ConPIP (zkratka za anglického Constant Number of Projects in Process) byla představena pány Boaz Golany a S. Anavi-Isakow v roce 2003 ve článku [31]. Staví na tzv. pull systému, ve kterém jsou projekty vpuštěny do fronty na zpracování pouze na základě určitého signálu a pravidla. Každý nově příchozí projekt je veden ve vnější synchronizační frontě či zásobárně. V systému je vedena hodnota NPIP (Number of Projects In Process), která označuje počet právě zpracovávaných projektů. Na základě zkušeností či analýzy je stanoven maximální počet rozpracovaných projektů M NP (Maximal Number of Projects). Pokud je NPIP menší než M NP, smí nový projekt vstoupit do procesu zpracování, pomocí WBS jsou určeny jednotlivé činnosti, pomocí CPM jsou plánovány a rozděleny do front k jednotlivým zdrojům. Pokud je hodnota NPIP rovna M NP, projekt je zařazen do vnější synchronizační fronty. Po dokončení některého z rozpracovaných projektů je z vnější synchronizační fronty vybrán další projekt, který bude řešen. Někdy bývá vnější synchronizační fronta či zásobárna také omezena a v případě jejího zaplnění je nový projekt rovnou odmítnut a nerealizován. Metoda ConPIP nevykazuje dobré výsledky v případě velkého rozpětí a proměnlivosti rozsahu a pracnosti projektů. Je rozdíl, zda jsou rozpracovány tři rozsáhlé projekty inovace agend informačního systému a k tomu jeden e-shop či zda jsou rozpracovány dvě minutové animace, jeden e-shop a jeden reklamní web ConTIP Variantou metody ConPIP je metoda založená na kontrole množství procesního času, který potřebují všechny rozpracované projekty v systému. Oproti metodě ConPIP je sice mnohem složitější, řeší ovšem proměnlivost rozsahu a pracnosti projektů. Nazývá se ConTIP (zkratka z anglického Constant time in process) a představili ji stejní autoři, Boaz Golany a S. Anavi-Isakow, ve svém článku [31]. Hodnota zbytkového množství požadovaného procesního času (společného pro všechny rozpracované projekty) je aktualizována pokaždé, když je nějaká činnost rozpracovaného projektu svým přiděleným zdrojem dokončena. Nový projekt je vpuštěn do systému ke zpracování pouze, pokud hodnota zbytkového množství požadovaného procesního času klesne pod předem určenou horní časovou hranici M PT (Maximal Processing Time). Ihned po vstupu nového projektu do systému jsou jeho požadavky připočítány k hodnotě zbytkového množství požadovaného procesního času QSC QSC metoda (z anglického Queue Size Control) staví na tom, že existuje jeden zdroj jako úzké místo systému. Pokud se tomuto zdroji bude fronta aktivit neustále zvětšovat, může dojít ke zpoždění mnoha projektů. Proto je stanovený maximální počet aktivit, který může být ve frontě u strategického zdroje a tato fronta je označena jako vnitřní synchronizační fronta. Nový projekt smí být přidán do systému pouze, pokud u požadovaných zdrojů nenavýší počet aktivit přes stanovenou mez. To znamená, že při jeho přidání do soustavy se na celý nový plán spustí stochastická analýza, která odhalí strategický zdroj. V případě, že by přidáním nového projektu byl překročen maximální počet aktivit v synchronizační frontě, projekt nebude realizován. 6.2 Koordinace vycházející z Projektového managementu kritickým řetězem Projektový management kritickým řetězem (anglicky Critical Chain Project Management, zkratkou CCPM) vytvořil Eliyahu M. Goldratt a popsal ve své knize Kritický řetěz [27]. Jedná se o aplikaci jeho koncepce teorie omezení (z knihy Cíl [9]) na prostředí projektového managementu. 40

48 6.2.1 Základní problémy projektového řízení a jejich řešení dle Goldratta Eliyahu M. Goldratt si všiml několika zásadních problémů, které projektové řízení provází: efektivita na místní úrovni projektu jako celku nepomůže, projektoví manažeři velmi rychle ztrácí nadhled, do projektu jsou zahrnuty obrovské rezervy, a přesto se všechny promrhají, práce jednoho pracovníka na více projektech je jen iluze, projektové plány si nepřipouští omezení zdrojů, práce bývá odevzdána často po termínu, ale nikdy před termínem, analyzoval je, vymyslel řešení a propojil je do podoby postupu a doporučení v podobě CCPM Efektivita na místní úrovni projektu jako celku nepomůže Popis problému Představme si projekt A s následujícím diagramem činností. Obrázek 6.1: Diagram činností projektu A, červeně je vyznačená kritická cesta. Pokud se pracovníkovi X podaří optimalizovat svoji práci a zkrátí dobu trvání činnosti 3 na polovinu, nijak to nezkrátí trvání celého projektu. Činnost 6, poslední činnost v projektu je totiž závislá ještě na činnosti 4 a 5 a nemůže začít dříve, než budou dokončeny. Naopak zpoždění činnosti 4 se projeví zpožděním celého projektu. Pokud jsou jednotliví pracovníci či oddělení motivováni k tomu, aby byli efektivní v jakékoliv činnosti, jejich nasazení a snaha bude promarněná, jestliže se jedná o činnost, která není na kritické cestě projektu. Řešení dle Goldratta Eliyahu M. Goldratt rozlišuje činnosti na kritické cestě a činnosti na nekritické cestě. Potom činnosti na kritické cestě mají přednost před činnostmi na nekritické cestě i v případě snahy o efektivitu a zrychlení doby trvání Projektoví manažeři velmi rychle ztrácí nadhled Popis problému Představme si projekt B s následujícím diagramem činností. 41

49 Obrázek 6.2: Diagram činností projektu B, červeně je vyznačená kritická cesta. Eliyahu M. Goldratt vysledoval, že pokud všechny činnosti následující po činnosti 1 (tedy činnosti s čísly 2, 4, 5, 6, 8, 10) začnou zároveň, koordinátor či projektový manažer nezvládá všechny cesty sledovat, kontrolovat a řešit případné problémy. Potom se může stát, že věnuje většinu své pozornosti například na řešení problému na činnosti 6 a nevšimne si, že se objevil zásadní problém v činnosti 4. Přitom činnost 4 je na kritické cestě a zpoždění na ní zpozdí celý projekt. Zpoždění na činnosti 6 se ve zpoždění celého projektu projevit nemusí. Řešení dle Goldratta Eliyahu M. Goldratt zavedl tzv. pozdní start. Činnost na nekritické cestě by měla začít co nejpozději je to možné. Díky pozdním startům nekritických činností se koordinátor může od začátku soustředit na důležité činnosti a netříští tolik svoji pozornost. Přínosem není jen správné rozložení pozornosti, ale také vhodné rozložení investic. Představme si, že činnost 6 a činnost 8 v projektu A vyžadují nemalé investice a po dvou týdnech práce na činnosti 4 se přijde na zásadní problém, který zruší celý projekt. V případě brzkého startu činnosti jsou peníze již utraceny, v případě pozdního startu činnosti 6 a 8 jsou peníze ušetřeny. Pozdní starty u nekritických činností je potřeba zavádět spolu s přípojnými nárazníky (bude vysvětleno níže), aby zpožděním na nekritické cestě nebyl ohrožen celý projekt Do projektu jsou zahrnuty obrovské rezervy, a přesto se všechny promrhají Popis problému CCPM se ve velké míře zabývá rezervami a práci s jejich potenciálem i negativním vlivem na průběh projektu. V mnoha firmách je obvyklé, že pokud je pracovník požádán, aby stanovil dobu trvání činnosti x, přidá do odhadu rezervu. Dělá to z prostého důvodu za překročení časového termínu byl již v minulosti kárán, takže se chce pojistit, aby se mu to již nestalo. Čím více nejistoty a neurčitosti v odhadu činnosti je (viz kapitola 5.2), tím větší rezerva je do odhadu vložena. Manažer k tomuto odhadu činnosti či celkovému odhadu času na projektu opět přidá rezervu, neboť má například negativní zkušenost s krácením rozpočtu a nátlakem vedení na zkrácení termínů. Touto rezervou se pojistí, aby měl projekt i po krácení stále šanci na úspěch. 42

50 Vložené rezervy jsou skryté, nikde se obvykle nevede jejich evidence, nejsou samostatně vyznačeny v plánu. Bohužel v důsledku Studentského syndromu a Parkinsonova zákona nakonec v projektu dojde k promrhání těchto stanovených časových rezerv a projekt překračuje dohodnuté termíny, pracovníci činnosti na projektu nestíhají. Obrázek 6.3: Skryté rezervy v činnostech projektu versus viditelné rezervy. Řešení dle Goldratta Dle CCPM je potřeba s časovými rezervami hospodařit, vkládat je strategicky na taková místa, na kterých slouží jako opravdová pojistka a rezerva na projektu a přitom nedochází k jejich promrhání. Rezervy jsou v metodice obsaženy v pojmu nárazník. CCPM rozlišuje několik typů nárazníků, prvním z nich je tzv. projektový nárazník. Jedná se o akumulaci všech časových rezerv, které by pracovníci skryli v činnostech, a umístění na konec sledu všech činností. Projektový nárazník chrání celý projekt před neočekávanými komplikacemi. Dalším typem nárazníku je tzv. přípojný nárazník, který se přidává na místa připojení vedlejších cest ke kritické cestě v projektu a chrání kritickou cestu před zpožděním a komplikacemi na jedné z nekritických cest. Dalším typem nárazníku je tzv. zdrojový nárazník, který zajišťuje, aby zdroje pro práci na kritické cestě byly včas k dispozici Práce jednoho pracovníka na více projektech je jen iluze Popis problému Multitasking pracovníků vytváří iluzi, že se na všech úkolech pracuje a všechny tedy rychle postupují kupředu. Bohužel je to jen klam, multitasking snižuje výkon pracovníků (viz kapitola 4.2.1) a navíc koordinátor ztrácí informaci, jak projekt postupuje, protože dokud není činnost či jednotlivý úkol hotov, nelze postup na projektu určit. 43

51 Řešení dle Goldratta Řešením je především omezení multitaskingu využitím jasných priorit činností a zdrojů Projektové plány si nepřipouští omezení zdrojů Popis problému Projektoví manažeři dle Goldratta často neberou v potaz zdrojovou závislost činností a na jednu časovou jednotku naplánují paralelně činnost 1 a činnost 2, přitom obě činnosti může vykonávat pouze 1 zdroj X. Zdroj se dostává do situace, kdy neví, kterou činnost začít dřív, je tlačen manažerem či manažery k tomu, aby pracoval na obou zároveň. Dojde k multitaskingu a následně k prodloužení doby zpracování obou činností. Řešení dle Goldratta Eliyahu M. Goldratt ve své knize [27] zavádí pojem kritický řetěz. Kritický řetěz rozšiřuje pojem kritické cesty (viz kapitola 2.4) tím způsobem, že bere v úvahu i zdrojové závislosti Práce bývá odevzdána často po termínu, ale nikdy před termínem Popis problému Z důvodu Parkinsonova zákona (viz kapitola 2.8) není práce odevzdána před stanoveným termínem a z důvodu Studentského syndromu (viz kapitola 2.7) je práce často odevzdána po termínu, neboť pracovník začne pozdě, narazí na problém a následně dochází ke zpoždění a překročení termínu. Řešení dle Goldratta Eliyahu M. Goldratt se snaží v CCPM eliminovat jakékoliv termíny, stanoven je pouze začátek projektu a konec projektu. Vymizí tedy milníky i pevné termíny začátků a konce jednotlivých činností, práce je předávána hned, jakmile je hotová. Tento princip ve své knize [27] pojmenoval jako princip štafetového běhu CCPM v prostředí několika IT projektů Metodu CCPM lze použít i pro multiprojektové prostředí. Postup popisuje už částečně Goldratt v knize [27] a neopomíjí jej ani další autoři, kteří o CCPM píší. Hlavními kroky jsou: přiřazení priorit projektům, plánování jednotlivých projektu podle CCPM, uspořádání projektů, měření nárazníků a řízení nárazníků. Bohužel, v literatuře a článcích [8], [34], [27] je CCPM v multiprojektovém prostředí věnováno jen několik stránek a chybí podrobný popis, jak postupovat v případě problémů. Problémy CCPM v prostředí více projektů Předpokladem CCPM je, že existuje omezení systému strategický zdroj označovaný jako DRUM a tento zdroj je potřeba nejprve najít (například databázový specialista, který pracuje na každé zakázce v podniku). Strategický zdroj je použit pro uspořádání projektů, správce DRUMu mu plánuje práci a vše ostatní se plánu přizpůsobí. Postup velmi dobře funguje v případě, že v podniku existuje jen jedno omezení, které se v čase nemění často, tak jako je obvyklé v prostředí průmyslu. Ovšem jak postupovat, pokud se omezení mění v čase, tedy není zde žádný dlouhodobý stabilní stav? Dle Goldratta stačí pouze sledovat přípojné nárazníky a pokud jedna z přípojných cest začíná prorážet nárazníky jeden za druhým, zaměřit na ni pozornost. Pokud v ní identifikujeme nové omezení, je třeba mu naplánovat práci a vše ostatní plánu přizpůsobit. V případě, že by se omezení v čase měnilo často či kvůli dynamickému nahrazování jednoho projektu jiným došlo ke zpoždění projektů, koordinátor by nedělal nic jiného, než stále přeplánovával a celá sestava projektů by se hroutila. Pro 44

52 případ podniků, jejichž portfolio projektů se mění dynamicky, je CCPM ve své původní podobě použitelné velmi těžko. Problémy CCPM v prostředí IT Tématem, zda je tato metodika aplikovatelná i na prostředí vývoje informačních systémů, se zabýval Petr Ondrůšek ve své práci Zkušenosti s metodikou Kritický řetěz [8]. V kapitole Závěr shrnul, že CCPM je velmi vhodné například pro stavebnictví a pro jiné přesně zadané projekty, ale není příliš vhodné pro IT, především pro situace, ve kterých není jasné zadání, pro výzkumné projekty potom není vhodné vůbec. Inspirace CCPM Při sestavování postupu koordinace se tedy odkláním od standardního postupu CCPM pro multiprojektové prostředí z výše uvedených důvodů. Přesto je následující postup velkou mírou inspirován CCPM, především nakládáním s rezervami v projektech. Postup je pouze teoretický, jsou v něm využita pravidla stanovená Goldrattem, znalosti Studentského a Parkinsonova zákonu a plánů z kapitoly 5.1, znalost vlivu multitaskingu. Popsaný postup nebyl zatím vyzkoušený v praxi na reálném projektu. Oproti původnímu CCPM zde nejsou použity zdrojové nárazníky, neboť by jich bylo z důvodu mnoha zdrojových kolizí příliš a znesnadňovaly by samotnou koordinaci. Jako kompenzace absence těchto nárazníků je vhodné navýšit projektový nárazník Postup plánování Pro každý projekt jsou nejprve sestaveny jednotlivé plány dle kapitoly 5.1. Následně je projekt začleněn do soustavy projektů. Koordinátor pracuje s diagramy, plány či seznamy: plán CO, plán JAK, plán S KÝM, plán KDY, plán ZA KOLIK daného projektu, pruhový diagram činností dle zdrojů daného projektu, časový harmonogram daného projektu, plánu vytíženosti zdrojů v čase, seznam činností pro pracovníky Plány projektu Jakmile přijde požadavek na nový projekt, postupuje koordinátor v následujících osmi krocích: 1. Je zpracována analýza proveditelnosti. 2. Je přidělena zodpovědná osoba, je přidělena priorita projektu. 3. Je vytvořen plán CO. 4. Je vytvořen plán JAK. 5. Je vytvořen plán S KÝM. 6. Je vytvořen plán KDY. 7. Jsou přidány nárazníky. 8. Je sestaven pruhový diagram činností dle zdrojů. 9. Je vytvořen plán ZA KOLIK Krok 1: Je zpracována analýza proveditelnosti. V tomto kroku se musí firma rozhodnout, jestli má o projekt zájem. Projektový manažer, koordinátor či pověřený pracovník musí zanalyzovat, jaké přínosy pro firmu projekt přinese, jak bude asi nákladný a především, zda je vůbec realizovatelný. 45

53 Krok 2: Je přidělena zodpovědná osoba, je přidělena priorita projektu. Ke každému projektu je přiřazen pracovník, který je za něj zodpovědný, často se jedná o osobu, která na projektu vykonává největší podíl práce. Prioritou zde není myšleno pouhé rozlišení důležité, středně důležité, méně důležité. Firma by měla vést seznam všech projektů seřazených podle priority a k tomuto seznamu by měli mít všichni pracovníci přístup. Podstatné je, aby byl seznam udržován aktuální a aby byl opravdu úplný. V případě kolizí se potom pracovník může rychle rozhodovat, která činnost bude mít přednost. Krok 3: Je vytvořen plán CO. Koordinátor či projektový manažer spolu se zodpovědnou osobou vytvoří plán CO. Pokud se jedná o složitější projekt, je možné využít některou z týmových technik, například metodu brainstorming. Dle textu [26] navrhuji využít pro vizualizaci plánu Mind mapu. Ukázka plánu CO je k vidění v příloze B. Krok 4: Je vytvořen plán JAK. Koordinátor či projektový manažer spolu se zodpovědnou osobou vytvoří plán JAK nejlépe v podobě jednoduchého síťového grafu. Pokud je plán CO velmi podrobný, lze využít třeba jen první jeho úroveň nebo či zvolit jiné zjednodušení grafu, tak aby byly viditelné všechny podstatné závislosti a přitom byl stále přehledný. Ukázka plánu JAK je k vidění v příloze C. Krok 5: Je vytvořen plán S KÝM. V dalším kroku je třeba sepsat všechny zdroje (pracovníky, stroje, konzultanty), které daný projekt vyžaduje. Koordinátor ve spolupráci se zodpovědnou osobou navrhne, jak obsadit dané zdroje konkrétními pracovníky týmu a tuto informaci doplní do plánu JAK. Ukázka plánu S KÝM je v příloze D. Krok 6: Je vytvořen plán KDY. Pro každou činnost je potřeba stanovit časový odhad nejlépe jednou z týmových technik v kapitole 5.3. Koordinátor či projektový manažer musí přesvědčit pracovníky, aby odhady stanovili bez rezerv (více v kapitole 5.2.3). Celý projekt bude chráněn tzv. projektovým nárazníkem na konci projektu, pracovníci by se neměli bát trestu za překročení stanoveného odhadu ani by se neměli bát o neúspěch projektu. Je na vyjednávacích schopnostech koordinátora, aby pracovníkům dostatečně popsal situaci a přesvědčil je k vytváření odhadů bez rezerv. Určené časové odhady by si měl zaznamenat koordinátor, ale pracovníci by tyto údaje již dále vidět neměli (z důvodu zabránění Parkinsonova zákona). Důležité je potom zaznačení do síťového grafu a také vyznačení kritické cesty v grafu. Ukázka plánu KDY s vyznačením kritické cesty je na obrázku E.1 v příloze E. Jakmile je zaznačena kritická cesta, síťový graf je třeba si uložit a uchovat 3. Následně je třeba v grafu zvážit také zdrojovou závislost a nejlépe ji vyznačit do grafu, například jiným typem šipek či čárkovanou čárou. Potom je potřeba znovu vyznačit nejdelší řetězec na sobě závislých kroků, který tuto zdrojovou závislost bere v potaz, a vznikne tzv. kritický řetěz. Pro větší přehlednost může být vhodné graf překreslit. Ukázka plánu KDY s vyznačením kritické cesty i kritického řetězu je na obrázku E.2 v příloze E. 3 Graf je vhodné si uchovat pro případ, že se změní situace a na projekt budou přiděleny zdroje jinak kritickou cestu to nezmění, ale kritický řetěz ano, proto je dobré mít kritickou cestu uloženu a z ní opět nový kritický řetěz vytvářet. 46

54 Krok 7: Jsou přidány nárazníky. Koordinátor či projektový manažer stanoví vhodnou pozici pro tzv. nárazníky a vypočítá jejich délku, nejlépe dle vzorce stanoveného panem Eliyahu M. Goldrattem: n počet po sobě jdoucích činností, za které nárazník umisťujeme t i odhad doby trvání činnosti i b délka nárazníku n b i = 1 = i Jako první je třeba stanovit projektový nárazník a do vzorce dosadit odhady trvání všech činností kritického řetězu (ne jen kritické cesty). Dalším krokem je stanovení přípojných nárazníků, ty by měly být umístěny na konec každé cesty, která se ke kritickému řetězu připojuje, a jejich délku lze opět určit dosazením do vzorce výše. Ukázka plánu KDY s doplněnými nárazníky je v příloze F. Délku nárazníků lze určit i jiným způsobem a to například součtem odhadovaných rezerv u daných činností. Tyto odhady rezerv by museli opět stanovit samotní pracovníci, což klade vyšší časové nároky na schůzky. Projektový manažer si musí dát pozor, aby opravdu počítal všechny činnosti přípojné větve a ne jen tu poslední. Problém nastává, pokud je přípojná větev ještě rozvětvená, potom je třeba pro výpočet vzít činnosti, které tvoří nejdelší závislou posloupnost v dané přípojné větvi. 2 t Obrázek 6.4: Ukázka špatně zvoleného přípojného nárazníku. Hodnota 1 neodpovídá celé přípojné větvi, ale pouze poslední činnosti. Červeně je v grafu vyznačena kritická cesta. (Zdroj obrázku: autorka, překresleno z obrázku v textu [34], strana 10, pozměněno) Nastíněný příklad (obrázek 6.4) ukazuje také druhý problém, který může nastat. Pokud v přípojné větvi správně doplníme nárazník, zjistíme, že přípojná větev i s přípojným nárazník je v součtu delší než část kritické cesty do bodu spojení (obrázek 6.5). 47

55 Obrázek 6.5: Modře vyznačená přípojná větev je delší než původní kritická cesta. (Zdroj obrázku: autorka, překresleno z obrázku v textu [34], strana 10, pozměněno) V tomto případě je potřeba zmenšit velikost nárazníku na reálnou velikost (na obrázku 6.6 je to hodnota 3) a navýšit hodnotu projektového nárazníku, neboť se zvýšila pravděpodobnost, že na kritické cestě může nastat zpoždění. Doporučují projektový nárazník navýšit o více než je hodnota snížení projektového nárazníku. Obrázek 6.6: Upravený síťový graf s navýšeným projektovým nárazníkem. (Zdroj obrázku: autorka, překresleno z obrázku v textu [34], strana 10, pozměněno) Krok 8: Je sestaven pruhový diagram činností dle zdrojů. Pro následné začlenění projektu do soustavy je třeba sestavit pruhový diagram, ve kterém jsou jednotlivé činnosti rozmístěny podle zdrojů v řádcích. Diagram poskytuje vizuální představu vytíženosti jednotlivých zdrojů v čase a umožní snadnější začlenění projektu do soustavy. Ukázka pruhového diagramu činností je v příloze G. Krok 9: Je vytvořen plán ZA KOLIK. Projektový manažer na základě jednotlivých plánů může stanovit cenu projektu a předběžný rozpočet Přidání projektu do soustavy projektů Předpokladem pro přidání projektu A do soustavy je aktualizovaný plán vytíženosti zdrojů v čase, který spravuje koordinátor či projektový manažer. Náhled, jak by takový plán mohl vypadat, je v na obrázku I.1 v příloze I. Do plánu vytíženosti zdrojů v čase by měly být značeny například i plánované dovolené či plánovaná školení a každá činnost by měla obsahovat informaci, jestli je nebo není na kritickém řetězu. Pracovníci by tento plán s časovými termíny ovšem vidět neměli (z důvodu Parkinsonova zákonu a Studentského syndromu). Jim by se měl zobrazovat pouhý seřazený seznam činnos- 48

56 tí, jeho podoba je popsána v následující kapitole. Postup přidání projektu do soustavy projektů je následující: 1. Koordinátor si zobrazí pruhový diagram činností dle zdrojů projektu P. 2. Počínaje první činností koordinátor zařazuje jednotlivé činnosti projektu P do plánu vytíženosti zdrojů v čase. 3. Koordinátor sestaví časový harmonogram projektu P. 4. Koordinátor aktualizuje seznamy činností jednotlivých pracovníků. Krok 1: Koordinátor si zobrazí pruhový diagram činností dle zdrojů projektu P. Zároveň je vhodné, aby měl připravený i plán JAK a bral v potaz logické návaznosti činností. Krok 2: Počínaje první činností koordinátor zařazuje jednotlivé činnosti projektu P do plánu vytíženosti zdrojů v čase. Jednotlivé činnosti lze samozřejmě zařazovat jen do volných políček. Přitom je třeba brát v potaz logické návaznosti činností. Zařazování činností do plánu vytíženosti zdrojů vyžaduje také notnou dávku manažerských rozhodnutí. Představme si situaci, ve které koordinátor potřebuje, aby zdroj X pracoval 1 den na projektu P. Zdroj X je ovšem vytížen celý měsíc činností pro jiný projekt. Potom se koordinátor musí rozhodnout, zda projekt P o celý měsíc posune v čase kvůli této jedné krátké činnosti nebo zda nechá zdroj X přerušit v určitý čas svoji činnost, aby strávil 1 den na činnosti projektu P a pak se opět vrátil k činnosti na jiném projektu. (Ukázkou tohoto případu může být řádek zdroje C v obrázku I.1 v příloze I.) Pokud je k dispozici prostor 4 políček a je potřeba do nich dosadit činnost o odhadu 5 dní, může být následná činnost posunuta v čase, ovšem s plným vědomím, jaké důsledky posun přinese (například zkrácení projektového nárazníku jiného projektu a tím zvýšení rizika nedokončení projektu v termínu). Pořád je třeba mít na paměti, že v plánu pracuje koordinátor pouze s odhady, ne s neměnnými a pevně danými čísly. Drobné (jednodenní) překryvy u dlouhých činností nemusí ve svém důsledku hrát žádnou roli. V rozhodování by koordinátorovi měl pomoct i seznam projektů seřazený dle priority. Stále také může koordinátor zvážit jiné obsazení potřebných zdrojů na projektu P konkrétními lidmi. Pokud je zdroj C nevytížený, může zpracovávat činnost tvorba PDF místo zdroje A, který je plně vytížený jinou prací. Samozřejmě velmi záleží na tom, zda má zdroj C potřebné znalosti a dovednosti. Převedení činnosti na jiného člověka se může projevit i ve změně délky odhadu, neboť méně zkušený programátor stráví na stejné činnosti více času než jeho mnohem zkušenější kolega. Varovným signálem pro možné problémy by měl být pro koordinátora stav, ve kterém má některý z pracovníků svůj řádek v plánu vytíženosti téměř bez mezer 4. V plánu jsou totiž zaznačeny odhady délek činností bez rezerv a je pravděpodobné, že se činnosti mohou zpozdit. Pokud jsou to činnosti z jednoho projektu, tak hrozí zpoždění a čerpání projektového nárazníku u toho daného projektu. Pokud jsou to ovšem činnosti z různých projektů, zpoždění jedné činností způsobí zpoždění a tím i čerpání nárazníků u mnoha projektů. (Ukázkou tohoto případu může být řádek zdroje Z v obrázku I.2 v příloze I.) 4 V případě, že koordinátor identifikuje jeden zdroj, který je v průběhu delšího časového období téměř vždy vytížen bez rezerv na mnoha projektech jedná se o úzké místo systému a v tomto případě lze pro koordinaci využít původní neupravený postup pana Goldratta. 49

57 Krok 3: Koordinátor sestaví časový harmonogram projektu P. Po úspěšném zařazení projektu P do plánu vytíženosti zdrojů v čase lze již snadno připravit časový harmonogram samotného projektu P. V časovém harmonogramu musí být viditelně zaznačeny i nárazníky. Ukázka časového harmonogramu činností je v příloze H. Krok 4: Koordinátor aktualizuje seznamy činností jednotlivých pracovníků. Koordinátor je nejen aktualizuje, ale také je musí domluveným kanálem zaslat pracovníkům, podrobněji je seznam činností pracovníků popsán v další kapitole Postup koordinace Řízení soustavy projektů a koordinace prací probíhá především pomocí sledování plánu vytíženosti zdrojů a časových harmonogramů projektů, tyto plány musejí být udržovány aktuální. Pracovníci se řídí tzv. seznamem činností pro pracovníky připraveným koordinátorem. Principy, které jsou obecně uplatňovány: Obchodování s časovou rezervou jestliže pracovník potřebuje pro svoji činnost více času, kupuje si jej ze společné rezervy (nárazníku). Jestliže potřebuje méně času, než bylo v plánu, prodá tento čas do společné rezervy (nárazníku). Čekání není špatné pokud pracovník čeká, například zpracoval svůj úkol dříve, než byl plán a zatím nemá podklady, neměl on sám tlačit na koordinátora, že nemá práci a potřebuje něco hned dělat, ani by k tomu neměl být tlačen okolím. Pracovníci by měli vědět, že k těmto situacím může docházet a že je to přirozená součást složitého projektového prostředí. Naopak maximální snaha o využití každé minuty pracovníka by v důsledku multitaskingu spíše vedla ke zpoždění projektů Seznam činností pro pracovníky Pracovníci získávají informaci o tom, co mají vykonávat z tzv. seznamu činností pro pracovníky. Tento seznam pro každého pracovníka určuje posloupnost činností v pořadí, ve kterém je dle plánu mají vykonávat. Každá činnost by měla nést informaci o jejím aktuálním stavu a případně barvu pro snazší vizuální rozlišení: plánovaná standardní stav; bílá barva, jsou podklady vše je připraveno pro to, aby pracovník činnost mohl vykonávat; zelená barva, zpožděná činnost už čerpá z některého nárazníku; oranžová barva, vysoce prioritní činnost je natolik důležitá, že vyžaduje přerušení stávající činnosti a započetí prací; červená barva, hotová činnost je dokončená; černá, šedá či modrá barva. Může být i vhodné rozlišení činnosti na kritickém řetězu od ostatních, stejně jako zaznačená priorita projektu, ze kterého činnost je. Pro úložiště seznamů činností jednotlivých pracovníků musí být zvolené místo, ke kterému budou mít všichni pracovníci snadný přístup. Pracovníci spolu s koordinátorem by měli zvolit podobu, jakou se k pracovníkům budou dostávat aktualizované seznamy činností, zda se každý den podívají do systému či jim systém nebo třeba koordinátor bude zasílat seznam činností pomocí u nebo zvolí formu papírovou, například nástěnku v kanceláři apod. Je obvyklé, že se pracovník dostane do situace, kdy čeká, než bude dokončena jiná činnost, která logicky předchází jeho plánované činnosti. Přitom neví, jak dlouho bude muset čekat, seznamy činností jsou oproštěny od jakýchkoliv termínů. Potom je na rozhodnutí koordinátora, jak se pracov- 50

58 ník v takové situaci má obvykle zachovat: buď musí napsat koordinátorovi o rozhodnutí (neefektivní, koordinátor může řešit spousty takových žádostí od pracovníků) nebo postupovat dle předem domluveného postupu. Tímto postupem je myšleno například započetí nejbližší další činnosti, pro kterou jsou již připraveny podklady a přerušení a návrat k původní činnosti, jakmile bude možné ji začít vykonávat (jedná se vlastně o formu multitaskingu, která v tomto případě může být výhodná). Případně může pracovník pracovat na některé volné interní činnosti (samostudium, vzdělávání se, tvorba šablon, tvorba interního pomocného konvertoru), tedy činnosti, která má velmi nízkou prioritu, žádný určený termín dokončení a může být vedena ve zvláštním seznamu. Obrázek 6.7: Ukázka seznamu činností pro pracovníky Povinnosti Povinnosti pracovníků by měly být: hlásit koordinátorovi a zodpovědné osobě projektu, jakmile je činnost dokončena, předat práci dál ihned, jakmile je dokončena, hned po dokončení činnosti začít pracovat na další ze seznamu, v případě čekání postupovat dle předem dohodnutého postupu věnovat dané činnosti 100 % úsilí, tedy žádný multitasking. Povinnosti koordinátora by měly být: každý den sledovat plán vytíženosti zdrojů, aktualizovat jej na základě informací od pracovníků a reagovat na odklony od plánu, aktualizovat pracovníkům seznamy činností. Povinnost zodpovědné osoby by měla být: jakmile je nějaká činnost hotová, zajistit, aby měl pracovník navazující činnosti připraveny podklady a aby v seznamu činností byl následně zobrazen stav jsou podklady Postupy Postup při brzkém dokončení činnosti Pokud činnost skončí dříve, než byl v plánu termín dokončení, koordinátor nemusí v plánech na tuto skutečnost nijak reagovat. Pracovníkovi navazující činnosti se jeho činnost objeví ve stavu jsou podklady dříve, a pokud čekal, tak začne na navazující činnosti také pracovat dříve. Pokud je ještě zaneprázdněn jinou činností, začne pracovat nejpozději až podle plánu (případ zpoždění je řešen níže). 51

59 Pro efektivnější začlenění nových projektů do soustavy však může být výhodné, aby na tuto skutečnost reagoval. Reakcí myslím posun činností projektu, který takto získává náskok, pokud to plán vytíženosti zdrojů dovolí, a přidání náskoku do nárazníku projektu. Posun se vyplatí především v případě výrazného náskoku (4 dny a výše, záleží na obvyklé době trvání činností). Postup při zpoždění začátku činnosti Pokud koordinátor zjistí, že činnost v plánu nezačala v den, kdy byla plánována, musí na tuto skutečnost reagovat. V případě činnosti, která není na kritickém řetězu, by měl v časovém harmonogramu projektu (například projekt P) pouze posunovat pruh znázorňující danou činnost (a případné další navazující činnosti v dané větvi) doprava a tím prorážet nárazník. Pro prorážení nárazníku definoval pan Eliyahu M. Goldratt obecně pravidlo třetin: v pořádku vytvoř plán akce akce Obrázek 6.8: Pravidlo třetin při prorážení nárazníku. Pokud je nárazník proražen do první třetiny, koordinátor by neměl nic podnikat, takový průraz je normálním důsledkem toho, že jsou odhady stanoveny bez rezerv. Jakmile je nárazník proražen do druhé třetiny, již by měl koordinátor zjistit příčinu proražení, důvod zpoždění a odhad, jak dlouho ještě bude dokončení činnosti trvat. Měl by vytvořit záložní plán, jak bude situaci řešit v případě proražení nárazníku (předání práce zkušenějšímu pracovníkovi, přesčasy, zaplacení služeb konzultanta, vyjednání změny požadavků a jiné). Může se také rozhodnout, že bude pouze čerpat z projektového nárazníku, například pokud byl projektový nárazník díky brzkému dokončení několika činností navýšen. Při proražení třetí třetiny by měl jednat dle navrženého plánu a situaci řešit. V případě, že posunem zpožděné činnosti prorazíme nárazník do druhé třetiny, měl by koordinátor v tomto případě označit činnost stavem vysoce prioritní a zajistit tak, aby na činnosti začal pracovník ihned pracovat. Je vhodné se podívat, kterou činnost tím přerušíme. Pokud přerušíme činnost projektu s mnohem vyšší prioritou kvůli projektu s nižší prioritou, nemusí to být v důsledku dobré manažerské rozhodnutí. Postup při zpoždění termínu dokončení činnosti Pokud koordinátor zjistí, že dle plánu měla být činnost již hotová, ale pracovník ji jako hotovou ještě nenahlásil, měl by ji v seznamu činností označit jako zpožděnou a zároveň hlídat prorážení nárazníku a jednat dle pravidla třetin. Postup při kolizích Pokud pracovník pracuje na činnosti se stavem vysoce prioritní a stane se, že další činnost opět získá stav vysoce prioritní, měl by tuto skutečnost projednat s koordinátorem. Případně mohou být nastavena pravidla, která činnost má přednost podle priority projektu, pozice na kritickém řetězu nebo na nekritickém řetězu, zbytkového času v časovém nárazníku větve či projektu. Pozastavení projektu Koordinátor může projekt pozastavit, např. když potřebuje čas na projekt s vyšší prioritou. Často bývají pozastavovány interní rozvojové projekty. Pozastavený projekt je odebrán z plánu vytíženosti zdrojů v čase a ze seznam činností pro pracovníky. Časový harmonogram pozastaveného projektu je 52

60 označen za neplatný. Pokud jej chce znovu obnovit, musí se zbývající část opět začlenit do soustavy projektů Odměňování a delegování V některých textech bývá doporučeno využít obchodování s rezervou v systému odměňování. Pokud pracovník přetáhne odhadovaný čas, ztrácí ze svého banku body odměny. Naopak v případě odevzdání před termínem body odměny získává. Osobně tento způsob nedoporučuji, neboť by potom pracovníci své odhady úmyslně nadhodnocovali, aby jejich šance získat body, které smění za odměnu, byly vyšší. Navíc by měli mít pracovníci zaručeno, že za mírné překročení termínu nebudou nijak trestáni a za vysoké překročení termínu v případě zdůvodnění také trestáni nijak nebudou. Pokud by chtěl koordinátor přenést více odpovědnosti na samotné pracovníky, může poskytnout zodpovědné osobě časový harmonogram projektu a nechat ji, aby sledovala průběh a informovala o průrazech nárazníků či zpoždění začátků činností. Velmi ovšem záleží na postojích a kvalitách pracovníka, neboť pokud bude mít k dispozici časové termíny, snadno může v činnostech, které na projektu vykonává on, sklouznout pod vlivem Studentského syndromu a Parkinsonova zákona ke zpoždění projektu či neefektivním využitím času na projektu Kontrola výkonu I když je metodika CCPM silně zaměřená na eliminaci multitaskingu i z důvodu větší výkonnosti pracovníků, postup kontroly výkonu zde explicitně uveden není. Seznamy činností jsou obdobou techniky ToDo listu uvedené v kapitole a mezi povinnosti pracovníka patří věnovat právě prováděné činnosti 100 % úsilí. Pro systematickou kontrolu výkonu je možné zavést postup uvedený v kapitole Jak začít? Metodika, která je určená pro multiprojektové prostředí se velmi těžko zavádí pokusně na jednom projektu a v případě osvědčení postupně na všech. Podnik se musí rozhodnout a metodiku zavést najednou v podstatě ve formě velkého třesku. Nejvhodnější dobou pro zavedení je období v rámci roku, ve kterém má podnik méně zakázek a projektů a tudíž i méně práce. Všem pracovníkům musí být objasněn důvod, proč se nová metodika zavádí a její hlavní principy. Teprve, když pochopí principy, mohou do důsledku chápat přínos opatření, která se budou zavádět. Inspirativní a dobrou knihou pro zavedení změny v podniku je kniha Náš ledovec se rozpouští [35]. Velmi zjednodušeně lze popsat zavádění ve firmě například takto: 1. Prvním krokem po školení pracovníků je vytvoření plánů či úprava plánu pro všechny stávající projekty, které běží a nové, které se chystají. Především je důležité, aby v nich byly odhady bez rezerv. Tyto plány existují určitý čas paralelně vedle původních plánů. 2. Je třeba sestavit seznam projektů dle priority. 3. Je dobré pro každého pracovníka sepsat seznam činností, které jsou plánované stávající metodikou, a začít využívat označení stavů a barevné značení, aby si na ně postupně pracovníci zvykli. 4. V projektech, kde je to možné (nejsou omezeny smluvenými termíny dodavatelů, konzultantů apod.), lze zbývající rezervy, které v činnostech byly plánovány, přesunout na konec projektu aniž by byl změněn smluvený termín a pracovníci již mohou zkusit pracovat principem štafetového běhu. 5. Koordinátor si začne vést plán vytíženosti zdrojů v čase, některé činnosti z projektů tam budou včetně odhadů s rezervami. 53

61 6. Jak budou postupně dobíhat postaru plánované projekty a nové již budou vkládány dle pravidel metodiky, dostane se koordinátor do stavu, kdy nakonec všechny projekty poběží dle nové metodiky. Hodně záleží na stávajícím systému a firemní kultuře, tedy nastíněný postup nemusí být úplný a vhodný pro každého. 6.3 Koordinace vycházející z agilní metodiky Scrum Podle květnového (2010) průzkumu Forrest Research se metodika Scrum stává nejpoužívanější metodikou pro řízení softwarových projektů. V textu [2] mne zaujaly argumenty pro nasazení této metodiky v reálném podniku a po zvážení dalších agilních metodik jsem ji vybrala jako metodiku se základem vhodným i pro nasazení v multiprojektovém prostředí Princip metodiky Scrum Dokážete si představit, jak sníst slona? Nejlépe to půjde sousto po soustu, tak jak to rozpracovávají metodiky pro time management. How Do You Eat An Elephant? One Bite at a Time. (Bill Hogan, 2004) Potom metodika Scrum dává obdobně návod na to, jak koordinovat velký projekt s notnou dávkou neurčitosti: rozdělit jej na malé části a ty seřadit dle priority. Obrázek 6.9: Princip Scrum metodiky: rozdělení na malé části a seřazení dle pririty. (Autor: Henrik Kniberg; převzato z [36]) Následně v předem domluvených intervalech tzv. sprintech postupně dávat výsledný produkt či cíl projektu dohromady. 54

62 Obrázek 6.10: Princip Scrum metodiky: postupné dodávky produktu ve sprintech. (Autor: Henrik Kniberg; převzato z [36]) Je nutné podotknout, že metodika Scrum obsahuje obecný přístup pro koordinaci a řízení projektů především v oblasti vývoje software, ale již nepopisuje přímo postupy tvorby testů, release management, requirements management, configuration management, verzovací systémy, principy a pravidla dokumentace ani volbu programovacího jazyka. Respektive, částečně je requirements management popsán v rámci předehry projektu a třeba testování je začleněno do každého cyklu sprintu. Nelze však očekávat podrobný popis, tak jako například v rámci metodiky RUP (IBM Rational Unified Process) Pojmy v metodice Scrum Product Backlog je seznam, ve kterém jsou uvedeny všechny požadavky na daný projekt a to v krátké, jasné a srozumitelné podobě, nosič informace o funkcích a vlastnostech či činnostech, co jsou potřeba, seznam věcí, které chtějí mít zákazníci hotové v rámci daného produktu, seřazený podle priority. Zápis musí být srozumitelný jak pro zákazníka, tak i pro tým, tedy neměly by se v něm bez vysvětlení objevit technické programátorské pojmy či odborné neznámé pojmy uvedené zákazníkem. Důležité pravidlo zní: Product Backlog může doplňovat kdokoliv z týmu, tedy nejen zákazník. Ze začátku je obvyklé, že členové týmu, kteří zakázku zpracovávají, požadavky nepřidávají, protože mají obavu z přidělání práce. Někdy bývají do seznamu Product Backlog zahrnuta i rizika, chyby, vylepšení, v podstatě cokoliv vztahujícího se k danému produktu. Vždy by položky měly zůstat napsány pod sebou v seznamu, neboť tento způsob zápisu reprezentuje frontu, která je lidskému chápání srozumitelná. Zákazník se pak lépe v seznamu orientuje a ví, které požadavky jsou v jakém pořadí zpracovávány. Product Backlog musí být přístupný zákazníkovi, ale také všem lidem v týmu. Možnost vidět celý seznam požadavků pomůže programátorům v pochopení, co vše je třeba zvládnout a identifikovat, kde se právě ve frontě požadavků nacházejí a kolik požadavků ještě zbývá. Scrum Master V metodice Scrum se používá několik označení rolí, které jsou klíčové. Jednou z nich je tzv. Scrum master osoba, která je zodpovědná za správný průběh celého procesu a úspěch projektů či zakázek. Nejčastěji roli přebírá projektový manažer či koordinátor týmu, ale dle agilního přístupu by si nejlépe sám tým měl demokraticky zvolit, která osoba bude zastávat pozici Scrum master. Úkolem osoby na této pozici je řídit vývojáře, starat se, aby jim fungovaly počítače, aby měli dostupný software, aby mezi nimi nedocházelo ke sporům a nedorozuměním. Někdy se lze setkat i 55

63 s přístupem, že Scrum Master chodí pro bagety a kafe a především obstarává ty činnosti, které by programátory zdržovaly od práce (dle prezentace [37]). Není vhodné, aby Scrum Master zároveň programoval, neboť v krizových situacích (například v případě nestíhání termínu vydání další verze programu) by se věnoval samotnému programování namísto hledání optimálního řešení situace s nadhledem. Je vhodné, aby zastával projektový manažer pozici Scrum Master? V literatuře bývá často doporučováno, aby pozici Scrum master zastával právě projektový manažer, liniový manažer či koordinátor týmu. Na první pohled se zdá být tato volba logická manažer je osoba, která týmu a jeho potřebám rozumí, umí vyjednávat a jednat správně s lidmi, zvládá konflikty. Pokud ovšem není manažer seznámen s agilním manifestem, principy a vůbec s metodikou Scrum, může docházet k velkým problémům, neboť v krizových situacích se může manažer chovat velmi direktivně a nenechat tým rozhodovat ani se na rozhodování o důležitých věcech podílet. Přitom na rozhodování v týmu jsou agilní metodiky založené. Product Owner Vlastník procesu, projektu, respektive zakázky. Tento člověk bývá obvykle zákazník, v případě interních projektů to je zadavatel projektu. Sprint Základní časovou jednotkou metodiky Scrum je sprint. Jedná se o krátký vývojový cyklus, obvyklá doba trvání je 1 až 4 týdny. Na konci každého sprintu se očekává hotová fungující část software. Správná doba trvání je otázkou mnoha debat, liší se podnik od podniku a doporučením je, že by neměla překročit jeden měsíc. Pomůckou pro stanovení doby sprintu je úvaha nad délkou trvání běžné úlohy. Pokud je tým schopen dokončit většinu úloh do jednoho týdne, může být sprint po jednom či dvou týdnech, v jiném případě bude vhodnější například interval jednoho měsíce. Volba délky sprintu není tak důležitá, jako jeho pravidelnost. Když se tým dostane do rytmu, velmi dobře potom určuje, co je v daném sprintu zvládnutelné. Sprint Backlog Detailní popis úkolů a jednotlivých činností pro daný sprint. Vzniká zpodrobněním a rozepsáním seznamu Product Backlog. Story Označení pro hlavní oblast, která musí být hotova pro odevzdání celého projektu. Často je Product Backlog tvořen jednotlivými Story. Sprint Budget Hodnota označující obvyklý počet bodů (bezrozměrné číslo), který pracovníci ve sprintu zvládnou zpracovat Přizpůsobení metodiky Scrum pro více projektů Metodika Scrum pro jeden projekt se zavádí poměrně snadno a dobře. Na počátku lze již předběžně rozdělit vývoj po jednotlivých cyklech sprintech a určit pracnost, časovou náročnost, stanovit rozpočet a finanční stránku věci. 56

64 Jakmile však dojde na multiprojektové prostředí, situace se zkomplikuje a není jednoduché pracovat se všemi projekty jako s celkem. V textu [38] je sice definována metoda Scrum of scrum jako postup pro více projektů, ovšem předpokladem metody zůstává stav, kdy je pro řešení každého jednoho projektu ustanoven jeden tým a tyto týmy jsou dále řízeny samostatně a nezávisle. Stanovit realistický termín dodání a dodržet jej je v případě multiprojektového prostředí velmi obtížný úkol. Zvláště v případě prostředí, kde je častá změna požadavků, pozdní reakce zákazníků a přeplánovávání projektů. Scrum metodika nabízí způsob, jak v tomto chaotickém prostředí lze efektivně fungovat, ale nedává již návod, jak projekt naplánovat a jak stanovit termín dodání. V této oblasti je třeba ještě dalšího výzkumu, diskusní fóra (např. [39], [40]) obsahují spoustu dotazů zaměřených na použití Scrum metodiky v multiprojektovém prostředí a některé články (např. [38], [41]) píšou o evoluci ve Scrum metodice, vyvíjí nové metody či stanovují hlavní problémy, na které by výzkum v této oblasti měl být zaměřen. Na základě rešerše a studia literatury jsem identifikovala dosavadní navržené možnosti řešení: a) Procentuální rozdělení: projekty vezmou v daném sprintu procentuální část doby pracovníka (jeden projekt 20%, druhý 30% a třetí 50% času) [42]. V případě, kdy pracovník řeší projekty a zároveň například i uživatelskou podporu, lze třeba vyhradit každý den 6 hodin pro práci na sprintu a 2 hodiny pro práci na jiných úkolech neprojektového charakteru. b) Plánovač: jedna osoba spravuje celou soustavu projektů (například pomocí Ganttova diagramu), pracuje s bodovým ohodnocením komplexnosti jednotlivých Story a plánuje je, výsledkem její práce je jeden Product Backlog, ve kterém jsou požadavky všech projektů dle priorit, následně se seznamem Product Backlog pracovníci pracují jako v případě jednoho projektu. c) Intuice: projekty jsou přidávány a řešeny na základě intuice pracovníka či osoby Scrum Master, tato možnost vyžaduje velké zkušenosti a nese velké riziko překročení termínů. d) Plánování v obrysech: projekty jsou plánovány v obrysech a často přeplánovávány dle aktuální situace, plánovací schůzka je obsažena při každém plánování sprintu a obsahuje i výhled na další sprinty k jednotlivým projektům. Následující popis koordinace a postupu se bude věnovat možnosti d) Postup plánování Každý projekt prochází v metodice Scrum třemi fázemi: Předehra - plánování, tvorba seznamu Product Backlog, analýza rizik, volba nástrojů, systémová architektura, návrh, doménová analýza. Hrubý plán projektu, prvotní návrh architektury, přiřazení priority projektu. Hra sprinty, vývoj. Uzavření příprava produktu k finálnímu uvolnění a šíření; integrace, testování, dokumentace (pokud nejsou průběžnou součástí vývoje). K plánování projektu a stanovení termínu dodání dochází v předehře, a pokud projekt a další projekty postupují dobře, není nutné nijak zasahovat. V případě problémů či změn je třeba přeplánování, ovšem vždy k němu dochází jen na tzv. Sprint planning meeting, tedy na schůzce určené k naplánování sprintu. Pokud je třeba zasáhnout hned, musí být celý sprint ukončen a naplánován nový. V případě, že má Scrum Master pocit nutnosti přeplánování několikrát za sprint, indikuje to příliš dlouhou dobu sprintu a řešením je zkrácení intervalu sprintu. Odpovídá to také citátu: nedokážeš-li plánovat přesně, plánuj často (Watts S. Humphrey, volně přeloženo). 57

65 Je na místě si v týmu vyjasnit, zda a jak bude nakládáno s rezervami (viz kapitola 5.4) v časových odhadech, metodika Scrum nedává jednoznačné stanovisko ohledně rezerv. V textu [2] je například doporučeno vynásobení odhadů koeficientem složitosti projektu. Lze také plánovat vše bez rezerv a akumulovat si rezervy na konec projektu. Nadále při popisu koordinace používám taktiku odhadů bez rezerv a akumulaci rezerv na konci projektu. Projekty ve firmě by měly být také seřazeny dle priority a sepsány do podoby aktualizovaného seznamu. Scrum Master pomocí seznamu priorit projektů lépe rozhoduje o zařazení jednotlivých položek Product Backlog seznamu do Sprint Backlog seznamu Kontrola výkonu v metodice Scrum Základem kontroly výkonu v metodice Scrum jsou denní schůzky, tzv. Stand-up meetings či Daily Scrum Meetings. Podrobně jsou již popsány v kapitole 4.4 Systematická kontrola výkonu Postup koordinace Jakmile přijde nový požadavek na projekt, Scrum Master volí následující postup: 1. Přidělit zodpovědnost. 2. Předehrát projekt. 3. Nechat zákazníky zvolit prioritu. 4. Stanovit termín dodání. Všechny zakázky jsou řešeny v rámci tzv. sprintů, postup koordinace je následující: 5. Naplánovat sprint. 6. Sprintovat. 7. Ukázat demo. 8. Zhodnotit sprint. 9. Iterativně postup opakovat. Krok 1: Přidělit zodpovědnost. Každý projekt musí mít přidělenou právě jednu osobu, která je za průběh zakázky a zdárné vyřešení zodpovědná. Tato osoba by měla být vždy poznačena i v databázi zakázek a v případě, že bude chtít projektový manažer informace o postupu či stavu dané zakázky, právě tato osoba mu podá hlášení. Je obvyklé, že se na jednom projektu podílí více osob, než tato jedna, případně lze přidělit i jednotlivé vlastníky požadavků, kdy každý jeden vlastník zodpovídá za zdárnou implementaci svého požadavku. Přiřazení pracovníků na projekty může direktivně udávat Scrum Master nebo tato věc může být projednána v týmu. Obojí má své výhody i nevýhody, direktivní přidělení je rychlé, nezávislé na tom, jestli se sejde celý tým a Scrum Master může sledovat i další cíle (záměrné přidělování různých typů činností nováčkovi na zaškolení apod.). Výběr v týmu více odpovídá agilnímu přístupu, pracovník lépe přijme odpovědnost za něco, co si sám dobrovolně vybral či mu bylo v týmu přiděleno po vyslechnutí jeho výhrad. Při výběru v týmu více hrozí, že pohodlní pracovníci si budou vybírat snadnější úkoly a častěji odmítat práci s výmluvami (například, že jsou přetížení apod.), zatímco aktivní pracovníci se budou hlásit o každý zajímavý a těžký úkol, aniž by zvážili, zda jej spolu s dalšími stihnou či zda na něj mají dostatečné schopnosti a reálně potom přetížení budou. Krok 2: Předehrát projekt. Součástí předehry projektu je nejprve rozhodnutí, zda má projekt pro firmu smysl a zda jej chce realizovat. Je třeba zvážit realizovatelnost, komplexnost, časovou náročnost i prioritu v kontextu ostatních projektů. Dalším podstatným krokem je tvorba seznamu Product Backlog. Pro každý projekt by 58

66 měl být vytvořen samostatný Product Backlog. Není třeba, aby byl detailní, jen musí obsahovat všechny aktivity a hlavní oblasti (Story) které musí být hotovy pro odevzdání projektu. Detailněji budou Story rozděleny na jednotlivé úkoly a úlohy až v průběhu sprintů. Někdy bývá doporučováno vytvořit Product Backlog na základě tzv. předimplementační analýzy (specifikace požadavků). Každou Story je třeba ohodnotit z pohledu náročnosti, neboť součtem hodnocení koordinátor získá přehled o velikosti projektu a může porovnávat projekty mezi sebou. Hodnocení je pomocníkem pro rozhodování o prioritách, zároveň je však třeba mít na paměti, že stále jde o pouhý nepřesný odhad. Nejlepšími jednotkami náročnosti jsou v případě Scrum metodiky body, tedy bezrozměrná čísla, jež označují spíše komplexitu úlohy než pouhou časovou náročnost a jako takové jsou vývojářům bližší (dle [43]). Ze začátku lze například na body konvertovat náročnost určenou v tzv. člověkodnech, později se tým naučí tzv. myslet v bodech a pracovat s nimi velmi přirozeně. Pro samotný proces hodnocení je vhodné využít techniku Plánovací hry z kapitoly Kromě bodů může tým označovat velikost dané Story například formou obvyklou pro značení oblečení: XS, S, M, L, XL, XXL apod. Do předehry projektů bývá také řazena analýza rizik, volba vhodných nástrojů pro vývoj, návrh prvotní architektury, doménová analýza i stanovení hrubého finančního plánu projektu. Krok 3: Nechat zákazníky zvolit prioritu. Ke každé zakázce musí být zvolen právě jeden člověk na pozici Product Owner. Tento člověk rozhoduje o prioritě položek v seznamu Product Backlog dané zakázky a to tak, že seznam řadí od nejvíce prioritního požadavku po ten nejméně prioritní. Častým problémem bývá nezájem zákazníka o větší začlenění do celého procesu a například i o zvolení priority. Pokud mu Scrum Master vysvětlí výhody tohoto začlenění, objasní, jaký profit z toho bude zákazník mít, i tak se nemusí podařit zákazníka do procesu více vtáhnout. Může se stát, že zákazník zvolí ze své firmy nejméně vytíženou osobu, která má dát požadavkům prioritu, a přitom tato osoba o dané zakázce neví vůbec nic. Možné reakce zákazníků na žádost o větší začlenění do procesu: Nemám čas vám vše vysvětlovat, potřebuji funkční e-shop, vy jste tady přece odborníci, za to vás platím. Všechny naše požadavky jsou stejně důležité. Nemohu se tím zabývat, náš obchodní zástupce vám tu prioritu požadavků určí. Představa pravidelného setkávání zákazníka s vývojovým týmem v něm může probudit představu, že na něj máte v plánu přenést svoji práci. Časté ukazování rozpracovaných verzí jej může spíše obtěžovat a ignoruje je, neboť chce vidět až konečný výsledek. Proto je vhodné zvážit, kterého zákazníka se snažit do procesu více vtáhnout a kterého raději ne. Ideálním postupem v případě nezájmu zákazníku o začlenění do procesu může být nenápadné vyptávání při analýze. Na jedné z prvních schůzek se zákazníkem, kdy jsou sepisovány požadavky na produkt, by se pracovník měl ptát, jak je daný požadavek důležitý a poznačovat si tuto prioritu. Pokud je pro něj důležité vše, je vhodné zkusit dotazy zacílit na to, co by chtěl zákazník více a co méně, případně, co by chtěl dříve a co později. Volba jiných slov může pomoci ze zákazníka informaci o prioritě získat. Pokud zákazník nechce spolupracovat a věnovat čas určení priority položek v seznamu požadavků (Product Backlog) dané zakázky, měl by pracovník přidělit prioritu sám dle analýzy a 59

67 svých poznámek a nechat zákazníka takový seznam zrevidovat a potvrdit. Na základě agilního přístupu by se měl pracovník snažit přesvědčit zákazníka, aby to byl on, kdo bude určovat prioritu. Krabicový software V případě vývoje tzv. krabicového software, tedy programů, aplikací či utilit, které jsou určeny širokému spektru zákazníků a jsou volně prodávány, se nabízí otázka, kdo v tomto případě zastává pozici Product Owner. Není možné vybrat jednoho potenciálního zákazníka a toho na tuto pozici dosadit, stejně tak není možné skrýt pod tuto roli lidí, kteří si daný produkt potenciálně koupí. V případě vývoje krabicového software je potřeba se dívat po lidech ve firmě, vždy totiž existuje tzv. Produkt manažer osoba, která sbírá podněty uživatelů, analyzuje je a určuje, jak by měl výsledný produkt vypadat. Přesně tato osoba by potom měla zastávat pozici Product Owner. Zajímavý způsob získávání požadavků (včetně priorit) od zákazníků v případě vylepšování informačního systému je uveden v krátké případové studii v příloze J. Krok 4: Stanovit termín dodání. V týmu jsou postupně brány Story ze seznamu Product Backlog od nejvíce prioritní položky a rozdělovány do jednotlivých sprintů s přihlédnutím k odhadované komplexnosti Story, k dalším úkolům či Story, které již jsou plánované. Cílem je určit, kolik sprintů je pro projekt potřeba a brát v potaz vliv dalších projektů. Tímto postupem je stanoven interní termín dokončení projektu. Při odhadování doby trvání bez rezerv je třeba ještě k vnitřnímu termínu přičíst rezervu a teprve tento termín prezentovat zákazníkovi jako termín dodání. Krok 5: Naplánovat sprint. Plánování probíhá na osobní schůzce, tzv. Sprint planning meeting, které se účastní celý tým a lidé, kteří jsou do projektu zapojeni (vývojáři, analytici, testeři, grafici, Scrum Master). Účast osoby na pozici Product Owner bývá pro případ jednoho projektu doporučována, pro případ více projektů vhodná není, neboť by se schůzka mohla změnit v boj jednotlivých zákazníků o prioritu zpracování jejich projektů. Na možnou změnu názorů v prioritě požadavků může Scrum Master jednotlivé Product Owner osoby kontaktovat před schůzkou em či telefonicky, jejich požadavky na změnu priorit týmu tlumočit. V prvním kroku tým vybere ze Product Backlog seznamů všech projektů ty požadavky a Story, které budou v daném sprintu implementovány, vznikne Sprint Backlog. Tým by si měl na této schůzce ujasnit, že vybraným požadavkům dostatečně rozumí, pokud ne, je na místě vysvětlení a objasnění. Metodika výběru požadavků: Přednost mají požadavky s vyšší prioritou nad těmi s nižší prioritou. Přednost mají požadavky, které logicky předcházejí dalším požadavkům. Přednost mají požadavky projektů s vyšší prioritou nad těmi s nižší prioritou. Je doporučeno naplánovat do úvodních iterací technicky rizikové požadavky. Product Owner každého projektu by měl být seznámen s důvody, proč jsou případně řešeny požadavky s nižší prioritou před těmi s vyšší. Hlavním principem je postupovat podle priority určené Product Ownerem. 60

68 Následně jsou vybrané položky Product Backlogu rozděleny na jednotlivé úlohy. Není nutné rozdělit na úlohy všechny položky, někdy to ani není možné, dokud se daná položka nezačne řešit. Ideální rozpad na úlohy je ten, kdy 1 úloha zabere maximálně 1 den, potom lze velmi snadno sledovat postup na projektu, neboť každý den můžeme buď úlohu označit jako hotovou nebo ne. Při celém procesu plánování sprintu by mělo být cílem sestavit Sprint Backlog tak, aby na konci sprintu bylo hotovo něco, co lze ukázat zákazníkovi (hotov návrh webu, zpracováno grafické rozhraní aplikace, zapracovány požadavky na vyhledávání, hotovy první 3 minuty z 6 minutové animace apod.) Úlohy lze dle doporučení metodiky také ohodnotit v bodech, součet bodů za úlohy by měly odpovídat bodovému hodnocení celku, tedy dané Story či požadavku. Následně sečtením všech úloh zařazených do Sprint backlogu a porovnáním s tzv. hodnotou Sprint Budget (obvyklý počet bodů, který pracovníci ve sprintu zvládnou zpracovat) lze získat názor, zda pracovníci úlohy ve sprintu zvládnou. Pokud se hodnoty liší, je vhodné některé úlohy ze Sprint backlogu vyřadit nebo naopak další přidat. Výsledkem plánování sprintu je Sprint Backlog, který obsahuje jednotlivé úlohy, jež by měly být v daném sprintu zvládnuty, opět nejlépe seřazeny dle priorit. Následně je vhodné do Sprint Backlogu doplnit tzv. stretch tasks úlohy, které nemusí být dokončeny v rámci sprintu a na kterých mohou pracovníci začít pracovat v případě, že dokončí svou práci velmi rychle. Sprint Backlog by měl být uložen v systému či vyvěšen třeba na nástěnce v kanceláři tak, aby k němu každý pracovník měl přístup. Sprint Budget a dovolené Poprvé při tvorbě hodnoty Sprint Budget lze využít přepočet hodin pracovní doby pracovníků na body. Následně se již z dat z historie tým ustálí na určitě bodové hodnotě. Je důležité neopomínat dovolené či plánovaná školení apod., buď je nutné přepočtení na body a snížení celkové hodnoty Sprint Budget, nebo lze s dovolenou u daného pracovníka operovat jako s úkolem časově jej ohodnotit a dosadit do Sprint Backlogu. Více tipů pro zpracování doby dovolené je v textu [44]. Na plánovací schůzce také dochází k plánování nových projektů a případnému přeplánování projektů v případě změn. Přeplánováním myslím posuny a přemístění Story z jednotlivých budoucích sprintů do jiných či vyřazení plánovaných Story projektů s nízkou prioritou apod. Krok 6: Sprintovat. Metodika Scrum neurčuje postup, jak má tým pracovat, aby dosáhl zdárného dokončení všech úkolů. Dokonce se někdy říká, že tým má dovoleno udělat cokoliv, aby dosáhl cílů sprintu tedy dokončení úkolů v seznamu Sprint Backlog. V tomto je třeba být opatrný, cokoliv může pro vývojáře znamenat například vynechání komentářů v kódu či nedůsledné testování, aniž by domysleli důsledky. Proto je vhodné přihlédnout i ke zkušenostem a povahám jednotlivých pracovníků a stanovit firemní pravidla, která by neměla být porušena. Pokud tým získá volnost poprvé, může dojít jak ke Studentskému syndromu, tak i k prokrastinaci. Po několika sprintech se pracovníci naučí, že je pro ně nepříjemné na konci sprintu vysvětlovat, proč daný úkol není hotov, v začátcích ale pomůže podpora osoby na pozici Scrum Master a použití pravidla z kapitoly Polykání žab. Například ve formě, aby se pracovník pokaždé na začátku sprintu věnoval nejprve nejtěžší činnosti, která jej čeká, a až poté pracoval na dalších věcech. Hlavním kontrolním mechanismem postupu jsou denní schůzky (viz 4.4 Systematická kontrola výkonu). Na nich Scrum Master sleduje postup jednotlivých projektů, může radit, usměrňovat postup 61

69 a především reaguje na potíže a problémy. Příjemnou vizualizací postupu je nástěnka, na níž jsou lístečky s úkoly každý den přemisťovány mezi sloupci To Do (v plánu), WIP (rozpracováno, ze zkratky Work in Progress), Done (hotovo). Do sloupce Done přemisťuje úkoly pouze Scrum Master, po tom, co zkontroluje, že úkol je opravdu hotov. Doporučuje se na začátku sprintu stanovit, co pro tým znamená, že úkol je hotov. Obrázek 6.11: Vizualizace postupu pomocí nástěnky, písmena A-F označují pracovníky. V případě, že některý pracovník stíhá svoji práci velmi rychle nebo se dostal do situace, kdy čeká na odezvu zákazníka, může pomoct jinému pracovníkovi, využije tzv. stretch tasks nebo mu Scrum Master přidá další úkol ze seznamu Product Backlog. V případě, že některý pracovník má potíže, buď mu pomůže některý z pracovníků, který stíhá svoje úkoly rychle, nebo Scrum Master přesune jeho další úkoly zpět do seznamu Product Backlog. Na dalším Scrum meetingu se potom bude řešit, jak s nedokončenými a vrácenými úkoly naložit, co je třeba přeplánovat a které projekty třeba i pozastavit. Právě díky denním schůzkám Scrum Master velmi rychle zjistí problémy na projektu a může na ně reagovat. Jak dělat denní schůzky v týmu, který není spolu v kanceláři? Například společnost Seznam.cz využívá videokonferenčních zařízení i prostého přenosu zvuku (informace v prezentaci [45], krátce popsáno v blogu [46]), specifika virtuálních týmů v metodice Scrum popisují články [47], [48], [49]. Krok 7: Ukázat demo. Na konci každého sprintu by měl zákazník vidět demo neúplný produkt s ukázkou vlastností, které byly nově implementovány. Na demo prezentaci často padnou nové požadavky od zákazníka, ty by měl zákazník vložit do seznamu požadavků dle pořadí jejich priority. Zákazník může vyžadovat změny a dochází k vyjednávání (např. pokud implementujeme tuto změnu, termín se prodlouží o 2 62

70 dny nebo můžeme vynechat tento požadavek s nejnižší prioritou ). Stane se, že zákazník si až při zhlédnutí demoverze například u webové publikace vzpomene, že chce publikaci doplnit o komplexní schémata. Potom je třeba zákazníka informovat, že dojde k prodloužení termínu dodání. Nedoporučuji ukazovat demo po každém sprintu, ale spíše zvolit pro každého zákazníka individuálně, ve kterých sprintech dojde k předvedení demo verze. Interně by však prezentace nově implementovaných vlastností proběhnout měla, aby byli pracovníci navyklí, že na konci sprintu musí být něco hotovo. Zákazníkovi například není třeba ukazovat demo verze, ve které byly pouze opraveny všechny chyby, ale nebylo implementováno nic nového, neboť zákazník považuje opravu chyb za samozřejmou součást vývoje. Krok 8: Zhodnotit sprint. Na konci každého sprintu by měla proběhnout v týmu zpětná vazba, Scrum Master by se měl zeptat, co šlo dobře, co by mohlo být lepší a co by tým mohl příště udělat jinak. V pojmech metodiky Scrum se můžete setkat s termíny Sprint Review a Sprint Retrospective. Krok 9: Iterativně postup opakovat. Na dalším Scrum planning meeting se plánuje další sprint, opět následuje sprint, ukázka demo verze a zhodnocení sprintu Jak začít? Metodika Scrum i jiné agilní metodiky doporučují začít zavádět metodiku na malém projektu s nízkým rizikem a malou důležitostí. Ovšem v případě multiprojektového prostředí, kde jsou jednotlivé projekty provázané se zdroji, není možné začít jen na jednom projektu. Jako první musí tým pochopit agilní principy a samotnou metodiku, nejlépe na školení. I školení ale může probíhat agilně, například pomocí hry (příklad v textu [50]). V textu [2] jsou popsána kritéria, pomocí kterých se podnik může rozhodovat, zda vůbec agilní metodiky má zavést. Protože je přechod na agilní přístup velkou změnou, doporučuji postupovat v osmi krocích zavedení změny dle knihy [35]. Někteří projektoví manažeři doporučují i tzv. plíživý postup zavádění metodiky (v textu [51]), tedy například nenápadné zavedení pravidelných schůzek, na kterých padnou dotazy typické pro denní schůzky. Koordinátor či projektový manažer může začít postupně plánovat práci do podoby iterativních cyklů sám a začít se ptát pracovníků na jejich časové odhady apod. Potom pracovníkům přijde přechod na Scrum metodiku přirozený. 6.4 Srovnání Srovnávat jednotlivé metodiky není jednoduché. Výzkumné týmy se nejčastěji zaměřují na časovou stránku věci a srovnávají průměrné doby zpracování činností modelovou simulací (např. [33]). V procesu rozhodování o nasazení metodiky v reálné praxi si však koordinátor klade otázky: Budu schopen hned po úvodní analýze sdělit zákazníkovi konečný termín, který je reálné dodržet? Zatíží metodika tým velkým množstvím administrativních úkonů? Bude mě tým potřebovat na plný úvazek nebo lze procesy metodiky automatizovat? Dostanou pracovníci větší volnost ve výběru činnosti, na které mají pracovat, nebo z nich metodika vytvoří jen výkonné stroje, které by nad pořadím činností přemýšlet ani neměli? Budu mít jak kontrolovat jejich práci? 63

71 Pozice projektového manažera a často i koordinátora je (v České republice) ještě stále často spojena s mocí, pravomocemi a pověřením rozhodovat za ostatní namísto opravdového vedení týmu (ve smyslu anglického leading). Proto si někteří koordinátoři budou klást také otázky, jak změní metodika jejich pozici a zda je nebude omezovat. Přijetí vybrané metodiky ve firmě potom závisí na mnoha faktorech: kultura organizace, struktura hierarchie, postoj pracovníků ke změnám a další (v textu [2]). Proto v této práci nezazní určení nejlepší metodiky ani zde nebude uvedeno srovnání, ze kterého by koordinátorovi kroužkováním položek vyšla metodika přesně pro něj. Cílem této práce je představit jednotlivé možnosti, výběr nejvhodnější je ponechán na úvaze koordinátora. V příloze K uvádím pouze stručnou tabulku vlastností jednotlivých metodik. 64

72 7 Využití vybrané možnosti v praxi Nasazení vybraného postupu koordinace proběhlo v týmu, kde pracuji na pozici koordinátorky. Rozhodla jsem se pro postup koordinace vycházející z agilní metodiky Scrum, neboť nejlépe podporoval naše potřeby týmu a projektu. Postupné kroky a příprava probíhaly již od srpna 2010, za plné nasazení vybrané metodiky ale považuji až začátek října Vyhodnocení přínosů metodiky proběhlo na konci prosince Některé detailní informace budou z důvodu ochrany zákazníků pozměněny, podstata však zůstane zachována. 7.1 Představení projektu a týmu Servisní středisko pro podporu e-learningu na MU (dále zkráceně jen servisní středisko) je celouniverzitní pracoviště, které působí na Masarykově univerzitě již od roku Počet pracovníků v průběhu let kolísá, v době zavádění metodiky tým čítal celkem 8 pracovníků. Pracoviště poskytuje vyučujícím Masarykovy univerzity služby, které se týkají elektronické podpory výuky a tvorby multimediálních výukových pomůcek. Pro bližší představu, výstupem jsou webové výukové publikace, interaktivní tutoriály, elektronické slovníky, digitální knihovny, 2D i 3D animace a vizualizace procesů, drobné aplikace a programy či zpracované video a audio soubory. Činnost střediska je financována z projektu z Operačního programu Vzdělávání pro konkurenceschopnost díky Evropskému sociálnímu fondu a státnímu rozpočtu České republiky. Pro koordinaci a získávání zakázek vyplývá, že zákazníci vyučující za služby neplatí. Cílem projektu je zpracovat co nejvíce multimediálních pomůcek a inovovat co nejvíce předmětů na Masarykově univerzitě. Pracoviště je součástí Centra výpočetní techniky na Fakultě informatiky. Tým Každý pracovník je odborníkem na několik oblastí zpracování multimedií a také na oblast tvorby aplikací a elektronických výukových pomůcek. Pracovníci nesdílejí jednu kancelář, mají rozdílné pracovní úvazky a často jezdí na schůzky s vyučujícími proto většina komunikace probíhá elektronickou cestou a tým se pravidelně setkává na osobní schůzce jedenkrát týdně. Hierarchicky jsou pracovníci podřízeni koordinátorovi týmu. Projekty Požadavek na zpracování multimediálního díla je interně označován zakázka, v terminologii projektového řízení však plně odpovídá definici projektu. Veškerá práce je řízena projektově, doba zpracování jednoho projektu kolísá od 1 týdne až po 16 měsíců, přičemž na jednom projektu se podílí často více pracovníků. Některé projekty nemají stanovený přesný termín, dostačující je zpracování do začátku následujícího semestru, jiné jsou striktně vázané například na termín konference, blokové výuky či zkoušky. Počet rozpracovaných projektů v jednom okamžiku kolísá od 4 projektů k 28 projektům. 7.2 Stav před nasazením metodiky a očekávané přínosy Před nasazením vybrané možnosti koordinace nebyla k řízení projektů využívána žádná známá metodika, nebyly použity žádné softwarové nástroje a metody určené pro řízení projektů. Projekty byly řízeny na základě intuice koordinátora, neformálně. Důvodem byla nevhodnost a selhání standard- 65

73 ních metod (metoda Kritické cesty, standardní CCPM) v silně multiprojektovém prostředí plném změn. Odpovědnost za řádné a kvalitní zpracování projektu nesl pracovník, který jím byl pověřen. Odpovědnost za dodržení slíbených termínů nesl koordinátor, stejně jako odpovědnost za důsledky přidání nového projektu do soustavy projektů. Jak již bylo zmíněno v kapitole Princip metodiky Scrum, v popisu metodiky není podrobně popsána tvorba testů, release management, knowledge management či pravidla dokumentace. Pro zavedení postupu koordinace to však nebylo překážkou, neboť tyto oblasti jsou v servisním středisku již dostatečně a dobře nastaveny a popsány pomocí procesů. Problémy stávajícího přístupu k řízení projektů Projekty v akademickém doprovází požadavky na samé hraně technologie a možností spolu s častými požadavky na změny a čekáním na odezvu od zákazníka. Odhadování doby trvání bylo nepřesné a nespolehlivé, vzhledem k objemu tvůrčí práce. Do projektů byla započítána velká časová rezerva, která byla bohužel často vyčerpána. Častou situací byl stav, kdy pět projektů se v jednom týdnu dostalo do situace čekání na podklady. Koordinátor do soustavy projektů tedy přidal pět nových projektů, aby pracovníci měli na čem pracovat a v okamžiku rozběhnutí původních projektů byli pracovníci zahlceni a přetíženi. Protože důsledky za přidání nového projektu do soustavy nesl koordinátor, byl to on, kdo někdy nakonec pomáhal s programováním, testováním i plněním dat namísto řádného řízení týmu jen proto, aby se stihnul slíbený termín dokončení. Docházelo k překračování nejen interních termínu dokončení projektu, ale i k překročení termínů slíbených zákazníkovi. Koordinátor neměl dostatečnou informaci o opravdovém rozsahu projektu, co se týká velikosti a pracnosti. Projekty byly pouze kategorizovány dle předem stanovených kritérií bez přihlédnutí k individuálním a často technicky náročným detailům. Potom docházelo k přetížení pracovníků, neboť jim byl bez předchozí diskuse přiřazen nový projekt, pracnost přidělených projektů již přesahovala rámec úvazku pracovníka a docházelo ke zpoždění dokončení činností. Nové projekty byly automaticky přidány do soustavy, nebyl stanoven kontrolní mechanismus, který by jejich přidávání omezil, neboť vzhledem k častému čekání byla pravděpodobnost, že se brzy dostanou na řadu, velká. Očekávané přínosy zavedení vybrané možnosti koordinace Před zavedením vybrané možnosti koordinace jsem stanovila podmínky, po jejichž splnění budu zavedení metodiky považovat za přínosné a v průběhu realizace jsem sledovala jejich plnění: 1. Proces přidání nového projektu do soustavy musí být přehledný a nesmí být příliš rizikový. 2. Postup koordinace musí umožnit snadnou reakci na změny, nenáročné přeplánování projektů a podporu rychlých a včasných manažerských rozhodnutí. 3. Změny v projektech poskytují týmu nové a žádané příležitosti, proto nesmí být potlačovány % slíbených termínů dodání musí být dodrženo. 5. Pracovníci by neměli pocítit příliš administrativního zatížení spojeného s novou metodikou koordinace. 6. Pracovníci by neměli být přetěžováni velkým množstvím projektů o vysoké míře pracnosti. 7.2 Nasazení postupu Před samotným postupem je třeba si ujasnit silné a slabé stránky zavádění nové metodiky stejně jako hrozby a příležitosti pomocí tzv. SWOT analýzy (v příloze L). Na počátku zavádění změn v projektech je také třeba řádně zvážit rizika, která s sebou změny ponesou. Pro případ zavedení 66

74 upravené metodiky Scrum v servisním středisku jsem zvolila kvalitativní metodu určení rizik, postupovala jsem dle knihy [7]. Analýza rizik je uvedena v příloze M. Inspirovala jsem se částečně tzv. plíživým postupem zavádění metodiky [51]. S pracovníky byla probrána stávající situace a potřeba nového postupu koordinace, školení na agilní přístupy a metodiku Scrum však plánováno nebylo. Od srpna 2010 byly postupně nasazovány základní prvky metodiky, krok za krokem každý týden, než bylo začátkem října 2010 dosaženo plného nasazení nového postupu koordinace. Vytvoření Product Backlog seznamů Pro pracovníky nebylo problematické vytvořit a udržovat pro každý projekt samostatný Product Backlog. Několik diskusí ovšem proběhlo nad formou uložení v systému zakázek takovým způsobem, aby nebyla aktualizace a určení priorit administrativně a časově náročná. V příloze N je názorně zobrazeno konkrétního umístění Product Backlog seznamů jednotlivých projektů. Role Product Owner v projektech Zapojit zákazníka více do procesu určení priority požadavků a častých zhlédnutí demo verzí se podařilo jen zčásti. Vyučující ocenili průběžné zasílání demo verzí, ke kterým se mohli vyjádřit. Velice brzy jsme získali zpětnou vazbu a včas i změny a upřesnění požadavků. Příliš časté zasílání demo verzí však bylo spíše kontraproduktivní. V případě drobných změn (zpracování dalších 7 HTML stran z 60 stránkové publikace) nereagovali či chtěli vidět až úplný výsledek a nebýt obtěžováni drobnými přírůstky. Až na základě zkušeností jsme pro každého vyučujícího schopni odhadnout optimální míru pro zasílání demo verzí. Určení priorit požadavků získávají pracovníci na úvodní osobní schůzce se zákazníkem, změny v prioritách vyjednávají nejčastěji telefonicky, méně přes y. Způsob získávání je založen na vhodném dotazování, co by zákazník chtěl dříve, co je pro něj důležité. Plánování Využíváme přístup plánování v obrysech, u zakázek je stanovena jejich pracnost a jsou rozplánovány do jednotlivých sprintů s přihlédnutím k výhledovému měsíčnímu plánu. Je stanoven předběžný interní termín dokončení a termín odevzdání zákazníkovi, v němž je zahrnuta i rezerva. Na Sprint Planning meeting, které je pracovníkům prezentováno jako obvyklá schůzka, dochází nejen k předehraní nových zakázek, ale především k plánování sprintu. Obrysy v plánech získávají konkrétnější podobu, pracovníci sdělují, na kterých zakázkách budou pracovat (je zvážena priorita zakázek, jejich rozsah) a následně vybírají Story dle jejich pořadí. Story jsou rozloženy na samostatné úkoly. Pokud například pracovník bude pracovat na tvorbě HTML stránek publikace a ví, že nestihne celou publikaci, je úloha definována například v počtu stránek: zpracovat 20 HTML stran z publikace XY. Důvodem je měření postupu na projektu i kontrola výkonu pracovníka. Není využit Sprint Budget, neboť se pracovníci naučili díky pravidelnosti sprintu velmi dobře odhadovat, co opravdu lze v daném sprintu zvládnout. Časté je přeplánovávání a manažerská rozhodnutí ve formě pozastavení projektů s nízkou prioritou, přerozdělení práce, změna technologie, to vše z důvodu změn. Zodpovědnost za zpracování zakázky přiděluji ve větší míře direktivně, neboť je to rychlejší způsob. Snažím se pracovníky přiřazovat na různé typy úkolů, aby získali více zkušeností, znalostí a dovedností a mohli zastoupit své kolegy v případě nemoci. Je to také obranný mechanismus, jak při vysoké fluktuaci pracovníků zajistit stálé portfolio dovedností a technologií. 67

75 Týdenní sprinty Zvolila jsem za interval sprintů 1 týden vzhledem k velkému rozpětí zakázek a prostředí plnému změn. Navázala jsem tak na tradici týdenních schůzek s pracovníky, proto byl přechod na týdenní sprinty přirozený. Sprint planning meeting se koná pravidelně v předem určený čas a den v týdnu. Z každé schůzky je pořízen zápis, který obsahuje Sprint Backlog seznamy, zvlášť pro každého pracovníka. Ukázka části zápisu je v příloze O. Do Sprint Backlog seznamu jsou zahrnuty i adminitrativní činnosti, které byly dříve pracovníkům zadávány ve formě týdenních úkolů (viz kapitola 4.3.3) Denní schůzky Důležitou součást kontroly výkonu a postupu na projektech tvoří ve Scrum metodice denní schůzky. Bohužel se mi nepodařilo je zavést, pracovníci nesdílejí jednu kancelář, mají rozdílné pracovní úvazky a často jezdí na schůzky s vyučujícími, proto je denní setkávání organizačně a časově příliš náročné. Využití videokonferenční techniky či mobilních telefonů bylo také vyhodnoceno jako nevhodné. Právě pravidelné denní schůzky jsou podstatným mechanismem pro kontrolu výkonu, proto bylo třeba je nahradit jinak. Pracovníci každý den nahrávají výsledky své práce do společného úložiště zakázek, které koordinátor kontroluje, a z každé schůzky s vyučujícím pořizují krátký zápis. Jejich povinností je vést pracovní výkaz. Otázky typické pro denní schůzky jsou pokládány na týdenních Sprint planning meeting. 7.3 Vyhodnocení Zavedení vybrané možnosti koordinace jsem hodnotila z pohledu splnění stanovených podmínek: Podmínka 1: Proces přidání nového projektu do soustavy musí být přehledný a nesmí být příliš rizikový. Kontrolním mechanismem procesu přidání nového projektu (v servisní, středisku označovaném jako zakázka) do soustavy projektů jsou nyní sami pracovníci. Zakázky jsou předehrány na schůzce Scrum planning meeting, které se účastní všichni členové týmu a mohou se vyjádřit k realizovatelnosti, plánu, stejně jako ke stanovení interního termínu a termínu pro zákazníka. Začlenění týmu do procesu plánování považuji za motivující faktor, pracovníci jsou dle mého názoru silněji motivováni splnit termíny, na jejichž stanovení se přímo podíleli. V průběhu října až prosince jsem srovnávala termíny, které bych zakázce stanovila sama a které byly stanoveny v týmu. V případě dvou zakázek byly velmi odlišné, odhad pracovníků byl násobně větší a v důsledku se díky němu odvrátilo riziko nesplnění termínu, protože reálná doba zpracování zakázky spíše odpovídala odhadu pracovníků. V šesti případech se odhad lišil opačným způsobem, odhad pracovníků byl mnohem nižší a zbývalo větší množství volného času pracovníka, než bych počítala. Mohla jsem tedy včas realizovat drobnou kampaň pro získání určitého typu zakázek a efektivně čas pracovníka využít. Výsledek: Podmínka 1 byla splněna. Podmínka 2: Postup koordinace musí umožnit snadnou reakci na změny, nenáročné přeplánování projektů a podporu rychlých a včasných manažerských rozhodnutí. Časté plánování v podobě týdenních Sprint planning meeting je vyhovující způsob podporující reakci na změny. Týden je pro tým vždy stabilní jednotkou, pracovníci mají stanovené úkoly ve Sprint Backlog seznamu, stretch tasks pro případ, že práce na projektech půjde dobře či se naopak dostanou do stavu čekání. 68

76 Veškeré změny, problémy, nápady jsou diskutovány při plánování dalšího sprintu. Probírají se postupy, jak jednat v případě čekajících projektů, jak získat podklady od vyučujícího co nejdříve a neprodlužovat tak dobu nečinnosti na projektu. Součástí je i strategie vyjednávání o posunu termínu dodání v případě, že se čeká na vyučujícího. Identifikované problémy, pokud nebyly vyřešeny za pomoci kolegů už v týdnu, jsou popsány a vybranou metodou týmového řešení (brainstorming, graf rybí páteře či šestislovný graf v servisním středisku je v téměř 95 % případů využíván brainstorming) je nalezeno nejvhodnější řešení. Po dokončení sprintu následuje dle metodiky ukázka demo neúplného produktu pro každý projekt. Pracovníci někdy posílají demo ihned v průběhu týdne, jakmile potřebný úkol dokončí, jinak si ukázku demo ponechají až na společnou schůzku. Právě časté ukázky demo verzí produktů umožňují koordinátorovi učinit včasná rozhodnutí například o změně technologie. Plány projektů mají podobu jednoduchého rozdělení Story do sprintů. Pracovníci zpracovávají výhledové měsíční plány, ze kterých je patrné předběžné zatížení jednotlivých zdrojů. Samotný rozpad na úlohy je prováděn až na Sprint planning meeting, stejně jako finální přidělení úloh na zdroje. Systém je proto vysoce flexibilní, koordinátor má například snadnou možnost přerozdělit úlohy na jiné pracovníky, než bylo plánováno (s přihlédnutím k měsíčním plánům). V případě zpoždění prací na projektech často dochází k pozastavení projektů s nízkou prioritou (interní vývojové či výzkumné projekty) a práce je přerozdělena mezi pracovníky pozastavených projektů. Díky této vlastnosti se daří případné zpoždění na projektech zvládnout. Výsledek: Podmínka 2 byla splněna. Podmínka 3: Změny v projektech poskytují týmu nové a žádané příležitosti, proto nesmí být potlačovány. Změny se mohou týkat samotných požadavků na aplikaci, web, animaci i například jejich priority. Je obvyklé, že si vyučující služby střediska zkouší, předloží jen několik požadavků a pokud jsou s prvními demo verzemi spokojeni, přidají další požadavky. Někdy může dojít k situaci, že je dosavadní práce zahozena a produkt je vytvořen technologií vhodnější pro nové požadavky. I když jsou tyto změny provázeny složitějšími vyjednáváním o termínech, ve svém důsledku se servisnímu středisku vyplatí. Product Backlog reprezentuje jednotlivé požadavky v zakázce a pracovníci jej průběžně doplňují či mění pořadí jednotlivých Story dle poznatků ze schůzek a telefonátů se zákazníky. V případě rozsáhlých změn jsou na Sprint planning meeting upraveny i výhledové měsíční plány. Vzhledem k mechanismu finálního rozpadu Story na úlohy až na Sprinning planning meeting se pracovníci nemusejí obávat, že úpravami a změnami v jednotlivých Product Backlog seznamech naruší již pracně sestavené plány všech činností na projektu, jak by tomu mohlo být za použití standardních technik projektového řízení (například metoda Kritická cesta). Žádné podrobné a neměnné plány projektů nejsou vytvářeny. Výsledek: Podmínka 3 byl splněna. Podmínka 4: 90 % slíbených termínů dodání musí být dodrženo. Za období 1. říjen 2010 až 31. prosinec 2010 se v servisním středisku podařilo dodržet 84,2 % slíbených termínů v zakázkách. Do výpočtu byly zahrnuty i průběžné termíny, takže u probíhajících projektů je šance, že se slíbený konečný termín odevzdání produktu dodržet podaří. Tři měsíce jsou krátkým časovým obdobím na to, aby se dodržování termínů podařilo, neboť byly zpracovávány ještě i projekty, jejichž termíny byly stanoveny před zavedením metodiky. 69

77 Výsledek: Podmínka 4 nebyla splněna. Podmínka 5: Pracovníci by neměli pocítit příliš administrativního zatížení spojeného s novou metodikou koordinace. Jedním z vážných rizik zavedení nové metodiky (viz příloha M) bylo i odmítnutí metodiky týmem z důvodu přílišného zatížení administrativními činnostmi. Forma financování činnosti servisního střediska s sebou nese velké množství administrativní zátěže, proto každý další požadavek na vyplňování formulářů, tabulek či vedení jakékoliv evidence je pracovníky vnímán nelibě a stává se z něj v případě prosazení stresový faktor. Za zvýšený administrativní požadavek jsem osobně vnímala zavedení Product Backlog seznamů. Dříve pracovníci do systému zakázek pouze doplnili název zakázky a požadavky sepsali e- mailem pouze v počátku zpracování zakázky, pozdější změny měli uloženy jen v paměti, některé v e- mailové komunikaci se zákazníkem. Nově je požadována evidence jednotlivých Story a požadavků zákazníka včetně aktualizací. Jako první nápad jsem předložila samostatné soubory, které budou ze systému zakázek linkovány. Udržování mnoha souborů a přepínání se mezi systémy a stránkami pracovníci odmítli a předložili jednoduchý návod nahrazení kolonky Název zakázky seznamem Story, jehož pořadí určuje prioritu (viz Příloha N). Ten byl následně přijat a je úspěšně používán. Další administrativní zátěží bylo stanovení pracnosti jednotlivých zakázek. Pracovníci pochybovali o přínosu evidence pracnosti. Z jejich pohledu se jednalo o zbytečnost, z pohledu kordinátora o potřebnou informaci, která umožňuje nepřetěžovat pracovníky dalšími zakázkami, srovnávat zakázky mezi sebou a nepodceňovat některé zakázky z pohledu času ( ten jednoduchý web přece musí pracovník X zvládnout sám do dvou týdnů ). Po vysvětlení tohoto na první pohled skrytého významu na evidenci přistoupili. Pracovníkům bylo nabídnuto hodnocení v týdnech, bodech či velikostech oblečení (S, M, L, XL, XXL) s převodem na člověkodny či člověkotýdny pro začátek. Zvítězila metafora velikostí oblečení a tu pracovníci používají. Na závěrečném zhodnocení zavedení metodiky se pracovníci shodli, že administrativní zatížení, které nová metodika zavedla, je snesitelné a nevnímají jej jako problematické. Výsledek: Podmínka 5 byla splněna. Podmínka 6: Pracovníci by neměli být přetěžováni velkým množstvím projektů o vysoké míře pracnosti. Zavedení evidence pracnosti zakázek umožnilo lepší vhled do zakázek, které zpracovává jeden pracovník. Není již pracovníkovi přidělována zodpovědnost za zakázku o pracnosti například L, pokud již má dvě zakázky o pracnosti XL. Před zavedením metodiky by k této situaci jistě došlo a také často docházelo. Na druhou stranu, pracovníci nejsou nepřiměřeně zatěžováni ani množstvím drobných úkolů nesouvisejících se zakázkami (například tvorba statistik, případových studií, novinek a článků). Na základě přehledu činností a úkolů v daném sprintu je snazší odhadnout, kterému pracovníkovi lze úkoly zadat a u kterého by již byla ohrožena činnost na zakázkách. Výsledek: Podmínka 6 byla splněna. Pět ze šesti stanovených podmínek se podařilo splnit, zavedení metodiky považuji za úspěšné. V hodnocení nebyla sledována výkonnost pracovníků, neboť aspekty práce pracovníků servisního střediska neumožňovaly v současné době zavést denní schůzky (viz kapitola 4.4 Systematická kont- 70

78 rola výkonu). I když je zvoleno náhradní možnosti kontroly výkonu, osobně považuji denní schůzky za nejlepší možné řešení. Závěrem si dovolím přidat jeden poznatek, který jsem identifikovala a který by byl spíše podnětem pro psychologický výzkum. Zavedení metodiky Scrum zbavuje koordinátora některých pravomocí, rozhodování i plánování je přenášeno na celý tým. Zprvu nemusí být pro koordinátora snadné vydržet v této roli označené Scrum master a hrát ji zodpovědně tak, jak si přístup agilních metodik žádá. Teprve po době několika týdnů na základě prvních viditelných výsledků se z direktivního nadřízeného může stát Scrum master. Osobně bych ocenila článek či metodický text, který by koordinátora na tento přechod připravil. 71

79 8 Závěr Již v úvodu bylo zmíněno, že cílem této práce je přidání dílků puzzle a sestavování pomyslného obrazu multiprojektového prostředí. Metafory a připodobnění umožňují lidstvu již dlouho vyjádřit mnoho jen v několika řádcích a obrazech. Proto se v závěru k této metafoře navracím a přínos mé práce popisuji přes dílky puzzle. Prvním dílkem bylo představení metafor pro pochopení multiprojektového prostředí. Jen díky řádnému pochopení prostředí, ve kterém se koordinátor či projektový manažer ocitá, může využívat správné techniky a dělat správná rozhodnutí. Na základě roční stáže a zkušeností z praxe jsem identifikovala a analyzovala dvě hlavní problematické oblasti, které multiprojektové prostředí s převahou tvůrčí činnosti provází: nedostatečný výkon pracovníků a jeho kontrola a oblast plánování. V obou oblastech jsou v rámci této práce popsány hlavní příčiny problémů a negativní vlivy. Na základě studia literatury a článků čtenáři představuji vybrané techniky či drobné nástroje, které mu umožní negativní vlivy a problémy eliminovat. Dvě jednoduché techniky: Prověrka firemních pravidel, Týdenní úkoly vznikly na základě vlastních zkušeností z praxe. Pochopení a následné vyřešení problémů ve dvou popsaných oblastech představují dva složené dílky puzzle, které jsou k pochopení všech aspektů obrazu multiprojektového prostředí nezbytné. Na poli projektového řízení se počátkem 21. století výzkum i praxe začaly orientovat třemi hlavními směry: automatická synchronizace projektů, rozvíjení myšlenek E. M. Goldratta a oblast agilních metodik. Metody koordinace představené v této práci reprezentují jednotlivé směry, důraz je kladen na dva poslední zmíněné. Při studiu literatury jsem očekávala, že jak myšlenky a přístupy pana Goldratta, tak i některou agilní metodiku již někdo přenesl do multiprojektového prostředí s převahou tvůrčí činnosti. Očekávání se nenaplnilo, myšlenky rozšíření a úprav se objevují jen v náznacích, ucelený popis koordinace chyběl. Volné místo je tedy zaplněno popsanou úpravou metodik CCPM a Scrum, neboť považuji za vhodné stavět na základech již ověřených přístupů a myšlenek než se pokoušet vytvářet úplně nové. Na základě plného pochopení zmíněných metodik v mnoha souvislostech a následného podrobení vlivů multiprojektového prostředí jsem některá pravidla přidala, některá vynechala a jiná přizpůsobila. Vznikly dva ucelené postupy krok za krokem doplněné o praktické tipy a schémata v přílohách, které tvoří dva chybějící dílky puzzle do obrazu. Postup založený na metodice Scrum jsem úspěšně nasadila v reálné praxi, stanovila očekávané přínosy a sledovala jejich naplnění. Obraz multiprojektového prostředí ještě není sestaven a možných směrů dalšího výzkumu je mnoho. Uvedená upravená metodika dle CCPM ještě není vyzkoušena v praxi, metafora Čínského draka také dosud není kriticky zhodnocena a více rozvedena. Aplikace přístupů z průmyslu do IT odvětví ve formě Lean Development metodiky a Kanban techniky je spolu s evolucí Scrum metody (v článku [38]) další prázdnou částí puzzle obrazu, kterou je třeba zaplnit dílky. 72

80 9 Literatura [1] Slovník cizích slov.net. Slovník cizích slov online [online]. Ostrava: Studio Enfaces, 2006, 2010 [cit. 30. prosince 2010]. Dostupné na Internetu: < [2] KOTT, Petr. Nasazení agilní metodiky : diplomová práce [online]. Brno : Masarykova univerzita, Fakulta informatiky, s. Vedoucí diplomové práce RNDr. Jaroslav Ráček, Ph.D. [cit. 30. prosince 2010]. Dostupné na Internetu: < [3] Wikipedia contributors. Wikipedia, The Free Encyclopedia [online]. Wikimedia Foundation Inc. [cit. 30. prosince 2010]. Dostupné na Internetu: < [4] PALETA, Petr. Co programátory ve škole neučí : aneb softwarové inženýrství v reálné praxi. 1. vyd. Praha : Computer Press, s. ISBN [5] PROCHÁZKA, Jaroslav. Problémy při zavádění agilních přístupů. Systémová integrace [online], 2008, 15, 3, [cit. 30. prosince 2010]. Dostupné na Internetu: < ISSN: [6] STANÍČEK, Zdenko. Prezentace v předmětu PV098 Řízení implementace IS. Masarykova univerzita : Fakulta informatiky, [7] ROSENAU, Milton D., BRUNOVSKÁ, Eva. Řízení projektů. Vyd. 3. Brno : Computer Press, s. ISBN [8] ONDRŮŠEK, Petr. Zkušenosti s metodikou Kritický řetěz : diplomová práce [online]. Brno : Masarykova univerzita, Fakulta informatiky, s. Vedoucí diplomové práce prof. RNDr. Jaroslav Král, DrSc. [cit. 30. prosince 2010]. Dostupné na Internetu: < [9] GOLDRATT, Eliyahu M., COX, Jeff. Cíl : proces trvalého zlepšování. 2. přepracované vyd. Praha : InterQuality, s. ISBN [10] Společnost pro projektové řízení. Národní standard kompetencí projektového řízení [online]. Verze 3.1, vydání druhé revidované. Brno: VUT v Brně ve spolupráci se Společností pro projektové řízení, o. s., 2010 [cit. 30. prosince 2010] s. Dostupné na Internetu: < ISBN [11] BANNISTER, Frank, REMENYI, Dan. Multitasking: the Uncertain Impact of Technology on Knowledge Workers and Managers. In Proceedings of the 2nd European Conference on Information Management and Evaluation. UK: Academic Conferences Limited, 2008, p ISBN: [12] WALLIS, Claudia. genm: The Multitasking Generation. TIME [online], 2006, Vol. 167 No. 13, [cit. 30. prosince 2010], p Dostupné na Internetu: < [13] BECK, Kent, GRENNING, James, MARTIN, Robert C., et al. Manifesto for Agile Software Development [online] [cit. 30. prosince 2010]. Dostupné na Internetu: < 73

81 [14] JURKA, Radovan. Projektové řízení : diplomová práce [online]. Brno : Masarykova univerzita, Ekonomicko-správní fakulta, s. Vedoucí diplomové práce Ing. František Kalouda, CSc., MBA, [cit. 30. prosince 2010]. Dostupné na Internetu: < [15] STANÍČEK, Zdenko, HAJKR, Josef. Řízení projektů zavádění IS do organizací TUTORIAL. In DATAKON Sborník databázové konference sborníku. DATAKON Proceedings of the Annual Database Conference. 1. vyd. Brno: Masarykova univerzita, Fakulta informatiky, s. ISBN [16] DANILOVIC, Mike, BÖRJESSON, Håkan. Managing the multi-project environment. In Proceedings of the 3rd international design structure matrixworkshop [online]. Cambridge: Massachusetts Institute of Technology (MIT), [cit. 30. prosince 2010], 17 p. Dostupné na Internetu: < Multiproject%20Environment.pdf>. [17] ESKEROD, Pernille. Meaning and action in a multi-project environment : Understanding a multi-project environment by means of metaphors and basic assumptions. In International Journal of Project Management [online]. Volume 14, Issue 2. Elsevier Science Ltd., 1996, [cit. 30. prosince 2010], p Online dostupné od 22. února 1999, dostupné na Internetu: < ISSN [18] PAUKNEROVÁ, Daniela. Psychologie pro ekonomy a manažery. 2., přepr. a aktualiz. vyd. Praha : Grada, s. ISBN [19] Vanderbilt University. Neural bottleneck found that thwarts multi-tasking. In ScienceDaily [online]. ScienceDaily LLC, 1995, Článek zveřejněn 19. ledna 2007, [cit. 30. prosince 2010]. Dostupné na Internetu: < [20] MARK, Gloria, GONZALES, Victor M., HARRIS, Justin. No task left behind?: examining the nature of fragmented work. In Proceedings of the SIGCHI conference on Human factors in computing systems (CHI '05). New York : ACM, 2005, [cit. 30. prosince 2010], p Dostupné na Internetu: < [21] AVIDOR, Raanan. Murphy's laws site : All the laws of Murphy in one place. Israel, 2002 [cit. 30. prosince 2010]. Dostupné na Internetu: < [22] GABRHELÍK, Roman. Akademická prokrastinace: Ověření sebepopuzovací škály, prevalence a příčiny prokrastinace : disertační práce [online]. Brno : Masarykova univerzita, Fakulta sociálních studií, s. Vedoucí diplomové práce doc. PhDr. Michal Miovský, Ph.D. [cit. 30. prosince 2010]. Dostupné na Internetu: < >. [23] PASSIG, Kathrin, LOBO, Sascha. Odložím to na zítra : jak si zorganizovat život bez zbytečného organizování. Vyd. 1. Praha : Portál, s. ISBN [24] McCREA, Sean M., LIBERMAN, Nira, TROPE, Yaacov, at al. Construal Level and Procrastination. In Psychological Science, December 1, 2008, vol. 19, no. 12 [cit. 30. prosince 2010], p Oxford : Blackwell Publishing. ISSN Dostupné na Internetu i v online podobě: < 74

82 [25] Arnet on Line. Zákony ČR online : Zákon č. 262/2006 Sb. [online]. Ostrava: Arnet On Line, a.s., 2004, 2010 [cit. 30. prosince 2010]. Dostupné na Internetu: < [26] FINDEISOVÁ, Radka. Vizualizace informací a znalostí pro potřeby řízení soustavy projektů : diplomová práce [online]. Brno : Masarykova univerzita, Fakulta informatiky, s. Vedoucí diplomové práce RNDr. Zdenko Staníček, Ph.D. [cit. 30. prosince 2010]. Dostupné na Internetu: < [27] GOLDRATT, Eliyahu M., JIRÁK, Jan. Kritický řetěz. Vyd. 1. Praha : InterQuality, s. ISBN [28] MACINKA, Václav. Techniky stanovení nákladů softwarových projektů : diplomová práce [online]. Brno : Masarykova univerzita, Fakulta informatiky, s. Vedoucí diplomové práce RNDr. Jaroslav Ráček, Ph.D. [cit. 30. prosince 2010]. Dostupné na Internetu: < [29] GRENNING, James. Planning Poker, or How to Avoid Analysis Paralysis while Release Planning [online]. Hawthorn Woods : Renaissance Software Consulting, 2002 [cit. 30. prosince 2010]. 3 p. Dostupné na Internetu: < [30] COHN, Mike. Agile estimating and planning. New Jersey : Prentice Hall Professional Technical Reference, p. ISBN [31] ANAVI-ISAKOW, S., GOLANY, Boaz. Managing multi-project environments through constant work-in-process. In International Journal of Project Management [online], Volume 21, Issue 1, January 2003 [cit. 30. prosince 2010], p 9-18, ISSN Dostupné na Internetu: < [32] ADLER, Paul S., MANDELBAUM, Avi, NGUYEN, Viên, at al. From Project to Process Management: An Empirically-Based Framework for Analyzing Product Development Time. In MANAGEMENT SCIENCE [online], Volume 41, Issue 3, 1995 [cit. 30. prosince 2010], p Dostupné na Internetu: < [33] COHEN, Isack, MANDELBAUM, Avishai, SHTUB, Avraham. Multi-Project Scheduling and Control: A Process-Based Comparative Study of the Critical Chain Methodology and Some Alternatives. In Project Management Journal [online], 2004, 35, 2 [cit. 30. prosince 2010], p Dostupné na Internetu: < [34] RAZ, Tzvi, BARNES, Robert, DVIR, Dov. A critical look at critical chain project management. In Engineering Management Review [online], IEEE, vol.32, no.2, [cit. 30. prosince 2010], p 35-35, Dostupné na Internetu: < [35] KOTTER, John P.., RATHGEBER, Holger, MUELLER, Peter. Náš ledovec se rozpouští: připravte se na změnu a úspěch za jakýchkoliv podmínek. Praha : Pragma, s. ISBN [36] KNIBERG, Henrik, SKARIN, Mattias. Kanban vs Scrum : making the most of both [online]. InfoQ.com,Version 1.1, 2009 [cit. 30. prosince 2010]. 120 p. ISBN: Dostupné na Internetu: < 75

83 [37] FERSCHMANN, Petr. Přednáška Scrum: praktické zkušenosti. Plzeň: Západočeská univerzita v Plzni, 9. květen 2007 [cit. 30. prosince 2010].. Záznam dostupný na Internetu: < [38] SUTHERLAND, Jeff. Future of scrum: parallel pipelining of sprints in complex projects. In Agile Conference, Proceedings, 2005 [online], [cit. 30. prosince 2010], p Dostupné na Internetu: < [39] Scrum for Team System. Scrum for Team System - v1.x Discusions [online]. EMC Corporation, 2007, 2009 [cit. 30. prosince 2010]. Dostupné na Internetu: < [40] Stack overflow internet services, inc. Stack Overflow [online]. Revision: Stack overflow internet services, inc., 2011 [cit. 30. prosince 2010].. Dostupné na Internetu: < [41] MARCHENKO, Artem, ABRAHAMSSON, Pekka. Scrum in a Multiproject Environment: An Ethnographically-Inspired Case Study on the Adoption Challenges [online]. AgileSoftware- Development.com, 2008 [cit. 30. prosince 2010].. Dostupné na Internetu: < [42] WATERS, Kelly. How To Share An Agile Development Team [online]. Agile Development Made Easy!, 2007 [cit. 30. prosince 2010].. Dostupné na Internetu: < [43] ŠOCHOVÁ, Zuzana. Agilní metody a Scrum. In CIO Business World [online]. IDG Czech Republic, a. s., 2009 [cit. 30. prosince 2010].. Dostupné na Internetu: < [44] STEVENS, Peter. 5 tips for Iterating through the holidays [online]. AgileSoftwareDevelopment.com, 2008 [cit. 30. prosince 2010].. Dostupné na Internetu: < [45] PERGLER, Tomáš. Přednáška A Year with Scrum in Seznam.cz. Praha : WebExpo Prague 2010 Conference, 25. září [46] AICHINGER, Michal. Jak se dělá SCRUM na dálku v podání Seznamu [online]. Aichiho blog, 2009 [cit. 30. prosince 2010].. Dostupné na Internetu: < [47] BERCZUK, Steve. Back to Basics: The Role of Agile Principles in Success with an Distributed Scrum Team. In AGILE 2007 [online], 2007, [cit. 30. prosince 2010], p Dostupné na Internetu: < [48] SEPULVEDA, Christian. Agile development and remote teams: learning to love the phone. In Agile Development Conference, ADC Proceedings of the [online], 2003 [cit. 30. prosince 2010]. p Dostupné na Internetu: < [49] JENSEN, Bent, ZILMER, Alex. Cross-Continent Development Using Scrum and XP. In Extreme Programming and Agile Processes in Software Engineering [online], Springer Berlin, 2003 [cit. 30. prosince 2010]., p Dostupné na Internetu: < 76

84 [50] ŠOCHOVÁ, Zuzana. Srum hra. Zuzi's blog, 2006, 2011, článek publikován 13. června 2010 [cit. 30. prosince 2010]. Dostupné na Internetu: < [51] ŠOCHOVÁ, Zuzana. Zavádíme Agilní metody agilně. Zuzi's blog, 2006, 2011, článek publikován 9. dubna 2010 [cit. 30. prosince 2010]. Dostupné na Internetu: < [52] ARIELY, Dan, WERTENBROCH, Klaus. Procrastination, Deadlines, and Performance: Self- Control by Precommitment. In Psychological Science [online], May 1, 2002, vol. 13, no. 3 [cit. 30. prosince 2010], p Dostupné na Internetu: < Seznam obrázků Obrázek 1.1: Metafora problematiky projektového řízení v multiprojektovém prostředí Obrázek 2.1: Ukázka vlivu multitaskingu na délku trvání činností na jednom projektu Obrázek 2.2: Ukázka vlivu multitaskingu na délku trvání činností v případě více projektů Obrázek 2.3: Průběh činnosti při působení Studentského syndromu Obrázek 2.4: Průběh činnosti při působení Parkinsonova zákona Obrázek 3.1: Metafora multiprojektového prostředí jako stavba Velké čínské zdi Obrázek 3.2: Metafora multiprojektového prostředí jako Čínský drak Obrázek 5.1: Graf rozdělení pravděpodobnosti ukončení činnosti a v čase t Obrázek 5.2: Graf rozdělení pravděpodobnosti ukončení činnost a v čase t, doplněn odhad času od pracovníků Obrázek 5.3: Graf rozdělení pravděpodobnosti ukončení činnosti a v čase t, doplněn o vizualizaci rezervy Obrázek 6.1: Diagram činností projektu A, červeně je vyznačená kritická cesta Obrázek 6.2: Diagram činností projektu B, červeně je vyznačená kritická cesta Obrázek 6.3: Skryté rezervy v činnostech projektu versus viditelné rezervy Obrázek 6.4: Ukázka špatně zvoleného přípojného nárazníku Obrázek 6.5: Modře vyznačená přípojná větev je delší než původní kritická cesta Obrázek 6.6: Upravený síťový graf s navýšeným projektovým nárazníkem Obrázek 6.7: Ukázka seznamu činností pro pracovníky Obrázek 6.8: Pravidlo třetin při prorážení nárazníku Obrázek 6.9: Princip Scrum metodiky: rozdělení na malé části a seřazení dle pririty Obrázek 6.10: Princip Scrum metodiky: postupné dodávky produktu ve sprintech Obrázek 6.11: Vizualizace postupu pomocí nástěnky, písmena A-F označují pracovníky Seznam tabulek Tabulka 4.1: Význam písmen metody SMART dle [3]

85 Seznam zkratek BOZP CCPM COCOMO ConPIP ConTIP CPM ETE FCFS FPA IPMA IT LOC MinSLK NGT NP-hard NPIP PERT PMI PROBE QSC RUP SLOC SWOT TOC WBS WIP XML XP Bezpečnost a ochrana zdraví při práci Critical Chain Project Management The Constructive Cost Model Constant Number of Projects in Process Constant time in process Critical path Method Estimate-Talk-Estimate procedure First come, first served Function Point Analysis International Project Management Association Informační technologie Lines Of Code Minimum Slack Activity The nominal group technique Non-deterministic Polynomial-time hard Number of Projects In Process Program (or Project) Evaluation and Review Technique Project Management Institute Proxy-Based Estimation Queue Size Control Rational Unified Process Source lines of code Strengths, Weaknesses, Opportunities, and Threats Theory Of Constraints Work breakdown structure Work in Progress Extensible Markup Language Extreme Programming Zdroje obrázků JURKA, Radovan. Projektové řízení : diplomová práce [online]. Brno : Masarykova univerzita, Ekonomicko-správní fakulta, s. Vedoucí práce Ing. František Kalouda, CSc., MBA, [cit. 30. prosince 2010]. Dostupné na Internetu: < KNIBERG, Henrik, SKARIN, Mattias. Kanban vs Scrum : making the most of both [online]. InfoQ.com,Version 1.1, 2009 [cit. 30. prosince 2010]. 120 p. ISBN: Dostupné na Internetu: < Getty Images. Stock.XCHNG [online]. HAAP Media Ltd, Version 6.00, 2001, 2009 [cit. 30. prosince 2010]. Dostupné na Internetu: < Meetdragons.com. Chinese Dragon Pictures,Chinese Dragon,Chinese Dragon Wallpaper. 2002, Dostupné na Internetu: < 78

86 10 Přílohy Příloha A Statistický průzkum úspěšnosti IT projektů v letech 1994 a 2004 Příloha B Ukázkový plán CO projektu ZM1 Příloha C Plán JAK projektu ZM1 Příloha D Plán S KÝM projektu ZM1 Příloha E Plán KDY projektu ZM1 Příloha F Plán KDY projektu ZM s doplněnými nárazníky Příloha G Pruhový diagram činností projektu ZM1 Příloha H Časový harmonogram projektu ZM1 Příloha I Plán vytíženosti zdrojů v čase Příloha J Případová studie Podnětovny v IS MU Příloha K Vlastnosti jednotlivých metodik Příloha L SWOT analýza zavedení nové metodiky Příloha M Kvalitativní analýza rizik zavedení nové metodiky Příloha N Zavedení seznamu Product Backlog s minimální administrativní zátěží Příloha O Forma zápisu Sprint Backlog seznamů 79

87 Příloha A Statistický průzkum úspěšnosti IT projektů v letech 1994 a 2004 Průzkum prováděla společnost The Standish Group v rámci projektu The CHAOS (převzato z textu [8]). Obrázek A.1: Grafické znázornění úspěšnosti projektů.

88 Příloha B Ukázkový plán CO projektu ZM1 Obrázek B.1: K vizualizaci plánu CO je použita tzv. Mind mapa.

89 Příloha C Plán JAK projektu ZM1 V plánu JAK je zahrnuta pouze první úroveň plánu CO, síťový graf je doplněn o zahajovací činnost s názvem Začátek a závěrečnou činnost s názvem Ukončení, které ovšem slouží jen jako počáteční a koncový bod a nebudou opravdu vykonávány (nemají přiřazené zdroje a doba zpracování je nulová). Všechny činnosti jsou šipkou znázorněny ve vztahu Finist-to-start, tedy ve vztahu, ve kterém jedna činnost nemůže začít, dokud neskončí předchozí činnost. Obrázek C.1: Plán JAK.

90 Příloha D Plán S KÝM projektu ZM1 Zdroje potřebné pro projekt ZM1 grafik programátor analytik tester osoba znalá tvorby PDF Obsazení zdrojů jednotlivými pracovníky pracovník A pracovník Z pracovník Z pracovník Z, pracovník X pracovník B Tabulka D.1: Seznam zdrojů a obsazenost zdrojů pracovníky. Obrázek D.1: Plán JAK doplněný o informaci obsazenosti zdrojů jednotlivými pracovníky (označení pomocí zkratek zeleně nad činností).

91 Příloha E Plán KDY projektu ZM1 Do plánu JAK jsou zaznačeny jednotlivé odhady činností, pro zjednodušení jsou vynechány názvy činností, graf však plně odpovídá grafu JAK z přílohy C. Činnost začátek a konec mají nulovou hodnotu, proto jsou v grafu zaznačeny pod písmeny a barevně odlišeny. Červeně je vyznačena kritická cesta. Modrou přerušovanou čárou je vyznačen kritický řetěz v projektu. Obrázek E.1: Plán KDY s vyznačením kritické cesty. Obrázek E.2: Plán KDY s vyznačením kritické cesty a kritického řetězu.

92 Příloha F Plán KDY projektu ZM s doplněnými nárazníky Plán KDY je na rozdíl od obrázků v příloze E překreslený, bere již v potaz kritický řetěz. Nárazníky jsou značeny zeleně, přípojné nárazníky mají hodnotu 0,5 a 3, projektový nárazník má hodnotu 16. Obrázek F.1: Logický plán činností, který zahrnuje i zdrojovou závislost činností. Obrázek F.2: Upravený plán KDY s doplněnými nárazníky.

93 Příloha G Pruhový diagram činností projektu ZM1 Ţlutá barva označuje činnosti, zelená barva označuje nárazníky. Pro rychlý a jednoduchý nákres stačí čtverečkovaný papír. Příloha H Časový harmonogram projektu ZM1 Obrázek G.1: Pruhový diagram činností projektu. Obrázek H.1: Časový harmonogram projektu ZM1 je odlišný od pruhového diagramu činností, bere již v potaz i další projekty.

94 Příloha I Plán vytíženosti zdrojů v čase Písmenem D jsou označeny dovolené, Š označuje školení, tečka označuje činnost na kritických řetězech, jedna barva označuje jeden projekt. Obrázek I.1: Plán vytíženosti zdrojů v čase před začleněním projektu ZM1. Obrázek I.1: Plán vytíženosti zdrojů v čase po začlenění projektu ZM1, který je vyznačen žlutou barvou.