Skrytá zákoutí týmové práce

Ano, celkově je idea týmových projektů úžasná, všichni se naučí, anebo si alespoň osvěží koncept týmové práce a rozdělených povinností; někdy se dokonce přiučí něco o korporátních procedurách, které se dají následně použít v budoucím životě a v pracovních anebo v osobních projektech. Co ale na konceptu silně nesedí, je idea toho, že se náhodně sloučí několik studentů stejného předmětu. Ano, skupina IT studentů zní jako to pravé ořechové pro IT projekt, ale měřítkem úspěchu je svým způsobem jen jeden aspekt – kdo z oněch náhodně vybraných studentů bude ten, kdo vystoupí a zaujme roli lídra, anebo alespoň jakéhosi koordinátora? V teorii by si skupina měla navzájem pomáhat, navzájem se úkolovat, a pomáhat si s různými aspekty projektu – ale kdo má na něco takového během ostatního studia tolik času? V praxi je nutné, aby se někdo ujal oné role koordinátora a alespoň poměřil zkušenosti ostatních, a podle toho je na projektu zařadil k různým úkolům. Je onen člen nenadaný na tvrdé programování, ale vyniká v designu a vizuální prezentaci? Je výtečným programátorem ve všech aspektech, ale jeho komunikační dovednosti se rovnají nule? A co když se zkrátka nenajde ten pravý člověk na porovnávání členů týmu a koordinaci?

Plně si uvědomuji, že následující paragraf bude znít možná arogantně, ale něco jako 2 roky studia předmětu Business & Management má na člověka silný dopad; a jenom zmínka toho, že by se náhodně seskupili lidé a pracovali spolu na projektu, zní jako recept na katastrofu. I když se jedná o svět IT, je stále nutné mít v týmu alespoň jednoho člověka, který má alespoň jakési povědomí o managementu; a hlavně se neobává vystoupit a nastartovat týmovou práci, ne-li se dobrovolně ujmout přímo pozice koordinátora.

I v samotném IT se dají najít porovnání, která vystihují problematiku týmové spolupráce – může to být dělení systémových procesů mezi jednotlivá jádra procesoru, anebo rozdělení práce na vícero programových vláken. Vždy se musí připravit a navrhnout nějaký způsob koordinace, a pokud nejsou ošetřeny kolize, pak je program anebo systém extrémně náchylný k různým výpadkům a nepřesnostem. Ve výsledku tak bude v porovnání s ostatními systémy (které efektivně využívají koordinaci) v extrémní nevýhodě z hlediska stability a kvality vykonané práce.

Co si z toho tedy odnést? Týmové projekty jsou skvělou cestou, jak naučit studenty týmové práci a poukázat na praktiky velkých korporací v praxi; ale nedá se ani v nejmenším očekávat, že týmy bez jakékoliv předchozí zkušenosti dokážou samy sebe dobře zkoordinovat v momentě, kdy jsou bez přípravy vrženy do víru akce. Je pravda, že se někdy poštěstí a týmoví hráči se domluví na neformálním a vysoce efektivním střídání koordinátorů podle zkušeností, ale jak o takovém přístupu vůbec budou předem vědět? A i když se poštěstí a ona struktura se stane tím, co drží tým dohromady, co když onen koordinátor nemá nejmenší tušení, jak se v různých fázích projektu zachovat? V reálných situacích se musí najít člověk, který bude schopen tým několika lidí zkoordinovat tak, aby se každý mohl volně vyjádřit ke struktuře a výsledné podobě produktu, ale aby se všichni zároveň drželi jednoho směru a vyprodukovali cosi prezentovatelného a aplikovatelného. A pokud se v týmu žádný takový člověk nenajde, anebo má málo zkušeností, všichni si z projektu odnesou o to méně poznatků a jejich motivace pracovat v týmu spadne na samé dno. Z týmového projektu se zkrátka nedá nic naučit, pokud projektu chybí to základní – tým.