Gorączka informatyka - przyczyny, objawy, leczenie

Chyba każdy informatyk zna ją z autopsji. Czasami pojawia się nagle, czasami swoje przyjście zapowiada przez wiele miesięcy. Za każdym razem oznacza to samo - długie wieczory spędzane w pracy, wysiłek ponad siły i nieustające wątpliwości - zdążymy czy nie? Słowem, zaczyna się gorący tydzień informatyka.

Chyba każdy informatyk zna ją z autopsji. Czasami pojawia się nagle, czasami swoje przyjście zapowiada przez wiele miesięcy. Za każdym razem oznacza to samo - długie wieczory spędzane w pracy, wysiłek ponad siły i nieustające wątpliwości - zdążymy czy nie? Słowem, zaczyna się gorący tydzień informatyka.

Tworzenie rozwiązań informatycznych zwykle odbywa się w rytmie takim, jak typowe prace inżynierskie. Poprzez fazy analizy, projektowania i programowania rozwiązanie jest przygotowywane, a następnie wdrażane. W każdym takim cyklu występuje co najmniej jeden, a najczęściej kilka "punktów kontrolnych". Zespołowi zależy na tym, aby produkt zaprezentował się jak najlepiej i był najbardziej funkcjonalny. Dlatego w ostatnim okresie przed uzgodnionym terminem stara się pracować jak najwięcej.

Przyczyny choroby

Są w zasadzie trzy przyczyny "gorączki informatyka". Pierwsza to zwykła niefrasobliwość ludzka, która każe nie martwić się na zapas. Wszyscy po prostu mają tendencję do odkładania tego, co nieprzyjemne (a do takich należy wytężona praca nad szczegółami systemu), na później. Skutkiem tego wszystko, co najmniej ciekawe, to, co najbardziej nużące, kumuluje się przed terminem. Druga przyczyna to błędy popełnione w zarządzaniu. Menedżerowie, którzy nie są informatykami, często nie rozumieją specyfiki tej dziedziny i w planowaniu zadań nie przewidują koniecznej rezerwy czasowej. Ci zaś kierownicy, którzy są lub byli informatykami, nie rozumieją, że projekt informatyczny nie polega na tym, by system robić, ale na tym, żeby go zakończyć. Przejawiają więc tendencję do "pieszczenia" rozwiązań. W obu przypadkach przynosi to spiętrzenie zadań pod koniec czasu przewidzianego na ich wykonanie. Trzecią przyczyną, z powodu której występuje zjawisko gorącego tygodnia, jest ograniczona przewidywalność inżynierii oprogramowania i jej zależność od wielu, z pozoru nieistotnych, czynników. Jeżeli np. zawodzi technologia baz danych, którą stosował zespół, to nie można winić jego członków za powstałe opóźnienia (chyba, że wcześniej sami forsowali wybór tej technologii, ale to inna sprawa).

Ogólnie mówiąc "gorącemu okresowi" rzadko winny jest sam zespół. Na ogół winę ponosi kadra zarządzająca, która albo przyjęła zobowiązania przekraczające możliwości informatyków, albo nie potrafiła tak zaplanować zadań (i dopilnować ich wykonania), by wysiłek rozłożony był w miarę równomiernie przez cały okres pracy, a nie skumulowany pod jego koniec.

Symptomy

Najczęstszym objawem "gorączki informatyka" są przedłużone godziny pracy i praca w dni wolne. Zostawanie po godzinach nie musi być formalnym nakazem, często jest raczej spontaniczną inicjatywą grupy. W dobrym, zgranym zespole poszczególni jego członkowie są wobec siebie lojalni. Jeżeli widzą, że choć tylko jeden z nich jest przytłoczony obowiązkami, solidarnie zostają, aby go odciążyć.

Ogólne podenerwowanie oraz zmęczenie członków zespołu i ich szefa to kolejny objaw charakterystyczny dla gorączki przed terminem. Wszyscy zdają sobie sprawę, że pracy jest dużo, a czasu niewiele. Niechętnie więc wdają się w dyskusje nie poświęcone pierwszoplanowemu celowi - przygotowaniu uzgodnionej funkcjonalności na czas. Próba skłonienia ich do czegokolwiek, co nie jest podporządkowane oddaniu uzgodnionej funkcjonalności w uzgodnionym czasie, kończy się zdecydowaną odmową. Jakość rozwiązań spada na dół listy pożądanych cech. Wszystko, co tworzone jest podczas takiego okresu, ma po prostu działać, a mniej ważne jest, jak działa. Można więc znaleźć rozwiązania skrajnie nieeleganckie bądź działające tylko w jednej, konkretnej konfiguracji (takiej, która będzie prezentowana).

Rzut oka na źródła pozwala odróżnić program pisany w normalnym okresie od tworzonego w pośpiechu. Gwałtownie spada liczba komentarzy w kodzie, pojawiają się rozwiązania, które stoją w sprzeczności z podstawowymi kanonami sztuki programistycznej (np. zmienne globalne), nawet formatowanie tekstu takiego programu wskazuje na to, że był on przygotowywany gorączkowo, bez dbałości o szczegóły. Program ten na ogół nie nadaje się do niczego, poza jednokrotnym zaprezentowaniem działającego rozwiązania.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200