Szybkie wypalenie po przejęciu małego zespołu.

0

Hej,
Mam taki problem. W firmie dla której pracuje szło mi dobrze więc w nagrodę otrzymałem 2 osobowy zespół i zarządzanie. Problem w tym, że to mnie strasznie dobiło. Na początku było spoko, ale teraz czuje, że utknąłem w miejscu. Jedna osoba ogarnia a po drugiej muszę wszystko poprawiać - i to jest strasznie dobijające. Musze jej wszystko tłumaczyć i prowadzić za rączkę (niby osoba z kilku letnim doświadczeniem). Zgłaszałem to wyżej, ale zawsze otrzymuje "poczekajmy jeszcze"... najgorsze jest to, że to jakaś osoba po znajomości (którego z szefów). Wiele rzeczy muszę robić za nią, Przez 2 dni pracowałem po 12h a wczoraj byłem tak wypalony, że nic nie zrobiłem. Nie bardzo wiem jak sobie poradzić. Ktoś był w podobnej sytuacji? Co zrobić? Stack fajny, kasa fajna ale ta sytuacja mnie dobija.

13

Nie siedź po 12 godzin, jeśli nie ma pożaru - najczęściej nie ma. Poczytaj mikrobloga @p_agon . Też mówił górze, że są problemy, starał się jak mógł, a góra tego nawet nie zauważyła.
Można porozmawiać z gościem, powiedzieć, że słabo mu idzie, i podrzucić linki do kursów albo książek. Albo po prostu spytać czy ma z czymś problem i czy możesz mu pomóc. Czasem ktoś może mieć gorszy czas i nie załapać, że coś nie gra. Naprawdę. Może jak się rozgada, to powie o czymś, czego nie wiesz. Uprzedzam, nie jest to łatwe. Komunikacja nie jest łatwa, bo język, którym się posługujemy, powstał w ciemnych czasach i tworzyli go prości ludzie.
Pamiętaj, że to Ty chcesz coś zmienić a pozostałym może być wszystko jedno (nie wiadomo do końca). Jeśli kolejne próby nie przyniosą skutku, można pomyśleć o zmianie pracy. Może się trafić praca za mniejszą kasę, ale fajniejsza. Z drugiej strony jeśli za wszelką cenę będziesz cisnąć jak najwięcej kasy, to będziesz musiał tę kasę wydać na psychologa, psychiatrę, lekarza itp. A i tak nie rozwiążesz problemu do końca, bo straconego czasu nie da się cofnąć.

6

Jeszcze pytanie co znaczy, że musisz wszytko poprawiać? To co robi nie działa w ogóle? Nie macie CR? Może problem też leży w tym jak pracę organizujesz? Pamiętaj Ty też się musisz nauczyć organizować pracę i delegować zadania.

6

w nagrodę otrzymałem 2 osobowy zespół i zarządzanie

xD

muszę wszystko poprawiać

Nie rozumiem. Robisz code review, piszesz co jest nie tak i niech poprawia i tak do skutku, bo inaczej się nie nauczy.

Zgłaszałem to wyżej, ale zawsze otrzymuje "poczekajmy jeszcze"

Bo nie da się kogoś ot tak zwolnić. Trzeba najpierw robic różne cyrki, "programy naprawcze" itd, stąd nikomu nie chce się w to bawić.

Inna opcja to ewakuacja, bo nie warto kopać się z koniem :)

3

Jest też jeszcze jena opcja, powiedz że się nie wyrabiacie i dorekrutuj sobie jeszczę jedną nową osobę - ale rekrtuj już sam, kogo sobie dobierzesz tego będziesz miał. Pewnie będzie opór przed zatrudnieniem nowego "kosztu" ale inaczej się nie da. Generalnie nie siedź po 12h, to szkodzi twojemu zdrowiu, żadna pensja raka nie wynagrodzi.

5

Siedź 8h i jak ktoś Cię zapyta dlaczego wynik jest taki jaki jest, powiedz wprost. Masz dwie osoby, z czego jedna nie ogarnia. Ty już wcześniej brak ogarnięcia zakomunikowałeś. To już nie leży po Twojej stronie. Nikt tych 12h dziennie nie doceni, a życie jest jedno. Staraj się naprostować sytuację tylko w ciągu tych 8h. Oczywiście o ile te 8h to jest dość efektywny czas

2

Pójdź po podwyżkę za ciężkie warunki pracy :P

3

I żeby było jasne. Nie ma idealnego programisty, każdy popełnia błędy, każdy ma jakieś braki. Ja też idealny nie jestem. Tylko jeśli ktoś jest jako mid/senior i 60% jego kodu to switch case albo if + duże tasiemce to coś chyba jest nie tak ?

3
zjadek1991 napisał(a):

Nie ma idealnego programisty

Helloł, ja to wszystko widzę!

Tylko jeśli ktoś jest jako mid/senior i 60% jego kodu to switch case albo if + duże tasiemce to coś chyba jest nie tak ?

Nie, to jest jak najbardziej normalna sytuacja. Większość ludzi po prostu nie zna płynnie języka, nie zna wzorców projektowych, nie rozumie abstrakcji (słynne "interfejsy to abstrakcje") skutkiem czego nie potrafi dzielić i organizować kodu.
Ludzie na ogół skupiają się na poznaniu technologii i pisaniu w niej proceduralnych tasiemców.

1
zjadek1991 napisał(a):

I żeby było jasne. Nie ma idealnego programisty, każdy popełnia błędy, każdy ma jakieś braki. Ja też idealny nie jestem. Tylko jeśli ktoś jest jako mid/senior i 60% jego kodu to switch case albo if + duże tasiemce to coś chyba jest nie tak ?

Jasne, nikt nie wymaga bycia ideałem. Zawsze możesz spisać wytyczne odnośnie projektu i pokazać górze, żeby wiedzieli do czego to zmierza. Jak niby możesz czegoś wymagać, skoro ktoś pewnie w ogóle nie wie co jest wymagane? Wtedy rozmawiasz z podwładnym i mówisz mu, że lepiej trzymać się wytycznych - albo chociaż ich części - żeby dotrzymywać terminów i nie mieć nad głową dyrekcji. Jeśli dostanie plan minimum, to będziesz miał na papierze, że dowiózł X rzeczy a powinien Y.

4

Jeśli mogę dołożyć swoje 3 groszę...
Umiejętność zarządzania jest taką samą umiejętnością jak każda inna. Wymaga wielu lat ćwiczeń i praktyki w styczności z wieloma ciekawymi elementami ludzkimi. Tutaj masz dwie osoby, wyobraź sobie co się dzieje przy 10 i więcej. Jeśli będziesz kontynuował tą ścieżkę to na pewno spotkasz, super ogarniętych buraków, zdolnych leniów, takich którzy robią dobrze jak im się nad głową stoi i takich którzy potrzebują bata nad sobą. Potrakuj ten przypadek jako możliwość zdobywania doświadczenia z elementem ludzkim.

Oraz jak tu wielu już wspomniało nie rób za nikogo pracy, nie jesteś męczennikiem który będzie te krzyż miał sam nosić. Zrób z nim może cotygodniowe checkiny albo codzienne. Jasno określaj zadania i dawaj mu ciągły feedback. Czasem może się zdażyć świeży pasjonat który będzie siedział w domu, czytał kształcił się i wiele robił w swoim prywatnym wolnym czasie ale... raczej nie często. Gro ludzi traktuje to jako pracę, przyjść zrobić swoje i wyjść. Do każdego trzeba mieć inne podejścia.

Nie ma większego bagdna jak zarządzanie ludźmi :D, powodzenia!

3

@zjadek1991

Głupio to zabrzmi, ale zacznij się nosić eleganckie ubrania, zegarek, pójdź do lepszego fryzjera, zacznij uprawiać sport, zacznij dbać o siebie. Odstaw kod na jakiś czas!

Buduj wewnętrzny spokój, buduj dobre relacje ze wszystkimi ludźmi.

ZAKODUJ SOBIE: Twoim celem już nie jest kod, techniczne problemy, abstrakcje i tego typu sprawy. Nie teraz. Teraz liczą się ludzie więc zamiast ich gasić, dąż do tego, aby uwolnić ich w nich potencjał.

Zrozum, że jeśli na 9 sytuacji jesteś więcej niz w porządku, a tylko raz puszczą Ci nerwy to właśnie wtedy wszystko psujesz i przekreślasz. Człowiek, który jest pod Tobą nie będzie się angażowł w 100% tak jakby mógł przy kimś innym. Jak stracisz dobre relacje z ludźmi to zostanie Ci tylko dryfowanie, bo sam za nich przecież wszystkiego nie zrobisz.

Pomyśl przez chwilę czy Amerykanin / Brytyjczyk angazowałby się w takie sprawy? Czy poprawiałby ifologię po kimś? Czy w ogóle patrzyłby do kodu? Czy próbowałby wchodzić w dyskusje jeśli ona nie ma dobrego zakończenia. Nie rób z siebie kozła tylko wykorzystaj sytuacje jaka się do Ciebie uśmiecha. Doceń to jak masz, bo kiedyś mogą odwrócić się te role i będziesz narzekał, że ktoś słaby techcznie zarządza projektem.

Jeśli stan techniczny kodu Ci nie leży to nie mów o tym, spróbuj zachować to dla siebie. Poczekaj trochę, obserwuj sytuację, zobacz jak zespołowi się pracuje nad projektem. Czy ktoś zgłasza jakieś problemy? Czy ludzie się dogadują miedzy sobą? Może być tak, że tylko Ty widzisz problemy, których nie dostrzega Twoja ekipa, ale jeśli oni idą do przodu to nie psuj im tego. Poczekaj, aż pojawi się problem, być może będzie to ten sam problem jaki wcześniej zobaczyłeś. Będziesz wtedy na to przygotowany i jeśli zespół będzie potrzebował pomocy to pomóż, buduj swoją reputację. Natomiast jak pojawią sie napięcia to bądź sędzią, wykorzystaj wiedzę i doświadczenie, by fachowo rozwiąząć spory na programistycznej płaszczyźnie.

Jeśli nie możesz się powstrzymać i jeśli coś Ci się nie podoba w kodzie. To nie używaj argumentu w postaci best practices, a skup się, by druga strona po prostu zauwazyła problem. Najlepiej jeśli ten problem dotyczy aktualnych potrzeb, a nie jeśli jest czymś co może kiedyś się wydarzy. Mów o problemach, nie dawaj rozwiązań, daj ludziom przestrzeń, by mogli chwilę pomyśleć i się zaangażować.

Jeśli uważasz, że źle się dzieje w projekcie, bo ludzie słabi. To po prostu reaguj na problemy. Zamiat koncentrować się na jednostce zacznij wprowadzać ograniczenia, jakieś zasady, automaty itp wszystko byleby ludzie włożyli w pracę większy wysiłek i żeby szansa na pojawienie się poprzedniego błędu była jak najmniejsza.

Jako kierownik poza tym masz mniej czasu na kodowanie, więc uważaj z progarmowaniem jeśli musisz coś robić. Pozwól, aby inni też Twój kod przeglądali, nie ignoruj uwag, nie odpuszczaj sobie w czasie pracy, bo jeśli zacznisz sobie pod jakimś względem luzować to inni zobaczą, że nie jesteś fair i, że wyznaczasz reguły do których sam się nawet nie stosujesz.

Reasumując:

Jesli Twoim zdaniem zespół jaki masz jest slaby i jeśli nie możesz za bardzo na to wpłynąć (zwolnić) lub zmienić go od środka (uwolnić potencjał, dać do myślenia, porozmawiać, zmotywować itp) to idź w zasady i procedury, nie ma sensu się użerać. Jeśli nie jesteś decyzyjną osobą to nie angażuj emocjonalnie, po prostu zbieraj fakty (raporty, rzeczy mierzalne), jesteś wtedy tylko pomostem między zarządem, a zespołem. Przedstaw zarządowi to co powinien widzieć i niech to oni podejmują decyzje. Przedstaw zespołowi jak wygląda sytuacja i niech zespół też spróbuje chwilę nad tym pomyśleć.

5

Klasyczny problem w IT, gdzie programista zostaje kierownikiem na niby - bez prawa zwalniania.
Komiks z roku 1995: https://dilbert.com/strip/1995-01-23

To, że zaczynasz od próby pozbycia się kolegi, sprawia że management widzi cię jako niedoświadczonego na pozycji kierownika. Nie ma znaczenia, że najprawdopodobniej masz rację.
Ja mimo 15 lat doświadczenia jeszcze nie spotkałem się z przypadkiem programisty, który został zwolniony za słabą wydajność/jakość pracy (pomijam przypadki totalnej wtopy w procesie rekrutacji) W twojej sytuacji dochodzą jeszcze plecy.
Pozbycie się podwładnego to ciężka praca. Może lepiej po prostu nie dawać mu istotnych zadań i nie nominować do podwyżek. Sam odejdzie.

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