Jak usprawnić proces mentoringu? Devdebata

Wsparcie mentora odgrywa niebagatelną rolę w rozwoju juniora. Szczególnie trudne są początki w branży dla osób, które dopiero co zaczynają swoją przygodę w IT. Jak w takim razie proces ten powinien wyglądać podręcznikowo? A może w ogóle nie powinien się opierać na schematach? A przy tym, dlaczego warto zaangażować w mentoring seniorów? Tych wartościowych informacji dowiecie się z poniższej devdebaty!

Odpowiedzi na pytania udzielili:

Rafał Mszal. Senior Embedded Software Engineer at TIER Mobility. Absolwent AGH na kierunku Automatyka i Robotyka oraz Elektronika i Telekomunikacja. Od ponad 2 lat pracuje w zespołach zajmujących się projektowaniem pojazdów dla branży micromobility, właśnie dołączył jako Senior Embedded Software Engineer do TIER Mobility, poprzednio na tym samym stanowisku pracował w JUMP Bikes (UBER). Wcześniej Firmware Engineer w Nordic Semiconductor, a także projektant urządzeń do oświetlenia architektonicznego w PXM. W międzyczasie, w latach 2016-2019 rozwijał startup Shape.Care jako Co-founder i CTO. Pracę w branży embedded traktuje jako swoją największą pasję, a projektowanie urządzeń elektroniki użytkowej i użyteczności publicznej jako formę spełnienia zawodowego. Z książkowym stylem mentoringu w pracy spotkał się tylko raz, już na późniejszym etapie kariery. Niesmak pozostał do dzisiaj. Zwolennik stosowania opartego na empatii zdroworozsądkowego podejścia do rozwoju młodszych programistów.

Mateusz Lewandowski. Senior Software Engineer w Talentech. Absolwent Uniwersytetu Gdańskiego na kierunku Informatyka i Ekonometria. Senior Front End developer w Talentech – firmie zajmującej się tworzeniem oprogramowania dla potrzeb HR i zarządzaniem pracownikami wewnątrz firmy. Poprzednio pracował w zarówno małych firmach i agencjach interaktywnych, jak i w dużej międzynarodowej korporacji, gdzie pierwszy raz spotkał się Mentoringiem. Pasjonat front endu i ewangelista Reacta. W wolnym czasie realizuje się jako Mentor dla swoich dwóch synów.

Bartosz Jurkiewicz. Software Engineer at Hapag-Lloyd AG. Socjolog z wykształcenia, developer samouk z 6-letnim doświadczeniem jako frontend/fullstack developer. Wolny czas spędza m.in. na tworzeniu własnego produktu (SoundHouse), byciu mentorem dla osób chcących znaleźć pierwszą pracę jako frontend developerzy oraz poznawaniu nowych technologii. Od zawsze mocno związany z muzyką – perkusista, który stara się plumkać na basie. Lubię grać w gry, czytać książki (głównie fantastyka + postapo – fan serii Metro 2033), grać w kosza i oglądać mecze NBA. Ostatnie 2 lata spędziłem pracując dla firmy ze stanów gdzie poznałem Elixir. Dopiero co dołączyłem do Hapag-Lloyd jako Software Engineer. Lubię dzielić się wiedzą oraz pomagać rozwijać się innym – podobno wychodzi mi to całkiem nieźle. 🙂

Jak wspominasz swoje wejście do branży pod względem mentoringu?

Rafał Mszal, Senior Embedded Software Engineer at TIER Mobility:

Początki w nowej pracy bywały bardzo trudne, można powiedzieć, że zwykle byłem rzucany na głęboką wodę bez koła ratunkowego. Co prawda nie miałem wtedy do czynienia z mentoringiem, natomiast wiele wniosków wyciągnąłem, analizując własne błędy i problemy w czasie zmiany pracy. To w zasadzie uświadomiło mi, jak ważne jest przemyślane wprowadzanie nowych osób do zespołu i zadbanie o ich komfort psychiczny w pracy od pierwszego dnia, co jest podstawą budowania odpowiednich relacji, w których nowo dołączające osoby nie mają oporów przed zadawaniem z pozoru prostych pytań i proszeniem o pomoc. Wypracowane zasady z powodzeniem stosowałem w poprzednich firmach gdy do naszych zespołów dołączali stażyści, jak również podczas powiększania naszego ostatniego zespołu programistów z “two man army” do 13 osób.

Wyobraź sobie następującą sytuację: dołączasz jako junior do kilkuosobowego zespołu, otrzymujesz ogólnikowe, nieprecyzyjnie wyjaśnione zadanie do zrobienia, po czym zespół się rozpływa: kilka osób bierze urlop, inne wyjeżdżają na konferencję, a ostatnia, którą możesz poprosić o pomoc siedzi cały dzień w słuchawkach i uproszczoną łaciną komentuje jaki interesujący problem naprawia. W tle słychać poranne stukanie w klawiaturę kilkunastu osób, których Twoje zadania zupełnie nie interesują. Człowiek spala się psychicznie, gwarantuję, że po 2 dniach będziesz myślał, że w pracy potrafisz tylko zaparzyć sobie kawę, a po tygodniu zaczniesz szukać wzoru wypowiedzenia umowy.

Na późniejszym etapie kariery zetknąłem się po raz pierwszy z mentoringiem w książkowym stylu[kołczingiem], skupionym na rozwoju umiejętności miękkich i udzielaniu pomocy w “stawaniu się lepszym człowiekiem”. Niestety, z perspektywy czasu oceniam tego typu mentoring jako jedno z narzędzi manipulacji zespołem, będące na pograniczu NLP, niesmak pozostał do dziś. Prowadzony w nieetyczny sposób potrafi szybko zniszczyć zaufanie i dobre relacje, w efekcie czego zespół przestaje podążać za mentorem. Wniosek z tej historii jest prosty: jeśli ktoś zaproponuje Ci pomoc w rozwoju umiejętności miękkich, w ramach profilaktyki poświęć nieco czasu na zaznajomienie się z podstawami programowania neurolingwistycznego.

Mateusz Lewandowski, Senior Software Engineer w Talentech:

Do branży wchodziłem poprzez małą firmę, gdzie zostałem postawiony w roli one-man army. Pracowałem wtedy jako programista PHP + MySQL, a do tego dorabiałem front i tworzyłem widoki w programach typu Photoshop. Samo hasło mentoringu wtedy niewiele mi mówiło i chyba nie każdy wiedział nawet, co to jest (poza dużymi korporacjami z wypracowanymi procesami i metodykami wdrażania nowych pracowników) i w jaki sposób powinno być to prowadzone. Tak więc na wejściu nie miałem możliwości skorzystania z tej formy zdobywania wiedzy i wszystko było przerzucone na mnie – od researchu do implementacji – co niejednokrotnie sprawiło, że popełnione błędy czy założenia odbijały się czkawką w dalszym procesie tworzenia oprogramowania. Jednakże spowodowało to także, że na własnej skórze odczułem to, z czym większość ludzi wchodzących do branży musi się zmagać i jak przytłaczająca i często dezorientująca jest to sytuacja. Nie mając się kogo poradzić czy wysłuchać uwag starszego i bardziej doświadczonego kolegi poniekąd skazani jesteśmy na popełnianie błędów, których z łatwością moglibyśmy uniknąć choćby po krótkiej rozmowie na temat problemu. Stąd też wiem, jak ważny jest to proces i staram się dołożyć wszelkich starań, żeby ułatwić start w projekcie nowym współpracownikom.

Bartosz Jurkiewicz, Software Engineer at Hapag-Lloyd AG:

Myślę, że nie będę oryginalny, mówiąc, że wchodziłem do branży bez mentora i było to bardzo trudne. Jestem samoukiem i zaczynałem od pojedynczych zleceń na super proste strony internetowe, później przerzuciłem się na stawianie stron opartych o WordPress i dopiero po tym znalazłem swoją pierwszą pracę jako Web Developer. Niestety przez brak mentora moja wiedza często była niepełna lub niepoukładana i poskutkowało to złymi nawykami, z którymi później musiałem walczyć. Dodatkowym problemem było to, że tak na dobrą sprawę pojęcie Mentora jeśli już gdzieś istniało to, było rozmyte. Sam Mentor nie do końca wiedział, jaka jest jego rola, więc proces wdrożeniowy często przebiegał w sposób nieustrukturyzowany i koniec końców wynikały z tego braki w wiedzy.

Jakie zasady mentoringu panują w Twojej firmie? Korzystacie z jakichś narzędzi?

Rafał Mszal, Senior Embedded Software Engineer at TIER Mobility:

W jednej z poprzednich firm utrzymywaliśmy rozbudowaną dokumentację w Confluence, w której można było znaleźć między innymi bazę linków do przydatnych materiałów oraz krótkie tutoriale dotyczące korzystania z podstawowych narzędzi, np. bardzo uproszczony tutorial dla Git i narzędzi CI. Takie podejście ma sens gdy firma nastawiona jest na regularne przyjmowanie stażystów i juniorów. Wymaga to również zaangażowania i nakładu pracy wielu osób, na co nie zawsze można sobie pozwolić.

Od kilku lat pracuję w bardzo małych i efektywnych zespołach złożonych z doświadczonych programistów, więc temat mentoringu pojawia się stosunkowo rzadko. Z mojej perspektywy w tego typu zespołach liczy się przede wszystkim utrzymanie wysokiego poziomu kultury i zasad pracy: wzajemny szacunek, szybkie sygnalizowanie problemów i poważne podejście do code review. Dlatego poświęcamy trochę czasu na początku pracy na wyjaśnienie tych zasad, chociaż nie nazwałbym tego mentoringiem, raczej docieraniem się zespołu.

Jak wspomniałem, temat mentoringu pojawia się tylko podczas wdrożeń nowych pracowników – zwykle już na etapie rekrutacji ustalamy plan kilku pierwszych tygodni w pracy, biorąc pod uwagę słabe i mocne strony dołączającej osoby, dobierając zadania, które wpisują się w jej stack technologiczny. Celem jest przede wszystkim szybkie zbudowanie pewności siebie nowej osoby, poczucia przynależności do zespołu, a jednocześnie wykonywania zadań, które mają duży wpływ na produkt. Najgorszą, niestety czasami spotykaną sytuacją, byłoby w takim momencie przydzielanie nowym osobom zadań nudnych bądź będących poza “głównym nurtem” pracy zespołu. Dlatego też zwykle w zespołach, w których pracowałem, wprowadzaliśmy coś w rodzaju okresu wdrożenia, w czasie którego wszystkie niewdzięczne zadania wykonywały osoby z dużym stażem.

Mateusz Lewandowski, Senior Software Engineer w Talentech:

Co do zasad mentoringu to nie ma ich jako takich – Mentoringiem może zająć się każdy, kto ma to ochotę i znajdzie chętnych, dla których mógłby być mentorem. Jeśli już ustalimy, kto będzie mentorem, a kto mentorowanym – zbieramy się, żeby razem wypracować plan działania i zakres materiału, który chcemy zrealizować. Z jednej strony pozwala to na spojrzenie kilku par oczu na ten sam problem, czyli jak rozłożyć materiał dla osoby mentorowanej. Niezwykle ważne jest to, żeby ułożyć plan mentoringu w sposób taki, aby nie przekazać zbyt dużej ilości informacji, ponieważ może być to przytłaczające i ogromna ilość pozornie łatwych materiałów i zagadnień przerodzi się w stos wiadomości, z którego trudno będzie wygrzebać coś wartościowego. W takim wypadku lepiej jest podzielić to na kilka etapów. Ważne jest też poukładanie tego w sposób przemyślany, aby do zagadnień podchodzić po kolei tak, aby wynikały jasne implikacje. Staramy się też nie omijać rzeczy, które są z pozoru oczywiste, gdyż często zapomina się o tym, że osoba mentorowana może nie wiedzieć oczywistych dla nas oczywistości, przez co będzie miała problem z późniejszym zrozumieniem, dlaczego cos działa tak, a nie inaczej.

Jeśli chodzi o narzędzia, to pierwszym i podstawowym narzędziem dla nowych osób jest dobra dokumentacja – często z przykładami implementacji czy opisem – dla osób które dopiero zaczynają pracować z daną technologią, jest to niezwykle pomocne, gdyż pozwala im zobaczyć jak korzystać z wypracowanych już narzędzi.

Co do narzędzi wykorzystywanych w samym procesie mentoringu:

• Narzędzia pakietu office,
• GitHub do code-review,
• Osobiście wybieram Code Surfer jako formę prezentacji materiałów – animacje, ciekawa i przystępnie podana informacja to już połowa sukcesu.

Bartosz Jurkiewicz, Software Engineer at Hapag-Lloyd AG:

Na dobrą sprawę nie spotkałem się jeszcze z jasno określonymi zasadami bycia mentorem. W zależności od tego, czy mówimy o byciu mentorem, który wprowadza w technologię, czy w projekt, te zasady mogą się różnić. Jednak podstawą jest zweryfikowane źródło wiedzy – póki dokumentacja jest pełna i wyjaśnia wszystkie przypadki szczególne oraz mamy kogoś doświadczonego, komu w razie czego możemy zadać pytanie związane z projektem/technologią (niezależnie od tego, czy uważamy, że pytanie jest głupie czy nie) to będzie dobrze. Jeśli chodzi o narzędzia to tak naprawdę jakikolwiek soft do zarządzania projektem (np. Jira, Confluence) + repozytorium kodu powinno dać radę. Najważniejsze jest to, żeby nowa osoba miała dostęp do wszystkich niezbędnych zasobów. Jeśli chodzi o firmy/projekty, w których miałem przyjemność pracować to niestety często wiedza ta przekazywana była “na żywca”, bez jakiegokolwiek przygotowania. Często trzeba było wracać do pewnych tematów, aby tę wiedzę uzupełnić co, jak można się domyślić, nie skutkowało niczym innym jak dezorientacją i zamieszaniem.

Co sprawia najwięcej trudności osobom niedoświadczonym w IT?

Rafał Mszal, Senior Embedded Software Engineer at TIER Mobility:

Myślę, że największe trudności są związane z mylnym zrozumieniem własnej roli w zespole i stawianych oczekiwań, czego rezultatem jest nałożenie na siebie zbyt dużej presji w pierwszych tygodniach pracy. Czasami łączy się to również z brakiem cierpliwości w oczekiwaniu na rezultaty swojej pracy i utratą motywacji. Kolejną trudnością jest przeskok ze świata akademickiego do realiów komercyjnych, co wymaga zmiany mentalności. Po części jest to też związane z systemem edukacji i kulturą oceniania przez pryzmat wiedzy, a nie umiejętności rozwiązywania problemów. Kilka typowych dla juniorów błędów myślowych:

• „Przyznanie się do niewiedzy to okazanie słabości”,
• „Zadawanie pytań przeszkadza innym w pracy”,
• „Powinienem “to” już wiedzieć”,
• „Nie nadaję się do tej pracy, inne osoby przyswajają wiedzę o wiele szybciej niż ja”.

Inne trudności są związane z brakiem osoby, która wyprowadzi Cię z tej drogi donikąd i przekona, że:

• rekrutacja już się skończyła, teraz jesteś częścią zespołu i nie musisz niczego udowadniać,
• braki w wiedzy nie są problemem, problemem jest tkwienie w tej niewiedzy,
• lepiej zadać z pozoru proste pytanie i rozwiać swoje wątpliwości niż milcząco zmarnować kilka godzin na szukanie odpowiedzi,
• senior to nie jest osoba, która zna odpowiedź na każde pytanie, to osoba, która jest w stanie znaleźć rozwiązanie dla większości problemów (a pozostałe potrafi schować przed użytkownikiem).

Mateusz Lewandowski, Senior Software Engineer w Talentech:

Zadawanie pytań. Wydaje mi się, że jest to największy problem. Pokutuje przeświadczenie, że zadawanie wielu pytań świadczy o braku kompetencji czy elementarnej wiedzy – jest to niezwykle krzywdzące i często prowadzi do nieporozumień. Osobiście uważam, że nie ma głupich pytań, a są tylko głupie odpowiedzi.

Kwestionowanie decyzji innych bardziej doświadczonych współpracowników. Nawet choćby zwykle zapytanie w stylu „a dlaczego tak?” może sprawić ze rozwijając swoja myśl ktoś faktycznie dostrzeże błąd w rozumowaniu lub pokaże niezrozumienie konkretnego zadania. Pozycja seniora nie daje immunitetu ani absolutnej władzy w podejmowaniu decyzji oraz nie sprawia, że stajemy się Alfą i Omegą – mylimy się i jak wszyscy ludzie mamy do tego prawo. Inną kwestią jest to, czy potrafimy się do tego przyznać i wyciągnąć wnioski. Czy odpowiadamy i tłumaczymy młodszym kolegom, czy też stawiamy na swoim „bo tak!”

Niedocenianie swojej roli w zespole. Juniorzy wnoszą swego rodzaju świeżość do zespołu, co jest naprawdę fajne. W końcu, skoro tu jesteś, to znaczy, że chcemy z Tobą pracować. Dla seniorów jest to też świetna odskocznia od „zamykania tasków”. Osobiście bardzo lubię pracować z juniorami. Lubię patrzeć, jak ludzie rozwijają się i ile satysfakcji im to przynosi – jest to bardzo budujący obraz

Procesy. Ale to już często kwestia organizacji firmy, w jakiej pracujemy – na początku choćby z pozoru prosty SCRUM realizowany krok po kroku z Agile Manifesto w dłoni sprawia, że nie do końca wszyscy są w stanie pojąć, po co to i dlaczego. Estymowanie i metody estymacji, które potrafią być czasem bardzo wymyślne, również potrafią wprowadzić w konsternację. Jeśli dodamy do tego branching model i proces zamykania tasków i „definition of done” do tego posypiemy to typową „zwinnością” – na początku może to być przytłaczające – ale po pewnym czasie wchodzi w krew.

Bartosz Jurkiewicz, Software Engineer at Hapag-Lloyd AG:

Przede wszystkim strach/brak pewności siebie. Jeśli czegoś nie wiemy/nie rozumiemy – powinniśmy pytać. Jeśli ktoś nam mówi, że mamy coś zrobić w ten, a nie inny sposób a my nie rozumiemy dlaczego – powinniśmy pytać. Jeśli chodzi o zadawanie pytań to możemy za wzór wziąć dzieci – a dlaczego tak? A po co?

Nie możemy się bać tego, że czegoś nie wiemy (lub tego, że inni będą o tym wiedzieć) – powinniśmy się bać tego, że mimo tego, że czegoś nie wiemy, nie dążymy do zdobycia tej wiedzy. Grunt to uświadomić sobie, że każdy w którymś momencie swojej kariery przechodził przez to samo.

Obowiązkiem każdego juniora jest rozwój oraz dążenie do tego, aby kiedyś móc postawić się w roli mentora czyt. czerpać wiedzę od osób z większym doświadczeniem tak długo jak to tylko możliwe. W ten sposób potwierdzi swoją wartość dla firmy oraz reszty zespołu.

I tak – często starsi programiści są co najmniej trudni w obyciu lub procesy wewnątrz firmy mogą być na początku niezrozumiałe ale jeśli będziemy chłonąć tę wiedzę konsekwentnie, to szybko stwierdzimy, że to wcale nie było takie straszne.

Dodatkowo – każdy członek zespołu ma wpływ na produkt/projekt i uświadomienie sobie tego jest bardzo ważne.

Jak sprawić, żeby mentoring nie był nudny dla seniora?

Rafał Mszal, Senior Embedded Software Engineer at TIER Mobility:

Przede wszystkim nie powinien to być obowiązek nakładany na każdą osobę w zespole. W jednym z zespołów, w którym pracowałem, panowało mylne przekonanie, że “senior to osoba, która potrafi i powinna wychować juniorów”. Jeśli dołączasz do nowego zespołu, to nie ma chyba nic gorszego niż przeczucie, że ktoś pomaga Ci z przymusu. Krótko mówiąc, “wystarczy” dobrać odpowiednią osobę do tego zadania, kogoś, komu przekazywanie wiedzy sprawia satysfakcję. Z drugiej strony, nawet najlepszy nauczyciel i pasjonat nie będzie zadowolony i zmotywowany do mentorowania osoby, która nie przejawia odrobiny ambicji i zaangażowania w naukę – warto mieć to na uwadze już podczas rekrutacji juniora.

Mateusz Lewandowski, Senior Software Engineer w Talentech:

Przede wszystkim nie robić z tego obowiązku – zrozumienie, że ludzie są różni pod wieloma względami to podstawa. Niektórym ludziom radość przynosi znajdowanie błędów i rozwiązywanie trudnych problemów, innym z kolei dzielenie się wiedza. Do tego nie każdy może dobrze czuć się w roli mentora. Dobór ludzi, którzy będą mentorowani jest również niezwykle istotny. Ciężko znaleźć będzie radość w nauce osoby, która nie wyraża choć odrobiny ambicji czy chęci i uczestnictwo w mentoringu traktuje w kategorii kary. To potrafi być niezwykle demotywujące dla prowadzącego mentoring. Również stworzenie jednego schematu, według którego mentorujemy ludzi po raz dziesiąty, sprawia, że czujemy się znużeni – dlatego zachęcam, aby za każdym razem przygotowywać się na nowo – eksperymentować i bawić się konwencją. Pozwoli to też Seniorom na ocenę, jaka forma nauki czy przekazywania wiedzy jest najlepiej przyswajana. Słuchajmy również ludzi, nad którymi prowadzimy mentoring – to często sprawia, że spotykamy się z nieszablonowym spojrzeniem na dany problem czy zagadnienie.

Bartosz Jurkiewicz, Software Engineer at Hapag-Lloyd AG:

Myślę, że jakby to nie brzmiało, nie da się uniknąć nudy w procesie mentoringu. Obstawiam, że nawet najciekawsze zajęcie świata po iluś razach ma cząstkę nudy i jest to coś zupełnie naturalnego. Najważniejsze jest, aby sprawić, że tej nudy jest w procesie jak najmniej.

Z każdym kolejnym można eksperymentować oraz wprowadzać lub wykorzystywać inne formy nauki. Dodatkowo każdy człowiek jest inny i mimo powtarzalnych problemów proces może wyglądać zupełnie inaczej. Jeśli senior ma ‚zacięcie’ i lubi dzielić się wiedzą to delikatna nuda nie powinna być problemem, a jeśli nie ma najmniejszej ochoty tego robić – nie powinien być zmuszany.

Jak zachęcacie seniora do przekazywania wiedzy młodszym kolegom? Dostaje za to jakieś benefity?

Rafał Mszal, Senior Embedded Software Engineer at TIER Mobility:

Nie spotkałem się z bezpośrednimi benefitami związanymi z pełnieniem roli mentora, natomiast czasami wpływało to na wysokość premii rocznej czy też potencjalny awans. Zwykle w zespole znajdujemy ochotników, którzy podejmują się takich zadań nie licząc na benefity.

Dla mnie przekazywanie wiedzy młodszym kolegom to przede wszystkim inwestycja we własny zespół. W końcu im szybciej nauczymy kogoś efektywnej pracy, tym szybciej odciąży nas z części zadań, czego chcieć więcej? Klasyczne win-win. Ponadto, nauczenie kogoś nowych umiejętności zawsze sprawia mi satysfakcję i jest elementem spełnienia zawodowego.

Mateusz Lewandowski, Senior Software Engineer w Talentech:

W jednej z firm, w której pracowałem za mentoring otrzymywało się dodatkowe wynagrodzenie – symboliczne – więc nie była nawet przysłowiowa marchewka do prowadzenia mentoringu, a raczej takie „dziękujemy” od firmy. Mentoring natomiast był bardzo dobrze postrzegany w kwestii rozwoju pracownika i świetnie wyglądał w planie rozwoju, co przy awansach odgrywało niezwykle dużą rolę. Na koniec programu całkiem nieoczekiwanie wszyscy mentorzy dostali bluzy od koordynatora mentoringu, co było miłym gestem – ja swoja mam do dziś i patrzę na nią z ogromnym sentymentem. 😉

W obecnej firmie nie mamy programu motywacji mentorów. Mentoring prowadzi ten, kto chce się dzielić wiedzą, a to sprawia, że osoba prowadząca mentoring jest bardzo zaangażowana. Jak wiadomo, to inicjatywy oddolne są najmocniejsze i potrafią przetrwać zdecydowanie dłużej niż te narzucane z góry.

Bartosz Jurkiewicz, Software Engineer at Hapag-Lloyd AG:

Szczerze mówiąc nie spotkałem się jeszcze z czymś takim jak benefity dla mentora. Nie spotkałem się też z sytuacją, że trzeba było kogoś specjalnie do tego zachęcać. Uważam, że każdy developer prędzej czy później powinien przejść przez proces mentoringu jako mentor, ponieważ jest to bardzo dobry sposób na weryfikację własnej wiedzy czy umiejętności, a dodatkowo może się okazać, że jesteśmy w tym całkiem nieźli. Ponadto może nas wiele nauczyć, jeśli chodzi o umiejętności miękkie, co również jest mile widziane.

Jak poza godzinami pracy wspieracie juniorów w nauce?

Rafał Mszal, Senior Embedded Software Engineer at TIER Mobility:

Jak już wspomniałem, na co dzień nie mam do czynienia z juniorami. Wydaje mi się dobrym pomysłem założenie kanału na firmowym slacku, na którym umieszczałbym linki do przydatnych materiałów – nic tak nie motywuje do nauki jak świadomość, że ktoś może o to zapytać po weekendzie. 😀

Inny pomysł, który przychodzi mi do głowy to rozmowa o projektach hobbystycznych – jeśli młodszy kolega realizuje np. jakiś projekt studencki, warto poświęcić trochę czasu na zainteresowanie się tematem i próbę doradzenia sprawdzonych rozwiązań, czy też przedstawienia dobrych praktyk tworzenia projektu. Wyniesione z tej dyskusji doświadczenie z pewnością zaowocuje też w pracy. Takie rozmowy często toczy się również z bardziej doświadczonymi osobami, które wolny czas poświęcają na tworzenie hobbystycznych projektów.

Mateusz Lewandowski, Senior Software Engineer w Talentech:

Poza godzinami pracy raczej staram się nie wracać do tematów, które związane są z pracą, gdyż obecnie mocno kultywowane jest podejście work-life balance. Natomiast jeśli znajdę jakiś artykuł, który omawia, bądź rozwiązuje dany problem – podsyłam linki. Dlatego jak już wspomniałem, warto słuchać osób, nad którymi sprawuje się mentoring. Być może natkniemy się artykuł, narzędzie lub repozytorium, które może być interesujące bądź pomocne w zrozumieniu danych zagadnień czy rozwiązaniu konkretnych problemów.

Bartosz Jurkiewicz, Software Engineer at Hapag-Lloyd AG:

Poza godzinami pracy w firmie, w której aktualnie pracuję… Jestem mentorem. 🙂 Z racji tego, że przekazywanie wiedzy sprawia mi przyjemność i lubię patrzeć jak inni (w jakiejś tam części pod moim wpływem… mam nadzieję :)) nabierają nowych umiejętności, prowadzę „cykl mentoringowy” dla osób, które chcą wejść do branży jako Junior Frontend developerzy jako zajęcie dodatkowe. Na dobrą sprawę cykl jest dopiero rozkręcany i grupka jest raczej mała, ale mam nadzieję, że niedługo się to zmieni. Poza czasem spędzonym na mentoringu staram się zapewniać dawkę ciekawostek/nowinek w formie artykułów/filmów, które sprawią, że chęć do pracy i ciekawość nie maleje albo nawet i rośnie.

Jak usprawnić proces mentoringu?

Rafał Mszal, Senior Embedded Software Engineer at TIER Mobility:

Pomocne jest uświadomienie sobie i kolegom z zespołu, że szkolenie juniorów to inwestycja w zespół, a więc powinno być traktowane jako część pracy, a nie zajęcia po godzinach dla ochotników. Rozumiem przez to odpowiednie zaplanowanie pracy w zespole, żeby osoba podejmująca się wdrożenia i mentoringu miała na to przewidziany czas.

Mateusz Lewandowski, Senior Software Engineer w Talentech:

Jak już wspominałem – w mojej ocenie przede wszystkim nie zmuszać ludzi do prowadzenia mentoringu jeśli tego nie chcą bądź nie czują – oszczędzi to sporo nerwów i frustracji dla obu stron.

Zapewnienie czasu dla mentorów na przygotowanie materiałów i prowadzenie mentoringu w godzinach pracy. To natomiast wiąże się ze świadomą decyzją wyłączenia mentora z procesu tworzenia oprogramowania na kilka godzin w tygodniu.

Transparentność. Określenie jasnego celu i programu, który pokaże, co konkretnie będzie realizowane i jak szeroki będzie zakres materiału. Upatruję w tym przede wszystkim korzyści w postaci informacji dla osób, które szukają odpowiedniego zakresu materiału i nie chciałyby ponownie przerabiać materiału, który już opanowały, a z drugiej strony nie chcą rzucać się zbyt głęboką wodę.

Bartosz Jurkiewicz, Software Engineer at Hapag-Lloyd AG:

Myślę, że jeśli mentor podchodzi do zadania rzetelnie oraz z szacunkiem do czasu swojego i osoby uczącej się powinno być dobrze.

Oczywiście czasem trzeba niektórym uświadomić, że jest to zajęcie czasochłonne i aby wykonać to dobrze, nie można ulegać presji. Samo przygotowanie niezbędnych materiałów oraz ułożenie dostępnej wiedzy zajmuje bardzo dużo czasu. Fajnie jeśli to zadanie jest już wykonane ale jeśli nie to mentor będzie to musiał wykonać sam. Dodatkowo dochodzi czas na dyskusje/pytania osoby mentorowanej.

Grunt to nie popędzać, nie spieszyć się i podążać tempem osoby, której przekazujemy wiedzę.

Jakimi radami mógłbyś podzielić się z innymi mentorami?

Rafał Mszal, Senior Embedded Software Engineer at TIER Mobility:

Najważniejsza w przekazywaniu wiedzy młodszym kolegom jest empatia, umiejętność postawienia się w ich sytuacji i pamiętanie o tym jak wyglądały własne trudne początki w tej branży. Kilka prostych zasad, które są ważne nie tylko podczas pracy z juniorami:

• Zadbaj o to, aby Twój młodszy kolega miał poczucie spełniania misji i realizowania się zawodowo – zaplanuj dla niego zadania, które pozwolą mu w krótkim czasie “zrobić różnicę” i poczuć, że jego praca jest ważna. Więcej na ten temat w świetnym artykule.
• Bądź aktywną stroną współpracy. Zamiast liczyć, że ktoś podzieli się swoimi wątpliwościami, sam wyjdź z inicjatywą i kilka razy w ciągu dnia zapytaj, jak idzie praca, czy są jakieś problemy, czy możesz jakoś pomóc. Zwykle wykorzystywałem do tego celu chwilową przerwę od siedzenia za biurkiem, warto wstać raz na kilka godzin i zamienić parę słów z kolegami. Proste pytanie: “nad czym teraz siedzisz?” potrafi zachęcić taką osobę do szczerej rozmowy i zrobienia kroku naprzód.
• Często wspominaj o tym, że Twoją rolą jest pomaganie, a rolą juniora jest zadawanie pytań i poświęcanie części czasu na naukę. Na ciężką pracę przyjdzie jeszcze czas po wdrożeniu.
• Przy udzielaniu pomocy nie zaszkodzi dodać czegoś w stylu: “nie przejmuj się, wszyscy mieliśmy z tym problemy na początku” albo “zrozumienie jak to działa zajęło mi kilka dni”.
• Nie stawiaj “ofensywnych” pytań w stylu: “Wiesz jak działa XYZ?”, lepiej zamień to na “Wyślę Ci link z wyjaśnieniem jak działa XYZ” – na pierwsze pytanie często usłyszysz niepewne i czasami nieszczere “tak”, przy drugim w najgorszym wypadku odpowiedzią będzie ‘przecież to znam’.

Na koniec jeszcze jedna, bardzo ważna rada: jeśli poświęcasz swój czas i energię na to, żeby ktoś rósł przy Tobie jako programista, nie zapomnij zadbać też o to, żeby firma nadążała za jego rozwojem z oferowanymi warunkami pracy i rolą w zespole. Spędzenie kilku miesięcy na mentorowaniu nowego pracownika tylko po to, żeby później z powodów finansowych bądź ambicjonalnych zmienił pracę, może być bardzo irytujące.

Mateusz Lewandowski, Senior Software Engineer w Talentech:

Najważniejsze jest zrozumienie, że oprócz wymagań, które stawiane są uczestnikom mentoringu, wymagania stawiane są również mentorom. Nie wystarczy rzucać suchą teorią w nadziei, że junior będzie wchłaniać wszystko jak gąbka wodę – czasem trzeba poświęcić trochę więcej czasu na wytłumaczenie podstaw i zweryfikowanie czy zostały one dobrze przyswojone. Bycie mentorem to też ogromna odpowiedzialność – to my decydujemy o tym, jak przygotowany uczestnik „wyleci spod naszych skrzydeł” i z jak przygotowanym juniorem przyjdzie nam pracować.

Bycie Seniorem to nie tylko sama wiedza, ale również umiejętność dzielenia się wiedzą. Odpowiadanie wprost na pytania nie zawsze jest najlepszą formą pomocy – czasem wystarczy odrobinę się wysilić, aby nakierować juniora na odpowiedź. Można odpowiadać w sposób nieoczywisty tak, aby to on sam znalazł rozwiązanie problemu – uśmiech i zadowolenie na jego twarzy jest wielce budujące. Z drugiej strony należy też zachęcać do podejmowanie samodzielnych decyzji. Trzeba naprawdę to czuć, aby wszystko wyważyć w odpowiednich proporcjach. Naszym zadaniem jest również budowanie wartości osoby, nad którą sprawujemy mentoring i nie jest to wcale łatwe zadanie do zrealizowania. Nam sam koniec postawmy się w pozycji osoby mentorowanej i zastanówmy się przez chwilę, jak sami chcielibyśmy, aby wyglądał ten proces, gdyby role się odwróciły.

Bartosz Jurkiewicz, Software Engineer at Hapag-Lloyd AG:

Przede wszystkim trzeba pamiętać, że najprawdopodobniej samemu się przez to przechodziło oraz mieć świadomość tego, że ciąży na nas spora odpowiedzialność – umiejętności i wiedza juniora po przejściu procesu będą świadczyć także o Tobie.

Moim zdaniem jest kilka podstawowych zasad, których powinna się trzymać każda osoba chcąca zostać mentorem (oczywiście poza zasadami dobrego wychowania):

• Jeśli nie jesteś czegoś pewien – nie wprowadzaj w błąd. Często spotkałem się z sytuacją gdy mentorzy mówili nie do końca prawdę, aby tylko nie wyszło na jaw, że czegoś nie wiedzą. Myślę, że jest to jeden z największych błędów, jaki można w tej roli popełnić, ponieważ wtedy nie krzywdzimy tylko siebie, ale też i osobę, której mentorem jesteśmy. Nie spotkałem się jeszcze z osobą (niezależnie od doświadczenia), która wiedziałaby dosłownie wszystko – uważam, że jest to niemożliwe i niepotrzebne, lepiej w tym momencie wytłumaczyć, jak sytuacja wygląda i np. spróbować zbadać temat z drugą osobą.
• Bądź cierpliwy – ludzie uczący się często nie wiedzą jak zadawać pytania. Jest to umiejętność, która przychodzi po pewnym czasie obycia z tematem. Mentor musi być cierpliwy i mieć przynajmniej lekką dozę empatii. 🙂
• Schowaj ego – częstą przypadłością starszych programistów jest przekonanie, że są niezastąpieni i wyjątkowi… otóż nie. 🙂 Póki mamy świadomość tego, że nie jesteśmy niezastąpieni i podchodzimy do drugiej osoby jak równemu sobie, to powinno być dobrze.
• Bądź tak konkretny, jak tylko możesz – jeśli przedstawiasz jakieś zagadnienie, nie krąż wokół tematu, tylko opisz dokładnie, o co chodzi, dlaczego tak jest i jakie to niesie konsekwencje.

Zdjęcie główne artykułu pochodzi z unsplash.com.

Oferty pracy z