Vývoj týmu – od skupiny jednotlivců k týmové synergii

| Jan Doležal

Vývoj týmu

Co je vývoj týmu si můžeme nejlépe představit na bázi vlastní zkušenosti. Ať už řešíme projekt nebo vývoj produktu nebo nějakou podobnou činnost, velmi často spolupracujeme s jinými lidmi. Většinou se takovému uskupení říká tým. Ale není tým jako tým a žádný tým nevznikne lusknutím prstu nebo sepsáním lidí na papír nadepsaný „Tým X“.

Jistě jste už zažili situaci, kdy se octnete v novém kolektivu. Už když jste se octli v první třídě základní školy. Či prvním ročníku střední nebo vysoké školy, poprvé v práci atd. Některé lidi jste možná znali lépe z minula, některé jen od vidění, jiné vůbec. Prostředí bylo také nové, stejně jako způsoby práce a požadované výsledky. Prvních pár hodin, dnů, či týdnů bylo zřejmě dost náročných, než si vše „tak nějak sedlo“. Po určitém čase se vše zaběhlo do určitého rytmu, nové věci se staly návykem a celkově jste si prostě zvykli. Ale bylo to dobře nebo špatně? Jak jste se cítili? Jak to bylo efektivní? Někdy lepší, jindy horší, že? V čem byly ty hlavní rozdíly? Nejspíše v tom, do jaké fáze vývoje týmu jste se dostali.

Vývoj týmu podle Tuckmana

Již v roce 1965 popsal Bruce Tuckman vývojové fáze týmu, které probíhají řízeně či samovolně v de facto všech prostředích, kde má skupina lidí dosáhnout nějaký výsledek.

Bruce Tuckman - vývoj týmu

Bruce Tuckman

Od té doby uplynul už nějaký čas a celkové pojetí managementu se posunulo. Základní Tuckmanovy poznatky však zůstávají plně validní a použitelné. O jaké fáze vývoje týmu tedy jde?

  1. Forming – formování
  2. Storming – bouření, konflikty
  3. Norming – ustálení, zvyklost
  4. Performing – výkon
  5. Adjouring – rozpuštění, ukončení činnosti

Podívejme se na tyto fáze ve světle roku 2020 a konceptů jako Motivace 3.0, Management 3.0, Teal organization, agile atd. Role manažera (s jakýmkoliv přídomkem či předponou) se dnes více a více posouvá od „centrálního mozku týmu“, který ví vše o všem a činní veškerá rozhodnutí, k pojetí „pečovatele o tým“. K zahradníkovi, který pečuje o zahrádku. Umí ji základně rozvrhnout, zaleje a přihnojí místa, která chce podpořit, vypleje to, co se mu nezdá.  Ale nepřikazuje květině, kdy má vykvést, kde má vyrašit další lístek a nekontroluje to se stopkami v ruce. To nemá smysl. Vytváří tedy hranice, určuje směr a koriguje samovolný vývoj systému.

Kdo zodpovídá za vývoj týmu?

Cílem je vytvořit co možná nejvíce samostatný, angažovaný a úspěšný tým. Kdo by takový nechtěl, že? Ale moc jich takových není… proč? Protože vývoj týmu většinou nikdo neřídí. V agile, respektive ve SCRUMu je k tomu přímo určena role SCRUM Master. Tedy pokud je vykonávána správně, což také není zas tak častý případ. V tradičních metodikách a rámcích pro řízení projektu není toto téma příliš silně řešeno, na rozdíl od procesů, dokumentů a nástrojů. Respektive, není nikde stanoveno, kdo za vývoj týmu přímo zodpovídá. Alespoň co se PMI či PRINCE2 týká. IPMA v tom jde o něco dál, ale stále to je spíše postranní téma. Zodpovědnost za vývoj týmu je tak nějak rozmlžena mezi PM a liniový management. A tedy se o to většinou přímo nestará nikdo.

Podívejme se, jak takové fáze mohou probíhat v nějaké běžné korporaci (oranžová barva podle Lalouxovy taxonomie), která operuje dle běžných schémat. A zaměřme se na to, jak bychom se měli jakožto pečovatel o tým chovat, pokud chceme vybudovat výkonný a sebevědomý tým.

Forming

První fáze, ve které tým ještě není týmem. Nyní se jedná o skupinu lidí, která se řekněme octla na prvním jednání k novému projektu. Někdo jim prostě řekl (napsal), že mají přijít. S někým se znají, s někým ne a o projektu krom názvu a dvou vět v emailu toho mnoho neví. Případně jen drby od kávovaru.

Většina lidí na takovém setkání není moc aktivní, chtějí si hlavně poslechnout, o co jde, jak by se jich to mělo týkat a případně si „ochránit to svoje“. Tedy, aby jim na jedné straně nikdo nešahal na jejich pole kompetence, na druhé straně, aby po nich nechtěl někdo něco, co jim v jejich očích nepatří. Případně mají pocit, že je někdo zdržuje od ostatní práce a kladou si otázku „Co si to zas kdo vymyslel za …?“

Vývoj týmu - forming

Lze téměř fyzicky cítit bariéry mezi přítomnými.

Naší úlohou je v této fázi především informovat, a tak trošku i velet. V tuto chvíli je prostě potřeba udat jasný směr. Nyní je třeba vysvětlit základní smysl a cíl projektu, vizi produktu apod. Naučit lidi případné nové koncepty a nástroje pro spolupráci.

Vývoj týmu - forming

Forming – bariéry mezi členy týmu

TIP: Nečekejme zázraky. Posluchači si jistě nezapamatují vše a některým věcem nebudou přikládat váhu. Je tedy vhodné je nějak vtáhnout do děje. Velmi účinné je, když hned od začátku aplikujete přístup vedoucí k rostoucí sebeorganizaci a empowermentu vytvářeného týmu. Např. můžete použít na úvodním setkání Project Team Canvas a jen moderovat jeho použití (po krátkém úvodním vysvětlení zaměření projektu a ve spolupráci se sponzorem/product ownerem). Nebo je zajímavé začít používat Delegation board.

Storming

Poté, co si tým nastavil kurz a základní pravidla spolupráce, začíná reálně spolupracovat. Můžete si představit analogii, kdy forming odpovídá teoretické výuce v autoškole. Jsou promítány různé křižovatky a řešeno, které auto má přednost a proč. Storming odpovídá prvním jízdám v provozu. S trochou nadsázky nevíte, která ruka je levá, natož kdo má přednost.

Teď začnete zjišťovat, co jste při nastavování pravidel spolupráce nedořešili, co lidé nepochopili nebo nezavnímali. Karel přijde s tím, že mu Alice posílá ty věci ve špatném formátu, Alice se hájí, že takto se to dělá standardně a Lucie ještě netrefila na společné úložiště dat.

vývoj týmu - storming

Tato fáze je plná napětí, konfliktů a někdy i hádek. Je velmi nepříjemná pro všechny zúčastněné. Bohužel, pokud není vývoj týmu řízen, u velké části projektů je i fází konečnou. Protože abyste se z ní dostali v rozumném čase, tedy před konečným termínem projektu, musíte změnit svůj přístup.

Skrytá past stormingu

Je pochopitelné a přirozené, že chcete úspěch svěřeného projektu a že se tedy snažíte pomoci ze všech sil. A když je někde problém, snažíte se jej řešit. Ovšem pozor, to nejhorší, co nyní můžete udělat, je, že rozsoudíte výše zmíněného Karla s Alicí a řeknete jim, co mají dělat. Případně že zajdete za Lucií a počtvrté jí ukážete, jak chodit na sdílené úložiště. Proč je to to nejhorší? Protože veškerou svou činností ovlivňujete daný systém (tým). Něco jej učíte. V tomto případě, že všechny problémy řešíte vy a nikdo jiný tedy problém nemá. Až na vás, kdo má problémy všechny.

Vývoj týmu - storming

Storming – lidé začínají přes bariéry spolupracovat

Stáváte se tak naprosto nepostradatelným hasičem všech požárů, lítáte od čerta k ďáblu a když byste byli chvilku mimo, něco nezkontrolovali či nebyli v práci 10 až 12 hodin denně, projekt se zhroutí. A to asi nechcte, že?

Pozn.: Mimochodem, jedním z kroků ven na cestě z popsané situace, je uvědomit si, že na dálnici termín projektu nanaženete.

Jak zvládnout storming správně?

Co tedy dělat? Facilitovat! A přestat řešit vše jeden na jednoho (tedy Karel přijde za mnou, že Alice něco, takže já jdu za Alicí a vrátím odpověď Karlovi). Mnohem lepší je pozvat si Karla s Alicí společně a dotáhnout je k tomu, aby sami našli řešení jejich problému. Protože když jim řeknu, co mají dělat a bude to špatně, oni jsou v klidu. Jen dělají, co jsem jim řekl. Když to bude jejich řešení, jsou jeho vlastníci oni a je to jejich (vzájemná) zodpovědnost, že funguje. Tak vzniká empowerment.

Pokud Lucie neumí trefit na sdílené úložiště, jak jí tým (ve svém vlastním společném zájmu) pomůže? Co pro to kdo udělá?

Takto nastíněným přístupem můžete tým naučit starat se o své problémy a o své členy. Umět si pomoci a podpořit se. Být samostatným. A vám se takto dost uvolní ruce, protože většina požárů se uhasí sama. A vy se můžete soustředit na postup projektu, zákazníka, další zainteresované strany a také, v neposlední řadě, další vývoj týmu.

Norming

Pokud se Vám podaří dostat do této fáze vývoje týmu, vypadá to, že máte vyhráno. Většina konfliktů se vyřešila, hrany se ohladily, vše si tak nějak sedlo. Lidé už se nehádají, spolupráce funguje, aniž byste ji museli vy nebo tým řešit. A členům týmu je v tom dobře. Proto se jim nebude chtít z této fáze dál. Většinou budou mít obavy z nějakých dalších změn, protože by v jejich očích mohly vést zpátky k pádu do stormingu.

Je to tedy opět často konečná fáze pro mnoho týmů, a to i těch stabilních. I když vývoj týmu neřídíte, tak pokud „to“ necháte samovolně běžet dostatečně dlouho, hrany se ohladí a konflikty ustanou i samy od sebe. Jenže to neznamená, že byly vyřešeny.

Apatický norming

Většina lidí to prostě po nějakém (nepříliš velkém) úsilí bez další podpory vzdá, uzavře se v určité apatické slupce s mindsetem „co bych to přehnaně řešil, pracuji do výše své mzdy“ a zkrátka dělá věci vědomě neefektivně. Oni tu přece nejsou od toho, aby věci měnili. Naopak. Mají dělat, co se jim řekne a hotovo. Nebo prostě odejdou jinam, pokud jim takové prostředí nevyhovuje. Což se týká především těch schopnějších, o které jistě přicházet nechcete.

„Lepší“ norming

Je zřejmé, že výše uvedený stav není optimální, natož efektivní. Bohužel je velmi častý. Jak z toho ven? Předně je potřeba správě odřídit předchozí fáze, forming i storming. Aby mohla vzniknout motivace, lidé musí rozumět a přijmout smysl daného konání a rozpoznat svou roli v daném úsilí (forming). Následně si musí vyladit pravidla hry (storming). Pokud už máte tým „usazený“ v apatickém normingu, následku neřízeného samovolného vývoje týmu, nezoufejte. Do jisté míry dobrá zpráva je, že jakákoli změna, ať už věcná nebo třeba přidání či výměna člena týmu, vás v dynamice vývoje týmu dostává zpět na začátek. Takže stačí udělat změnu a máte možnost to udělat tentokrát správně.

Vývoj týmu - norming

Norming – tým již nemá bariéry mezi členy

Ten chtěný norming vypadá totiž tak, že si věci sice sedly, ale nikoliv následkem vzdání se a odevzdané apatie. Lidé v týmu si prostě byli schopni domluvit pravidla tak, aby jim seděla, vyhovovala, byla podle nich. Což je další velmi silná prekvizita pro motivovaný tým. Je opravdu nutné, aby byla tabulka rozvržení práce podle vašeho excelu? Co když si prostě tým vymyslí něco svého? Je to takový problém? Pro motivaci lidí je to obrovský posun, na kterém se dá dále stavět.

Jak dál?

Teď můžete opět změnit styl a začít koučovat. Až teď, kdy je tým na té správné vývojové úrovni. Už vědí, co mají dělat, propluli útesy stormingu a naučili se spolupracovat. Mají dostatečnou zkušenost. A budou také více sebevědomí, protože to zvládli sami. I přes obavy tedy budou mít větší ochotu k provádění změn a experimentů. Takže teď se můžete začít ptát stylem: „Co vám na tomto trvá nejdelší dobu?“, „Jak by šlo tohle zrychlit?“, „Co pro to můžete udělat?“, „Co navrhujete?“.

Těmito silnými otázkami jste schopni tým dostat až na několika násobný výkon. Do fáze performing.

Performing

Zde chcete tým mít. Spolupráce je velmi efektivní, a i když vznikají díky vysokému tempu a experimentování nějaké konflikty, tým je umí sám účinně řešit. Mimo jiné jste členy naučili přemýšlet nejen o tom CO dělají, ale také JAK to dělají. Takže třeba po nějakém drobném postrčení začnou probíhat pravidelné retrospektivy.

Týmová retrospektiva

Atmosféra v týmu je plná energie, a přitom klidná a příjemná. Konflikty nejsou osobní, ale v zájmu týmu a zlepšení výsledků a výkonu.

Jako pečovatel o tým už pro vás v této fázi zbývá jen jediný úkol – snažit se v ní tým udržet. Tedy monitorovat dění a při zjištění, že se změnil kontext, degraduje proces (např. retrospektivy), došlo ke věcným změnám v úkolech pro tým nebo nějakým personálním obměnám, je třeba tým opět provést (byť zrychleně) vývojovými fázemi.

Případně se nyní můžete i více zaměřovat na vztahy týmu s okolím a případně i na fungování organizace jako takové.

Adjouring

Poslední fáze je o zvládnutí ukončení práce týmu, rozloučení se a posun k novým výzvám a úkolům. Je to spíše o případné psychické podpoře členů, protože jim v performing týmu bylo jistě velmi dobře, téměř jako v rodině a bude jim po tom smutno.

Jak dlouho trvá vývoj týmu?

Záleží jistě na prostředí a kontextu. Nicméně to může probíhat i velmi rychle. Např. když hrajeme s různými skupinami Simulaci projektu Pacifická dráha, proběhnou výše uvedené fáze během jednoho jediného dne. Jedná se sice „jen“ o manažerskou hru v omezeném prostředí, nicméně je komplexní a týmová dynamika je v ní velmi dobře patrná.

V reálném prostředí, ve kterém je varialbilita a komplexita řešených úkolů samozřejmě vyšší, bude vývoj týmu zřejmě spíše otázka dnů a týdnů, nicméně ani zde to nemusí být měsíce.

Problém je spíše stabilita

Pro vývoj týmu je důležité, aby probíhaly všechny možné interakce velmi intenzivně a často. Jak už bylo zmíněno výše, změny dostávají týmy zpět do první fáze forming, ať už jsou v jakékoli fázi vývoje týmu. Takže pokud je daný člověk na 30% v jednom týmu, na 20% v druhém, na 40% ve třetím a 30% ve čtvrtém, což je v běžné firmě velmi časté uspořádání, tak se vlastně nemůže dostat dál než do stormingu. Neustále mění spolupracovníky a kontext.

vývoj týmu

Případně, pokud nikdo vědomě fáze vývoje týmu neřídí, tak trvají dlouho. A většina projektů skončí dříve, než se mohou týmy samospádem někam dostat. Což je možná i důvod, proč tomuto tématu metodiky PM nevěnují příliš pozornosti.

Efektivní tým jako základ úspěchu v 21. století

V agilním světě vzniklo doporučení: Nehromaďte lidi okolo práce, hromaďte práci u lidí (don’t bring people to work, bring work to the people). Myšleno tím je, že se ukazuje být více efektivním, když vytvoříte silný a efektivní tým, kterému pak dáváte různé úkoly a projekty, než na každý projet seskupovat nové týmy a pracovní skupiny.

Takový stabilní tým musí být samozřejmě multifunkční (cross-functional) a umět pokrýt větší spektrum problematiky, než jen velmi úzce specializované pracoviště. Byť i to je určitá možnost, nicméně specifická pro určité kontexty.

Proto mnoho korporací a firem v současné době zkoumá různé inovativní organizační modely, založené právě na klastrech relativně malých (5 až 12 lidí) multifunkčních, sebeorganizovaných týmů. Organizační struktury se významně zplošťují a leckde zbývají jen dvě nebo tři úrovně místo předchozích třiceti pěti. Jedná se o celkovou změnu pojetí, kdy byla organizace vnímána spíše jako stroj k pojetí, kdy je vnímána jako živý organismus.

Agilní transformace

Utopie? Sci-fi? Někde možná. Jinde realita či blízká budoucnost.

Podstatné pro úspěch takových transformací a změn je ovšem pochopit, že to není pouze „tvrdá“ změna organizační struktury. Že to není jen vydání nového organizačního schéma. Že se jedná především o změnu kultury, mindsetu. A to je potřeba „odmakat“, stejně jako vývoj týmu, který je základní jednotkou takovýchto inovativních organizačních struktur. Dovedete si představit, že nějaká struktura založená na shluku týmů, bude fungovat, pokud budou tyto týmy ve stormingu nebo apatickém normingu?

Týmy je potřeba nejen sestavit, ale postarat se i o vývoj týmu všemi fázemi. Rád to s vámi proberu např. na kurzu Vedení týmů.

O autorovi článku

Jan Doležal

Jan Doležal

V současné době se zabývá především agilitou v organizacích, Managementem 3.0 a vývojem simulačních her sloužících jako trénink projektového řízení, včetně Agile.

Dříve mimo jiné zastával pozici vedoucího projektové kanceláře a řídil velké mezinárodní projekty (Evropa, Jižní Amerika).

Má zkušenosti především s projekty z IT, strojírenství nebo elektrotechniky. Projektovému řízení se aktivně věnuje od roku 2001. Disponuje certifikací PMI PMP, IPMA B a CSPO – Certified SCRUM Product Owner a A-CSM – Advanced Certified SCRUM Master od SCRUM Alliance. Další podrobnosti čtěte zde.

Další zdroje informací

Komentáře (0)

Zatím žádný komentář.

Přidejte váš komentář

Vaše e-mailová adresa nebude zveřejněna. Pole označená hvězdičkou (*) jsou povinná.