Z serii prawdy nieoczywiste ;-)
A wiesz, że jak masz w zespole developera, który pisze kodu więcej niż inni to jest duża szansa, że jest ten developer najmniej potrzebnym developerem? ;-)
W tej branży wszyscy lubimy pisać kod. Programiści, architekci, managerowie, nawet niektórzy PMowie.
Kodowanie jest fajne... ale sam fakt tego, że pisze się dużo kodu niczego nie dowodzi. Tzn. tak ma się lepszą technikę pisania, ale to tyle.
Jeśli w zespole jest ktoś kto pisze dużo kodu to często jest tak, że ten ktoś "pisze pod siebie", pisze dużo i inni muszą się do tego jakoś dopasowywać.
Większość ludzi chce współpracować i nie ma tendencji do przepisywania "cudzego kodu", więc próbują się dopasować. Mamy wtedy sprzężenie zwrotne. X pisze na początku dużo kodu, narzuca swój styl, który jest "dziwny", inni próbują się przystosować więc piszą wolniej... a X pisze jeszcze więcej i szybciej.
Widziałem to 2 razy i 2 razy nie było to dobre. Reszta teamu się robiła smutna, byli sfrustrowani, zniechęceni, ale nie do końca wiedzieli czemu.
Oczywiście to nie jest tak, że każdy taki przypadek jest zły.... ale zwykle o czymś mówi.
Jak masz zespół nierówny bo kogoś z dużym doświadczeniem i reszta ludzi jest młoda to to jest możliwe, i usunięcie tej osoby nie przejdzie bez problemów.... ale lepiej takiego kogoś zachęcić do oddania części pracy, bo inni będą mogli urosnąć, a ten ktoś zajmie się większymi rzeczami.
Jednak jak masz zespół, który jest w miarę równy jeśli chodzi o lata doświadczenia i nie ma tam jednej osoby, która wyraźnie odstaje umiejętnościami na plus, to masz duże szanse na problem.
To nie jest wina tej osoby, pewnie team nie jest dopasowany. W dopasowanym teamie ludzie sobie patrzą na ręce i sobie pomagają. Jak ktoś się obsuwa to mu pomagają, jak ktoś umie coś nowego to uczy innych. Jak team jest niedopasowany to osoba, która ma najmniejsze opory przed pisaniem kodu (czyli jest najmniej podatny na bycie perfekcjonistą (w tej branży chyba wszyscy mają problem, tylko różni się intensywnością ;-)) zaczyna pisać tego kodu więcej, jeśli reszta teamu jest taka bardziej w trybie follow niż lead to się nie stawiają...
Tu się przydaje radical candor, idealnie w wersji "Hej X, daj się innym bawić", też dobrze w wersji "X, weź k... zostaw ten kod i daj nam coś napisać, bo znów spartolisz"... niestety często jest mówienie managerowi "nie ma ticketów, bo X bierze".... albo jeszcze gorzej zamknięcie się w sobie.
Dodajmy do tego nietechnicznego PO, który chce szybko zbudować produkt i problem się będzie nakręcał... aż X się znudzi i postanowi sobie poodpoczywać i wtedy spada wydajność całego zespołu, bo inni się przyzwyczajali do wyjadanie resztek po X.... X nic nie je i jest problem.
Stąd ja zawsze próbuję zrobić test ważności przez "a co będzie jeśli Y zniknie z zespołu". I ten test dziwnie często potrafi wskazać, że osoba pisząca najwięcej kodu swoim zniknięciem może zrobić nawet więcej dobrego bo w jej miejsce wskoczą inne osoby.. To widać np. jak X jest na urlopie i nagle za kodowanie biorą się inni ludzie i fajnie to wychodzi.
Podobne postybeta
Nie lenistwo, a strach. Prawdziwe źródło długu technicznego
Kiedy zmieniać pracę i po co? (w IT)
Kwietniowe książki
Głosowanie korespondencyjne jest tak dziurawe, że aż szkoda gadać - z perspektywy IT
Nie lejmy betonu na kod....
Brak komentarzy:
Prześlij komentarz