nav line

Ví opravdu každý člen teamu, kam projekt směřuje?

Říká se, že není třeba vymýšlet kolo, protože to už všichni znají, používají a nejde na tom vlastně vymyslet nic nového. Otázkou je, zdali to pověstné kolo implementujete opravdu jako kolo nebo výsledek vypadá někdy jako šiška. Kdy se z kola stane šiška a jak tomu předejít? Ví team, že vzniká šiška nebo si všichni myslí, že vyrábí kolo?

Svým způsobem je tato „problematika“ aplikovatelná prakticky na jakékoli odvětví činnosti. Na jaké straně běžně vázne komunikace nebo se nedostává tam, kam by měla a kdy tyto problémy vznikají? Lze je nějak účinně eliminovat a poučit se z blízké historie? Pochopitelně neexistuje univerzální odpověď, ale pojďme se na to podívat blíže.

Projektové řízení a webová integrace

Zdali team vytváří kolo nebo šišku by měl vždy vědět projektový manažer. Je především v jeho zájmu si průběžně třídit a aktualizovat informace, aby mohl dávat relevantní odpovědi jak směrem nahoru tak také dolů. Jsou samozřejmě situace, které proces nemůže pokrýt a je dobré těmto situacím předcházet. Níže zmiňuji různé checkpointy, které mnohé zbytečné práci dokáží bezpečně zabránit. Je už na schopnostech projektového manažera jak s takovými informacemi dále naloží. Checkpoint se může v některých situacích jevit jako práce QA teamu, ale není tomu tak. Checkpoint nejde na takový detail jako testování, je to především o rychlém porovnávání vstupních a výstupních informací mezi různými fázemi výrobního procesu. Za pomoci checkpointů v podstatě především eliminujete syndrom „tiché pošty“ – kdy na vstupu máte čtverec a na výstupu onen obdélník.

Svou komplexností se webová integrace rozmachuje i mimo běžné: „začátek – výroba – spuštění“ a tedy i na procesy spojené s daným projektem jsou kladeny jiné nároky než „obyčejně“. Projektové řízení webové integrace zahrnuje koordinaci různých odvětví, druhů práce a také různých subjektů, které na sobě mohou fungovat zcela nezávisle. Špatně zvolený proces je cestou do nekonečné smyčky úprav/oprav, ale také nadměrného množství zbytečné práce.

Procesy, schémata, poučky, guidelines…

Každá správně fungující organizace má nějaké více či méně podrobné „how-to“ na obor své činnosti. Je samozřejmě žádoucí, aby takovéto informace byly k dispozici v ucelené a aktualizované formě, aby v případě potřeby je mohl každý najít a čerpat z nich.

Postupem času se v teamu objevuje jakási forma individuálního výkladu daných postupů. Jedná se o v zásadě opakující se chování, které vzniká z jisté formy automatizace a „masteringu“ dané činnosti. Jedním z mnoha takovýchto drobných ústupků v procesu je tzv. protože minule to tak fungovalo taky“, se kterým jde ruku v ruce „nemusím to znovu nikomu říkat“. To se děje především u ostřílených matadorů, kteří tu samou věc dělají po několikáté, zdokonalují se a některé pravidla již jim třeba nemusí vyhovovat. Zapomínají ovšem někdy i na ty ostatní, kteří nemají věšteckou kouli a nepočítají s odchylkou.

To je běžný vývoj a evoluce, ale je potřeba nezapomínat na zlaté pravidlo: KOMUNIKOVAT a to i o zdánlivě banálních věcech, protože platí, že to co připadá banální jednomu tak druhému se takto jevit nemusí.

Opakujte, trénujte!

Opakování matka moudrosti. Nebojte se udělat jednou za čas schůzku, kde klíčovým lidem znovu oprášíte „jak to děláme“ a „proč to tak děláme“ i když by to měli znát. V následné diskusi může kdokoli přispět nějakým zajímavým názorem, který můžete využít. K tomu se nám velmi osvědčují některé pojmenované schůzky, které jsou zaměřeny na konkrétní stav projektu a procesu - začátek, vyhodnocení, opakování - o nich a nejen o nich v dalším samostatném článku.

Co je to checkpoint a jak si je správně stanovit?

Může to být komplexní výstupní dokument sestrojený pověřenou osobou na daném úseku nebo to může být 10min hovor u kafe na obědě? Samozřejmě forma je na každém a není upřímně až tak důležitá, důležitý je její přínos. Tyto body se dle metodiky řízení jmenují různě, ale v zásadě jde prostě o kontrolní mechanismus, který vám usnadní směrování celého systému. Je samozřejmě vždy lepší kontrolovat více menších částí než komplexní projekt až na konci.

Běžně se stává, že existují projekty, které jsou kontinuální po dobu i více než roku. Na takovémto projektu si bez checkpointů nebude prakticky nikdo pamatovat, co bylo na začátku a co má být na konci. Svou úlohu v tom hraje nejenom čas projektu, ale také klient, který v průběhu doby generuje množství připomínek, změn a návrhů.

Checkpoint je také dobré použít k rychlému zadání práce na další období do dalšího checkpointu. Potvrzení další práce je vždy žádoucí s ohledem na délku projektu a pověstné světlo na konci tunelu.

Vtáhněte všechny pracovníky do procesu!

Proces je soubor informací a postupů, které mají být dodrženy, aby byl výsledek správný. Pokud máte ve společnosti hierarchii tak se procesy dělí na různé úrovně pracovníků. Někdy to ovšem může být problém, jelikož někdo z levého konce si nemusí být vědom, co dělá někdo jiný na pravém konci. Ve velké míře je to způsobeno tím, že někdo nebere projekt za svůj a chápe se jen jako zdroj pracovní síly na daný task – nevidí širší souvislosti. Je tedy vhodné vysvětlit všem, jak daný projekt ovlivní to nebo ono či jak je daný projekt důležitý pro společnost a potažmo pro koncové pracovníky.

Konzultujte se členy teamu projektové záležitosti, dejte jim prostor se vyjádřit. 20min času, který věnujete zainteresováním lidí do projektu se vám mnohonásobně vrátí lepší proaktivitou a osobním zájmem na projektu.

Velmi se osvědčuje, aby daný checkpoint měl na starosti člověk oddělení, ke kterému se kontrola vztahuje. Zajistíte tím dvě velmi důležité věci; První je osobní zainteresovanost v projektu – možnost se vyjádřit případně něco ovlivnit je pro mnoho lidí zajímavou motivací. Druhým je osobní zodpovědnost za odvedenou práci a jistota, že na další část procesu bude dodán správný polotovar.

Uzavření projektu s teamem

Ve všech případech udělejte po dokončení projektu nějakou formu uzavření. My používáme tzv. „Lesson learned“ schůzku. Tam vyzdvihněte pozitivní, ale i negativní věci na daném projektu. Ideálně za účasti team leaderů i workerů, aby všem bylo jasné na co si příště dát pozor a také co bylo uděláno správně. Je velmi důležité sdělovat oba druhy informací a ne jen ty negativní – negativní schůzky každého otráví a klíčoví lidi si mnohdy odnesou jen ponaučení „budu příště mlčet“ – a to je špatně. Závěr projektu nikdy nepojímejte jako grilování lidí, kteří způsobili v cestě nějaký zádrhel. Zmiňte to, ale nebuďte adresní. Dotyčný to bude vědět a ostatní si dají na podobnou věc následně pozor.

Každá negativní informace by měla být adekvátně vyrovnána nějakou pozitivní.

Neexistuje univerzální rada, ale jen obecné doporučení. Nebojte se komunikovat, nebojte se dávat informace kolegům. Je lepší informaci opakovat než ji neříct vůbec, někdo tuto informaci třeba nemusí vědět. Vzdělávejte (se) a sdílejte zajímavosti nejen z oboru se svým okolím. Zajímejte se o to co dělají ostatní byť to není váš obor. Dovolí vám to navrhovat řešení se znalostí konkrétní technologie, což není nikdy na škodu.

Nejdůležitější: Naučte se přiznat i své chyby a vezměte si z nich ponaučení!

Máte na cestě vývoje checkpointy?

Zdánlivě jednoduchá otázka, kterou většina lidí z produkce zodpoví kladně. Každý proces počítá s nějakou mírou zpětné kontroly, ale jak často a jak hluboko? Checkpoint je důležitý krok v jakémkoli procesu výroby a nemělo by se na něj zapomínat. Rozhodně nestačí si říci na začátku procesu „děláme modrý čtverec“ a nechat do až do spuštění být. Někde po cestě se nám totiž z modrého čtverce může stát světlemodrý obdélník. Pokud nemáme dostatek vhodných checkpointů, že máme světle modrý obdélník, dozvíme nejhůře v den spuštění. I samotná kontrola kvality (testing) by mohla se špatným vstupem hodnotit světlemodrý obdélník jako funkční a tedy zcela v pořádku.

Každý projekt samozřejmě vyžaduje něco jiného, ale pro představu jak to děláme my v Lundegaardu jsem níže popsal pět „checkpointů“, které jsou takovým nutným minimem pro střední a menší webové projekty.

  • První: začátek projektu

Zde by měl být celému teamu představen tzv. „big picture“ projektu. Je důležité, aby všichni, co se na projektu podílejí, věděli o čem jejich práce je, jak zapadá jejich malá kostička do celku.

  • Druhý: po dokončení konceptu/wireframu

Jelikož business zadání bývá obvykle jasné nicméně logicky ne zcela detailní, je vhodné koncept porovnat zdali se od prvotního zadání neliší.

  • Třetí: po dokončení a připomínkování grafiky

Velmi často v průběhu kreslení všech stránek se stává, že se drobně odlišují od schválených WF (ať už je to z technického či kreativního důvodu). Mnohdy také grafiku připomínkuje klient a svým způsobem ji může nabourat, jelikož nedbá na WF, ale na výsledek.

  • Čtvrtý/Pátý: ucelené programové celky

Tyto checkpointy se již mohou prolínat s QA projektu, ale v zásadě se nejedná o testování funkčnosti, nýbrž o potvrzení shody se zadáním/konceptem.

  • Šestý: ukončení projektu

Důležitá část projektu, která celému teamu uzavře pohled na projekt. Sdělení všech kladných i negativních situací, sdělení jak je klient spokojen, či kde se práce zadrhly, jsou neocenitelnou zkušeností pro každého člověka v projektovém teamu.

Spolu se začátkem je tento bod prakticky nejdůležitější pro další vzdělávání a začlenění lidí do projektových teamů.

Komplexnější projekty vyžadují agilnější přístup a taky vyšší míru checkpointů, jelikož člověk u „pásu“ nevidí mnohdy začátek ani konec celého projektu a je potřeba mu jej ukazovat a kontrolovat. Mnohdy programátor dělá jen na jedné kostičce komplexního systému a o to víc potřebuje globální pohled na celý projekt! Pokud nezná souvislosti, může mu připadat (třeba i zcela správně), že pro jeho kostičku je navržené řešení zbytečně složité nebo nevhodné a udělat to po svém. Bez checkpointu nezjistíte, že k sobě kostička vhodně nepasuje.

Zákonitost projektového řízení je neúprosná a tedy na fakt, že vám kostičky nepasují,  přijdete pravděpodobně v ten nejnevhodnější okamžik ...

Ohodnoťte článek

Ví opravdu každý člen teamu, kam projekt směřuje?
Seriál
Projektový pohled

Související články

Vyhledávání na blogu

Webová integrace

Webová integrace jako nová oblast pro business „velkých" webových agentur.

o webové integraci

Profily blogujících