Słabi menedżerowie postępują jak opisany kapitan - naprawiają skutki zamiast przyczyny. Dobrzy menedżerowie potrafią spojrzeć krytycznie na taki okres i wyciągnąć z niego nauki. Co zawiodło? Kto wygrał, kto przegrał? Czy można było tego uniknąć? Jak sprawić, żeby takie okresy nie pojawiały się? Odpowiedzi na te pytania powinny stać się elementem tak zwanego raportu post mortem.

Najczęstszą przyczyną gorączki w pracy informatyków jest niewiedza. Informatycy nie znają wymagań klientów (i dlatego wydaje im się, że prace są prawie zakończone, choć wykonano nie więcej niż połowę systemu). Menedżerowie nie znają stanu zaawansowania projektu (bo w nim tak naprawdę nie uczestniczą) ani uwarunkowań płynących ze stosowanych technologii informatycznych. Sposobem na długofalową poprawę poziomu wiedzy po obu stronach jest jej lepszy przepływ. Pracownicy powinni być włączani w planowanie projektu, przynajmniej tej części, w którą są bezpośrednio zaangażowani. Kierownicy zaś muszą posiadać dogłębną wiedzę na temat technologii i narzędzi informatycznych oraz dziedziny, dla której przygotowywany jest program.

Często zdarza się, że pracownicy po prostu nie mają kwalifikacji, które pozwoliłyby im lepiej rozwiązywać powierzone zadania. Sposobem na podniesienie ich poziomu są szkolenia, kursy, zakup odpowiedniej literatury, a także lepsza wymiana doświadczeń między bardziej a mniej doświadczonymi informatykami.

Czasami przyczyną jest błędna organizacja grupy. Modelowym, dość częstym przykładem jest brak osób odpowiedzialnych za kontrolę jakości przygotowywanych rozwiązań. W efekcie intensywne testy, przeprowadzone przed ważną prezentacją, ujawniają błędy, o których informatycy wcześniej nie mieli pojęcia. Raport post mortem w tej sytuacji powinien zawierać konkretne propozycje zmian w strukturze zespołu.

Zespół informatyków powinien mieć jasność, jakie nagrody czekają za dotrzymywanie terminów, a jakie kary za spóźnienia. Jednakże bardzo istotne są dwa elementy "kija i marchewki". Po pierwsze, należy dobrze wyważyć odpowiedzialność grupową i jednostkową. Z jednej strony jest bowiem "urawniłowka", z drugiej zaś rozbijanie zespołu przez nieuzasadnione wyróżnianie kogokolwiek. Przykładowo, kierownik może wszystkim zaoferować dwa dni wolne od pracy w rewanżu za wzmożony wysiłek, ale tylko niektórym dać premię. Po drugie, zbyt łatwe nagrody i nie zasłużone kary dają efekt przeciwny do zamierzonego. Szef musi wiedzieć na pewno, że jego działania są przejrzyste i uzasadnione ponad wszelką wątpliwość.

Jeżeli "gorączka przed terminem" była szczególnie uciążliwa, konieczne jest jej odreagowanie. Może to być wspólna wyprawa do restauracji, mecz siatkówki informatycy kontra kierownicy (kierownicy muszą dać wygrać informatykom), wyjazd na trzy dni do zagubionej w puszczy leśniczówki itp. Należy pozwolić "odejść" złym emocjom, nagromadzonym podczas nerwowego okresu; umożliwić spojrzenie na niego z dystansu.

Pozbyć się gorączki

Tak naprawdę wszystkim informatykom zależy, żeby tworzyć dobre systemy w przewidywanym czasie. Większość spośród nich stać na wzmożony wysiłek i długie godziny pracy w sytuacjach kryzysowych, ale nikt nie jest skłonny zaakceptować ich jako normalnego sposobu pracy. Dlatego tak ważne jest zrozumienie, że "gorączka informatyka" to krótkotrwała choroba. Od czasu do czasu zapada się na nią i szybko się zdrowieje, ale jako stan przewlekły jest wyniszczająca.

1 Historia wzorowana na fragmencie książki Debugging the Development Process (Steve Maguire, Microsoft Press, 1995)