Menedżerowie różnych organizacji nie bardzo rozumieją termin "praca zespołowa". Już najwyższy czas, aby kierownicy działów organizacyjnych przestali wskazywać palcem na system informatyczny jako źródło wszelkich nieszczęść i wzięli również na siebie część odpowiedzialności za wyniki wdrożenia projektów technicznych.

Wiele firm chwali się, że szybko realizuje i kończy sukcesem nowe zadania charakteryzujące się udziałem w nich wielu zespołów. Niestety, najczęściej żaden z tych atrybutów nie dotyczy projektów związanych z zastosowaniami informatyki.

Jak twierdził jeden z menedżerów, nie związany z informatyką, projekty informatyczne zawsze przekraczają założone koszty i terminy oraz rezultaty przedsięwzięcia nigdy nie dawały pożądanych rezultatów.

Takie często uzasadnione opinie mają swoje źródło w nieumiejętności stworzenia warunków dla prawdziwej pracy zespołowej. Nie chodzi tu oczywiście o zespół informatyków, ale również o tych, dla których projekt jest realizowany.

Cały problem w tym, że zarząd firmy nie potrafi określić, co to jest właściwie zespół odpowiedzialny za wykonanie zadania. W praktyce, zespół powołany do wykonania zadania, to grupa ludzi realizująca ten sam cel. Niestety zakłada się najczęściej, że tylko grupa informatyków jest odpowiedzialna za wdrożenie systemu i rezultaty z tego wynikające.

W samych podstawach takiego założenia jest coś niewłaściwego. Wyobraźmy sobie sytuację, w której załoga jachtu złożona jest z informatyków i pracowników działu operacyjnego. Załóżmy, że w pobliżu skalistego wybrzeża złapał ich sztorm, a morze i wiatr sprzysięgły się, aby ich na tych skałach umieścić. Oczywiście w takim przypadku wszyscy będą pracować jakby byli elementami tego samego organizmu. Gdyby było inaczej, katastrofa byłaby więcej niż pewna. Nie ma znaczenia czy pracujesz z osprzętem na wietrze, czy stoisz z boku wydając komendy. Gdy jacht rozbije się o skały, los każdego członka załogi jest praktycznie przesądzony. Właśnie na tym polega prawdziwa praca zespołowa. Mogę się założyć, że pracownicy działów operacyjnych nie byliby tacy skorzy do ratowania jachtu

gdyby wiedzieli, że nadlatuje helikopter, aby zabrać ich z tonącej łajby, pozostawiając facetom od informatyki "słone przeznaczenie". Dlaczego? Ponieważ na "jachcie" określanym jako informatyka czują się oni tak, jakby byli pasażerami. Często nawet są z tego dumni i podkreślają, że są "ponad to".

Znałem wielu informatyków, którzy stracili pracę po zawaleniu się projektu, ale tylko jednego gościa z innej branży, który ucierpiał z tego właśnie powodu.

Co nie gra w tym obrazie?

Przyjrzyjmy się sprawie bliżej. Wdrożenie systemu wymaga zespołowej pracy informatyków i pracowników działów operacyjnych, których ten system ma obsłużyć. Nie wystarczy przeznaczyć środki, nakreślić plan, a odpowiedzialnością za skutki obarczyć tylko twórców iwykonawców.

A oto inne wydarzenie. W związku z ciągłym postępem technicznym, w firmie zatwierdzono projekt, który miał zredukować koszty osobowe w jednym z działów o 30%. Chodziło o odejście od przetwarzania wsadowego do pracy interakcyjnej. Nie trzeba dodawać, że system pracował "on-line".

Mimo pewnych kłopotów system został wdrożony, cele osiągnięte, a wydajność pracy wzrosła. Kierownik zespołu, w którym wdrożono system twierdził, że mimo wprowadzonej modernizacji nie da się zmniejszyć zatrudnienia. Okazało się, że to właśnie kierownik działu najbardziej obawiał się wzrostu wydajności pracy. Chciał bowiem utrzymać ten sam i tak samo liczny zespół, aby później nie trzeba było go uzupełniać nowymi osobami, gdy zajdzie taka potrzeba. Wydawało mu się, że zaskarbia sobie w ten sposób wdzięczność pracowników. Nie mniej ważna jest w takich przypadkach ponadustrojowa biurokratyczna zasada - "im więcej podwładnych, tym większy kierownik".

Odpowiedzialnością za ten stan rzeczy obarczono system informatyczny, a więc tych, którzy go realizowali. Stracili oni dobrą reputację u zarządu firmy, a kolejne projekty były już bardzo ściśle kontrolowane pod kątem wykorzystania środków i harmonogramu pracy, co również im na dobre nie wyszło. Oczywiście nie jest to przypadek odosobniony.

Gdzie tu jest sens?

Z punktu widzenia biznesu, taka organizacja pracy nie ma sensu bo nie przynosi żadnych korzyści firmie. Nie należy tego nazywać pracą zespołową, ale wręcz pracą antagonizującą zespoły. Proponuję, aby po uzgodnieniu budżetu i planu przedsięwzięcia, kierownik zespołu informatyków i jego partner z działu, dla którego projekt jest robiony, uzgodnili stopień zwiększenia efektywności tego działu. Na przykład: redukcja kosztów osobowych będzie wynosiła 20%.

Co to oznacza w praktyce?

W chwili ukończenia projektu kierownik działu, dla którego został on przygotowany, musi być zainteresowany finansowo jego efektami. Zarząd musi widzieć twórców systemu informatycznego i jego użytkowników jako dwie części tej samej całości. Czy przedsięwzięcie zakończy się sukcesem czy porażką, obaj kierownicy będą za to jednakowo odpowiedzialni. Jeżeli będzie poważna wpadka, to obaj stracą pracę lub stanowiska. Nie powinno być więcej "my" i "oni", ponieważ wszyscy są członkami tego samego zespołu w rozumieniu firmy jako całości.

Wyzwania są stawiane przecież całej firmie, a nie tylko informatykom i jako całość musi ona im podołać. W końcu albo odniesiemy sukces, albo cytując Winstona Churchilla "pogrążymy się razem".