W praktykach Extreme Programming (XP) możemy przeczytać, że tydzień pracy programisty powinien wynosić 40 godzin. Możliwe są sporadyczne nadgodziny (kilka razy w roku), ale nigdy nie powinny występować przez dwa tygodnie pod rząd. Praktyka ta nosi nazwę Sustainable Pace, czyli zrównoważone tempo. Zgodnie z XP zespół powinien pracować w stałym tempie, które jest w stanie utrzymywać w nieskończoność. Nadgodziny są symptomem poważniejszych problemów z projektem i to nimi należy się zająć.

Może się wydawać, że to jakieś mrzonki osób oderwanych od rzeczywistości i roszczeniowa postawa programistów, którzy mają za dobrze. Jednak moim zdaniem ta zasada ma głęboki sens i warto się nad nią głębiej zastanowić.

Skutki nadgodzin

Praca w nadgodzinach powoduje chwilowe przyspieszenie postępów prac. Dlatego czasem są wykorzystywane do osiągnięcia jakiegoś doraźnego celu. Może się więc zdarzyć, że raz na kiedyś posiedzimy dłużej, żeby zdążyć z releasem w tym tygodniu, albo żeby poprawić krytyczny błąd blokujący całą aplikację.

Problem zaczyna się, kiedy ten mechanizm jest nadużywany. Po początkowym krótkotrwałym  i stosunkowo niewielkim przyspieszeniu przychodzi spadek efektywności i na dłuższą metę okazuje się, że nadgodziny wręcz zmniejszają efektywność. Po prostu pracując w zwykłym tempie mamy pewne rezerwy, które wystarczą nam na chwilę. Jednak po wyczerpaniu tych rezerw zostaje zwykłe zarzynanie się.

Programista pracujący przez dłuższy czas w nadgodzinach staje się zmęczony i brakuje mu motywacji. Na dłuższą metę nie jest w stanie utrzymać pełnej koncentracji przez więcej godzin i nie osiąga swojej normalnej efektywności. Wykonuje swoje zadania mechanicznie i pojawiają się proste błędy, które powodują stratę wielu godzin. Są one także źródłem frustracji. Taka praca jest wyniszczająca fizycznie i psychicznie. Powoduje zniechęcenie, wypalenie i może spowodować odejście z pracy.

Dlaczego pracujemy w nadgodzinach?

Najczęściej nadgodziny są odpowiedzią na niewyrabianie się z terminami. Po prostu musimy siedzieć dłużej, żeby zdążyć przed deadlinem. Drugą częstą przyczyną są bugi. Soft już został wydany, ale jego jakość jest na tyle słaba, że co chwilę trzeba w nim coś na szybko poprawiać. Można więc powiedzieć, że nadgodziny są sposobem maskowania problemów. W pierwszym przypadku te problemy to złe rozplanowanie pracy, nierealne oczekiwania, czy brak asertywności developerów. W drugim natomiast to niewystarczająca jakość, czyli np. brak testów, code review, continuous integration.

Często te głębsze problemy są trudne do dostrzeżenia dla osób decyzyjnych. One widzą tylko efekt i starają się go poprawić jak najprostszą metodą – zwiększając ilość pracy. Jest to również uspokojenie swojego sumienia i oczyszczenie się z zarzutów – zrobiliśmy co mogliśmy, daliśmy z siebie wszystko a i tak się nie udało.

Świeży umysł cenniejszy niż wysiedziane godziny

Programowanie to praca kreatywna – ilość nie przekłada się na jakość. Jeśli siedzimy dłużej i się przemęczamy, wcale nie wpadamy na lepsze pomysły. Przestrzeń do kreatywności osiąga się inaczej – przez możliwość wymiany opinii, świeżość umysłu, dobre samopoczucie. Kiedy jesteśmy wypoczęci, łatwiej wpadamy na pomysły . A to właśnie jest najcenniejsza część programowania. Nie mechaniczne klepanie kodu – wtedy prawdziwy problem jest już rozwiązany i tylko wcielamy go w życie.

Koncepcje opracowane na świeżo często są prostsze i po prostu lepsze. Zmęczeni myślimy zbyt schematycznie i możemy zastosować jakieś przekombinowane rozwiązanie, które będzie potem się za nami ciągnęło przez długi czas.

Wpływ na prowadzenie projektu

Czterdziestogodzinny tydzień pracy daje możliwość planowania. Robiąc nadgodziny posuwamy się zrywami i ostatecznie wcale nie jest szybciej, a dodatkowo ciężko cokolwiek przewidzieć. Czasem szybkość jest złudna, bo płacimy jakością i będzie nas to kosztować dodatkowy czas później przy fixowaniu bugów, testach i zmniejszaniu długu technicznego.

Najważniejszym celem jest zrealizowanie całego projektu mogącego trwać np. rok. Nie warto narażać tego celu dla osiągnięcia lepszych wyników przez kilka pierwszych tygodni. Nie chodzi nam o wygranie sprintu, tylko maratonu. Albo jeszcze lepiej – wieloetapowego wyścigu kolarskiego.

Kluczem jest wzajemne zaufanie pomiędzy developerami i managementem oraz szczera komunikacja. Zespół musi jak najszybciej informować o problemach i możliwym przekroczeniu terminów. Manager musi akceptować fakty i nie szukać winnych tylko wspólnie z zespołem poszukać rozwiązania.

Obowiązki programisty

Jest również druga strona medalu – developer powinien sam dbać o swą wysoką produktywność. Po powrocie z pracy powinien więc przede wszystkim odpocząć. Warto również dobrze się wysypiać, dbać o aktywność fizyczną i po prostu o dobre samopoczucie. Pewien czas powinien również przeznaczać na samodzielną naukę. Koncepcje wpadają do głowy na zasadzie skojarzeń. Warto więc mieć pod nie odpowiedni grunt.

Podsumowanie

Sporadyczne i dobrze uzasadnione nadgodziny skupiające się na osiągnięciu wymiernego celu mają sens. Jednak pracując w ten sposób, albo zmuszając do pracy w ten sposób cały zespół, zwykle narobimy więcej szkód niż pożytku. Ilość godzin spędzonych na klepaniu w klawiaturę nie jest wprost proporcjonalna do ilości wykonanej pracy. Dlatego warto pracować w stałym tempie i dążyć do realizacji celów długoterminowych nie wytracając niepotrzebnie energii zespołu. Co ciekawe ta zasada ma również zastosowanie w pracy fizycznej. Czterdziestogodzinny tydzień pracy wprowadził Henry Ford w swoich fabrykach twierdząc, że tak jego pracownicy są najefektywniejsi.