Méně práce s řízením organizace

Dlouhodobě se věnujeme problematice projektového řízení. Nikdo není univerzální, ani my a proto upřesňujeme, že naším oborem jsou projekty zaměřené na návrh a vývoj, organizační a procesní změny a rozvoj firem. Pomáháme s projekty a školíme vedoucí, ať už jde o manažery softwarových týmů, manažery kvality a liniový management středních i velkých firem.

Na této stránce se věnujeme všem otázkám, které souvisí s projekty ve firmách, projekty vývoje software a činností projektových vedoucích obecně. Rádi zodpovíme i všechny vaše dotazy.


Je Agilní přístup k plánování optimální?

Agilní přístup k řešení čehokoli už dávno není módním pojmem. Zabydlil se ve slovníků odborníků i manažerů a i když se používá pro označení ledasčeho (nejčastěji absence plánování a řízení obecně), má své pevné místo v pohledu na řízení týmových činností.

Agilní přístup přišel jako řešení dilematu projektových vedoucích

  1. Vedoucí projektů jsou pochopitelně tlačeni sponzory / managementem k tomu, aby v rámci projektů šetřili zdroje, resp. byli co nejlevnější.
  2. Z druhé strany účastníci projektu, ale stejně tak často sami sponzoři chtějí do projektu kdykoli zasahovat a od manažera projektu se očekává, že dokáže všechny změny zapracovat.

Agilní metodologie byly vymyšleny jako nástroj k řešení především druhého problému - přizpůsobivosti. Pro lepší úspěšnost v propagaci se samozřejmě vyzdvihuje i přínos k ekonomičnosti. Nutno přiznat, že reálný základ tato obhajoba má. Dokážu-li se kdykoli otočit, nehrozí, že půjdu jinam, než kam chci. Agilní přístup je právě o tom, abych se dokázat ve svém směru otočit kdykoli, když se ukáže, že původní směr není ten pravý. Jestli s tímto přístupem k vedení někdy vůbec někam dojdu, je věc druhá. Manažer samotných činností fakticky odpovědnost za to, že se někam dojde, přenechává na těch, kdo s požadavky na změny přicházejí.

Odpověď na otázku o optimálnosti agilního přístupu tak závisí na definicí samotného pojmu optimální. Je pro mě optimální někam dojít nebo se umět co nejrychleji otočit? Chci někam dojít s co nejmenším úsilím? Pokud chci skutečně minimalizovat náklady (zdroje), pak agilní přístup optimální není. Pokud ale na začátku nevím, kam chci dojít, jiná rozumná alternativa řízení projektu dnes v podstatě není.

Před rokem (v r. 2013) vyšel článek "Multi-sprint planning and smooth replanning: An optimization model" v Journal of Systems and Software, Volume 86, Issue 9, September 2013. Autoři používají metody lineárního programování na to, aby v každém okamžiku projektu našli optimální pokračování projektu a to nejenom v rámci aktuálního Sprintu, ale i v dalších spritech. Protože jde o problém patřící do skupiny nazývané "Problém obchodního cestujícího", jde o řešení náročné dokonce natolik, že autoři vyvinuli heuristický algoritmus, který celé plánování dostává do přijatelných časových mezí (viz článek "A Lagrangian heuristic for sprint planning in agile software development"). Nechme autory dál bádat; jejich práce i závěry ukazují pro nás podstatný fakt, že představa, že by Agilně řízený projekt byl optimální z hlediska využití zdrojů, je iluze, kterou se daří udržet jen do doby, než se skutečný průběh takto vedeného projektu porovná s optimálním. Takové srovnání naštěstí skoro nikdo nedělá, takže se iluzi daří udržovat dlouhodobě.

Ale zpět k úvodu: agilní přístup skutečně není a ani v principu nemůže zaučit optimální cestu. Agilní přístup je řešením pro situace, kdy teprve v počátcích projektu zjišťujeme, kam se jde a kudy se jít dá. Pro takové cesty máme pojem anabáze. Jestliže vaše projekty jsou anabází, pak je agilní přistup k řízení optimální. Pravděpodobně se to dá i otočit: Jestliže se v organizaci agilní přístup dlouhodobě jeví jako nejlepší možný způsob řízení, firma prožívá dlouhodobou anabázi. Se všemi důsledky na efektivitu, schopnost dosáhnout cíle i spokojenost pracovníků.

Otázce agilního vývoje se věnujeme i v samostatném článku

25. 9. 2014


Potřebuje vedoucí projektu rozumět technologiím, se kterými se projekt realizuje?

Na tuto otázku proběhla před časem diskuze vedoucích projektů. Z cca 2000 účastníků diskuze jich bylo téměř 75% přesvědčeno, že potřebuje.

Jak to vidíme my ať už v projektech tak v našich školeních pro vedoucí projektů?

Základní problém otázky je už v ní samé. Pokud není projekt triviální, pak se používá spousta technologií.

Co všechno potřebujete, když stavíte dům, potřebujete betonáře, svářeče, bagristy, zedníky, topenáře, elektrikáře, podlaháře, tesaře, pokrývače, sklenáře, malíře a mnoho dalších profesí. Každý z nich má vlastní technologie, nástroje, postupy a nikdo nepředpokládá, že by vedoucí stavby dokázal kohokoli zastoupit.

Když vyvíjíte software, potřebujete analytiky, architekty, technické designéry, grafiky, programátory pro back-end, fornt-end, testery, možná školitele, možná řadu dalších profesí. Čím je firma a projekt menší, tím více se práce kumulují. A tím větší všeuměly takový projekt vyžaduje. Jenomže všeuměl byl i Všeználek i Neználek v oblíbené dětské knize doby naštěstí snad minulé od Nikolaje Nosova. I když zastáváme přesvědčení, že širší rozhled je pro každého pracovníka důležitý, odbornost vyžaduje soustředné úsilí a to nelze směřovat na mnoho dovedností.

Obrácený pohled je ale také špatný. Stavbyvedoucí, který úspěšně řídil stavbu deseti kancelářských budov, bude jistě dobrým projektovým manažerem. Přesto bych mu větší softwarový projekt nesvěřil. Práce s partou zedníků je jiná, než s partou grafických designérů a domluvit správný rozsah testování podnikové aplikace vyžaduje jiné znalosti, než dohodnout předávku střechy s kontrolou vodotěsnosti. Projektový manažer musí mít přehled o technologiích i postupech, které se v projektu používají, stejně tak, jako musí znát, jak pracují lidé, kteří podobné projekty dělají:

Všechny uvedené dovednosti víceméně souvisí i s používanými technologiemi. Jinak se staví cihlový dům a jinak dřevostavba. Jinak je třeba přistoupit k implementaci podnikového CRM a zcela jinak k vývoji výukové aplikace pro tablety. Projektový manažer, který přestoupí do zcela nové branže (např. z podnikových systémů na mobilní), je zcela odkázán na odhady lidí z týmu, není schopen je kontrolovat a posoudit jejich realističnost. Je veden informacemi svého týmu, místo aby byl leaderem. Jestliže takový projekt dobře skončí, je to díky jiným kvalitám, než kvalitnímu řízení.

Velký projekt, malý projekt

Musí tedy rozumět technologiím? Ne, nemusí, nemusí být zedníkem ani programátorem, nemusí být ani architektem nebo malířem. Musí ale vědět, jak ty činnosti, které v projektu probíhají, fungují, co vyžadují, jaké jsou jejich rizika. Míra detailu, ve které se orientuje, závisí především na velikosti projektu samotného.

Jak už je zmíněno výše, potřeba orientace v technologiích hodně závisí na velikosti projektu. V malých projektech si vedoucí třeba i zapracuje - vykonává některou z expertních rolí a je tedy logicky nezbytné, aby byl na tu danou činnost odborníkem (měl expertní znalost). V IT/SW projektech to často bývá kombinace s analytikem.

V projektech, kde pracují řádově jednotky nebo několik málo desítek lidí (cca do 25) je možný ještě režim, kdy vedoucí projektu přímo řídí všechny práce. Musí těmto pracím rozumět, má o nich znalosti, ale manažerské, nikoli expertní. Do jeho kompetence bude spadat řada manažerských rozhodnutí souvisejících s technologiemi, např. jejich schválení.

Ve velkých projektech se manažer k práci ani nedostane, protože jednotlivé oblasti práce budou plně řídit vedoucí týmů nebo dokonce vedoucí podprojektů. Manažer projektu pak zajišťuje globální plánování a řízení (koordinaci, synchronizaci, komunikaci apod.), ale nečiní technická rozhodnutí ani technologické předpoklady nebo odhady. I vedoucí projektu na této pozici musí mít technické povědomí, ale to se týká celku, nikoli konkrétních činností. Příkladem je vedoucí projektu návrhu nového dopravního letadla. Desetiletý projekt s tisíci zaměstnanci je řízen podobně, jako středně velký hi-tech podnik a od vrcholového managementu se neočekává žádná znalost testování real-time systémů nebo vlastností leteckých motorů.

U středních a velkých projektů naopak velkou pozornost vyžadují skutečně manažerské činnosti, vyžadující specifickou odbornost - vedení lidí, řízení rizik aj. Manažer, který se v těchto oborech dlouhodobě rozvíjí, nemůže být současně odborníkem na nejnovější technologie

Neznámé technologie v projektu

V mnoha projektech se vyskytnou nové technologie, které jsou zcela neznámé i pro vedoucího projektu, v horším případě pro celý tým. Takové technologie vyžadují doslova zvláštní zacházení a vedoucí projektu by měl i vědět, co v takovém případě dělat, aby ho ?nenapálily? a projekt mu nezkazily. Dobrý projektový vedoucí proto umí v projektu využívat i technologie, které nezná. Pokud jich ale je mnoho, projekt se stává agenturou - putováním neznámou krajinou bez mapy.


Jak zajišťujete v projektu kvalitu?

Otázka kvality je důležitá a je dobré si hned říct, že odpověď nutně závisí na typu projektových prací. Co vyhovuje našim projektům, nemusí vyhovovat jiným.

Důležitým faktem, na který se v projektech občas zapomíná je, že ne všechny kvalitativní parametry je možné odhalit z hotového výrobku. Pokud bude projekt spoléhat na finální testování, nejdůležitější potenciální závady nejsou vůbec zkoumány. To platí pro mnoho projektů - vývoj a výrobu automobilu, stavbu domu i návrh a vývoj software. Ale zatímco materiálové testy jsou běžné, průběžná kontrola kvality prací v softwarovém projektu stále ještě běžná není.

Zpět tedy k původní otázce. Základem rozhodování o kvalitě je plánování kvality hned od počátku:

Velmi často je konečné zjištění takové, že nekvalitu mohu odhalit pouze tak, že sleduji proces, při kterém daný výstup vniká, protože nemohu po dokončení nekvalitu odhadnout. Jako nelze efektivně ověřit kvalitu svárů na armaturách (bez jejich destrukce), kvalitu armatur po zalití betonem, tak nelze efektivně odhalit nekvalitu vnitřního návrhu nového IT produktu z hotového celku. Jistě, puristé namítnou, že to lze - mohu filmovat průběh stavby stejně jako mohu procházet všechny záznamy a návrhy analytického týmu. Obojí je ale zbytečné. Za prvé zpětné procházení bude velmi zdlouhavé a náročnější než přímá kontrola na místě. Za druhé, a to především, když zjistím nedostatek, je to k ničemu, protože pravděpodobně nepůjde odstranit.

Rozhodnout se o vhodném způsobu kontroly proto musím před tím, než se s pracemi začne. Nejúčinnější a nejefektivnější kontrola je totiž už při samotné činnosti. Poslední smysluplná kontrola musí proběhnout okamžitě po činnosti, předtím, než na činnost navážou činnosti další.

Samotný způsob kontroly se samozřejmě liší podle toho, co se testuje. Možností je mnoho, základní jsou ale skupiny:

Znovu ale připomínám to důležité - když se rozhoduji a správném testování, musím si umět odpovědět i na klíčovou otázku: Co budu dělat, když test ukáže, že testovaný výstup je špatný?

Únor 2013


Chci Vás požádat o stručnou informaci. Potřebuji vědět, zda existuje (příp. kde ji nalézt, stáhnout...) adresářová struktura pro řízení projektů.

Předpokládám, že adresářovou strukturou myslíte skutečně adresáře na disku ať už lokálním projektového manažera nebo sdílenou projektovou kancelář na serveru.

Neexistuje obecně platná struktura vhodná pro každý projekt. Vždy se využívá struktura odpovídající oblastem, které je třeba v projektu třeba řešit. Dále záleží na firemním standard. My např., když ve firmách vytváříme pravidla projektového řízení, tak standardně v každé projektové kanceláři máme složky _Rizeni-projektu, _Archiv, _Contract (ten má často omezený přístup pouze pro lidi, kteří vidí do kontraktů), někdy také _Audit (podle pravidel firmy). Další složky už se řídí činnostmi.

Např. když se podíváte na poslední příspěvek v našem blogu (http://ww.pdqm.cz/Blog/Blog-List.html) , tak tam je obrázek konceptu jednoho projektu ve formě myšlenkové mapy a podle ní jsou i složky v projektové kanceláři: Zřízení-pobočky, Lidé, Préce,... taková struktura by ale pro jiný typ projektu byla samozřejmě nesmyslná, nenapadá mě mnoho projektů, ve kterých bych měl složku Práce :-)

2009

PDQM, s.r. o.   1997-2007-2015   Podmínky užití stránek

Hlavní stránka

O firmě

CMMI - otázky a odpovědi

Blog PDQM

Na této stránce

Znalost technologií u PM?

Zajištění kvality v projektu

Struktura projektové kanceláře

Nabízíme

Vzdělávací program pro projektové manažery

Školení řízení programů

Return to main page www.pdqm.cz Podpora řízení Školení Analýzy Vývoj Software Standardy O nás

Telefon: +420 605 203 938

Email:

Kontakt