Hej
Zdarzało wam się pracować w nocy lub w trybie "ma być zrobione na już" szczególnie przy utrzymaniu jakiś systemów?
Pamiętam, że czasami zdarzały mi się takie akcje i na dłuższą metę odbija się to negatywnie na zdrowiu.
Teoretycznie dostępność 24/7/365 doprowadza to do tego, że system który utrzymujemy jest od nas zależny i niezależnie co się stanie trzeba usiąść i pracować.
Jakie są wasze doświadczenia?
Uciekać, też tak miałem, myślałem, że beze mnie się zawali.
Noi się zawaiło.
Ale co mi tam, w nowej pracy jest spokój, porządek i luz ;)
Na krótką średnią i dłuższą metę nie ma absolutnie sensu pracować w takich firmach. To jest sygnał tego że firma nie inwestuje odpowiednio w utrzymanie produkcyjne systemów - redundancję, monitoring, deploymenty, kontrolę jakości. Takie akcje prawie niczego cię nie nauczą, nie wpłyną pozytywnie na twoją karierę, nie zostaną docenione przez nikogo.
@devRandom: praktycznie same posty w kariera, jesteś z HR?
Pracowałem tak kilka miesięcy, nigdy wiecej za żadną kase. Kazdy tego typu dzien (niezależnie czy jest interwencja czy nie) odbija sie negatywnie na zdrowiu.
Utrzymanie 24/7 jakichkolwiek systemów powinno być robione modelem follow the sun jeżeli firma każe ci siedzieć po nocy to znaczy że stara się oszczędzać jak tylko się da, a to nie jest dobry sygnał :)
@Marcin Marcin też mam większość postów w kariera, a z HRów nie jestem to odpowiadać nie mogę? (:
jeżeli to jest praca przymusowa a ie dobrowolna to się odbije na zdrowiu, także zdrowiu systemu. Jeżeli sama siedzę po nocy jak ostatnio to rano jeszcze raz przeglądam czy to co napisałam ma sens
Wiadomo, że są systemy używane w firmach 24h/dobę 7dni w tygodniu i bez wsparcia przynajmniej I linii wsparcia się nie obejdzie. Często gęsto programistę się budzi jak nie daje się tego rozwiązać systemowo, jednak to powinny być sytuacja WYJĄTKOWE a nie reguła.
Dodatkowo po każdym takim incydencie powinna być robiona taka retrospektywa aby drugi raz już z tego powodu pożaru nie było.
Kolejna sprawa, to że powinna być jakaś rotacja wśród załogi, który utrzymuje dany system aby w razie problemów z rozwiązaniem go na I linii wsparcia ciągle nie budzić tej samej osoby.
Dalej. Za takie wsparcie powinna być dodatkowa kasa.
@Marcin Marcin jeżeli pracujesz tak na dłuższą metę i wezwania masz często to może pomyśl o zmianie pracy albo pogadaj o podwyżce lub przeniesieniu tych obowiązków na kogoś innego?
PS Nie, nie jestem z HR :D ;)
Jeśli już miałem takie sytuacje przy utrzymaniu, to były konkretne zadania do zrobienia. Nie musiałem ślęczeć nad nimi ani w środku nocy ani po kilka godzin. Ważne, żebym serwery testowe robił po szesnastej a produkcyjne w weekend. Napisałem automat do takich spraw. Ustawiałem na konkretną godzinę a potem sprawdzałem czy jest ok. Parę razy gasiłem pożary, ale zawsze wtedy byłem w domu. Wystarczyło klepnąć parę poleceń.
Nigdy nie pracowałem na zmiany i nie zamierzam. Praca zmianowa to zło. Pożary, czyli sytuacje wymagające reakcji w nocy to rzadkość nawet, jeśli jest się adminem. Nie dość, że pożary wybuchają rzadko, to jest się jednym z kilku adminów. Kolejka na dyżury wypada może raz na miesiąc. Jeśli coś miałoby wybuchnąć podczas mojego dyżuru, to może dwa razy do roku z rozwiązaniem na zasadzie: wyłącz, włącz.
Zasada jest bardzo prosta -> Regularna praca ponad normę (wymóg) = Natychmiastowa decyzja o zmianie pracy.
Szczerze mówiąc nawet dobrowolna praca ponad normę powinna przez kogoś być zauważona i ukrócona. Kilka argumentów za tym:
Jeśli ktoś z zewnątrz to zauważy to też nie wygląda to dobrze dla leada/managera:
Oczywiście pracoholika trudno oduczyć i znajdą się tacy którzy będą zadowoleni że velocity się zwiększa, ale mimo wszystko to raczej chora sytuacja.
Utrzymanie, w szczególności on-call 24h potrafi wykończyć niejednego. Nie zgadzaj się na to za żadną cenę, twoje zdrowie nie jest tego warte. Byłem widziałem, dostałem po D, nie polecam.
W firmach gdzie pracowalismy dla USA zdarzały się takie klimaty, ale ja sam nigdy się na to nie pisałem. Bardzo nie lubię pracować pod presją fackupu na produkcji plus jak nie jestem w łóżku o 22 to potem kolejny dzień to u mnie tragedia.
Zazwyczaj znajdowali się chętni za dodatkową kasę bo awarie były żadkie i kasa była za gotowość, ale dla mnie są świadomość, że jestem na czujce to już kłopot i wolałem sobie po pracy odpocząć.
W kolejnych firmach to juz raczej incydenty typu deploy nowego systemu w weekend aby uniknąć przestojów w pracy, jakieś korpo planowanie z USA przez pół nocy etc. Z takimi rzeczami nie mam kłopotu. Nadgodziny od czasu do czasu też mi nie przeszkadzają pod warunkiem, że nikt tego nie wymusza.
No i nie było nic takiego jak support ani nic, w sensie dedykowanych ludzi do tego. Tylko jako ludzie programiści w myśl naszego managera powinniśmy być odpowiedzialni za aplikację e2e no bo to my najlepiej w sumie wiemy jak naprawić coś, wyprowadzić hot-fixa. W ciągu tygodnia rotowalismy po 1-2 razy w tygodniu między sobą nocki. Dodam także że pracowaliśmy na b2b i tam dodano nam w Januszexie jakieś SLA na update buga w jakimś tam okreslonym czasie i oczywiście jakieś kary finansowe za opóźnienie, nie pamiętam ile godzin to było i informowanie na bieżąco o statusie hot-fixa.
Dodam także że ten system był pisany przez ludzi w tzw. crunchu Sprintów i wszystko tam było tak podrutowane że głowa mała. Więc stabilność tej aplikacji była zerowa.
Na początku z nerwów miałem tak że nie spałem całe noce ze stresu i koledzy również. Potem doszło to że zacząłem pić. Ale no stwierdziłem że nie dam rady tak dłużej i się zwolniłem i zarazem przestałem pić. Serio mowie. Teraz się cieszę z tej decyzji, chociaż parę osób dalej tak robi.
devRandom napisał(a):
Szczerze mówiąc nawet dobrowolna praca ponad normę powinna przez kogoś być zauważona i ukrócona. Kilka argumentów za tym:
- niektórzy developerzy, zwłaszcza tacy którzy mają mniej doświadczenia, mogą odebrać to jako sygnał że oni też powinni pracować więcej
- ta jedna osoba może tworzyć nierealistyczne oczekiwania odnośnie czasu realizacji zadań
- tego typu praca może wskazywać że nadgodzinowiec sobie nie radzi, próbuje wyrobić "normę" (często wymyśloną przez nich samych) poza godzinami
- po jakimś czasie efektywność zacznie spadać, prawdopodobnie spadnie jakość rozwiązań (patrz wyżej: ktoś rano sprawdza czy kod który napisali w nocy ma sens), ostatecznie pewnie dojdzie do wypalenia
Jeśli ktoś z zewnątrz to zauważy to też nie wygląda to dobrze dla leada/managera:
- jeśli ktoś sobie nie radzi, to proces rekrutacji był nieodpowiedni, osoba nie dostała wystarczającego wsparcia przy onboardingu
- zespół akceptuje więcej pracy niż jest w stanie dowieźć, lead nie powinien do tego dopuścić
- projekt jest słabo zarządzany
- lead bawi się w project managera i daje nierealistyczne wymagania
Oczywiście pracoholika trudno oduczyć i znajdą się tacy którzy będą zadowoleni że velocity się zwiększa, ale mimo wszystko to raczej chora sytuacja.
To akurat w przeciągu ostatnich dwóch lat zdarza mi się notorycznie. (odkąd weszła praca zdalna)
Zazwyczaj niestety, jest tak, że managerowie przymykają na to oko, a czasem wręcz faworyzują te osoby. W aktualnym zespole mam znowu osobę która robi darmowe nadgodziny, i to programista z 6 letnim doświadczeniem. Osobnik bez rodziny, dzieci (z pasją programowania??). Gość ma cały czas laptop w pokoju, bo praca zdalna no i robi non stop bez opamiętania. Tutaj ktoś może pomyśleć, że ma takie godziny pracy, ale nie mogę się z tym zgodzić bo osobnik jest z nami na Daily o 10.30, a potem w ciągu dnia udziela się na Teams, widać commity no i potem na Teams świeci się na zielono do późnych wieczorów. W Sprintach realizuje po 12-17 Story Pointów jak normę mamy koło 8 na dwa tygodnie. Ja też już pracuję 4 lata i mniej więcej widzę ile w stanie sam jestem zrobić oraz mam mniej więcej wykalibrowane ile kodu inni są w stanie naprodukować w ciągu paru dni.
Jeżeli jest np. jakaś nowa technologia w zespole to ja mówię że potrzebuję dnia, czasem nawet paru dni na przerobienie tutoriali, bo po czasie pracy spędzam czas z rodziną i nie mam czasu się dokształcać w ramach pracy po pracy za darmo...
A ten gość np. ma takie podejście że potrafi pro-bono przesiedzieć cały weekend nad czymś i w poniedziałek coś zrobić, we wtorek. No wszystko spoko, ale odbija się to tym, że w zespole zaczyna mimowolnie robić się toksyczna atmosfera zapierd.... Velocity idzie w górę, ta osoba zaniża Story Pointy w Scrum Pokerze i czasem na Daily mnie już coś trafa, że mam ochotę powiedzieć że dałem więcej bo nie robię darmowych nadgodzin, ale brak mi tej asertywności :( Tak samo ze zwykłymi taskami, staram się pracować po 8h dziennie i kończyć, idę odbierać dziecko z przedszkola, potem mam życie prywatne. A ten gość siedzi za darmo np. do 18-19stej w dzień dzień, bez umiaru. Wczoraj niby mieliśmy wolne 11 listopada a gość potrafił review robić i wystawić Pull Requesta. Jak takie coś zgłaszać HR'om w dobie pracy zdalnej? Jak z tym walczyć?
Najgorsze jest to, że Team Leader to widzą, manager tak samo, ale każdy udaje że nic się nie dzieje i wszystko jest OK. Jest to jeden z powodów dla którego znowu myślę zmienić pracę.
Jakieś on-calle przy utrzymywaniu systemów się zdarzały, dobrze wspominam. Płacili dodatkowo, a nikt i tak nie dzwonił, bo klient zapomniał wdrożyć sobie systemu na produkcję.
Czy można się czegoś nauczyć pracując tak w trybie 24/7/365 i rozwiązując na czas bugi pod presją czasu?
Czy to zły sposób nauki i lepiej programować spokojnie?
Owszem, można:
Pracowałem tak przez rok, mając ~tydzień dyżuru w miesiącu. Jest to dość upierdliwe, bo trzeba być w pobliżu komputera. Powiadomienia leciały u mnie głównie z automatycznego monitoringu. W moim przypadku było jeszcze w miarę ok, bo ustawiliśmy sobie 12 godzinne szychty, w porozumieniu z zespołem w stanach, więc większość tego dyżuru wypadała w normalnych godzinach pracy i nie było budzenia jakimiś bzdurnymi komunikatami w środku nocy. Dało się z tym żyć, ale mimo wszystko dawało to momentami popalić.
Albo wiedziałeś na co się piszesz podpisując nową umowę, albo jest to dobra okazja do wynegocjowania stawki, a jak się nie da, to na rynku jest trochę firm, które szukają ludzi...