One man show versus workgroup

Zaujímavým úkaz sa deje dnes a denne. S pridaním členov tímu sa celkový výsledok odďaľuje pôvodnému zámeru a obvykle vzniká mačkopes natretý obľúbenou farbou najhysterickejšieho z hlasov.

Začnime vyrábať web stránku jednomužne. Jeden človek má potrebu, jeden človek ju navrhne, jeden človek nakóduje a namaľuje, jeden človek zhodnotí. V jedinej osobe. Pozitívom je absolútna moc a v prípade profesionála je jediným limitom čas a chuť.
Profík má ešte snahu robiť weby iným ľuďom či dokonca zákazkovo. Silná osobnosť presadí taký z možných kompromisov, že je so svojou prácou spokojný a klient tiež.
Predstavte si však pracovné tímy. Nie také, kde je proporcionálne rozdelená práca. Obvykle je v praxi situácia taká, že na strane kódera, grafika či databázového programátora nedochádza k navyšovaniu počtu ľudí. Dajme tomu, že od onemanshow z predošlého príkladu sa to líši iba tým, že pribudlo množstvo „kecalov“.
Rýchlo si preberme ideálnejší pomer – ak pribudne „kecal“ či iný typ tímu, ktorého práca je „komunikácia“ a „projektovanie“, tak adekvátne pribudne aj výkonná časť pričom interface medzi výkonnou časťou a „komunikačnou“ je dôsledne jednovláknový. Teda všetky nápady, požiadavky, zmeny sú navrhované jedným kanálom s tým, že jeho výstupom sú uzavreté záležitosti smerujúce k výkonnej časti tímu.
Lenže takto to skoro nikdy a nikde nefunguje. Komunikátori majú totiž snahu pretiecť akýmikoľvek kanálmi smerom k chudákom vo výkonnej skupine. Najkrajšie situácie vznikajú, keď do projektu priebežne pribúdajú „komunikátori“. Ľudia, ktorí do tímu prichádzajú neočakávane a kladú na stôl svoj subjektívny pohľad (maskovaný nezávislosťou, inovatívnosťou a nezaťaženosťou) s autoritatívnym postojom (musí to byť takto). Postupne sa v projekte vystrieda nepomerné množstvo komunikátorov ale výkonná časť tímu zostáva nezmenená.
V týchto situáciach je paradoxným výsledkom nekonečného priebehu zmien fakt, že nápady, výsledky, ukážky z prvých štádií projektu sú zrejme jeho vrcholom a všetko ňom je už neustále „kompromisovanie“, kedy sa akosi snaží projekt vyhovieť v prvom rade najmä komunikátorom. Naraz či postupne. Pri pozornom sledovaní zistíte, že jeden komunikátor v jednej fáze žiada niečo, čo neskôr iný zasa zamieta, vyhadzuje a žiada čokoľvek ale hlavne iné.
Čo v týchto prípadoch? Bohužiaľ asi sa nedá nič urobiť. Tímu chýba autorita, ktorá určí mantinely a vedie projekt tak, aby bola práca vyvážená. Dôležité je vedieť určiť priority a dokázať aj dobré ale nerealizované nápady či pripomienky v zárodku odmietnuť aj bez diskusie. Musí v nadhľade vidieť projekt od zrodu až po niečo, čo ešte neexistuje – hotovú vec a ako bude fungovať.
Nie je možné lepiť projekt priebežne v aktuálnom stave – teraz niečo na ňom vidím, tak to ohnem, odrežem, zväčším, zmením. Ak nevidím poriadne minulosť a budúcnosť, nemôžem meniť prítomnosť.
Vrátim sa k tým pomerom – pribúdaním „kecalov“ všeho druhu je naozaj nevyhnutné myslieť aj na to, koľko práce to predstavuje a aká časť z nej neposúva projekt nikam (dva kroky vzad, krok vpred nie je posun).
Komunikátori v tíme sú dôležití – vybavujú komunikáciu s klientom, dodávateľmi, majú nápady, sú to manažéri, obchodníci, mediálni analytici, tlmočníci, účtovníci, sú prví, čo vidia nedorobky (nefinálne verzie). Musia však akceptovať istú štábnu kultúru a vytvoriť si trebárs medzi sebou „mediátora“, ktorý je pri projekte od začiatku a akceptujú jeho autoritu tak, aby nedochádzalo ku sporom, kedy si akurát prichádzajúci „kecal“ začne v strede projektu robiť nároky na zmeny vecí, ktoré prešli kecalmi pred ním.
Posledné – projekt by nemal byť definovaný na začiatku nejasne len všeobecným popisom čo predstavuje. Od zrodu je treba vidieť jeho koniec, čo najrýchlejšie vychytať slabé miesta, určiť si jeho schopnosti a toto všetko skĺbiť do termínu spustenia, ktorý je prijateľný. Ak kecal vidí, čo všetko je možné, tak požaduje všetko možné a „zmeň to zo zelenej na zelenšiu“ nechápe ako „odmietnuteľnú vec“.
Treba sa naučiť povedať: kde si bol, keď sme jednali o zelenej farbe. Tento bod programu je za nami. Projekt skončí spustením a dovtedy vypracuj štúdiu nevyhnutnosti zmeny farby, ktorá bude zaradená v projekte redizajnu, ktorého ukončenie bude plánovane o X dní po spustení. Na začiatku sa stanoví spôsob komunikácie, všetky požiadavky budú jednokoľajne predkladané a zaraďované písomne do projektových úloh. Každá zmena bude mať iniciátora (zodpovedný za predĺženie projektu), potrebný čas na vyhotovenie, pripomienkovanie a schválenie. Všetci v tíme by mali vidieť do projektových úloh a nemali by mať triviálne problémy – ak požadujem zmeniť zelenú na zelenú, nesmiem sa tváriť divne pri požiadavke na RGB či HEX :)
Rozhodne si netreba príliš striedať úlohy, ak je „hovorcom“ tímu jedna osoba, nesmie ju paralelne obchádzať niekto ďalší. Ani šéf tímu nie je putovná rola :) A šéf tímu nie je osoba, ktorej musíme predstaviť ostatných členov a ktorý pred koncom vyvalene pozerá, čo sa urobilo a nikoho radšej neoslovuje menom :) Pamätajte na to, že iba povedané a iba mailom poslané neexistuje ak to nie je dohodnutá forma zaraďovania požiadaviek (samozrejme).

A tak spolu žili za siedmymi verziami, pod hradom z HTML, kým neprišiel CSS a javascriptom nerozbil tabuľky.