Ve světě software developmentu je komunikace stěžejní. A to nejen v rámci vývojového týmu, zásadní je rovněž předávání informací mezi projektovým manažerem a klientem, potažmo zadavatelem. Právě projektový manažer je styčnou osobou, která je odpovědná za řízení a transparentní komunikaci, což je základní předpoklad pro úspěšné doručení projektu. Ne vždy ale všechno funguje hladce.
Jakmile nastane i zdánlivě menší problém, může se projektový manažer snadno dostat do vleku událostí, ze kterého je někdy komplikované vystoupit. Jak se této situaci, která může potkat i zkušené matadory, vyhnout?
Buďte v komunikaci transparentní
V praxi se často setkávám s projekty, které na první pohled fungují. Projektový manažer úspěšně označuje úkoly jako vyřešené, plán vypadá slibně. Na druhé straně stojí klient, informován, jak se projekt hýbe kupředu. Ale v průběhu realizace přichází s dalšími a dalšími požadavky. A své požadavky má i delivery (například dokumentace, technologický dluh, optimalizace výkonu řešení nebo automatizované texty), se kterým se na začátku ne úplně počítá. Projektový manažer pak argumenty obou vyhodnotí jako validní a rozsah projektu narůstá.
A v tuto chvíli se otevírá obrovský prostor pro nedorozumění – obě strany sice chtějí spolupracovat, ve skutečnosti však jen vzájemně vrší požadavky. Projektový manažer se ocitne mezi dvěma ,houbami‘, které chtějí jenom nasávat. Je nutné přepracovat plán projektu a termín dodání je v nedohlednu. Proto je třeba za každou cenu udržovat komunikaci transparentní pro obě strany. Zasednout ke kulatému stolu a uvědomit si, co nové požadavky znamenají jak z pohledu času, tak z pohledu rozpočtu projektu. Vždy je jednodušší uhasit malý, konkrétní problém než si falešně nalhávat, že vše se nějak vyřeší samo. Malé problémy by časem jen přerostly v krizi a mohly mít za následek i vypovězení spolupráce nebo totální frustraci týmu – až jeho rozpad.
Důvěřuj, ale prověřuj
Důvěra v projektový tým je pro projektového manažera naprosto nezbytná, to však neznamená, že by si občas neměl zašpinit ruce. V praxi to znamená znát potenciální hrozby a potíže, se kterými se tým potýká. Na druhou stranu nemůže každému stát za zády a zabývat se drobnostmi. Platí zde proto zlaté pravidlo ,důvěřuj, ale prověřuj‘, díky kterému se i sám projektový manažer udržuje lépe v obraze než na základě odškrtnutých položek nebo vyplněných reportů.
Navíc ten, kdo má přehled o hotové a dodané práci, ji může lépe dávkovat. Nevznikají prostoje, tým je efektivnější a motivovaný. Projektový manažer si tak udrží i střízlivý pohled vůči klientovi a neslibuje nemožné. A samozřejmě by měl mít každé rozhodnutí podpořené daty a argumenty.
Jak to zajistit prakticky? Pokud můžete během realizace klientovi výstup průběžně prezentovat, byť v ne úplně souvislých celcích, určitě to dělejte. A co víc, jako projektový manažer k těmto ukázkám přizvěte i zástupce z řad vývojového týmu. Vždy někoho nominujte. Je to nejlepší způsob, jak do týmu přenést reakci zákazníka a jeho připomínky. Projektový manažer je nikdy nedokáže zprostředkovat věrně. Buďte realisti a nechtějte po programátorovi, aby snad řešení prezentoval, nebo se dokonce se zadavatelem ze strany klienta pouštěl do obhajoby řešení. Úplně postačí, když bude pasivním účastníkem a seznámí se s pocity klienta.
Sofistikované procesy a nástroje nic neznamenají
Softwarový vývoj má svá pravidla. Existuje řada přístupů, kterými se lze řídit. Od vodopádových po agilní. Ať už upřednostníte kterýkoli z nich, všichni účastníci projektu, včetně zúčastněných osob na straně zákazníka, musí aplikovaný přístup chápat. Minimálně jeho základní principy. Neexistuje univerzální řešení. Populární scrum není všespásný a nebude vyhovovat zadavateli, který chce jasně definovanou roadmapu a pevně zakotvený termín dodání. Volba metodiky vyžaduje notnou dávku citu a zkušeností.
Říká se, že Excel snese všechno, a často je to bohužel pravda. Někdo dodá projekt i s tužkou a poznámkovým blokem. Proč ale nevyužít některý z nástrojů pro podporu vývoje softwaru, když navíc může podporovat zvolenou metodiku. Na trhu jich existuje řada, a především ty cloudové lze začít využívat prakticky ihned.
Pusťte vlka do kurníku
Sledujete zásilku, kterou vám někdo odeslal? Zda je již zabalená, v depu, nebo u kurýra? Využíváte při cestě autem navigaci? Sledujete počet kilometrů do cíle, čas do cíle, nebo předpokládaný čas příjezdu? Já ano, chci být informovaný. A váš zákazník také. Chce vědět, kolik toho už máte, jestli se vejdete do rozpočtu a zda vše bude v dohodnutém termínu.
Spoléhat se na pravidelný status projektu, kde se vše klient věrně dozví, je jedna z možností. Ať si ale každý projektový manažer sáhne do svědomí, zda vždy podával pravdivé informace, nebo vytvořil falešná očekávání, jen aby byl klid. A ujistil klienta, že „my to přece v následujícím měsíci opravíme a zpoždění doženeme“.
Samozřejmě přístup klienta do systému může znít jako sebevražedná mise, pro zadavatele zase může být myšlenka kontroly velmi lákavá. I zde platí – všeho s mírou. Elegantním řešením je dát zadavateli klíče jen od určité části a zpřístupnit mu pouze vybraná data, případně s jeho systémem vybrané informace synchronizovat. Pro řízení projektu si tedy vytvořte ,zákaznickou zónu‘, kde bude možné nahlížet na reálný stav.
Obraťte se na odborníky dřív, než bude pozdě
Pokud se projektový manažer dostane do situace, kdy se rozjetý vlak řítí špatným směrem, může (a měl by) se obrátit na nadřízeného nebo vyhledat jinou odbornou pomoc. Není od věci poohlédnout se po externí kapacitě v podobě projektového manažera. A to především proto, že daná osoba dokáže na problematiku nahlížet zvenčí, nemá problém klást nepříjemné otázky a pomůže týmu najít ztracenou důvěru.
Paradoxně největším problémem je stav, kdy si daný projektový manažer řekne, že už je pozdě a s danou situací se nedá nic dělat. Ve skutečnosti není nic horšího než se dál řítit do propasti. Říkat si, že přece vy za nic nemůžete, a začít obviňovat okolí. Zadavatel nedokáže specifikovat zadání, vývojáři odhadují nepřesně a taky pořád kupí chyby. To je úplně běžný stav, a je na vás, abyste podobné situace dokázali řídit.
Z vlastní praxe mohu říct, že prakticky o všem se dá se zákazníkem jednat. Nejhorší je přirozeně okamžik, kdy komunikujete nepříznivý vývoj projektu. Vzápětí ale nabídněte varianty, jak dál navrhujete postupovat. Někdy nelze všechny krize vyřešit bez negativních následků, minimálně však můžete zmírnit jejich dopad.
