Czy "crunch" i nadgodziny to norma w IT?

Witam wszystkich.

Postanowiłem założyć konto i zapytać się o parę rzeczy, ponieważ mam w korporacji kolejny okres gdzie za 2 miesiące wchodzimy na produkcję. Project Manager oraz Scrum Master na daily zaczynają być coraz bardziej nerwowi, a manager nawet ostatnio podniósł głos "ale to przecież nie jest takie trudne do zrobienia?".
Zapanowała niezręczna cisza, potem rozłączyliśmy się i robiliśmy swoje. Przez takie podświadome naciski widzę, że w projekcie zaczyna się robić ciśnienie, gdzie przestajemy siedzieć po 8h dziennie, a koleżanka np. siedziała dziś aby dokończyć taska, widziałem commity na gitlabie :(

Jasne, aktualnie jest "rynek pracownika" ale to nie zmienia faktu, że do dobrych firm wciąż się ciężko dostać etat, bo stos CV chętnych osób jest duży.
Dochodzi stres, że w razie postawienia się managerowi można dostać wypowiedzenie, zepsuć relacje, gdzie każdy udaje że jest fajnie :(
To już moja kolejna (4) firma w Javie (warszawa) w której odczuwam presję, momenty gdzie pracuję nieraz po 10h dziennie, bo np, pisanie taska zajęło 6-7h, ale np. z mavenem coś się pochrzaniło, a człowiek musi skończyć na tzw. "już" i zaczynają się nadgodziny.
Dziewczyna z którą żyję powiedziała mi, że to chyba uroki tej branży, że nie mogę mieć tak że pracuję tyle ile mam w umowie o pracę, czyli 160h. Znajomy dyrektor departamentu w IT, zaczynał programować w 94 powiedział mi, że crunch, ciśnienie, Sprinty to norma w IT oraz finansówce, że albo się nauczę z tym żyć albo aby zmienić zawód. Było to dla mnie zderzenie trochę głową w mur. Czy faktycznie praca w korpo, sprinty, scrumy zawsze za tym gdzieś kryje się podświadome ciśnienie?

Czy próby przebranżowienia się na docelową specjalizację gdzie nie ma takich rzeczy np. administratorka (jak się ustawi coś to działa, jak nie to nie) jest dobrym pomysłem? Czy myśli o pójściu w DevOps gdzie jeszcze nie jest się zaprzęgniętym do Sprintu są jakąś alternatywą? Boję się, że trochę pomieszały mi się priorytety w życiu, bo dawniej byłem zadowolony, że się rozwijam, że nowe technologie, nadgodziny brałem z pocałowaniem ręki, ale ile tak można....

Maciek.

1. Nie jest normalne. Jasne, moze się czasem zdarzyć jakiś pożar na produkcji ale to jest sytuacja wyjątkowa a nie jakaś norma klepania nadgodzin. Jak się nie wyrabiacie to trzeba zmniejszyć scope albo powiększyć zespół albo przesunąć release. Zresztą dlatego też popularne są wszelkie zwinne metodyki prowadzenia projektu, bo w praktyce ciężko planować w dłuższej perspektywie niż następnie 2-3 tygodnie.
2. To problem managerów jeśli źle wyestymowali projekt, nie problem developerów. Niektórzy będą próbowali zrzucić winę na was, ale koniec końców managerom właśnie za to płacą, żeby zajmowali się estymowaniem projektu i analizą ryzyka. To gość którzy zarabia kilka razy więcej od ciebie podpisał się pod tym że dostarczycie ficzery XYZ do konkretnej daty i za to mu właśnie płacą, żeby poprawnie przewidywał.
3. Nie brzmi to jak dobra firma.

Zawsze jak czytam te tematy (zresztą połowę tematów na 4p) to zastanawiam się czy ja żyję w jakiejś alternatywnej rzeczywistości gdzie trawa jest zieleńsza.

Jedyne co potrzebujesz to znalezienie firmy w której pracują ludzie którzy się szanują (uwaga - nie cię, a się) - jak nie wyrobicie się w terminie to albo przesuwacie release albo obcinacie scope. Jak ktoś wam wisi nad głową to powiedzcie że jak chce to niech sobie sam zaimplementuje. Jak dacie się zaprząc do orki w polu to się nie dziwcie że traktują was jak bydło.

Jeśli pójdziesz w devops to zgadnij kto będzie na oncallu, i dlaczego zespoły operacyjne używają kanbana zamiast scruma.

Nadgodziny albo praca w nietypowych godzinach czasem mają miejsce, ale dotyczy to pożarów albo wdrożenia na produkcję. Z tym, że pożary zdarzają się bardzo rzadko a wdrożenie na produkcję to sprawa paru godzin w miesiącu. O wdrożeniach ludzie często są informowani przed pracą albo podczas okresu próbnego. Może to wyglądać tak, że osoba odpowiedzialna za wdrożenie przychodzi do pracy tak, żeby zostać po szesnastej i klepnąć zadanie w Jenkinsie.
W firmie leży zarządzanie, estymacja albo jedno i drugie. A teksty dyrektora, że trzeba robić szybko, to normalna gadka dyrektorów. Oni zawsze cisną. Można nawet powiedzieć, że dyrektorowi trzeba podawać dłuższy, niż trzeba, czas realizacji projektu, żeby z tryumfalnym tonem mógł ten czas skrócić. Np. powiedzieć mu 30 dni + 15 zapasu, to skróci o ten czas o 10 dni, więc zostanie 5 :) . Trochę to żartobliwe, ale z dyrektorem trzeba umieć rozmawiać.

ładujw skille tyle ze poznasz swoja wartosc na rynku, jak zaczna ludzie sie do ciebie zglaszac z pytaniami jak cos dziala i z prosbami o wytlumaczenie to poznasz wartosc swoja i nie bedziesz siedziec po godzinach, nawet nie beda tego tobie sugerowac, o ile maja minimum ogarki

1. To jest normalne w polskich firmach gdzie panuje kultura folwarczna i skąpstwo budżetowe.
2. Manager ma dwie opcje - albo staje po stronie developerów i ciśnie wyżej że potrzeba więcej czasu i pieniędzy albo jest tchórzem i ciśnie developerów. Marni managerowie myślą że ich rolą jest poganianie ludzi, poza tym boją się nawet wspomnieć że coś w projekcie może być nie tak. Wyższy management często może się łatwo zgodzić na przesunięcie terminów, ale wtedy manager boi się że straci twarz więc woli udawać że wszystko jest OK.

Pytanie do OP'a czy macie przynajmniej płacone ze te "nadgodziny"?

Problem w tym że jeśli człowiek daje sobą pomiatać to nim pomiatają. Jak wspomniał Shalom, to nie twój problem że ktoś źle wyliczył ile czasu zajmie dowiezienie projektu. Po prostu robisz 8h i tyle.

maciek_rz napisał(a):

Jasne, aktualnie jest "rynek pracownika" ale to nie zmienia faktu, że do dobrych firm wciąż się ciężko dostać etat, bo stos CV chętnych osób jest duży.

Wchodzę dziś na money.pl i widzę to:
https://www.money.pl/gospodarka/w-it-potrzeba-100-tys-pracownikow-na-juz-bialorus-ma-swietnych-fachowcow-6639226632370305v.html

maciek_rz napisał(a):

Project Manager oraz Scrum Master na daily zaczynają być coraz bardziej nerwowi, a manager nawet ostatnio podniósł głos "ale to przecież nie jest takie trudne do zrobienia?".

Z tego wynika że góra jest przyparta do muru, na pewno zwalnianie pracowników w takim momencie nie będzie dobrym ruchem z ich strony.

Aczkolwiek, nie wiem czy praca w takiej atmosferze "metodyka pan-niewolnik" jest warta świeczki, długotrwały stres może negatywnie odbić się na twoim zdrowiu w przyszłości.

@The Pontiff:

Manager ma dwie opcje - albo staje po stronie developerów i ciśnie wyżej że potrzeba więcej czasu i pieniędzy albo jest tchórzem i ciśnie developerów. Marni managerowie myślą że ich rolą jest poganianie ludzi, poza tym boją się nawet wspomnieć że coś w projekcie może być nie tak. Wyższy management często może się łatwo zgodzić na przesunięcie terminów, ale wtedy manager boi się że straci twarz więc woli udawać że wszystko jest OK.

O to to. Wspomniałem o tym chyba w innym temacie, że jeżeli zamiast managera mamy handlowca, to i zarządzanie będzie kiepskie, bo taki handlowiec będzie dbał o swoją dolę ;] i cisną zespół.

Ogólnie manager/po lider projektu ma za zadanie tak przygotowywać wkład (wymagania) aby był zrozumiały dla zespołu, ma tak organizować spotkania aby jak najmniej one rozwalały dzień zespołowi i na końcu ma dbać o to aby wiaderko z rzeczami które trzeba zrobić zawsze miało ich tyle aby dało się je zrobić.

Wyższy mangament często jest odrealniony i odsunięty od zespołów. Nie zna realiów i jedyną osobą która im to tłumaczy to właśnie manager zespołu. Jeżeli mamy tam handlowca a nie managera, to będzie patologia.

Regularne siedzenie po godzinach (np. 18 lat temu w Accenture) to patologia i to niezaleznie od powodu czy dziedziny.

W bankowosci i ogolnie finansach jest robota luzna i nudna. Chyba ze trafiasz do jakiejs maszynki autotradingowej gdzie licza sie ns.

To ze ktos siedzi o 23 w niedziele nad kodem nie powinno Cie interesowac. Byc moze ta osoba musiala w tygodniu wyjsc na pare godzin i odrabia. Wyciaganie takich faktow moze tej osobie zaszkodzic.

Normalny, odpowiedzialny programista posiedzi czasem 2-3h dluzej jesli realese jest zblokowany przez NPE w jakims banalnym (lub nie) kodzie. Wychodzenie w takiej sytuacji o 17:00 jest niepowazne, chyba ze jedziesz do matki do szpitala, do zony do porodu, albo wlasnie rozpoczal sie atak pokowidowych zombii.

A co do gadki typu "to jest proste" albo "dlaczego tego jeszcze nie mamy" trzeba odpowiadac rozbrajajaco szczerze, np. "jesli to proste to prosze o 2h konsultacji bo dla mnie takie nie jest". Bywa ze wtedy zza biurka wysuwa sie jakis senior ktory potrafi to wytlumaczyc. Manipulacje tego typu zle swiadcza o zarzadzajacych.

Do (dev)opsow idziesz tylko jesli nie masz sily lub checi kodowac, uczyc sie i analizowac czyjes wypociny, za to lubisz poswiecac wieczory, weekendy i swieta na instalacje, backupy i upgrejdy.

maciek_rz napisał(a):

Czy próby przebranżowienia się na docelową specjalizację gdzie nie ma takich rzeczy np. administratorka (jak się ustawi coś to działa, jak nie to nie) jest dobrym pomysłem? Czy myśli o pójściu w DevOps gdzie jeszcze nie jest się zaprzęgniętym do Sprintu są jakąś alternatywą? Boję się, że trochę pomieszały mi się priorytety w życiu, bo dawniej byłem zadowolony, że się rozwijam, że nowe technologie, nadgodziny brałem z pocałowaniem ręki, ale ile tak można....

Maciek.

To zależy od firmy, a nie od stanowiska.

Bywało tak, że devopsi siedzieli po 16h w weekend bo kazano im robić release w weekend, gdzie dotąd byli prowadzeni za rączki i wszystko się posypało.

Generalnie to nie powinno być normą, w niektórych firmach jest regułą, w innych... Cóż, nie ma takiej firmy, w której wystarczająco ważny projekt nie skłoniłby managementu do wywierania presji. Jeżeli masz UoP i masz w umowie o pracę, że pracujesz przeciętnie 8h dziennie przy przeciętnie 40 godzinnym tygodniu pracy (lub coś zbliżonego) to tak ma być, i twierdzenia managera że "IT to nie dotyczy i można robić 50/60/80h albo zmienić zawód" tego nie zmienią.

Żeby nie było, istnieje coś takiego jak nadgodziny, pracodawca może Cię chyba nawet do nich zobowiązać ale 1) musi za nie płacić 2) musiałyby być na polecenie / za zgodą pracodawcy, a nie że będziemy cisnąć roboli to posiedzą dłużej sami 3) nie można dorzucać tych nadgodzin do pieca bez żadnego limitu, są różne ograniczenia i obwarowania np. nieprzerwany odpoczynek dobowy i tygodniowy

Czy "crunch" i nadgodziny to norma w IT?

nie

Co firma, to obyczaj. Byłem w firmach, gdzie regułą było spędzanie godziny dziennie na granie w FPSy w sieci lokalnej i nikt nie miał z tym szczególnego problemu. Byłem też firmach, gdzie zdarzało się robić deploy w piątek i siedzieć nad tematem do 23:00. Zależy od wielu czynników, chociażby od deadline'ów czy tzw. scope, ale także od organizacji pracy (która często jest po prostu robiona nieefektywnie).

Nigdy w korpo z własnym produktem się z niczym takim nie spotkałem (na razie). Ale w Polskiej kontraktorni już jak najbardziej, tam to były wyścigi :D