Projektový Underground

Velkou část dnešního čísla věnujeme jedné hybridní metodice spojující klasické vodopádové řízení s agilním. Agilní řízení je dnes buzzword, ale ne vždy a všude je tento styl vhodný. Ale zároveň platí – proč se nepoučit z agilních principů a proč je nevyužít? Metodika DSDM je jedna z prvních agilních metodik. Byla tu dokonce dřív, než se ukotvil termín „agilní“. Vznikla již v roce 1994 a vycházela částečně z RAD (Rapid Application Development), ve které projektovým manažerům přišla nedostatečná kontrola a disciplína. Tato metodika klade důraz na včasné dodání, což je dnes častý požadavek. Také klade velký důraz na to, aby se projekt podniku vyplatil z obchodního hlediska a aby bylo dosaženo co nejlepší ROI, ale i na dodržení rozpočtu. Pro dosažení těchto projektových cílů doporučuje používat tyto nástroje: workshopy, modelování a iterativní development, prioritizaci MoSCoW a timeboxing, neboli rozdělení na časové úseky. Podle průzkumu je metodika DSDM celosvětově z méně používaných. Na prvním místě je metodika Scrum, po ní následují metodiky Extreme Programming a Feature Driven Development a DSDM je s 4,166% trhu na čtvrtém místě, s metodikou Kanban ve velmi těsném závěsu. V české Republice není moc známá, ve světě se užívá především v korporátním prostředí.

Metodika DSDM je výjimečná tím, že jako jedna z mála agilních metodik popisuje průběh celého projektu a životního cyklu produktu. Metodiku lze také kombinovat vodopádovými s metodami jako je metodika PMI. Hlavní filosofií DSDM je „the best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people”. Toho je dosaženo, pokud všechny zainteresované strany jak uvnitř, tak mimo projekt, jsou plně zapojeny, mají možnost rozhodovat o věcech týkajících se jejich oboru, chápou vizi a cíle projektu, dodržují časový plán a akceptují, že během projektu může dojít ke změnám jak požadavků, tak způsobů řešení. S tím souvisí i parametry DSDM projektu. Obecně jsou hlavními parametry projektů náklady (finanční i časové), kvalita a užitné vlastnosti (features), které řešení nabízí. Tradiční projekty kladou důraz na dodané užitné vlastnosti, kde náklady se stanou proměnnými (jinými slovy cena i čas doručení se podřizují tomu, aby řešení mělo tyto vlastnosti). Pro DSDM metodiku jsou naopak nejdůležitější časové a finanční náklady a užitné vlastnosti jsou pouhou proměnou. Důraz je tedy na dodržení termínu dodání a finančního rozpočtu a tomu se podřizuje, jaké vlastnosti bude výsledné řešení mít, tak, aby byla zachována co nejvyšší možná kvalita a byly splněny cíle projektu. Právě to odpovídá požadavkům na projekt DMS.

DSDM metodika rozděluje projekt celkem do šesti fází. Čtyři hlavní fáze se nazývají Feasibility, Foundations, Evolutionary Development a Deployment. Před fází Feasibility se nachází ještě tzv. Předprojektová fáze a projekt je ukončen poprojektovou fází. Z Feasibility fáze, kde se ověřuje realizovatelnost záměru, přechází projekt do fáze Foundations, kde jsou vymezeny základní cíle celého projektu. Poté následuje Evolutionary Development, kde probíhá samotný vývoj aplikace. Když se rozhodne o nasazení aplikace, projekt přejde do fáze Deployment. Často (i dle doporučení metodiky) se aplikace nasazuje po částech, proto se fáze Evolutionary Development a Deployment mohou několikrát opakovat v iteracích. Pokud se v rámci fáze Deployment dojde k rozhodnutí, že je třeba přehodnotit požadavky na řešení, lze se vrátit i do fáze Foundations. V poslední iteraci je nasazen finální produkt a projekt je ukončen. Po jeho ukončení následuje tzv. poprojektová fáze.

Dle metodiky DSDM je důležité rozdělení rolí v týmu tak, aby každý člověk měl vymezenou část projektu, za kterou je zodpovědný. Nepočítá se tedy se sdílenou (týmovou) odpovědností, typickou např. pro metodiku SCRUM. Kvůli tomuto vymezení je velice důležitá komunikace mezi členy týmu a vzájemný respekt. Podle DSDM existuje dvojí dělení rolí – podle zaměření či podle postavení v rámci projektu. Role a jejich rozdělení v rámci projektu jsou detailněji popsány v následující kapitole.

Role

Role jde podle zaměření rozdělit do čtyř kategorií.

• První kategorie se sestává z rolí starajících se o zájmy podniku a obchodní pohled na řešení. Do této kategorie se řadí např. Obchodní Sponzor (Business Sponsor), který má mj. na starost financování projektu a dohled nad jeho směřováním v souladu s požadavky firmy, nebo Obchodní Vizionář (Business Visionary), který je zástupcem Obchodního Sponzora a jako takový komunikuje jeho požadavky napříč týmem a stará se o vizi celého projektu.
• Druhá kategorie rolí reprezentuje technický pohled na řešení. Jde především o Vývojáře, což jsou vývojáři řešení (softwaru), Testeři (Solution Testers – testeři kvality vyvíjeného řešení) nebo Technický koordinátor (Technical Coordinator), který je zodpovědný za technický stav projektu.
• V další kategorii jsou role managementu, které mají na starost řízení celého projektu. Projektový manažer (Project Manager), role zodpovědná za celý projekt, nebo Vedoucí týmu (Team Leader), zodpovědný za tým vývojářů.
• Poslední kategorií jsou procesní role. Některé role se mohou nacházet na rozhraní dvou kategorií a nemohou být jasně vymezeny, např. Obchodní Analytik, který je prostředníkem mezi managementem a vývojáři a řadí se proto jak do podnikových, tak do technických rolí.

Podle postavení se role dělí do tří kategorií – projektové role, tým vývojářů a podpůrné role.

• Projektovými rolemi se rozumí ty role, které rozhodují o směřování celého projektu a jsou za něj zodpovědné. Patří sem všichni manažeři a koordinátoři jako Projektový manažer, Technický Koordinátor nebo Obchodní Vizionář. Obchodní Analytik je na pomezí projektové role a týmu vývojářů.
• Tým vývojářů se skládá ze všech rolí, které se podílejí na dodání řešení, tedy kromě Vývojářů také např. Tester nebo Vedoucí týmu. Každý z týmu vývojářů je kompletně zodpovědný za svou část řešení. V rámci jednoho projektu se může vyskytnout i více týmů vývojářů.
• Do podpůrných rolí se řadí všechny ostatní role, např. poradci z různých oborů jako Obchodní poradci nebo Techničtí poradci.

Metodika nerozporuje obsazení více rolí jednou osobou ani obsazení jedné role více osobami – v tom případě je ale podmínkou že musí úzce spolupracovat.

U některých rolí se zastavme, protože mohou být obecně chápány trochu jinak než v této metodice, nebo jejich vysvětlení pomůže objasnit principy vlastní metodiky.

Obchodní vizionář je fakticky plnohodnotný zástupce vlastníka, protože metodika správně předpokládá, že vlastník obvykle nemá dostatek času věnovat se projektu naplno. Slovem plnohodnotný se rozumí i vybavení odpovídající autoritou dovnitř organizace. Jedná se o seniorní vedoucí roli na úrovni projektu, kterou by měla mít alokovánu pouze jedna osoba, protože projekt potřebuje jednu jasnou vizi, aby se předešlo nejasnostem a nesprávnému vedení. Angažuje se aktivněji než obchodní sponzor, protože je obvykle vyčleněn na full time. Je odpovědný za interpretaci požadavků obchodního sponzora, jejich předání do týmu. Obchodní vizionář zůstává zapojen do celého projektu, poskytuje týmu strategický směr a zajišťuje to, že dodané řešení umožní dosažení přínosů.

Odpovědnosti

• Definování obchodní vize projektu
• Komunikace a propagace obchodní vize všem zúčastněným a / nebo dotčeným stranám
• Sledování průběhu projektu v souladu s podnikatelskou vizí
• Řešení širších důsledků jakékoli business změny z organizačního hlediska
• Přispívání ke klíčovým požadavkům, návrhům a revizím, zejména tam, kde jsou aspekty řešení považovány za klíčové prvky obchodní vize
• Identifikace a vlastnictví podnikatelského rizika
• Definování a schvalování změn požadavků na high-level, tzn. jakékoli změny, která ovlivňuje základní rozsah nebo významně mění rovnováhu priorit
• Zajištění spolupráce napříč oblastmi podnikání v rámci projektu
• Zajištění obchodních zdrojů je pro projekt k dispozici podle potřeby
• Propagace převodu obchodní vize do pracovní praxe, tj. Zajištění úplného obchodního přijetí řešení vytvořeného projektem
• Posílení obchodních rolí v rámci týmu pro rozvoj řešení na odpovídající úrovni v rámci jejich odpovědnosti
• Tam, kde se vývojový tým nemůže dohodnout, jedná jako arbitr.

Obchodní analytik je garantem konzistentnosti řešení z byznysového hlediska. Je aktivní v podpoře rolí na úrovni projektu. Obchodní analytik primárně řeší vztah mezi obchodními a technickými rolemi, zajišťuje přesné a vhodné rozhodnutí o vyvíjejícím se řešení na každodenní bázi. Obchodní analytik zajišťuje, že byznysové potřeby jsou správně modelovány a analyzovány a jsou správně zohledněny v pokynech, které tým potřebuje k vytvoření řešení. Aktivní zapojení koncových uživatelů do procesu vývoje řešení je životně důležité pro úspěch projektu DSDM. Proto je důležité zajistit, aby se Obchodní analytik nestal zprostředkovatelem mezi členy vývojového týmu, ale místo toho komunikaci mezi nimi podporoval a usnadňoval.

Odpovědnosti:

• Pomoc obchodnímu vizionáři při formulaci a propagaci podnikatelské vize
• Modelování současného a budoucího stavu z hlediska identifikace příležitostí, rizik a dopadů
• Spolupráce s obchodním vizionářem a s vývojovým týmem pro formulaci a komunikaci možností řešení
• Podpora a usnadnění jednoznačné a včasné komunikace mezi obchodními a technickými účastníky projektu
• Zajištění kvalitně definovaných požadavků a jejich řádná analýza a řízení
• Řídit vývoj, distribuci a základní schvalování veškerých komunikací souvisejících s obchodními požadavky a jejich interpretací, se zvláštním zaměřením na zajištění toho, aby seznam prioritních požadavků byl průběžně aktualizován, protože se detaily rozšiřují a vyvíjejí.
• Zajištění toho, aby obchodní a organizační důsledky každodenního vývoje řešení byly správně modelovány a promyšleny
• Zajištění dopadu obchodních rozhodnutí je posuzováno v kontextu projektu
• Zajištění toho, aby obchodní a technické složky řešení společně poskytovaly soudržný celek pro podnik
• Spojení s obchodním vizionářem při organizaci podpory řešení prostřednictvím implementace do živého provozu

Technický poradce podporuje tým tím, že poskytuje konkrétní a odborný technický vstup do projektu, často pohledem manažerů odpovědných za provoz, provozní podporu, průběžnou údržbu atd.

Lektor workshopu je zodpovědný za řízení vlastního procesu workshopu. Je katalyzátorem pro přípravu a komunikaci. Je to facilitátor odpovědný za organizaci workshopů, které účastníkům umožní dosáhnout cíle. Facilitátor workshopu by měl být nezávislý na výsledku, kterého má být v projektu dosaženo.

Nástroje metodiky

Zde jsou podrobněji rozepsány některé nástroje specifické pro tuto metodiku, ostatní jsou jen vyjmenovány.

1. Prioritizace MoSCoW

Vzhledem k povaze DSDM projektu, který klade důraz na včasné dodání a kvalitu a proměnnou projektu jsou užitné vlastnosti, které bude mít dodané řešení, je důležité stanovit si priority, tj. jasně vytyčit, které vlastnosti dodávaného řešení jsou bezpodmínečně nutné a které jsou naopak pouze příjemným doplňkem. K tomu slouží právě priotizace MoSCoW, což je zkratka pro „must have, should have, could have, won’t have this time“. Prioritizace se používá v průběhu celého projektu –  ať už při tvoření cílů celého projektu, jednotlivých time-boxů či iterací. Díky tomu může docházet k přesunu požadavků z jedné kategorie do druhé – co během jedné iterace je zamítnuto a odsunuto do kategorie Won’t have this time může být v příští iteraci must have a naopak. Pokud se projekt ocitne v časovém skluzu, začne se upouštět od jednotlivých požadavků, aby byl dodržen termín dodání. V takovém případě se začíná „odspoda“, tj. nejprve se upouští od požadavků could have a pak až případně od should have požadavků.

Must have jsou minimální požadavky na dodané řešení, které musí být vždy splněny, bez kterých by řešení nebylo použitelné. Should have požadavky jsou ty, bez kterých by dodané řešení nemuselo být úplně komfortní, které jsou sice důležité, ale nejsou pro projekt životně důležité. Could have jsou požadavky takové, které jsou možné a mohly by být příjemným rozšířením, nicméně nejsou pro dodávané řešení tolik důležité. Nakonec won’t have this time (odložené) požadavky jsou požadavky, které nyní nebudou dodány. Je důležité si je uchovat, aby nebyly opakovaně navrhovány (a zamítány), což by znamenalo zbytečné plýtvání časem, anebo naopak pro případ, že by daný požadavek byl přehodnocen a přesunut do jiné kategorie.

• Timeboxing

Timeboxing je praktika, kdy se projekt (především ve fázi Evolutionary Development) rozdělí na menší časové úseky (timeboxy), které mají jasně stanovený cíl. Pro každý timebox je vhodné udělat MoSCoW prioritizaci, čímž se jasně vymezí, čím se bude tým v daném timeboxu zabývat a co naopak nyní řešit nebude. Jeden projektový inkrement se obvykle skládá z více timeboxů. Důležité je si uvědomit, že stejně jako sprint v metodice SCRUM timebox neskončí, když se dosáhne nastavených cílů (požadavků), ale když vyprší jeho čas. Pak se vyhodnotí úspěšnost timeboxu dle toho, kolik z naplánovaných požadavků tým stihl dodat. Doporučená délka timeboxu v DSDM projektu je dva až čtyři týdny.

Styly timeboxů jsou dva – strukturovaný DSDM styl a volný styl. Volba mezi styly závisí na povaze projektu a dodávaného řešení.

Strukturovaný DSDM timebox nabízí jasně dané fáze a revize, což napomáhá dlouhodobějšímu plánování (revize se budou opakovat pravidelně). Jednotlivé fáze se nazývají Investigation, Refinement a Consolidation. První a poslední fáze by měly každá zabrat okolo 10-20% celkového času timeboxu a zbylých 60-80% připadá na Refinement. Na konci každé této fáze je revize. Před první fází je kick-off, tedy Zahájení timeboxu, a na konci timeboxu je close-out (Zakončení).

Prosím povšimněme si, že na rozdíl od sprintu je zde jasně oddělena fáze nasazení do provozu a doladění na jejím základě (Refinement).

• Workshopy
• Modelování a prototypování
• User stories

Shrnutí

Autor nasadil tuto metodiku v projektu, který na základě požadavku zákazníka byl vyvíjen agilně, ale zároveň byl zasmluvněn smlouvou Fixed Time – Fixed Price. Obě strany kontraktu byly v určité době po startu značně nespokojeny se stavem, což vedlo k problémům a nedůvěře ve vzájemné komunikaci. Zavedení metodiky fakticky žádný velký průlom neudělalo, protože i tak se pracovalo intuitivně podobným způsobem. Ale pojmenování rolí a odpovědností, to, že jednotliví účastníci si byli vědomi svého úkolu, autority i omezení, ale i vyčištění backlogů (přinucení k pořádné prioritizaci) značně „vyčistilo vzduch“ a projekt se znovu rozběhl a běží ke spokojenosti obou stran.

Do podobné situace se může dostat kdokoliv. Nebo i se objeví stav, kdy se tato hybridní technika ukáže jako užitečný nástroj. Neváhejte se s ní proto seznámit, literaturu lze dohledat na internetu.

Zde najdete popis situace, odpověď či doporučené řešení je až v následujícím příspěvku, který bude publikován o den později. To proto, abyste si mohl vyzkoušet, jak byste takovou situaci řešil sám, kdybyste se s ní setkal – a pak si porovnat svoje zkušenosti se zkušenostmi ostatních. No a vůbec nejraději budeme, pokud se popisem „strefíme“ do problému, který vás aktuálně trápí, a přispějeme tak zkušenostmi k jeho řešení.

První situace: Rizika a neurčitost

Jak nejlépe naložit při plánování zdrojů s neurčitostí? Tzn. aktivity s jinou než 100% pravděpodobností zahrnovat/nezahrnovat/zahrnovat a násobit danou pravděpodobností? Konkrétní (velmi modelový) příklad: Kontrakt ještě není podepsán pravděpodobnost, že se podepíše je 50%, rozsah je 100 MD na 3 měsíce, práce mají být zahájeny dle předpokladu za 1 měsíc. Problém: PM musí mít zdroje rezervovány, pro případ, že se kontrakt podepíše. Pokud je ale má rezervovány a kontrakt se nepodepsal, vystavuje se situaci, že lidé již nebudou utilizováni jinde. Pokud si je rezervuje a zohlední pravděpodobnost 50%, tak jich má rezervovánu „pouze polovinu“. Snížil dopad rizika, ale téměř jistě má problém, protože kontrakt se buď nepodepíše nebo podepíše. V prvním případě má rezervováno zdrojů moc a ve druhém málo. Existuje nějaká 4tá možnost? Co je nejmenším zlem v modelovém příkladu? Jaké jsou vaše zkušenosti s obdobnými situacemi v praxi?

Druhá situace: Řešení konfliktů při plánování

Jaké jsou zkušenosti s řízením/řešením kolizí v čerpání lidských zdrojů v rámci firmy?

Třetí situace: Akceptace

Ideální stav je pokud lze konkrétní akceptační kritéria ve velmi raných stadiích projektu a nejlépe je spolu s popisem akceptačního procesu vložit jako přílohu ještě přímo do smlouvy se zákazníkem. Jak se ale postavit k situaci, kdy to z principu projektu před zahájením nelze udělat?

V zářijovém čísle PM network vyšel příspěvek s radami, jak mohou projektoví manažeři získat zpět čas na svou práci. Z obsáhlého článku vybíráme základní ideje:

STOP AKTIVITÁM PLÝTVAJÍCÍM ČASEM

U projektových úkolů musí manažer projektu najít způsob, jak je zefektivnit – nebo je eliminovat. Přemýšlejte o aspektech své práce, zvláště těch, které se zdají neefektivní, a zeptejte se sami sebe:

1. Je to úkol, který musím udělat, nebo to může udělat někdo jiný?

2. Kdy je pro mě ten nejvhodnější čas na tento úkol?

3. Jakou hodnotu přidává tento úkol? Pokud nic cenného, změňte jej tak, aby byl hodnotný, nebo ho přestaňte dělat.

POZNÁMKY

Jsem-li mimo svůj pracovní stůl, přidám si do telefonu poznámku nebo připomenutí s alarmem.

NEMILOSRDNĚ NA E-MAILY

Dodržuj tři pravidla na došlé maily:

1. Smazat. Doručená pošta se může snadno zaplnit bezcenným e-mailem. Pokud nepoznávám odesílatele nebo předmět nesouvisí s mou prací, zprávu smažu. Zároveň ji označím jako spam a nechám svou e-mailovou službu zablokovat odesílatele.

2. Vyřešit. Některá pošta spojená s projektem může být zpracována brzy – za dvě tři minuty. Udělej to hned; jinak se ztratí čas opětovným otvíráním e-mailu.

3. Odložit. To je často nejtěžší. Odpověď na e-mail by někdy mohla vyplnit celý den. To je problém. Takže odložím e-mail na konkrétní čas, abych mohl dělat jinou práci a na reakci na mail si zablokuji čas. Že takto nakládáte s e-mailem by ale ostatní měli vědět. Například, pokud mi někdo pošle e-mail s naléhavým problémem, neměl by očekávat, že dostane odpověď hned. Pokud očekává okamžitou odpověď, ať vypustí e-mail a zavolá.

NE TELEFON PO PRÁCI

Počkejte do rána. Podle zkušeností je stejně velmi málo toho, co lze po pracovní době udělat. Ostatní organizace jsou uzavřeny, tak co?

PLÁNUJTE V KALENDÁŘI

Je důležité blokovat si čas ve dni nebo v týdnu pro důležité úkoly. V té době je možno využít zprávy, že nejsem momentálně k dispozici – a máte klid na důležité úkoly.

V životním cyklu projektu začíná plánování, když startujeme projekt, na nule. Je  to vidět v knize paní A. Svozilové, „Projektový management: systémový přístup k řízení projektů“. viz obr. Patrně se vychází z jednoduché úvahy, že na startu je vše na nule. Z mého pohledu to je ale velký omyl a to jak z hlediska teorie, tak i praxe. Před startem projektu je vždy předprojektová fáze. Zde se stanovují cíle,  analyzuje se trh, hledají se rizika, kalkulují se náklady na pracovníky i materiál, ověřují se zákaznické požadavky, ověřuje se nová technologie, provádí se prototyping, simulace, modelování, kontaktují se budoucí dodavatelé, vyhodnocují se jejich nabídky, rezervují se zdroje, atd. Stručně řečeno vše pro to, aby na konci projektu byly splněny požadavky co do kvality, času i nákladů.  Tak vzniká soubor dokumentů, který je základem pro smlouvu se zákazníkem (externí projekt) nebo pro rozhodnutí vedení firmy (interní projekt).

Plánování zdrojů je součásti nabídky pro zákazníka. Je třeba si ověřit zadaná data, např. deadlines, počet pracovníků a jejich man-days. Výsledky plánování jsou předpokladem pro kalkulaci ceny projektu a splnění všech požadavků zákazníka.

Kalkulace nákladů se provádí podrobně a sice za každé oddělení.

Pro kalkulaci nabídky např. u firmy Siemens AG byly vyvinuty specielní programy, které na základě požadavků zákazníka vykalkulují požadované výstupní hodnoty např. množství a cena materiálu, počet man-days pro pracovníky, kteří montují, zkoušejí a též odpovídající náklady. To vedlo k vytvoření rychlé a spolehlivé nabídky.

Jednou zákazníkovi zaslaná nabídka se už nedá znova kalkulovat. Zákazník však může některé pozice eliminovat a pokrýt je za lepší cenu u konkurence.

Úspěšné projektově orientované firmy mají před projektovým startem připravené plánování z více jak 70%.

Období mezi odevzdáním nabídky a smlouvou může trvat i několik měsíců. Po tuto dobu jsou rezervovány zdroje. Projekt je nastartován podepsáním smlouvy se zákazníkem nebo souhlasem vedení firmy. Po startu projektu následují 2-3 týdny na přípravu kick-off meetingu.

V tomto období jsou odchylky ve smlouvě zaneseny do plánu i dalších dokumentů. Jednotlivá oddělení kontrolují momentální situaci. Změny, jako výpadek specialisty se řeší též v tomto období.

Na kick-off meetingu jsou všichni účastníci seznámeni již s velmi stabilním projektovým plánem. Další změny, např. od zákazníka během realizace projektu, se zanášejí do plánu a vždy se kontrolují jejich následky, t.j. náklady a potřebný čas.

Změny se diskutují na projektové schůzi a nová verze plánu se komunikuje s účastníky projektu.

Závěr:

Začít plánovat až po projektovém startu znamená plánování neúspěšného projektu. Předprojektová fáze a aktivity v ní jsou základem budoucího projektu. Zde se již vytváří know-how, šance na trhu a je i měřítkem profesionality firmy. Pokud není systémový přístup již v předprojektové fázi, tak váš projekt bude probíhat jako např. oprava dálnice D1 Praha-Brno.

Ivan Valíčeki.valicek@bluewin.ch