Adaptace a zkušební doba
Adaptační doba začínala tím, že noví kolegové z Brna a Prahy strávili první 2 až 4 týdny v Opavě na naší hlavní pobočce. To je aspekt, který nám v počátcích zaškolování velice pomohl. Jedinou stinnou stránkou bylo, že tento požadavek nás logicky připravil o některé z nadějných kandidátů. A asi se není moc čemu divit. Když chcete po pražském vývojáři, ať dočasně opustí svůj domov, své pohodlí a přijede na několik týdnů do menšího města na druhé straně republiky, tak to úplně není na seznamu věcí, které by chtěl dělat. Tím spíše, že v Praze je dost firem, které podobnou oběť pochopitelně vyžadovat nebudou. Po dobu, kdy byli noví kolegové v Opavě se nám vše jevilo růžově a nespatřovali jsme sebemenší potíže.
Naše vzájemná očekávání se pak postupně po drobných krůčcích začala rozcházet ve chvíli, kdy se nováčci vrátili na své domovské pobočky v Praze a Brně. Pro kontext je nutné opět zmínit, že se zde bavíme o době před epidemií COVID-19, to znamená o době, kdy jsme měli naprosto minimální zkušenosti s dlouhodobou spoluprací na dálku a videohovorech přes Skype, které zamrzávaly jako ledovce v Severním ledovém oceánu. Ve chvíli, kdy píšu tento článek máme za sebou 15 měsíců nepřetržité spolupráce v tomto režimu a jsme v mnoha ohledech zkušenější. Tenkrát jsme nebyli.
Co bychom teda dnes pro adaptaci nováčků udělali jinak?
- Nejen oni k nám, ale i my k nim – Nelze říci, že bychom neměli snahu za novými kolegy do Brna či Prahy jezdit, nicméně periodicita a výběr lidí, kteří jezdili asistovat patrně nebyl nejvhodnější. Na vzdálené pobočky nejčastěji jezdil personalista, nebo technický ředitel, kteří se snažili pomoci s elementárními potížemi, které v průběhu vznikaly. Ti pak na pobočkách strávili jen asi 3-4 dny v měsíci, později to bylo ještě méně. Při zpětném ohlédnutí víme, že nejlepší volbou by bylo, kdyby se na vzdálených pobočkách střídali jednotliví vývojáři a byli tam k dispozici v mnohem delším časovém úseku. Ta zkušenost již integrovaných vývojářů se znalostí domény, vývojového prostředí, metodiky a způsoby vývoje, by nováčkům pomohla nejvíce. Zdali bychom na služební cesty do Brna a Prahy našli dostatek dobrovolníků to úplně nevíme. Každopádně je to jedna z věcí, kterou bychom příště jistě řešili ještě před rozhodnutím o otevření nových poboček.
- Integrace do již zavedených týmů – S tím prvním popsaným bodem do jisté míry souvisí i bod druhý. V případě Brna i Prahy jsme se snažili ať nově tvořící se pobočky fungují jako samostatné týmy pracující na vlastním modulu. To zpětně vyhodnocujeme jako další chybu. Naopak jsme se měli od samotného prvopočátku snažit o integraci vzdálených nováčků do týmů již zavedených. V jejich adaptaci – předávaní veškerých znalostí, návyků a dovedností by to obrovsky pomohlo. Stejně tak věříme, že by se do značné míry předešlo i již zmiňovanému rozcházení se ve vzájemných představách o způsobu a přístupu k vývoji. V pozdějších fázích spolupráce již k nějakým pokusům o integraci vzdálených kolegů do lokálních týmů docházelo, nicméně to nebylo v adaptační době a tím pádem to bylo vnímáno spíše negativně, jako nekomfortní nabourávání jejich již zažitých zvyklostí.
Problémy běžného vývojářského života
Kromě výše zmíněných potíží z adaptační doby, které se pak dále přesouvaly i do běžného každodenního života vývojáře pracujícího na vzdálené pobočce, pak postupem času přibývaly i potíže další. Jako ten největší problém se nám zpětně jeví absence Leadera v nově vzniklých kancelářích.
Naše firma je jedinečná mimo jiné i tím, že má velice plochou organizační strukturu. Na vedoucí se tady moc nehraje a na rozdíl od většiny ostatních vývojářských firem u nás neexistuje pozice „Team leadera“, tady člověka, který tak nějak zastřešuje a koordinuje vývoj v rámci jeho týmu. Je zodpovědný za výkon a kvalitu odvedené práce. Absence vedoucích týmů z jedné strany znamená velikou svobodu a autonomii týmu bez nutnosti se napřímo zodpovídat nějakému šéfovi, na druhou stranu to však znamená, že zodpovědnost, kterou na svých bedrech takový vedoucí nese, musí logicky být rovným dílem rozprostřena mezi všechny členy týmu, kteří jsou tak svým způsobem všichni garanty kvality a rychlosti práce. V Opavě nám tento způsob autonomie velice dobře funguje. Při zpětném ohlédnutí za kancelářemi v Brně a Praze byla absence Team leadera patrně chybou, a to z následujících důvodů.
- Team leader je prostě leader. Je to člověk, který vede lidi ve svém týmů, je to člověk, za kterým mohou v případě potřeby či pochybností okamžitě zajít a na potížích začít pracovat. Je to člověk, který koriguje vývoj, tak aby šel tím správným směrem. Zajištuje, že tým neztrácí ze zřetele širší perspektivu celého projektu.
- Team leader je také mentor. Je to člověk, který je schopen lidi ve svém týmu posouvat po stránce technologické či metodické. Je schopen kontinuálně sledovat progres svých lidí a dávat jim pravidelnou zpětnou vazbu. Pomáhá integraci, ale i profesnímu růstu.
- Team leader přebírá odpovědnost. Rozmělnění míry odpovědnosti za výsledek práce mezi všechny vývojáře v týmu nám dobře funguje v Opavě, kde máme spoustu vývojářů s mnohaletými zkušenostmi s tímto přístupem. A priori očekávat stejnou míru zodpovědnosti od nováčků, kteří v podobném režimu nikdy předtím nepracovali, bylo chybné.
- Team leader jako kulturní referent. Největší devízou naší firmy je naše firemní kultura – autonomie, flexibilita, svoboda a důvěra. V integraci našich hodnot jsme do jisté míry selhali. Důsledkem pak byl vznik jakési subkultury na vzdálených pobočkách. Ta se v některých ohledech lišila od zvyklostí ve zbytku firmy. Dnes věříme, že třeba Team leader by mohl být tím člověkem, který by hrdě nesl prapor firemní kultury a přispěl k lepší kulturní asimilaci nových kolegů.
Jakkoliv se rozhodně nechystáme zavádět pozici Team leadera do našich současných struktur, je zřejmé, že v případě zakládání nové pobočky by to dnes již měl být náš cíl. Je asi dobré zmínit, že se především v Brně, vývojáři ozývali s poptávkou na takového člověka. My jsme však tuto potřebu nereflektovali a věřili jsme, že náš systém bez vedoucích uspěje i na vzdálených pobočkách. Věřili jsme, že čas to vyřeší. Jak by to nakonec dopadlo, se dnes již nedozvíme. Obě pobočky jsme uzavřeli.
Zavírání
Článek by patrně nebyl úplný, kdybychom na závěr neshrnuli i poslední dny a týdny Pompejí.
V případě Prahy to bylo poměrně jednoduché. Dlouhá dojezdová vzdálenost, vysoké náklady, nízká úspěšnost náborového procesu a k tomu byl pomyslnou třešničkou na dortu odchod jednoho ze dvou našich kluků v Praze. Ve chvíli, kdy přišel s výpovědí, jsme měli jasno. V Praze pokračovat nebudeme a pobočku uzavřeme.
V Brně to poměrně dlouho vypadalo velice slibně, nicméně v krátkém časovém úseku nám skončilo 5 lidí, kteří patřili navíc mezi ty zkušenější. Dvěma skončil projekt, na kterém pracovali a tři si našli práci v konkurenční firmě, kde mimochodem měli Team leadera hned od prvního dne. No a do toho Ostrava.
O Ostravě jsme zatím nemluvili, protože tento Blog má být o našich selháních, neúspěších a o tom co jsme se z toho všechno naučili. Ne že by se nám v Ostravě vždy vše jen povedlo, ale celkově rozvoj Ostravských kanceláří považujeme za úspěch, proto zde o nich doteď nebyla řeč. Nicméně právě tyto kanceláře ve finále stály i za konečným uzavřením těch Brněnských. Podařilo se nám totiž průběžně do Ostravy nabrat nějakých 10 nových vývojářů, takže jsme si jednoduše řekli, že snazší cesta nakonec bude ta Ostravská. Pokud bychom měli říci, proč budování pobočky zrovna v Ostravě skončilo lépe než třeba v Brně, tak na to asi nemáme jednoznačnou odpověď. Jisté je, že kontakt s lidmi z Ostravy byl a je intenzivnější, lidé se na pobočkách vzájemně navštěvují výrazně častěji, což pozitivně souvisí s přenosem firemní kultury a celkové atmosféry. Další možnou odpovědí je, že v Ostravě prostě nemáme tak silnou konkurenci jako v Brně. Upřímně řečeno, v Moravskoslezském kraji prostě lepší IT firmu nenajdete.