■Plánování
nRadim Dodek
n

Copyright © Unicorn Systems a.s.
2
Plán
nCo je projekt?
nCo je projektový plán a k čemu mi bude?
nJak by měl plán vypadat?
nJak plán udělat?
nCo by nemělo chybět?
nCo k tomu budu potřebovat?
n
n

Projít jednotlivé body agendy, nezapomenout zmínit předpoklady, vysvětlit, že daná specifika se
mohou lišit u různých typů projektů a je třeba si z workshopu odnést spíše způsob přemýšlení nad
plánem a základní metodiku a tu poté správně aplikovat na to, co potřebujeme naplánovat
Zmínit, že je třeba hlavně používat selský rozum. Absenci selského rozumu nezachrání žádná
metodika. Bez této vlastnosti neuspěje žádný manager
Zmínit KISS

Copyright © Unicorn Systems a.s.
3
Co je projekt?
nČasově a nákladově omezené úsilí za účelem realizovat množinu definovaných výstupů (naplnění
definovaných cílů) podle standardů a v požadované kvalitě.
nJedinečný proces, který se skládá z řady koordinovaných a řízených činností s termíny zahájení a
ukončení. Realizuje se pro dosáhnutí cíle, který vyhovuje specifikým požadavkům včetně omezení jako
je čas, náklady nebo zdroje.
nSoubor činností s jasným cílem, který je omezen časem, financemi a dalšími zdroji
nProjekt je řízený proces změny
n

Slide slouží k nastolení správného přemýšlení nad tím, co se vlastně plánuje a vymezení pojmu
projekt jako takového – pokud zadání nesplňuje tyto body, nejedná se o projekt a k plánování dané
aktivity by mělo být přistoupeno jinak

Copyright © Unicorn Systems a.s.
4
Co je projektový plán - Teorie
n
n
n
n
n
n
n
n
n
n
n
nZdroj: https://managementmania.com/cs/plan-projektu

Copyright © Unicorn Systems a.s.
5
Co je plán - praxe
n2 (někdy i více) plánů různé granularity dle potřeb různých lidí, které musí být vzájemně
konzistentní po celou dobu projektu
n

Každý si pod pojmem plán představí něco jiného. Zpravidla ale platí, že se jedná o chronologický
seznam dílčích aktivit, které se mají stát a které se vzájemně nějakým způsobem ovlivňují.
Proč potřebujeme 2 plány?
1.Pro interní účely – plánujeme detailně na úroveň jednotlivých úkolů (úkol by zpravidla neměl mít
více než 16hodin, vysvětlit proč). Slouží jako podklad pro kapacitní plánování, odhadování časové
náročnosti, atd
2.Pro externí účely – zpravidla méně detailní, obsahuje hlavní milníky z pohledu klienta (nemá
smysl dávat detaily, klient jim buď stejně nerozumí, nebo jej nezajímají, protože to je Vaše práce,
ne jeho). Zpravidla tam chce mít jednoznačné informace o tom, kdy on bude muset něco dělat
3.Vysvětlit obrázky – obrázek pro klienta vlevo, screenshot z JIRA vpravo – detail na úroveň úkolu
pro jednotlivce na projektu
4.Plán potřebujeme pro řízení projektu, abychom věděli, co kdy má dělat a co se stane, když se daný
úkol nestane/nestihne v daném čase. Chápeme, že plán není neměnný, ale je potřeba, abychom věděli,
jaký dopad bude mít určitá skutečnost (ať už časový, nebo nákladový). Bez plánu se jen složitě
odhadují celkové náklady na projekt

Copyright © Unicorn Systems a.s.
6
Modelový příklad
nVytvořit projektový plán tzv: Engineering projektu
nOčekávané výstupy ze strany klienta (co jste slíbili v nabídce):
nAnalytická dokumentace pro další fázi
nSeznam funkčností systému
nSeznam nefunkčních požadavků (tzv. non-functional requirements) na systém
nTestovací strategie
nSWA document
nNávrhy obrazovek
n
n
n
nPředpoklady
nVyvíjíte podle metodiky Waterfall, nebo RUP
nSnažíte se o tzv ‚optimální plán pro všechny‘
n
n
n

Vysvětlit, co je metodika Waterfall a RUP a Scrum, popsat, co je engineering projekt
Dále pak vysvětlit potřebu jednotlivých výstupů (proč jsme slíbili zrovna tyto)
Vysvětlit, co je myšleno optimálním plánem pro všechny  - pracujeme jen na výstupech pro klienta,
nebo na mitigacích rizika, zároveň se to všechno snažíme dělat za co nejméně úsilí/peněz
Vysvětlit, že plánujeme/pracujeme jen na dvou typech úloh – na výstupech pro klienta, na věcech,
které mitigují rizika – jako třeba PoC, jako třeba status reporty, schůzky s klientem, jako
management – na ty je třeba nezapomenout, i když jsme je klientovi explicitně neslíbili – pro
jejich nedělání bychom vždy měli mít jasný argument a přistupovat k tomu jako k riziku

Copyright © Unicorn Systems a.s.
7
Postup
nVytvořit PBS
nOdvodit WBS
nOdhadnout časovou náročnost aktivit
nSeznam rizik/předpokladů
nVytvořit interní plán
nExterní plán tvořit nebudeme, protože se dá odvodit z interního jeho zjednodušením
n

Celé je to trochu zjednodušené a slouží to spíš k pochopení za 90 min, rozhodně to není určené k
tomu, že podle toho odřídí někdo celé EP

Copyright © Unicorn Systems a.s.
8
PBS – Product breakdown structure
nCo to je?

Product breakdown structure – vydefinovat jednotlivé produkty a meziprodukty, které mají během
projektu vzniknout

Copyright © Unicorn Systems a.s.
9
PBS – Výchozí stav
n

Vycházíme z toho, co jsme slíbili v nabídce a to začneme rozpadávat a přidávat další
výstupy/mezivýstupy, které mitigují rizika

Copyright © Unicorn Systems a.s.
10
PBS – Jak by to mohlo taky vypadat
n

Vysvětlit, proč jsme přidali ty 3 nové, na co jsme rozpadli původní. Zároveň vysvětlit, že přidávat
se dá téměr do nekonečna, ale že jsme si dali zadání, že děláme optimální plán – tzn – co nejnižší
rizika za akceptovatelné náklady.
Upozornit na návaznosti projektu – Začínáme high level designem, z něj odvodíme seznamy
funkčních/nefunkčních požadavků, následně dopíšeme zbytek analýzy a zároveň děláme SWA dokument a s
tím spojené PoC, rozebíháme návrhy obrazovek, testovací strategii, nakonec píšeme seznam rizik a
out of scope

Copyright © Unicorn Systems a.s.
11
WBS – work breakdown structure
nJak odvodím z PBS WBS?
nProč bych tím vlastně měl ztrácet čas, když už mám PBS?

WBS se odvodí tak, že se s maximální mírou znalosti pokusím vymezit pracovní jednotku, která musí
být odpracována, aby bylo možné výstup/mezivýstup dokončit.
Zároveň přidávám pracovní aktivity, která mitigují rizika.
Zároveň slouží pro lepší pochopení, co je pod daným produktem – aby to bylo jasné nejen klientovi,
ale i internímu týmu (když se dohaduje, za kolik jde něco udělat/neudělat)

Copyright © Unicorn Systems a.s.
12
WBS – Modelový příklad

Ke každému výstupu jsem rámcově popsal, co má vzniknout a přidal několik položek navíc, které mají
mitigovat rizika – v případě, že bude třeba projekt udělat za méně času, tak tohle je možnost, kde
sekat, za předpokladu, že nám nevadí nárůst rizik na projektu

Copyright © Unicorn Systems a.s.
13
Časová náročnost

Nyní již víme, jak dlouho trvají jednotlivé aktivity, jaké jsou mezi nimi návaznosti. Tím pádem
můžeme dokončit plán a zároveň stanovit nákladovou částku za projekt (za předpokladu, že víme,
kolik stojí 1 MD každé role
Takže vím, v jakém pořadí budu odbavovat jednotlivé aktivity a generovat výstupy, jsem to schopen
říct klientovi, aby si v daný čas udělal čas na revize
Vím, kolik to bude stát
Dokážu to zaplánovat, organizovat, kontrolovat a řídit a následně i vyhodnotit

Copyright © Unicorn Systems a.s.
14
Vytvoření plánu

Definujeme vstup a výstup pro jednotlivé deliverables a jednání s klientem, těm přiřadíme termín –
postupujeme postupně podle aktivit.
Granularitu plánu definujeme podle velikosti projektu.

Copyright © Unicorn Systems a.s.
15
Seznam rizik/předpokladů
nDefinujeme rizika, která mohou ovlivnit splnění daného plánu
nDefinujeme předpoklady, se kterými počítáme, aby byl plán uskutečnitelný

Nikdy nesmíme zapomenout, s jakými riziky náš projekt počítá a s jakými předpoklady. Toto je dobré
sdílet interně a ideálně i s klientem. Bez tohoto se může stát, že za měsíc bude Váš plán vypadat
jako absurdní dokument, který nemá žádný vztah k realitě

Copyright © Unicorn Systems a.s.
16
Řízení rizik
nRisk list
nSeverita, dopad a opatření
nSoučást pravidelného vyhodnocování stavu projektu
nRisk => Problém

Copyright © Unicorn Systems a.s.
17
Příklad seznamu rizik

Copyright © Unicorn Systems a.s.
18
Rady na závěr
nPoužívejte selský rozum
nKISS
nNikdy nic nepředpokládejte a vždy ověřujte

■Děkuji

>