Jak zmotywować słabsze ogniwo zespołu?

1

Witam
Otóż mamy dość mały zespół i pracujemy nad dość dużym systemem. Po ogarnięciu nie jest on jakiś specjalnie skomplikowany, jednakże duża ilość bardzo słabej jakości kodu sprawia, że może on wydawać się dość trudny. Radzimy sobie dość dobrze z zadaniami, a mi w pracy jest całkiem spoko.

Nie pracujemy przy wykorzystaniu jakichś metodyk zwinnych jak SCRUM. Generalnie klient oraz nasz project manager dał nam wolną rękę do organizacji. Zacząłem pełnić rolę takiego nieformalnego Team Leadera. Decyduje o głównych elementach wytwarzanego kodu jak i o decyzjach organizacyjnych. Sam staram się brać cięższe rzeczy na klatę. Czasem inny kolega z zespołu mi pomoże, czasem ja innym i jakoś to leci.

Jednakże mamy w zespole odstające ogniwo. Kolega ma problemy z prostymi rzeczami. Co daje mu prostą rzecz do roboty to wszystko jest napisane na odwal się, w konsekwencji muszę poprawiać jego kod. Zacząłem mu dawać coraz mniejsze pierdoły do roboty, by nie musieć stać nad nim i mu tłumaczyć, ale no jest z tym słabo, bo i tak muszę mu podpowiedzieć jak to zrobić. Próbowałem programowania w parach i pisać z nim kod. W dodatku jego rozkojarzenie jest dla mnie niedopuszczalne. Potrafi zapomnieć każdy element systemu i za każdym razem trzeba mu przypominać o prostych sprawach. To trochę tak jak z przedszkolakiem co chwilę trzeba dopatrywać czy bawiąc się nie podpali całego domu.

Nie uważam się za nie wiadomo kogo. W zasadzie myślę, że powinienem być juniorem, ale w małej firmie często junior musi brać odpowiedzialność na siebie. Nie chcę też go krytykować, bo wiem, że mógłbym się znaleźć w takiej samej sytuacji w innej firmie. Nie będę przecież chodził na skargę do PM'a. Dlatego też piszę tutaj. Czy mieliście takie doświadczenia, jak zmotywować takie słabsze ogniwa ?

5

Powiedz mu na czym stoi problem i albo się poprawi albo nie i pójdziesz do PM. Nie po to został zatrudniony, by wiecznie mu pomagać czy też poprawiać jego kod.

Jeżeli nie motywuje go to, że widzi, że inni członkowie muszą za niego odwalać pracę to po prostu albo nie ma odpowiedniej wiedzy i umiejętności albo po prostu mi nie zależy.

Dla firmy jest nieefektywnym pracownikiem. W zespole zmniejsza wydajność innych członków. Jak by to powiedział Donald Trump "Zwalniam Cie".

4

Pochwal jak coś zrobi dobrze, powiedz gdzie robi błędy. Błędów nie robi tylko ten kto nie próbuje. Z czasem zobaczy że coś jest nie do końca dociagnięte.

0

Pogadaj z nim na osobności, powiedz dokładnie o co chodzi i, że jest zdolny ale przez to poświęca za mało czasu na proste zadania i przez to ma problemy.

Powiedz mu, że oczekujesz od niego więcej wkładu np. jak czegoś nie rozumie to niech dokształci się w domu na własną rękę. Powiedz, że nie pójdziesz do PM'a na skargę ale tak nie może być.

Potem licz sobie tak jak w baseballu, strike 3 and you're out! W następnej robocie będzie bardziej zmotywowany.

8

@mariano901229 zróbcie jednak takie niby-scrumowe spotkania, choćby raz na tydzień żeby zrobić podsumowanie co kto zrobił, tak żeby było widać o ile mniej kolega robi. Róbcie regularne code-review, najlepiej przed każdym commitem, ale nie tylko dla niego tylko dla każdego i niech on też bierze w nich udział, żeby widział że nikt się na niego nie "uwziął". Niech sam zobaczy że odstaje. A jeśli nadal będzie to olewał to nie przedłuży się mu umowy i tyle.
Najlepiej jakbyście mieli jeszcze na podkładkę jakąś jirę gdzie będzie widać że pracuje o x% słabiej niż średnia.

1

Ja bym postawił na jakiś gerrit albo inny system a'la code review. Dajesz mu zadanie i określony czas. Jak skończy wrzuca na gerrita i ludzie oceniają i spawdzają kod. Zaznaczasz tylko błędy nie podając rozwiązania i do poprawy i tyle aż będzie ok. Czasu na to zbyt wiele się nie traci, na pewno mniej niż gdybyś miał non stop wszystko tłumaczyć. Jak spędzi pare tygodni nad paroma, jak mówisz banalnymi linijkami kodu to pewnie zrobi mu się głupio i weźmie za siebie albo przynajmniej podirytuje i zapali się lampka, że coś jest nie halo.

0

No jak to człowiek, który się stara, ale mu nie wychodzi i nie łapie za super szybko no to tak.
Ale trzeba pamiętać, że są też zdolne cwaniaki, którym po prostu się nie chce i sobie tak bimbają,
że zamiast pracować siedzą na rożnych forach, chanach, portalach w necie..

4

Zastanów się też nad tym czy na pewno liderowanie jest dla Ciebie.
Dla mnie lead to ktoś kto w dowolnym momencie wie co gdzie jest albo jak to znaleźć. I uderzam do niego gdy rozwijam powiązania międzyklasowe 3 dzień z rzędu.
Słaby lead to taki który bierze najcięższe zadania na siebie, przez co albo jest słabo dostępny dla innych albo jest w ciągłym wewnętrznym konflikcie ze sobą.

Zacznij się zachowywać jak trener a nie jak kumpel który przypadkiem musi pomagać bo mu kazali.

(liderowałem w 4 firmach)

Edit: tu poniżej masz listę stylów liderowania, zastanów się który pasuje do Ciebie:
http://www.vectorstudy.com/management-topics/types-of-leadership

2

Myślę, że też kiedyś byłam takim ogniwem, w związku z czym od razu nasuwa mi się mnóstwo pytań:

  • Jak długo ten człowiek jest w firmie? Jeśli więcej niż te 2-3 miesiące, to kiepsko z nim.
  • Jaki ma staż jako programista w ogóle? Jeśli to nie jego pierwsza praca i ma ponad jakieś pół roku, to kiepsko z nim.
  • Na jakiej podstawie został zatrudniony - czy podczas rekrutacji jednak był dobry, czy wzięto go, bo może ewentualnie coś kiedyś z niego wyrośnie? Jeśli zatrudniono go z desperacji, to kiepsko z firmą.
  • Jaką ma osobowość - czy jest milczkiem wyciągniętym z piwnicy, czy swobodnie komunikuje się z otoczeniem? Jeśli ma dobry kontakt z ludźmi, to kiepsko z nim.
  • Jaki ma stosunek do programowania? Jeśli nie przejawia chęci do nauki i podczas dyskusji gapi się w sufit, to kiepsko z nim.
    Jeśli kiepsko z nim, to wyjściem będzie niestety wskazanie mu wyjścia. W przeciwnych przypadkach spróbować jak z jajkiem - chwalić za dobrze wykonane zadanie (na początku nawet małe), podsuwać materiał do nauki, zakolegować się, ale też być wzorem do naśladowania.
0

Na 100% czasu rozmowy z nim - ile % jest stricte o programowaniu, developmencie, szczegółach kodu ?

Wiem, że to dosyć płynny wskaźnik, ale się sprawdza. Jeżeli z kimś gadam i rozmowa w ponad 80% dotyczy programowania, to zakładam, że się zna / lubi / interesuje go to, kręci / JEST W TYM DOBRY - i przeważnie tak jest.

Jeżeli powiedzmy mniej niż 20% rozmowy dotyczy bezpośrednio programowania, to raczej taka osoba nie interesuje się pisaniem kodu, a robi wszystko "byleby nie pisać".

po doświadczeniu w branży, wystarczy z kimś tylko pogadać i od razu widać, czy go to kręci, czy nie.

To praca dla pasjonatów - u których jakieś szczegółowe kawałki kodu potrafią wywołać emocje porównywalne u innych np. do oglądania meczu piłkarskiego.

0

Ja jestem takim słabym ogniwem i kiepsko ze mną.
W pracy koledzy są mili i nie dają mi tego odczuć, ale fakty są jakie są.
Póki co z braku lepszego wyjścia staram się niwelować braki w i po pracy, ale przepaść pomiędzy moim poziomem a poziomem kolegów jest ogromna.
Najgorsze jest to, że to moja 3. firma i łącznie mam 5 lat doświadczenia.

2

Czy mieliście takie doświadczenia, jak zmotywować takie słabsze ogniwa ?

Czy na pewno trzeba go motywować, czy może raczej popracować nad komunikacją międzyzespołową? Może nie przekazujecie mu jasno czego się od niego oczekuje? Może ta osoba nie posiada odpowiedniej wiedzy na temat projektu (warto wtedy posiedzieć i wytłumaczyć jak działają odpowiednie moduły)?

Możliwe też, że coś jest nie tak z projektem. Jakiej jakości jest kod, architektura, dokumentacja itp.? Czasem bywa tak, że osoby, które siedzą dłużej w jednym projekcie przyzwyczajają się do smrodku i nie widzą już, że pewne rzeczy w projekcie są nielogiczne czy zaplątane.

A osoba, która wchodzi w duży projekt na starcie zawsze chyba jest najsłabszym ogniwem, bo dopiero musi się "wdrożyć w projekt". Jednak jeśli wdrożenie ma być bezbolesne to najlepiej jakby jakość kodu była dobra, architektura dobrze zaprojektowana i istniała dokumentacja kluczowych rzeczy.

Jeśli jednak z jakichś powodów tak nie jest, to dla projektu najlepiej będzie chyba, żeby daną osobę od niego odsunąć (zwolnić albo przenieść do innego projektu), i NIE zatrudniać nowej, ponieważ z nową osobą może być dokładnie tak samo (ponieważ działa prawo Brooke'a - https://en.wikipedia.org/wiki/Brooks%E2%80%99_law ). Może po prostu nie potrzebny wam dodatkowy programista i szybciej zrobicie pracę bez niego.

Z drugiej strony jeśli z jakichś powodów zdecydowaliście się go zatrudnić, to może należałoby się zastanowić dlaczego - może ta osoba ma jakieś specyficzne skille, które moglibyście wykorzystać w innych projektach w firmie? Nie każdy jest dobry we wszystkim (ja np. sam byłem kiedyś takim najsłabszym ogniwem, bo zostałem zatrudniony wtedy jako programista JavaScript, a wylądowałem w końcu na klepaniu CSSów, i szło mi z tego powodu topornie).

. W dodatku jego rozkojarzenie jest dla mnie niedopuszczalne. Potrafi zapomnieć każdy element systemu i za każdym razem trzeba mu przypominać o prostych sprawach.

To akurat w 100% normalne. Też ciągle wszystko zapominam, i pewnie większość programistów tak ma (gdyby programiści wszyscy pamiętali, to nie potrzebne byłoby autocomplete czy inne podpowiedzi w IDE).

To co jednak możesz mu poradzić, żeby założył plik na dysku(ew. skorzystał z jakiegoś zintegrowanego systemu notatek) i tam zapisywał różne rzeczy związane z projektem. Najlepiej żeby to był format pliku umożliwiający wklejanie screenów. Wtedy jak czegoś zapomni, to spojrzy do pliku, zamiast ciągle latać do kogoś. Taki prosty tip, na który sam wpadłem jak próbowałem ogarnąć projekt do którego się wdrażałem. Wtedy nie musiałem wszystkiego pamiętać, a tylko patrzyłem do notatek.

2

z drugiej strony jak gościu nie jest namaszczony jako jego przełożony to po co ta szarpanina ?
jest to pewno jakiś eksperymentalny team juniorów i coś tam robią, po co spinać tyłek, tez nie chodzi aby latać z krzykiem po sali i robić 300% normy, a jak tamten jest zbyt słaby to i tak go zwolnią prędzej czy później lecz nie jest to rola autora wątku ...

0

Bardzo dziękuje za wszystkie odpowiedzi.

czysteskarpety napisał(a):

z drugiej strony jak gościu nie jest namaszczony jako jego przełożony to po co ta szarpanina ?
jest to pewno jakiś eksperymentalny team juniorów i coś tam robią, po co spinać tyłek, tez nie chodzi aby latać z krzykiem po sali i robić 300% normy, a jak tamten jest zbyt słaby to i tak go zwolnią prędzej czy później lecz nie jest to rola autora wątku ...

Rozumiem Twój punkt widzenia i po części masz rację. Nie jest to moja rola, jednakże milej jest mieć w zespole ludzi, którzy ogarniają. A nie musieć poprawiać, powtarzać coś kilkakrotnie - siłą rzeczy jest to po kolejnym razie frustrujące.

3

A może po prostu kolega ma jakieś problemy i jest zdekoncentrowany, długo to trwa?

0

@mariano901229 Nie powinieneś poprawiać po nim kodu. Niech sam to robi. Do skutku.

0

Najlepiej takowe zmienić

0
mariano901229 napisał(a):

Jednakże mamy w zespole odstające ogniwo. Kolega ma problemy z prostymi rzeczami. Co daje mu prostą rzecz do roboty to wszystko jest napisane na odwal się, w konsekwencji muszę poprawiać jego kod. Zacząłem mu dawać coraz mniejsze pierdoły do roboty, by nie musieć stać nad nim i mu tłumaczyć, ale no jest z tym słabo, bo i tak muszę mu podpowiedzieć jak to zrobić. Próbowałem programowania w parach i pisać z nim kod. W dodatku jego rozkojarzenie jest dla mnie niedopuszczalne. Potrafi zapomnieć każdy element systemu i za każdym razem trzeba mu przypominać o prostych sprawach. To trochę tak jak z przedszkolakiem co chwilę trzeba dopatrywać czy bawiąc się nie podpali całego domu.

Po pierwsze, porozmawiaj z nim. Ale nie w formie pretensji czy jakichś zarzutów. Umówcie się na piwo po pracy, albo usiądźcie sobie w pracy przy kawie lub herbacie i porozmawiajcie po przyjacielsku. Może ten człowiek ma jakiś problem? A może problem jest po Twojej stronie? Mogło być tak, że dałeś mu coś do zrobienia, ale nie wytłumaczyłeś dobrze o co Ci chodzi, kolega to zrobił tak jak zrozumiał i okazało się, że oczekiwałeś czegoś innego. Musiałeś poprawić to po nim i zacząłeś dawać mu pierdółki do robienia. A robienie pierdółek obniża motywację kolegi bo kto by chciał robić pierdoły i być niedoceniany? Z tego powodu kolega może tracić motywację, być rozkojarzony i mieć wszystko głęboko gdzieś.
Problemem u Was może być brak odpowiedniej komunikacji. Jeśli sam bierzesz na siebie najtrudniejsze rzeczy i przez to nie masz czasu żeby skomunikować się z kolegą i to sprawia, że on jest niedoinformowany i przez to niewłaściwie wykonuje swoją pracę, to jest to niewłaściwa droga. W takiej sytuacji nie powinieneś zajmować się liderowaniem bo robisz to źle. Lider powinien być przede wszystkim komunikatywną osobą i z chęcią komunikować się z innymi członkami zespołu, tak żeby nie było nieporozumień i później marnowania czasu na poprawienie po kimś bo ktoś coś źle zrozumiał. A jeśli dodatkowo winą za niekomunikatywność z Twojej strony obciążasz kolegę i z tego powodu nie stawiasz przed nim wyzwań, tylko dajesz mu same pierdoły to w ten sposób pozbawiasz go motywacji bo po co ma się rozwijać skoro i tak dostaje same pierdoły do roboty?

1 użytkowników online, w tym zalogowanych: 0, gości: 1