Teambuilding: czynnik ludzki i podstawowe ryzyko (cz. 2)

Teambuilding: czynnik ludzki i podstawowe ryzyko (cz. 2)
Nazywam się Artur Litvinsky i jestem Project Managerem w DataArt. Z branżą IT jestem związany od ostatnich 5 lat, w tym czasie koordynowałem projekty oparte o różne technologie, obejmujące szeroki obszar geograficzny i na różną skalę od 100 do 50000 użytkowników. To druga część artykułu o czynniku ludzkim w projektach IT. Zachęcam do zajrzenia do pierwszej części, którą znajdziecie tutaj.

Pozwólcie, że raz jeszcze przytoczę moje założenia:

„Opiszę jeden z segmentów ryzyka projektowego, który jest związany z ludźmi i ich cechami oraz, między innymi, osobistymi motywacjami. Pytania i rady wspomniane w tym artykule w większości są uniwersalne, co oznacza, że mają szansę zadziałać w licealnej klasie, zespole górników w kopalni albo teamie Agile. Najważniejsze, że mówimy o grupach ludzi, którzy pracują na wspólny cel.”

Jak zwiększyć szansę na sukces? 

  1. W skomplikowanych sytuacjach, kiedy masz nawet cień wątpliwości, postaraj się uzyskać opinie zewnętrznych ekspertów. Nawet jeśli nie ma w twojej firmie osoby, która zajmuje się zarządzaniem ludźmi, na pewno znajdziesz kogoś na stanowisku związanym z HR, DM czy AM albo po prostu kogoś doświadczonego, z kim korzystnie będzie skonsultować swoje obawy.
  2. Próbuj. Czasami możesz zreformować swój zespół w trybie testowym i spróbować skonfigurować role w odrobinę inny sposób wykorzystując minimalną ilość czasu i minimalne zasoby. Jeśli okaże się, że coś nie działa, łatwo wrócić do poprzedniego stanu.

Jak ocenić rezultaty?

Trudno zidentyfikować osobne KPI dla poziomu zadowolenia zespołu, ale wciąż – powinniśmy wiedzieć, czy nasi ludzie są zadowoleni z pracy w teamie (tak, znowu mówię o rozmowach). Kluczowym wskaźnikiem, który podpowie ci, czy pracujesz właściwie, jest to, czy twój projekt albo produkt odnosi sukcesy. W końcu nie rozmawiamy o przyjaźni czy wakacyjnych wyjazdach, a o pracy!

Wypalenie zawodowe

Ludzie o wysokim poziomie produktywności i motywacji często mierzą się z problemem wypalenia zawodowego. Jeśli nie zauważysz w porę, że ten problem dotyczy kogoś w twoim otoczeniu, produktywność spadnie, a w jej miejsce pojawi się apatia, a nawet problemy zdrowotne. Ludzie zaczynają traktować pracę wyłącznie w kategoriach obowiązku albo – po prostu – odchodzą.

W jednej z amerykańskich firm miałem przyjemność pracować z niesamowitą panią dyrektor do spraw HR. To była bardzo profesjonalna osoba, która zbudowała wszelkie wewnętrzne procesy i udało jej się stworzyć doskonały team. Pięć lat później została poproszona o objęcie nadzorem kilku regionów w dużej, międzynarodowej korporacji, ale szef firmy, w której pracowała robił wszystko, by nie odeszła. Zaproponował jej nawet część udziałów i ostatecznie zdecydowała się zostać. Ale wieloletnie zmęczenie, niezliczona ilość prób przekonania do pozostania i przełomy, kompletnie ją zmieniły. Nie była nawet w połowie tak dobra, jak wcześniej. Była wypalona i załamana. Popracowała na rzecz tej firmy może jeszcze 3-4 miesiące.

Takie sytuacje mają ogromny wpływ na cały zespół. Właśnie dlatego lider powinien posiadać umiejętność rozstawania się nawet z kluczowymi osobami, kiedy przychodzi na to czas.

Co zrobić?

  • Jak najszybciej zorientować się, że dana osoba jest w stanie wypalenia. Zazwyczaj nawet poważne problemy mogą być rozwiązane poprzez zmianę projektu albo stanowiska lub prostą zamianę zadań w ramach tego samego projektu. Możesz nawet spróbować zmienić tej osobie biurko albo monitor na większy.
  • Zarządzaj oczekiwaniami ludzi. Nie możesz obiecać tego, czego nie możesz dać, ale jeśli ktoś czeka na coś cały rok i tego nie dostaje – nieważne, czy jest to podwyżka czy nowa mysz – naprawdę potrafi to zdemotywować. Dobrze jest wiedzieć, na co czekają członkowie zespołu.
  • Przymusowy urlop. Są pracoholicy, którzy przychodzą do pracy nawet chorzy lub skrajnie zmęczeni. Mogą być wściekli albo powtarzać, że ich obecność jest kluczowa, ale kiedy widzisz, że ich siedzenie w biurze nie ma sensu, wyślij ich do domu. Skorzysta na tym każdy, uwierz.
  • Bądź pożegnać się nawet z najważniejszymi osobami w teamiie, kiedy przyjdzie na to czas.

Oporność na zmiany

Prawdopodobnie każdy z nas spotkał się z team leaderem lub kimkolwiek innym, kto był kompletnie niechętny wobec nowego podejścia. Może dotyczyło to nawet ciebie. Czemu coś zmieniać, jeśli tak naprawdę nie wymaga naprawy? Niestety, gdybyśmy podążali za tą zasadą, wciąż ganialibyśmy włochate mamuty z kamiennymi młotami w dłoni…

Oto standardowy scenariusz: po wdrożeniu szczególnie wątpliwych albo niewygodnych innowacji, każdy pracuje dokładnie tak, jak dotychczas. Co więcej – każdy głośno komentuje, dlaczego proponowane zmiany nie mają szansy działać. Jeśli zespół jest przyzwyczajony do określonego sposobu działania, procesu albo reguł, będzie upierał się, że to jedyna właściwa droga. Na przykład – po co wypełniać karty czasu pracy, jeśli nigdy tego nie robiliśmy i wszystko działało?

Co zrobić?

Podział obowiązków i horyzontalna struktura pomaga. Oznacza to, że PM i lider zespołu nie stawiają się ponad innymi. Jeśli każdy czuje się odpowiedzialny za projekt, zdecydowanie bardziej interesujące staje się próbowanie nowych metod.

Pokaż, że inne teamy z sukcesem używają nowych technik. Znajdź tych, którzy wdrożą je wcześniej – 5-10% ludzi jest zadowolonych, jeśli próbują czegoś jako pierwsi.

Brak kwalifikacji

Istnieje ryzyko, że kiedy zatrudniasz Senior Developera do twojego zespołu szybko okazuje się, że to po prostu Junior o silnych kwalifikacjach. Założę się, że wielu z was spotkało się z sytuacją, w której wymagania wobec nowej osoby są wyższe niż jej rzeczywiste umiejętności i realny wkład w projekt.

Znam przypadki, w których wyniki pracy nowego Seniora przeraziły cały team i przyniosły do projektu chaos. Może znasz sytuacje, w których ludzie twierdzą, że osobiście instruowali Alana Turinga, kiedy budował swoją maszynę, a po kilku tygodniach okazuje się, że nie potrafią napisać linijki kodu…

Co zrobić?

Często jest niezmiernie trudno miarodajnie ocenić poziom umiejętności danej osoby. Można zminimalizować ryzyko zbierając feedback z poprzednich projektów/od poprzednich pracodawców. Jeśli masz wątpliwości, umów kolejną rozmowę techniczną.

Osoba, która rozczarowuje może nie robić tego celowo i nie być niczemu winna, więc nie panikuj. Może powinna dostać inne zadanie w ramach tego projektu? Rozwijaj ludzi, zapraszaj mentorów, ucz.

Zbyt wykwalifikowani

To się zdarza dość często. Ale to prawdopodobnie najłatwiejszy problem do rozwiązania. I jest na to tylko jedna rada: jeśli zatrudniasz architekta, nie każ mu robić prostej strony typu one-page…

Nieporozumienie

Czasami dwóch całkowicie rzetelnych profesjonalistów po prostu nie może ze sobą pracować. Spotykałem takie przypadki w projektach, w których pracowałem. Dwóch doświadczonych specjalistów – jeden – flegmatyczny front-end developer, drugi wybuchowy backendowiec, mieli wspólnie rozwiązać zadanie. Ostatecznie skończyło się to personalnym konfliktem i kompletną niechęcią do komunikowania się. Ich niekompatybilność powodowała tworzenie się niepotrzebnego napięcia bez powodu. Rozwiązaniem było zaangażowanie mediatora zanim skończyli swoje zadanie. Potem staraliśmy się nie angażować ich w tę samą część projektu i wszystko działało normalnie.

Takie sytuacje często występują w zespołach rozproszonych i mogą być rozwiązane nawet poprzez zmianę sposobi komunikacji. Najtrudniej jest negocjować poprzez maile (zwłaszcza, jeśli poczucie niezrozumienia już narosło). Komunikatory są odrobinę lepsze, jeszcze bardziej efektywne są rozmowy głosowe i wideokonferencje, ale sprawę najlepiej załatwia spotkanie twarzą w twarz.

Co robić?

Nie pozwól nieporozumieniom się tlić, powinieneś wiedzieć, jeśli ktoś w twoim zespole jest wrogo nastawiony wobec innych. Wszyscy członkowie twojego teamu powinni rozumieć, że mogą z tobą rozmawiać o wszystkich problemach, a ty spróbujesz rozwiązać je spokojnie, bez skandalu. W większości przypadków trzeba zidentyfikować źródło problemu, by dokładnie zrozumieć, jak go rozwiązać.

Czynnik autobusowy – bus-factor

Co stałoby się, gdyby jeden z członków twojego zespołu został potrącony przez autobus? Jeśli odpowiedź w przypadku choć jednego z członków zespołu brzmi: wszystko by się rozleciało, masz problem!

Zazwyczaj nie zdaje się tego testu w przypadku, gdy twój team ma jednego utalentowanego pracoholika, który odwala całą robotę albo techniczną gwiazdę czy niepodważalny autorytet, który utwierdza resztę w słuszności podjętych (może to być jedna lub więcej osób).

Taka sytuacja podsuwa jeszcze jeden czynnik ryzyka: co stanie się, jeśli twoja gwiazda zakocha się w sobie za bardzo? Ale oczywiście więcej problemów pojawia się, gdy taka osoba odchodzi.

Co robić?

Postaraj się podejmować decyzje z pomocą innych i dystrybuować obszary odpowiedzialności pomiędzy ludźmi, nawet jeśli twój zespół składa się z dwóch osób. Jeśli w twoim projekcie jest bardzo silny specjalista, masz szczęście, ale nie pozwól tej osobie na dyktowanie warunków albo wzięcie na siebie wszystkiego przy odsunięciu od zadań reszty. Jeśli inni boją się spierać z tą osobą, wtedy prawdopodobieństwo katastrofy wzrasta wielokrotnie. Inną sprawą jest to, czy zdołasz z takiego kolegi zrobić mentora dla reszty.

Niestety istnieją ekstremalne przypadki, w których efektywne będzie rozstanie się z twoją gwiazdą. Zawsze wygląda to jak rasowy strzał w stopę, ale jeśli jesteś pewien, że ta osoba daje zespołowi coraz mnie i wymaga coraz więcej podziwu, nie masz wyboru. Staraj się unikać sytuacji, w której 80% pracy teamu jest wykonywane przez jedną osobę.

Wszystko się zmienia

Niektórzy z moich kolegów uważają, że zespół powinien być pielęgnowany dopóki nie zacznie sam sobą zarządzać. Ale osobiście nie widziałem ani jednego dużego lub długoterminowego projektu, który mógłby bezpiecznie funkcjonować na tej zasadzie bez żadnego ryzyka. Często, jeśli przestajesz się regularnie komunikować z ludźmi i zbierać informacje zwrotne od klienta, możesz nie zauważyć, że projekt przekroczył punkt, z którego nie ma odwrotu, nawet jeśli z zewnątrz wszystko wygląda w porządku. Narzuciłem sobie zasadę okresowego powracania do klientów i pytania o to, czy są zadowoleni z pracy z nami, co lubią, a co by poprawili. Praktycznie wszyscy z nich odbierają taki sposób współpracy pozytywnie. Nie obchodzi mnie, jak oczywiste się to wydaje, bo wiele ludzi ignoruje tę zasadę. Bądźmy szczerzy – kiedy ostatnio tobie zdarzyła się taka rozmowa?

Porady i triki

Nie da się wyeliminować wszystkich czynników ryzyka. Ale jeśli uda ci się stworzyć zespół ludzi, którzy są nie tylko doskonali z technicznego punktu widzenia, ale łączą ich wspólne wartości, twoja szansa na sukces rośnie. Trudno to osiągnąć i najprawdopodobniej zajmie to masę czasu i będzie wymagać poddania się pewnej selekcji naturalnej.

Staraj się brać udział w procesie rekrutacji od wczesnych etapów, zbieraj informacje na temat projektów, w której wcześniej pracowały osoby z twojego przyszłego teamu i zbieraj feedback od ich poprzednich zespołów.

Bądź częścią zespołu, nie kierownikiem. Słuchaj swoich ludzi i staraj się zrozumieć, co chcą ci przekazać, pomóż im rozwijać talenty.

Łatwiej zapobiegać problemom na wczesnych etapach (nawet jeśli identyfikacja tych problemów jest trudna) niż eliminować konsekwencje.

I najważniejsze – staraj się, by zarówno zespół jak i klienci byli zadowoleni przez cały czas – uważam, że to nadrzędna misja i baza, na której każdy project manager powinien opierać swoją pracę.