Davis, Barbee: 97 klíčových znalostí projektového manažera

Zapojte uživatele – čím dříve, tím lépe. Možné problémy je třeba identifikovat v rámci vývoje co nejdřív, jakékoliv změny jsou tím nákladnější, čím blíže jsou plánovanému konci projektu. Zajistit, že hlas zákazníka bude slyšen hned od začátku projektu a ideálně i pravidelně v jeho průběhu, je důležité pro vzájemnou spolupráci i spoluzodpovědnost za výsledný produkt. Včasným zapojením zainteresovaných stran z nich uděláte své partnery po dobu trvání projektu.

Vyvarujte se ukvapeného, chyby produkujícího vývoje. Zadavatelé požadují, aby se softwarové produkty dodávaly rychle. Jenže co by se z krátkodobého hlediska mohlo zdát jako ztráta času, je v dlouhodobém výhledu naopak obrovskou časovou úsporou (například refaktoring).

Přijměte sponzory projektu definovat své požadavky. Hlavní příčinou selhání projektu bývají nedostatečně definované požadavky a nejvíce ohrožené jsou právě společnosti neschopné provádět kvalitní business analýzu. Mnoho vlastníků projektu (zákazník, sponzor, …) očekává, že požadavky na software definuje sám projektový tým, aniž by blíže specifikovali, co vlastně potřebují. Vlastníci skutečně nemusí znát, jak mají vývojáři postupovat, ale musí říct, co je požadovaným výstupem. Důkladně nadefinované požadavky propojí obchodní případ s projektovými cíli/výstupy. Úspěch projektu by měl zajímat právě ty, kdo do něj investovali peníze, proto by měli s participací počítat.

Dejte přednost jednoduchosti před složitostí. Složitost vzniká vždy, když nedáváte pozor. Jednoduchost by měla být cílená, zahrnutá v každém kroku. Nejlepší projektový manažeři dokáží problémy svého okolí absorbovat a dále je nezesilovat a nepropouštět na ostatní.

Splácejte své „technické dluhy“. Dobře spravovaný dluh je užitečným nástrojem, který řeší momentální nedostatek na úkor budoucích zisků tak, aby v daném okamžiku bylo dosaženo cíle. Technický dluh (hacky, workaroundy, chybějící dokumentace, …) může být opodstatněný pro dosažení ohrožených milníků, ale musí být spravován zodpovědně = projekt by měl s tímto „splátkovým kalendářem“ počítat.

Rozšiřujte tým o talenty, ne o dovednosti. Dovednosti si lze osvojit, znalosti naučit. Je však téměř nemožné učit dospělého člověka nadšení pro věc, chtít se rozvíjet, realizovat, spolupracovat, respektovat ostatní atp.

Jděte na to jednoduše. Požadavky mají zůstat jasné a jednoduché. Business analytici by měli požadavky formulovat do myšlenkové mapy. Jádro mapy tvoří jasně definovaný celkový cíl projektu (základní požadavek), na něj pak navazují hlavní požadavky, tvořené sadami vzájemně souvisejících detailnějších požadavků. Myšlenková mapa se postupně rozrůstá, dokud nejsou všechny požadavky krystalicky čisté a jasně definované.

Jděte na to, zbavte se neefektivních postupů. Filozofie „Méně je někdy více“ je  případě procesů klíčová. Antoine de Saint-Exupéry: „Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher.“ ~ „Stavu dokonalosti dosáhnete nikoli tehdy, kdy už není co přidat, ale teprve ve chvíli, kdy neexistuje nic, co byste měli odstranit.“

Produktivita vývojářů: vynikající versus průměrní. V softwarovém vývoji platí, že co naprogramujeme dnes, stane se základem pro zítřek. Pokud základy pokládají průměrní vývojáři, budou se k nim ti opravdu dobří muset vracet, aby se mohli posunout dál. Softwarový vývoj prostě není pásová výroba a často platí, že odvoláte-li z projektu neschopného vývojáře, bude to mnohem účinnější, než když přijmete jednoho dobrého navíc. I proto, že nově příchozí do již běžících projektů práci ještě zpomalí, čas potřebný pro dokončení projektu se tedy nezkrátí. Zvyšuje se tím nejen vytíženost stávajících lidí (je třeba nově příchozímu věnovat nějaký čas), ale také se zvyšuje i počet komunikačních kanálů, které musíte jako projektový manažer udržovat. Množství kanálů exponenciálně roste s počtem lidí v týmu: n*(n-1)/2. Pro 12tičlenný tým tedy = 12*11/2 = 66 komunikačních vztahů. Řešení? – Dejte kvalitním vývojářům mocné nástroje, aby mohli vytvářet kvalitní software rychleji.

Obchodní hodnota je to, co definuje úspěch. Projekt je úspěšný pouze tehdy, přinese-li společnosti určitou obchodní hodnotu. Projekt není jen o dodávce software, pokud projekt nepropojíte s obchodními potřebami, pak se i sebekvalitnější software může potkat s neúspěchem. Jakým způsobem výstupy vašeho projektu pomohou společnost ušetřit/vydělat peníze? Co bylo oním důvodem, že se přistoupilo k realizaci právě tohoto projektu? Motivování týmů a okamžité rozhodování o složitých záležitostech se stává jednodušším, pokud přesně víme, co má projekt společnosti přinést a zda je hlavním hybatelem čas, peníze, či kvalita.

Poskytněte pracovníkům čas na koncentraci. Obecně platí, že pokud je člověk vyrušen, trvá mu celkem dvacet minut, než se začne opět koncentrovat. Těmto prodlevám lze předcházet například vyhrazením dvou hodin denně, kdy nebudou vyrušováni a mohou soustředěně pracovat. Obdobně lze třeba celý jeden den vyhradit striktně na práci, tj. bez porad (Think Fridays ~ pátky k přemýšlení). Rovněž je důležité, aby vývojáři věděli, které dva z jejich úkolů jsou prioritní, a mohli si tak lépe plánovat práci, a ušetřit je infomanie (vysilujícího stavu informačního přesycení), jelikož už programování samo o sobě vyžaduje držení spousty informací současně.

Projektový management je management problémů. Kdyby to tak nebylo, nebylo by třeba projektových manažerů. Snadno by se zadal požadavek na realizaci projektu a propojilo se vše, co s ním souvisí (zdroje, technologie, zadání, časový plán atd.). Práce by běžela hladce a bez potřeby dozoru. V praxi však projekt bez problémů není reálný, a právě proto je tu role projektového manažera, který by si měl být vědom toho, že jeho práce spočívá právě v řešení komplikací všeho druhu (organizačních, interpersonálních, …).

Používejte wiki. Soustřeďte důležité projektové informace na jednom místě, aktualizované a s online přístupem pro každého člena vašeho týmu. Kdykoliv se chystáte poslat e-mailem informace související s projektem, zvažte, zda není týmová wiki vhodnějším místem k jejich sdílení a uchování.

Projektové kanceláře – trend poslední doby. Projektové kanceláře (Project Management Office – PMO) tvoří skupina pracovníků pověřená supervizí a podporou podnikových projektů a programů. Dohlíží zejména na konzistenci projektových šablon/dokumentací, standardizuje procesy (např. reporting). Tato centra informací a koordinace mají být určitou jistotou v nestálém pracovním prostředí.

Pravidlo 60/60. V průměru 60 % nákladů životního cyklu softwarových systémů se vztahuje k aktivitám spojených s údržbou (rozšíření, změna požadavků, migrační aktivity, opravy chyb atd.), zatímco vývoj generuje relativně slabých 40 % nákladů. Z těchto 60 % nákladů údržby softwaru jde právě 60 % na rozšíření systému. Z toho plyne, jak důležité je navrhovat udržitelné systémy, flexibilní vůči změnám (novým požadavkům zákazníka).

Vědět, kam směřuji já sám, je předpokladem úspěchu. Člověk, který neví, co se sebou, nemůže být dobrým manažerem. Aby mohl projektový manažer řídit nebo vést tým (mezi tím je velký rozdíl), musí zcela ovládat sám sebe – musí naprosto chápat účel své práce, mít stanovenu vizi a poslání, stejně jako osobní a profesní cíle, jasno v prioritách. Pomáhá si každý den, týden a půlrok vyhradit čas na revizi, v jakém bodě svého života se nacházíte, jak se držíte svých krátkodobých cílů na tý/denní bázi a jak těch dlouhodobých, osobních i profesních.

Zaveďte agilnější komunikační systém. Jednou z typických mylných představ je, že synchronní způsoby komunikace (tj. real-time komunikace mezi všemi účastníky, osobně či virtuálně) jsou vždy efektivnější než asynchronní (tj. přístup k informacím bez nutnosti fyzické přítomnosti a real-time dostupnosti, tj. e-mail, sdílené úložiště).

Neuctívejte metodologii. Žádná učebnice či metodika, které jste nuceni používat, nejsou důležitější než váš zdravý úsudek, protože projekt sama o sobě neuřídí. Kdyby tomu tak bylo, neměla by role projektového manažera opodstatnění. Strategie řízení projektu je až druhotná poté, co si sami zanalyzujete podklady k dodávce, vyhodnotíte skutečné potřeby, rizika.

Klam dokonalé znalosti. V žádném okamžiku nevíme vše. Technologie a postupy, včetně myšlenek, na kterých byly vystavěny, se mění tak rychle, že není možné, aby je ti, co je využívají, v jakémkoliv okamžiku dokonale znali. Je tedy bláhové myslet si, že v případě softwarového projektu můžeme stanovit kompletní a nekonfliktní požadavky, navíc hned v počátečních fázích, kdy je oblast neprobádaná, a míra poznání tedy velmi nedokonalá. Vzniká zde prostor pro agilní techniky, a to i ve fázi údržby softwaru.

Budujte tým maratonců, ne sprinterů. Když sprintujete, rychleji se vyčerpáte. Abyste zvládli maraton, musíte být disciplinovaným a trénovaným týmem, který má nastaveno dlouhodobě udržitelné tempo. Softwarový projektový manažer by měl primárně dbát na nastavení a údržbu tempa a nechat tým běžet, měl by být jako kernel: sám o sobě nevykonává žádné úkoly zadané koncovým uživatelem, ale zajišťuje, že tyto úkoly správně dokončí aplikace na něj navázané.

Svatá trojice projektového managementu. Připravte si nákres trojimperativu – rovnostranný trojúhelník, u jehož jednotlivých vrcholů budou nápisy Čas, Náklady, Rozsah. Ty vymezují prostor středu trojúhelníku, kterým je Kvalita. Tento geometrický způsob prezentace projektové práce ukazuje, že změna jakékoliv ze tří stran mění minimálně jednu ze dvou zbylých stran a ovlivňuje také kvalitu projektu.

Začínejte s myšlenkou na konec. Od začátku je dobré jasně vědět, k čemu směřujeme, a s tímto vědomím pracovat každodenně.

Komunikace je klíčová. Můžete mít spoustu certifikátů a řadu titulů před i za jménem, pokud však neumíte spolupracovat s lidmi, jen těžko v projektovém řízení uspějete.

Členové týmu jsou lidské bytosti. Nezapomínejte na to, že váš projektový tým tvoří lidské bytosti se všemi svými touhami, limity, silnými a slabými stránkami. Úspěch vašeho projektu závisí mnohem více na jejich osobních postojích a schopnostech než na kouzlech Ganttova diagramu. Proto nezapomínejte především vést svůj tým – otevřeně a čestně. Jsme „pouze“ lidé, emoce jsou nám přirozené a nemůžeme je odložit ani v práci. Ale pouze my lidé dokážeme vyvinout software. Je třeba proto nakládat se svým lidským kapitálem minimálně tak pečlivě, jako sledujeme a chráníme ostatní zdroje.

Důležité, nikoli naléhavé. Podle důležitosti a naléhavosti lze aktivity klasifikovat do čtyř kategorií:

1. Důležité/Naléhavé. Aktivity, které je třeba vypořádat hned, jakmile se objeví (tzv. „hašení“), ale měly by být ojedinělé, nevytěžovat.
2. Důležité/Nenaléhavé. Aktivity, kterými bychom se měli předně zabývat (produkce hodnot s využitím vlastní odbornosti = seberealizace).
3. Nedůležité/Naléhavé. Aktivity, které je třeba omezit či realizovat jindy (zpravidla se jedná o vyrušení „odjinud“).
4. Nedůležité/Nenaléhavé. Aktivity, od nichž lze upustit. Udělejte to.

Sdílejte vizi. Předpokládejte spíš to, že každý chce uspět a být pyšný na práci, kterou odvedl, a ne sabotovat váš projekt. Ale vězte, že většina týmů pracuje v temnotě. Neví, proč je projekt důležitý, jak přispívá celkové strategii organizace, proč je konečný termín zrovna ono datum, neznají pozadí rozhodnutí, kontext. Abyste mlhu rozptýlili, musíte s členy týmu sdílet klíčové informace, které jim pomohou pochopit podstatu toho, čemu chcete, aby věnovali maximální úsilí a to nejlepší ze sebe. Umožníte jim tak rozvíjet přirozené sklony k spolupráci a seberealizaci, čímž sami velmi získáte – nejen projekt, ale i dobré vztahy.