Przeczytaj wpis na blogu lub odsłuchaj go jako podcast z moim dodatkowym komentarzem. Podcast można również pobrać bezpośrednio


Kiedyś czytałem, że żony programistów pewnej firmy odpowiedzialnej za grę o „dużej kradzieży samochodów” pisały listy do firmy, bo ich mężowie pracowali po 12 godzin dziennie przez sześć dni w tygodniu. Postanowiłem zebrać uwagi na temat nadgodzin od społeczności IT. Prezentuję efekty tego researchu - nadesłane opinie i relacje piętnastu osób z branży oraz moje doświadczenia w temacie. Cel tego wpisu jest następujący: poprawić asertywność programistów.

Poza nadgodzinami pojawi się też inne pojęcie. Crunch to zjawisko pracy po godzinach, ale nie codziennie w ciągu tygodnia po parę godzin. To bardzo intensywna praca po godzinach w ostatnich miesiącach projektu, która odsuwa na dalszy plan życie prywatne.


Opinie osób z branży



Olek

Od ponad dwóch lat pracuję w większej korporacji - część tego czasu jako stażysta. Słysząc wszystkie historie o pracy w korpo po godzinach i w weekendy trochę się bałem, że na pierwszą pracę od razu wybrałem korpo – szczególnie, że miałem inne możliwości.

Z czymś takim jak nadgodziny właściwie prawie nie miałem styczności. Odkąd pracuję w firmie musiałem przyjść do pracy w jedną sobotę (restart i duży update serwera do CI) i posiedzieć przy laptopie jeden dzień wieczorem (różnica stref czasowych między Polską i USA). Ale skoro przyszedłem w sobotę na pięć-sześć godzin, cały następny tydzień mogłem wychodzić godzinę wcześniej. Jeśli pracowałem wieczorem dwie godziny, następnego dnia wracałem dwie godziny szybciej. 

Jeszcze nie wychodziłem z pracy później, niż o 18:00. Tylko, że… jeśli w ogóle siedziałem dłużej to dlatego, że poprzednio wychodziłem o wcześniejszej godzinie. Mój szef jest na tyle bezproblemowy, że mogę swobodnie żonglować godzinami. Wiem, że zaraz ktoś powie, że przecież praca programisty to nie siedzienie osiem godzin w biurze, ale nie każdy rodzaj programowania to kreatywne rozwiązywanie problemów. W dużym korpo może to często być właśnie praca z kodem po osiem godzin dziennie ;)

Mi osobiście nie, ale ogólnie w moim teamie zdarzały się jednak większe problemy i było wtedy jakieś większe napięcie. Ale crunchingu specjalnie nie zauważyłem, przynajmniej jakiegoś przesadnego. Owszem, może zamiast ośmiu godzin trzy-cztery osoby przez tydzień pracowały po dziesięć. Ale potem sobie to odbijały i w następnych tygodniach pracowały krócej, albo robiły sobie dłuższy weekend.

Wiem, że jeden przypadek o niczym nie świadczy i może po prostu to mi trafiło się takie fajne stanowisko, ale ja po dwóch i pół roku pracy jestem zadowolny. Może obowiązki mogłyby być ciekawsze, ale są inne plusy: bez żadnych problemów kończę magisterkę w trybie dziennym i zdobywam doświadczenie.


Artur Czuba

Poświęcam dużo czasu na pracę po godzinach, ale nie odczuwam tego jako obowiązek. Mój pracodawca jest nawet przeciwny. Dlaczego jednak to robię?

Pracuję w korpo, gdzie od czasu do czasu pojawiają się ciekawe projekty, w których mogę wykorzystać nowe technologie, a przy okazji się ich nauczyć. To wciąga w takim stopniu, że ciężko się oderwać. Nie lubię też zostawiania niedokończonej części jakiejś funkcjonalności, więc spędzam kolejne godziny na dopisywaniu następnych linii kodu i integrowaniu całości. Dodatkowo po powrocie do domu chcę zająć się już tylko swoimi projektami, życiem towarzyskim, (ehhh) gotowaniem, więc staram się separować moją pasję od czasu wolnego.

Poza tym klimat, jaki panuje w biurze późnym wieczorem, jest nie do opisania. Ta atmosfera skupienia, zgaszone światło i świecące monitory sprawiają, że chce się siedzieć i pisać kolejne linie kodu. Za dnia nie ma skupienia. Ktoś przychodzi, zaczepia, pyta, a wyjście na lunch lub spotkanie potrafi wybić z rytmu. Po godzinach ten problem znika, co właśnie jest dużą zaletą. 

Ale programista może sobie pozwolić na taki styl pracy. Inne działy, które wymagają kontaktu z klientem, mogą mieć z tym problem.


Tomek

Ze swojej strony mogę opisać crunch - do którego do końca nie doszło. Ruszyliśmy w firmie z nowym projektem. Prawie bez specyfikacji i bez wizek, praktycznie tylko z ideą, co to ma robić. Po miesiącu mieliśmy zaimplementowane podstawowe funkcjonalności, które - jak się wydawało - są potrzebne. Zlecający obudził się, że jednak trzeba obrać inny kierunek.

Z opresji wybawił nas główny PM. Konsekwentnie uświadamiał zlecającego, że nie da się zrealizować tak dużych zmian funkcjonalności w ciągu dwóch-trzech tygodni. Ustaliliśmy zadania do MVP i zaczęliśmy. Szczęśliwie udało się to zaimplementować praktycznie na czas.

Wnioski i nauka – dobre zarządzanie zespołem w sytuacjach krytycznych oraz konsekwencja w działaniu PM-ów czasami pozwala uniknąć crunchu.


cometa93 - funventure.eu

Staram się brać odpowiedzialność za to, co robię w pracy, a projekty traktuję jak własne. Przed wydaniem potrafię dość sporo czasu poświęcić na dowożenie. Nie jest to wykorzystywanie ze strony firmy - oczywiście, jeśli te godziny są do odebrania, bądź płacone extra. Za free nikt nie będzie robił. Ale jednak jeśli poczuwasz się do projektu, który współtworzysz, moim zdaniem naturalną rzeczą jest crunch - o ile jest potrzebny. Nieraz siedziałem po 15-16 godzin, potem chwila snu, śniadanie i znów maraton.


Piotr Gankiewicz - piotrgankiewicz.com

To moje stanowisko, którego się trzymam w sumie od zawsze - nadgodziny można „zastosować” w dwóch przypadkach.

Pierwszy - najbardziej oczywisty - to praca na swoim. I nie mam tu na myśli zawodu typowego freelancera - który nadal pracuje dla pewnego klienta, tyle, że zazwyczaj zdalnie. Chodzi przede wszystkim o rozwój własnych projektów, które w przyszłości mogą zaowocować np. pokaźnym zyskiem. Nie różni się to niczym innym od rozwijania własnej firmy. I tutaj zazwyczaj czeka nas ciężka harówka, niezależnie, czy tego chcemy, czy nie. 

Drugi przypadek to typowa praca w firmie - z tym zastrzeżeniem, że za spędzone nadgodziny otrzymujemy odpowiednią zapłatę. Nie dajcie się tutaj zwieść żadnym obietnicom, ani tym bardziej wykorzystać (zazwyczaj poprzez „wzięcie na litość”). W przeciwnym przypadku może Was spotkać bardzo niemiłe rozczarowanie, gdy okaże się, że mieliście wiele nadgodzin, a koniec końców, poza przysłowiowym uściskiem dłoni prezesa, nic z tego nie uzyskaliście.


Jakub Gutkowski - blog.gutek.pl

Do nadgodzin mam prosty stosunek, ale trzeba go rozbić na dwa punkty widzenia. Nie chcę wchodzić w samo znaczenie i negatywny wydźwięk słowa nadgodziny. Bo pierwszy odruch po jego usłyszeniu to przymus pracy i zło. A tak wcale nie musi być.

Osobiście nie jestem za dłuższym siedzeniem w pracy - nie lubię tego. Ale z drugiej strony, gdybym był singlem - nie ojcem i mężem - to pewnie nie miałbym nic przeciwko, by od czasu do czasu dłużej popracować. Ale przy spełnieniu paru warunków. Po pierwsze, ktoś miałby mnie o tym poinformować, a ja musiałbym wyrazić na to zgodę. A po drugie - każda nadgodzina byłaby płatna, albo równoznaczna dodatkowej godzinie wolnej. Na przykład teraz u mojego klienta jest tak, że jak pracownik pracuje dłużej, to może sobie wziąć do ośmiu godzin wolnego w miesiącu. Albo bierze sobie jeden wolny dzień za nadgodziny, albo skraca sobie czas pracy w innych dniach - tak, by się zgadzał wynik ośmiu godzin. I to jest ok. 

Drugi przypadek byłby taki, że nie ma czegoś takiego jak nadgodzina. Każda godzina pracy jest płatna X. W umowie nie ma zapisu o tym, że mamy pracować od 9:00 do 17:00 tylko, że mamy być dostępni i pracować minimum X godzin dziennie. Nie mamy przy tym określonego maksimum i każda dodatkowa przepracowana godzina jest wliczana do czasu pracy. A więc - jeśli chcę - mogę siedzieć 24h na dobę i pracodawca za to zapłaci. To także przypadek własnej działalności gospodarczej. Jak nie pracujemy to nie dostajemy, a jak pracujemy to po to, by ktoś nam za to zapłacił. 

Sytuacja, kiedy firma co chwilę wymaga od nas nadgodzin, a nie chce ich zrekompensować jest dla mnie nie do zaakceptowania. Wtedy po prostu powiedziałbym „dość” i złożył papiery. Ale co jest dla kogo akceptowalne to odrębna sprawa. Tak jak ze wszystkim, wszystko za obustronną zgodą jest w porządku. 



Tomasz Woliński - StormIT.pl

Z crunchem w całym tego słowa znaczeniu spotkałem się do tej pory tylko w jednym projekcie. Dzisiaj wiem, że zawczasu nie dopuściłbym do takiej sytuacji.

Warunki pracy oczywiście nie stały się tak krytyczne z dnia na dzień. Wszystkie początkowe nadgodziny były płatne i nawet mnie cieszyły, bo dodatkowe pieniądze przecież zawsze się przydają. Miałem również okazję się wykazać i szybciej nauczyć nowych rzeczy. To - na tym etapie programistycznej kariery - było dla mnie wyjątkowo ważne. 

Prawdziwe problemy zaczęły się, gdy otrzymałem do realizacji bardziej wymagające zadania. Więcej osób polegało na mojej pracy, a proces był tak skonstruowany, że moja nawet stosunkowo krótka niedostępność mogła blokować pracę innym. Spowodowało to całkowitą utratę czasu prywatnego. W tym okresie telefony od współpracowników o trzeciej-czwartej w nocy nikogo już nie dziwiły. Ba, wielokrotnie po takim telefonie siadałem do komputera i gasiłem pożary. W okresie wydania nowej wersji dość często bywało, że w pracy spędzaliśmy bez przerwy ponad 24h. Przy takim trybie pracy niektórzy zwyczajnie przysypiali na klawiaturze.

Powstały w ten sposób produkt był wyjątkowo niskiej jakości. Zawsze było coś do szybkiego naprawienia, co blokowało pracę. Dlatego nie było kiedy przeprowadzić niezbędnych refaktorów czy napisać dobrych testów, co w perspektywie czasu tylko pogarszało sytuację. Bywało również, że dane trzeba było naprawiać bezpośrednio na produkcji, by skrócić czas wdrożenia. Nie było to zbyt bezpieczne.

Patrząc na to z perspektywy czasu mogę stwierdzić, że najbardziej przerażające było to, że po pewnym czasie współpracownicy sami podjudzali tę sytuację. Pokutowała myśl, że skoro ja tak pracuję, to czemu Ty masz mieć lepiej? Chwilami było bardzo nerwowo i nieprzyjemnie. Niestety przełożeni godzili się na to, zasłaniając się dobrem projektu i klienta. Prawda jednak była taka, że klient nie był zadowolony z efektów współpracy. Nowe wersje produktu, które otrzymywał - notorycznie po terminie - były niskiej jakości.

Taki tryb pracy skończył się dla mnie zmianą pracodawcy. Całe szczęście po którejś nocnej pobudce żona postawiła weto takiej dalszej pracy. Zmiana okazała się bardzo dobrą decyzją, również pod względem finansowym. Bez robienia licznych nadgodzin uzyskałem podobne wynagrodzenie.


Maciej Aniserowicz - devstyle.pl

W branży IT często szczycimy się pracą po 20 godzin na dobę, spaniem po trzy godziny, wykończeniem i całkowitym poświęceniem programowaniu. Wielu programistów przechodzi przez ten etap – też tam byłem. Prawie wszyscy w pewnym momencie dochodzą do wniosku, że to nie ma sensu. Część ląduje przez to w szpitalu, inni kończą z wypaleniem zawodowym, niektórzy zostają ze stałymi problemami zdrowotnymi. Dając z siebie absolutnie wszystko jesteśmy w stanie pokonać tylko krótkie dystanse. Pamiętajmy, że to nie sprint, a maraton. Zawsze będzie coś do zrobienia.


KrzaQ - https://dev.krzaq.cc/

Pierwszy raz miałem do czynienia z crunchem w pracy latem 2012, kiedy pisałem soft do magazynu automatycznego. Mieliśmy spore opóźnienie - bardzo kosztowne dla naszego klienta. Z tego powodu siedzieliśmy wszyscy po kilkanaście godzin dziennie, czasem łącznie z weekendami, dopracowując system. W rekordowym tygodniu wyrobiłem 108 godzin, a w ciągu całego „najlepszego” miesiąca ponad 350.

Pewnie to podpada pod wyzysk i zdecydowanie przekracza wszelkie normy narzucone przez KP. Ale ostatecznie za przepracowane nadgodziny dostałem ekwiwalent: odpowiednio 150% i 200%, zgodnie z regułami, więc uważam, że było to spoko. Poza tym... szef również siedział i zap... .


Rafał

Moja pierwsza praca. Od razu trafiłem na projekt, który za trzy miesiące miał pójść na produkcję. Nadgodziny były u nas nieobowiązkowe, aczkolwiek spodziewane. Im bliżej „go live”, tym więcej godzin miał cały zespół. Wszystkie płatne, tak jak i soboty czy święta. Pracować w sobotę można było zdalnie. Jeśli przychodziło się jednak do biura, firma stawiała obiad.

Generalnie nie był to dla mnie ciężki okres, chociaż inne osoby czasami narzekały. Mieliśmy i tak dobre warunki na tych nadgodzinach w stosunku do innych branż. Porównując to do budowlanki dopiero widać różnicę. Jedynym minusem była organizacja i mało czasu na naukę. Zadania były przypisywane do ludzi, którzy znali temat najlepiej, a nie po to, by poszerzać wiedzę zespołu. Ogromnym plusem jest szansa, jaką dostałem. Gdyby nie nadchodzący crunch time pewnie nie dostałbym tej pierwszej pracy po przebranżowieniu się. 

Wypalenie się raczej nie miało miejsca. Pewnie trochę przyspieszyło u pewnych osób, ale generalnie każdy wiedział, że z wejściem na produkcję kończymy już z taką pracą i to się nie powtórzy, przynajmniej w tym projekcie. Na pewno dałoby się to odczuć, gdybym miał takie sytuacje cyklicznie. A tak, to w porządku. Okazja, aby zarobić więcej, zjeść dobrze i złapać dobre tempo pracy w tych pierwszych tygodniach. 


Grzegorz Koftis - gkotfis.blogspot.com

Spotkałem się ze zjawiskiem crunchu. Niestety, było to w mojej pierwszej pracy i na dość dużą skalę. Pracowałem wtedy jako gość od wszystkiego w IT. Administracja serwerami, bazami danych, oprogramowaniem, jakieś drobne serwisy komputerów, infrastruktury sieciowej. Telefony po godzinach czy tak zwane akcję na koniec dnia były nagminne. Bardzo często pewne rzeczy do zrobienia przypominały się szefowi o 15:59. Nie był to czas dodatkowo płatny.

Przyczyniło się to do frustracji i niechęci, a w konsekwencji do rotacji pracowników. Ja sam nie marudziłem za bardzo - była to moja pierwsza praca, a w dodatku rozwojowa i, jak na tamte czasy, z fajną kasą. Uważałem, że to normalne, bo koledzy byli w podobnej sytuacji. 

Dziś bardzo szanuję zarówno swój czas, jak i czas pracodawcy. Wyleczyłem się także z ratowania świata i syndromu bycia niezastąpionym filarem firmy. Dbam o work-life balance, ale dopuszczam sytuacje awaryjne, kiedy nie ma wyjścia - trzeba zostać i pomóc gasić pożar. Jeśli dzień w dzień go gasisz to zdecydowanie coś jest nie tak.

Aktualnie pracuję w firmie, gdzie zadania są dobrze zaplanowane, a takie sytuację nie występują. Brak telefonów po godzinach, odbierania maili. To bardzo komfortowe, a zarazem normalne – tak powinno być. Drugim aspektem, który chwalę sobie w obecnej pracy, jest brak organizacji mojego czasu wolnego przez pracodawcę. Znam firmy, które bardzo często organizują różne spotkania integracyjne po godzinach. Pewnie nieobowiązkowe... „ale co? Nie chcesz się integrować z zespołem?!”. Chcę, ale można to jak najbardziej robić w czasie pracy - w innej formie.


Michał Franc - mfranc.com

Nie akceptuję nadgodzin, uważam je za cos nienormalnego. To stan, z którego trzeba jak najszybciej wyjść i go unikać. Jedyne, co akceptuję, to nadgodziny wynikające z mojego profesjonalizmu. Np. coś popsułem i generuje to spore koszta, więc chcę jak najszybciej naprawić ten błąd. Ale wtedy zakładam, że następnego dnia wcześniej wyjdę z pracy, by mieć więcej czasu na odpoczynek.

Dawno, dawno temu robiłem nadgodziny za darmo, uznając, że to część moich obowiązków. Często nie wynikało to z mojej winy, tylko z celowego, cynicznego zagrania firmy/managementu, by wydusić ze mnie jak najwięcej. Płacono mi 5000 zł za 160h w miesiącu, a próbowano uzyskać jeszcze dodatkowe 40h. Przecież to tylko dwie godziny dziennie... Tak naprawdę firma tak dostawała ode mnie za darmo 1250zł wartości. Bezpłatne nadgodziny napędzają spiralę. Jeśli pracownik chce pracować za darmo, przykręca się śrubkę bardziej.

Nadgodziny powinny być dodatkowo płatne. Wtedy - i tylko wtedy - firma poczuje koszt utrzymywania nadgodzin i będzie zainteresowana zmianą organizacji, by nie generować dodatkowych kosztów. Długotrwale, nadmiernie nadgodziny to zagrożenie dla Waszej kariery i słaba inwestycja czasu. Jeśli chcecie robić coś dodatkowo, skupcie sie na sobie, zróbcie jakis projekt, kurs. Tyle projektów open source potrzebuje kogos do pomocy. Inwestujcie w firmę JA Sp. z o.o. - jedyną, na której powinno Wam zależeć. Szanujcie swój czas, bo już go nie odzyskacie.



Michał Gellert - michalgellert.pl/blog

Osobiście spotkałem się ze zjawiskiem nadgodzin. Były płatne, za taką samą stawkę, jak regularne godziny, z ewentualną opcją ich odbioru później. To znaczyło, że kiedy trzeba było ukończyć produkt - pracowaliśmy. Potem można był wziąć kilka dni wolnego w ramach wypracowanych nadgodzin. Absolutnie nie zgodziłbym się na pracę po godzinach za darmo.

Co do zjawiska nadgodzin w ogóle - mam mieszane uczucia. Nie powinny mieć miejsca, bo nasza praca wymaga skupienia. Przeciąganie czasu powyżej kilku godzin do, powiedzmy, kilkunastu dziennie może skończyć się kodem gorszej jakości. Możemy nie zauważać, że gdzieś mogliśmy np. użyć konkretnego wzorca projektowego. Preferuję podejście: „prześpij się z problemem”. Wiele się wtedy dzieje w naszej głowie, problemy mogą faktycznie rozwiązać się same. Z drugiej strony trzeba pamiętać o tym, że ciągle brakuje developerów, a nasze wynagrodzenia pochodzą z konkretnych, dowiezionych projektów. Dlatego ciężko powiedzieć, że sprawa jest czarno-biała.

Warto zauważyć już na początku projektu, że terminy mogą gonić. Ale nie zawsze jesteśmy w nim od początku. Czasem rozpoczynamy pracę i okazuje się, że do końca projektu, w którym jesteśmy, pozostały dwa miesiące, a pracy jest jeszcze sporo. Dobrze by było, gdyby pracodawca informował o takim fakcie w trakcie rozmowy rekrutacyjnej, a z tym różnie bywa.

Cenię sobie elastyczny czas pracy. Czasem sam z siebie wypracowuję nadgodziny, żeby mieć dodatkowy wolny dzień w tygodniu. Zawsze staram się dążyć do takiego porozumienia z pracodawcą, który by mi na to pozwalał. Najważniejsze, by pod koniec miesiąca stan godzin się zgadzał. Poza tym team musi wiedzieć o moich dniach wolnych, zadania, na które się zadeklarowaliśmy również należy skończyć, dbać o dobre praktyki w takich sytuacjach, etc. Jest to również zyskowne dla pracodawcy, ponieważ kiedy mam gorszy dzień mogę po prostu zająć się czymś innym, a pracę wykonać w innych godzinach, zamiast siedzieć i zmuszać się do czegoś, co z racji niechęci i tak będzie słabej jakości.

Niektóre firmy mogą oczekiwać nadgodzin z premedytacją, wierząc w zaangażowanie swoich ludzi. Inne wyciągają lekcję i starają się, by były to jednak tylko incydenty, ponieważ zależy im na pracownikach oraz jakości ich kodu.


Moje doświadczenia i opinia

Jeśli chodzi o pracę na etacie, spotkałem się raz z przypadkiem, gdzie termin bardzo gonił i zespół przez miesiąc robił sporo nadgodzin. W firmie była taka polityka, że za nadgodziny można było sobie wcześniej wyjść. Gdy nadgodzin było bardzo dużo w tym ostatnim ważnym miesiącu projektu, firma wynagradzała to dodatkowym urlopem i opłaconym wyjazdem. Jako zespół mieliśmy wynajęty domek na pięć dni i sobie imprezowaliśmy. Oczywiście wyjazd był dobrowolny - jeśli ktoś wolał, miał po prostu dodatkowy urlop. 

Muszę zaznaczyć, że nikt do tych nadgodzin nigdy nie zmuszał. Pokazuje to jak ważne jest dbanie o pracownika i warunki w miejscu pracy. Bardzo miło ten czas wspominam, chociaż oczywiście zdaję sobie sprawę, że to zwykła kalkulacja - firmie się tak opłaca. Parę osób notorycznie zostawało po godzinach i nie zauważałem, by brało za to dodatkowy urlop. Kiedyś zapytałem o to z ciekawości. Okazało się, że były to osoby, które miały udziały w firmie. „Dowiezienie czegoś” dawało im sporo potencjalnych korzyści. Mając tylko jeden procent udziału trochę grosza nam spadnie, gdy firma zostanie sprzedana za parę milionów dolarów...

Nie spotkałem się z sytuacją, gdy nie otrzymałem nic za dodatkową pracę. Nasłuchałem się natomiast trochę od kolegów, którzy pracowali kiedyś w firmach związanych z gamedevem. Często powtarzał się motyw, że firma dużo obiecywała i na obietnicach się niestety kończyło. Żałowali, że byli naiwni i nie mieli wszystkiego na papierze.

Co do pracy dla siebie... Tu często zdarza się, że pracuję więcej niż 40 godzin w tygodniu, a czasami zrobię sobie luźniejszy tydzień. Często nie mam problemu z pracą w weekend, bo robię coś, na co faktycznie mam ochotę. Z czasem nauczyłem się jednak jednej rzeczy dotyczącej efektywności. Najwięcej czasu oszczędzamy na tym, czego świadomie decydujemy się nie robić. Postawa typu „wszystko jest ważne” do niczego dobrego nie prowadzi. To tylko złe zarządzanie sobą czy zespołem. Lepiej zrobić dobrze mniej rzeczy, które dają faktyczne efekty, niż biegać w kółku i być dumnym z tego, że dużo się napracowaliśmy.