Když se řeší technologické věci, bývá to většinou jednoduché, často zábavné, někdy frustrující. Když se řeší problémy s lidmi, bývá to většinou složité, často frustrující a hlavně - nejednoznačné.
Problém podobný tomu aktuálnímu jsem řešil cca před rokem - přišel jsem jako team leader do týmu vývojářů. Tým nebyl zrovna vstřícně naladěn, někteří členové byli až nepřátelští. Protože jsem podobnou situaci zatím nikdy neřešil, koupil jsem si tematickou knihu (viz post (Ne)funkční tým) a zkusil jsem se s tím (z dnešního pohledu bych řekl, že neúspěšně) poprat.
Nevstoupíš dvakrát do téže řeky. Takže po roce: stejná role (teamleader), jiný tým (nesrovnatelně pozitivněji naladěn), podobný projekt (integrace na middlewaru) a úplně jiný problém. To si vám takhle týmlídruju, v týmu mám pět lidí, 50 % času věnuju řízení (takový ty JIRY, statusy a tak), 50 % věnuju vývoji. Radost pracovat. (Pozor, teď přijde zápletka.) Najednou: BUM, PRÁSK! Tým se ztrojnásobí! Nekecám, 16 lidí?!? Navíc, byť to téměř všichni byli seniorní javisti, z hlediska použité technologie a architektury (SOA), byli v podstatě juniorní a náběhová a učící křivka byla velmi dlouhá (2 měsíce).
Šestnáct lidí je opravdu hodně. Maximum, co mám teoreticky a empiricky ověřeno, je deset a člověku to zabere 100 % času. Na nějaké kódování může zcela zapomenout. Šestnáct lidí, to už není teamleading, to už je čistý management. Ehm. Já, excelentní vývojář ;-) a management? Jak říkám: když mám problém, sáhnu po knize.
Vybral jsem si titul Behind Closed Door, jejíž podtitul slibuje odhalit Secrets of Great Management. Nevím, jestli se dodržováním principů uvedených v knize, stane člověk skvělým manažerem. Ale to ani nebyl můj cíl. Chtěl jsem si jen ověřit, že některé věci dělám správně, že v dobré víře nedělám chyby a taky si trochu rozšířit repertoár.
Ostřílení matadoři by asi nad radami v knize mávli rukou, že to není nic nového, je to samozřejmost atd. Ano, ony to opravdu jsou jednoduché věci. Ale to asi nejtěžší na tom je, být konzistentní a perzistentní :-)
Kniha používá osvědčený formát - fiktivní příběh fiktivního manažera (který přijde nově do společnosti, vyřeší všechny problémy a všichni jsou šťastný a firma vydělá balík), prokládaný konkrétními tipy a postupy jak danou věc dělat/řešit. V průběhu příběhu jsou postupně probírána témata jako: delegování, prioritizace, zpětná vazba, koučování, one-on-one pohovory, prosazování vlivu apod.
Pro mne byly z knihy nejpřínosnější dvě témata. Jednak jsem se utvrdil v tom, že je důležité dělat one-on-one pohovory a držet je pravidelně. Už nějaký čas je dělám ve všech týmech a myslím, že to je jedna z věcí, která velmi podstatně zvedne důvěru v týmu. A důvěra to je základ, na kterém je dobrý tým postaven.
Druhým podstatným tématem pro mne byla zpětná vazba a přesněji korektivní zpětná vazba. Možná to znáte - lidi v týmu pracují většinou dobře, ale jeden/dva z nich podávají slabší výkon. Je to delikátní situace, vždycky je tu nějaký důvod, proč tomu tak je. Pokud má člověk zájem (a je mu to důstojně podáno), často se dají překážky, které brání kvalitní práci odstranit. V knize je popsáno, na co si dát pozor, aby se komunikace nepřeklopila do iracionální roviny. A taky, kdy to už nemá smysl řešit.
Komu bych knihu doporučil? Určitě začínajícím teamleaderům. Byť není zaměřena na technické vedení lidí a projektů se dotýká jen zlehka, je to dobrý začátek, protože jako teamleader budete komunikovat primárně se svým týmem a sekundárně s projektem a jinými týmy. Doporučil bych ji i pokud máte, tak jako já, nějakou tu teamleaderovskou zkušenost za sebou. Vždycky je totiž něco nového, co se dá naučit a stávající zlepšit. Třetím doporučením je pak edice, v které knížka vyšla - vydavatelství The Pragmatic Programmers je zárokou kvalitní softwarová literatury a mne nezklamala ani tentokrát.
No a jak se vyvinul můj v úvodu zmíněný problém? Tým se mezitím stabilizoval a taky se smrsknul na rozumnou úroveň deseti lidí. Držím pravidelné one-on-one pohovory jednou za měsíc. V jednom případě jsem si vyzkoušel korektivní zpětnou vazbu s následným dohledem, což nakonec, bohužel, vyústilo v odchod daného člověka z týmu. Taky jsem, s těžkým srdcem, musel delegovat několik Proof of Concept, na který jsem se moc těšil. Tak snad to aspoň pomohlo někomu jinému. Je toho samozřejmě daleko víc, co dělám (a co je potřeba dělat), aby jsme měli dobrý tým. Uvedl jsem pouze věci, které přímo souvisí a jsou tématy představené knihy.
