Feedback czy rada? O mentoringu w świecie IT

Jeśli jesteście doświadczonymi programistami, pewnie nieraz musieliście ocenić pracę kolegów czy koleżanek na juniorskich stanowiskach. Ba! Sami z pewnością też wiele razy otrzymywaliście feedback (dotyczący zrealizowanego projektu czy też przy okazji rekrutacji). Ile razy moglibyście powiedzieć, że informacja zwrotna, którą otrzymaliście, była pomocna i nie wpłynęła negatywnie na Wasze poczucie własnej wartości? Dziś zastanówmy się, jak dawać (dobrze!) feedback.

Feedback to nie relacja — o jednostronnym charakterze informacji zwrotnej

Na początku zauważmy, że feedback to opinia na temat osoby, projektu, jakości współpracy itp. Najważniejszą cechą charakterystyczną tej opinii jest to, że jest jednostronna. Ktoś ocenia i przekazuje tę ocenę, a druga strona jest biernym słuchaczem. Feedback może być pozytywny (chwali i wzmacnia pozytywne aspekty pracy) lub negatywny (w tym przypadku wskazuje pola do poprawy).

Najtrudniejszym zadaniem jest przekazywanie feedbacku dotyczącego nie samej pracy programisty, ale tego, jak działa aplikacja. Opisywanie mankamentów projektu jest bardziej skomplikowane, bo trzeba pamiętać, o całokształcie pracy każdego programisty i odpowiednio sformułować informację zwrotną. Komunikat powinien być jednocześnie pozytywny i zachęcający do rozwijania swoich umiejętności, a z drugiej strony wskazywać, co w projekcie należałoby udoskonalić.

Szef służb wywiadu w natarciu, czyli jak zbierać informacje?

Jeśli zarządzacie zespołem lub projektem, to z pewnością macie swoje techniki zbierania informacji. Oczywiście, jeśli chodzi o sam projekt, wskaźnikami sukcesu lub jego braku są funkcjonalności tworzonego oprogramowania czy też strony. Zazwyczaj jest to prosta sprawa: coś działa lub nie działa.

Trudniejszą kwestią jest długoterminowe zarządzanie zespołem. Będąc leaderami, musicie zbierać informacje na temat rozwoju pracowników, ich umiejętności i planów. Możecie oczywiście polegać na swoich obserwacjach, ale powiedzmy sobie szczerze, że uzyskacie w ten sposób dane szczątkowe i pozbawione kontekstu.

Skorzystaj ze wsparcia agentów…

…którzy nie do końca będą wiedzieć, że nimi są, ale nic w tym złego, w końcu obie strony zyskują na dobrze funkcjonującym zespole. Takim agentem powinien być każdy z członków teamu. Często pracownicy obawiają się o relacje w zespole, dlatego powstrzymują się od krytyki kolegów lub wskazywania menadżerowi czyichś trudności. Może warto skorzystać z anonimowej ankiety, w której pracownicy mogą napisać o trudnościach.

UWAGA! Takie ankiety pomagają wykrywać problemy w zespołach, ale obnażają także umiejętności przywódcze leadera. Nigdy nie lekceważcie trudności, nawet drobnych. Okresowy feedback to jedno, ale pamiętaj, że zarządzanie to też (a może nawet przede wszystkim) praca u podstaw.

Jak mentorować i (dobrze) zarządzać zespołem?

Przede wszystkim zastanówcie się, czy waszym pracownikom odpowiadają „sztuczne” warunki przekazywania feedbacku. Mowa o okresowych spotkaniach jeden na jeden, podczas których omawiacie dotychczasowe postępy. Czasem zdaje się, że leader jest zainteresowany naszą pracą tylko „od wielkiego dzwonu”. Może korzystniej byłoby zastąpić feedback — dobrą radą, a „centralne sterowanie” zmienić w pomoc koleżeńską?

Doceńcie seniorów i korzystajcie z ich doświadczenia

Rady i opinie niekoniecznie muszą płynąć od leaderów zespołu. Dobrze współpracujący zespół potrafi… no właśnie, współpracować. Nie oszukujmy się, każdy projekt menadżer czy inna osoba odpowiedzialna za pracę całego zespołu, chce w pewnym sensie trzymać ster, ale po pierwsze: nie możecie znać się na wszystkim (zresztą nie musicie) a po drugie: często macie też masę innych obowiązków (kontakty z klientami, dokumentacja projektu itd).

Sprawcie, żeby Wasi juniorzy nie bali się pytać, a seniorom chciało się odpowiadać. Oczywiście możecie po zakończeniu projektu oświadczyć osobiście, któremuś z pracowników „to nie działa, tego nie umiesz”, ale czy nie lepiej, żeby sam poszedł do bardziej doświadczonego programisty po pomoc i radę? Efekt: wszystko działa, nie ma na co narzekać. A ego doświadczonego kolegi mile połechtane ;) Oczywiście trzeba pamiętać, że żeby pracownicy chcieli sobie pomagać, muszą mieć na to czas… Mądre planowanie i rozdzielanie zadań jest w tym przypadku kluczem do sukcesu.

Zaraz, zaraz… ale przecież mieliśmy zarządzać…

Delegowanie zadań, to też zarządzanie. Codzienne problemy Waszego zespołu raczej będą dotyczyć technicznych aspektów projektu, a jak już wspomnieliśmy: nikt nie zna się na wszystkim. Co musicie umieć Wy, czego nie musi inny doświadczony programista w Waszym zespole?

Przede wszystkim do Was należy uspokajanie i rozwiązywanie konfliktów, jeśli takie się pojawią. Powinniście też skupić się na długofalowych planach swoich pracowników. W jakim kierunku chcą się rozwijać, jak im to zapewnić, tak by jednocześnie iść też za potrzebami przedsiębiorstwa, w którym pracujecie, to jedno z Waszych ważniejszych zadań. W tym miejscu znów pojawia nam się feedback czy też rada. Czasem plany pracowników bywają… nie całkiem adekwatne do ich możliwości czy aktualnych realiów rynku pracy. Nie wysyłaj negatywnego feedbacku, służ (dobrą) radą!

Stwórzcie środowisko, w którym chce się uczyć

Oczywiście, stworzenie takiej sytuacji, w której wszyscy sobie radośnie pomagają, jest trudne. Niektórzy doświadczeni pracownicy mają naturalne predyspozycje do dzielenia się wiedzą i często nieświadomie wchodzą w role mentorów. Jeśli takich osób jest zbyt mało, pomyślcie, jak ich zmotywować (dodatkowe punkty w programie motywacyjnym, extra premia — nawet drobna mogą zdziałać cuda).

„Pytanie, które warto sobie zadać przed przekazaniem feedbacku to “jaki mam tutaj cel?”. Musi chodzić o pomoc drugiej osobie, nie o wymądrzanie się i stawianie na swoim. Warto skupiać się na rozwoju osoby nim “obdarowywanej”. Feedback jest jak prezent i jeśli zostanie źle opakowany, osoba może go po prostu nie przyjąć. Metoda kanapki już dawno wyszła z mody, bo ludzie nadużywali schematu, zamiast uczciwie porozmawiać. Czy to znaczy, że nie należy dodawać pozytywnego feedbacku? Wręcz przeciwnie! Takiego feedbacku potrzebujemy najwięcej. Inaczej będziemy mieć wrażenie, że ciągle robimy za mało i nie wystarczająco dobrze. Jedną ze składowych wypalenia zawodowego jest obniżenie poczucie własnych osiągnięć. Dostawanie wyłącznie negatywnej informacji zwrotnej może się do tego przyczynić”.

Ola Kunysz, software engineer, mentorka i autorka treści

Czerpanie z doświadczenia starszych kolegów, może być trudniejsze, jeśli team pracuje zdalnie. Jak to rozwiązać? Godziny na doskonalenie, czyli taki dyżur, poranna nieformalna kawa (np. dwie godziny z rana w piątek), podczas którego nie klepiecie kodu, ale macie czas pogadać. Niekoniecznie o projekcie! Widmo wypalenia zawodowego nie omija programistów. Warto trzymać rękę na pulsie.

Feedback a rada — trudności i wyzwania

Jeśli do tej pory opieraliście swoją komunikację z zespołem na okresowym feedbacku np. podczas spotkania jeden na jeden, możecie z pewnością wskazać jedną główną zaletę takiego podejścia: regularność.

Konieczność sformułowania feedbacku rodzi konieczność skupienia się na konkretnym pracowniku i ocenie jego skuteczności. Dawanie rad jest procesem mniej formalnym i bardziej rozproszonym. Żeby stać się dobrym leaderem, trzeba faktycznie być członkiem zespołu i angażować się w jego pracę.

Pamiętajcie! Ani jednostronny feedback, ani porada udzielona w trakcie pracy, nie musi być jednocześnie poleceniem służbowym. Chcemy dbać o atmosferę, ale jeśli jako leaderzy wiecie, że coś musi być zrobione w określony sposób, mówcie o tym wprost, wskazując, dlaczego rozwiązanie nie podlega dyskusji. Ważne: argument „bo ja tak chcę”, to nie jest argument.

Ostatni punkt, ale na pewno nie najmniej ważny, to zaangażowanie. Mentorzy, którzy naprawdę nie chcą nimi być to błąd i strata czasu. Takim członkom zespołu dajcie się wykazać w jakiś inny sposób. Radzić i uczyć muszą ci, którzy serio chcą to robić i się do tego nadają. Nie zmuszajcie do tego wszystkich, którzy mają nieco więcej doświadczenia.

„Ktoś, kto nie ma mentorskich umiejętności, zmęczy siebie i mentee. Takie osoby najczęściej wolą skupić się na kodzie i dostarczaniu funkcjonalności. Zmuszone do mentorowania nie będą zadowolone i dadzą to odczuć wszystkim dookoła. Mogą stawać się cyniczne, dzielić się sarkastycznymi uwagami, albo całkiem odsunąć się od zespołu. Można „wyciągać wiedzę” z takich osób w inny sposób, choćby podczas planowania czy code review”.

Ola Kunysz, software engineer, mentorka i autorka treści

Wniosek? Niestety niejeden

Przede wszystkim musicie sami zastanowić się, jaki sposób zarządzania i przekazywania informacji zwrotnej jest preferowany przez Was i Wasze zespoły. Nie ma jednej słusznej metody. Jednym odpowiada bardziej uporządkowany i sformalizowany system, inni odnajdują się w luźnych radach i rozmowach. Trzeba jednak pamiętać, że bycie leaderem niesie za sobą wiele wyzwań i oczekiwań. Jak im sprostać?

Dowiecie się o tym podczas konferencji Infoshare! Będzie o tym mówił między innymi Wojciech Wereszko. Sprawdźcie, jak oczekiwania względem przywódców w branży technologicznej zderzają się z rzeczywistością. Zdarza się, że tą rzeczywistością staje się wypalenie zawodowe (zarówno u tych doświadczonych, jak i młodych programistów). Jak sobie z tym radzić opowie specjalistka w tym zakresie: Ola Kunysz.

Zarejestrujcie się, teraz!

Nie może Was zabraknąć na konferencji Infoshare! Jeśli jesteście ciekawi, co jeszcze szykujemy dla Was w tym roku, zapoznajcie się z opisem tegorocznych scen.