Informatycy z reguły są przeciwni procedurom postępowania. Ich praca - argumentują - ma charakter twórczy i wszelka biurokracja (a tak postrzegane są procedury działania) zabija jej twórczą atmosferę. Kiedy jednak uda się takie procedury wdrożyć, ci sami ludzie równie gorąco będą ich bronić, ponieważ wraz z nimi pojawi się nowa wartość - porządek w zarządzaniu.

W większości polskich firm informatycznych na początku działalności zespoły pracowników były niewielkie. Nie bez powodu małą firmę uważa się za najbardziej efektywną. Grupa dobrze się rozumie, istnieje naturalny podział obowiązków, autorytety są autentyczne i wynikają z rzeczywistych kompetencji, a wszyscy czują wspólną odpowiedzialność za terminowe zakończenie projektu i uzyskanie na koniec właściwego efektu.

Sukcesy takiego zespołu przekładają się na nowe zlecenia, a nowe zlecenia wymagają nowych ludzi. Zespół więc rośnie - często skokowo - i wtedy zaczynają się problemy. Niby jest więcej rąk do pracy, ale sprawy wcale nie idą szybciej. Więcej oczu, które oglądają kod, powinno powodować jego mniejszą awaryjność, ale przeciwnie, liczba błędów wzrasta. Mieszają się style programowania, gdzieś gubią się istotne informacje, informatycy spychają odpowiedzialność na siebie nawzajem, zaczynają się spory, a terminy wydają się niepokojąco bliskie.

Menedżerowie różnie reagują na taką sytuację. Pamiętajmy, że w polskich firmach na ogół dominuje kultura inżynierska. Kadra zarządzająca w zasadzie jest rekrutowana z doświadczonych programistów czy projektantów, normalne więc jest, że przyczyn błędów poszukuje się w rozwiązaniu technicznym. Pierwszym podejrzanym jest język programowania albo inne narzędzie pracy (np. technologia baz danych), potem - jedna czy dwie konkretne osoby, które "psują innym pracę", wreszcie pojawia się wiara, że jeżeli ludziom "przykręci się trochę śrubę", zaczną lepiej pracować.

Nie zaczynają. Ten moment w rozwoju firmy - znany zapewne wielu informatykom - to czas na strukturalizację działania firmy. Czas na zamknięcie jej działania w punktach i procedurach.

Robić lepiej

Informatyk czuje się poniekąd artystą. A artysta - wiadomo - nade wszystko ceni swobodę twórczą. Każda próba zbiurokratyzowania jego pracy wydaje się z góry skazana na niepowodzenie. Z drugiej jednak strony widać jak na dłoni, że wprowadzenie pewnych standardów jest konieczne. Mało doświadczony menedżer zrobi tak, jak przeczytał w podręczniku zarządzania: wypracuje pewne procedury, zapisze je na kartce, a następnie wyśle okólnik informujący o ich wprowadzeniu od określonej daty. A jak postąpi mądry menedżer, który chce, aby jego zespół informatyczny wdrożył reguły postępowania, czyli procedury? Mądry menedżer dopuści do niewielkiego kryzysu o ograniczonych skutkach.

Zmiany w zarządzaniu łatwiej wprowadzać przede wszystkim wtedy gdy wyraźnie zawiódł obecny sposób działania. Taki kryzys jest znakomitą okazją, by spojrzeć na firmę z dystansu i powiedzieć sobie, co zawiodło i co można poprawić. Skupić się nie na rozpatrywaniu win i żalów, ale na tym, co dałoby się zmienić.

Żelazna reguła zarządzania mówi też, że zmiany są łatwiej akceptowane, gdy pracownicy czują się ich współautorami. Jeżeli zespół dojrzał do tego, aby ustalić pewne zasady działania, najlepszym rozwiązaniem wydaje się "burza mózgów", w której każdy może wypowiedzieć własną opinię. Można powiedzieć, że w ten sposób świadomie rezygnują z części swojej "twórczej suwerenności" na rzecz wspólnego dobra.

Reguły, punkty i procedury

Jakie sytuacje można ująć w procedury postępowania w zespole informatycznym? Nie ma jednoznacznej odpowiedzi. Każda organizacja ma swoją kulturę, a każdy zespół ma własne wartości. Opiszmy jednak podstawowe zastosowania takich procedur, reguł i standardów.

Rozliczanie zadań

Kluczowym zagadnieniem w przedsiębiorstwie informatycznym jest dziś jego rentowność. Skończyły się czasy łatwych klientów, łatwych kontraktów i łatwych pieniędzy. Dlatego bardzo istotna jest analiza rentowności konkretnego zadania. Jeżeli ktoś zlecił firmie wykonanie systemu informatycznego i zapłacił za to konkretną kwotę, to powinna ona wystarczyć zarówno na opłacenie wszystkich godzin roboczych poświęconych na pracę nad takim systemem, na narzędzia wykorzystane przy jego tworzeniu, jak i na wszystkie wydatki gwarancyjne (znowu godziny robocze, dojazdy itd.).