Nie wyszło

Pewnego dnia ktoś otwarcie mówi to, co wszyscy wiedzą od dawna. Nie udało się. Projekt informatyczny, który zespół prowadził od miesięcy, a czasem od lat, zakończył się fiaskiem. Choć wszyscy bardzo chcieli, choć jeszcze niedawno wydawało się, że się uda, to dziś jest już jasne, że projektu nie da się skończyć. Jak radzić sobie w takiej sytuacji? Jak ocalić to, co jest do ocalenia? Jak sprawić, aby takie sytuacje nie powtarzały się w przyszłości?

Pewnego dnia ktoś otwarcie mówi to, co wszyscy wiedzą od dawna. Nie udało się. Projekt informatyczny, który zespół prowadził od miesięcy, a czasem od lat, zakończył się fiaskiem. Choć wszyscy bardzo chcieli, choć jeszcze niedawno wydawało się, że się uda, to dziś jest już jasne, że projektu nie da się skończyć. Jak radzić sobie w takiej sytuacji? Jak ocalić to, co jest do ocalenia? Jak sprawić, aby takie sytuacje nie powtarzały się w przyszłości?

Wyjątek czy codzienność?

Jeszcze w roku 1995 oceniano, że ok. 80% projektów informatycznych kończy się fiaskiem. We względnie łagodnej formie porażka przybierała formę opóźnień czasowych i przekroczenia budżetu projektu - czasami nawet kilkakrotnego. W drastycznej formie (czyli w ok. połowy przypadków), projekt nigdy nie oglądał światła dziennego. Dziś te statystyki przedstawiają się nieco lepiej. Ale z dużą dozą prawdopodobieństwa nadal można powiedzieć, że praktycznie każdy informatyk wziął lub weźmie udział w nieudanym projekcie.

Odwrotnie niż w innych dziedzinach, porażka nie jest niczym wyjątkowym w pracy zespołów informatycznych. Jest raczej stanem poniekąd normalnym, a przynajmniej powszechnym - co nie znaczy pożądanym. Dobrze jest być optymistą i wierzyć w sukces przedsięwzięcia, ale warto też przewidywać, co się stanie w przypadku klęski. Członkowie zespołu, a przede wszystkim jego kierownik, powinni wiedzieć, jak w takiej sytuacji się zachować.

Siła ciosu

Klęska przedsięwzięcia jest bardzo dotkliwym ciosem dla każdego pracownika. Przede wszystkim uraża ambicję i pogarsza jego samopoczucie, a co za tym idzie, motywację do dalszych wysiłków. Ma negatywny wpływ na karierę, bo nie można będzie wpisać do swojego CV kolejnego projektu zakończonego sukcesem. Często także "uderza po kieszeni" - bo spodziewana premia związana z zakończeniem projektu nie zostanie wypłacona. Ponadto powoduje inne perturbacje w miejscu pracy - nieprzyjemne rozmowy z przełożonymi, niemiłą atmosferę, szeptane uwagi na korytarzu.

Naturalnym odruchem wielu informatyków w zaistniałej sytuacji jest sięgnięcie po środki radykalne. Zaczynają oni kupować poniedziałkową Gazetę Wyborczą, przeglądać internetowe oferty pracy, kontaktować się z "łowcami głów". Słowem, wysyłają na rynek pracy sygnał: "Jestem do wzięcia". A ponieważ w zawodzie informatyka nie ma kłopotów ze zmianą pracy, dość łatwo znajdują nowe zajęcie.

W krótkiej perspektywie nikomu nie przynosi to korzyści. Pracownik trafia w nowe środowisko i zaczyna od podstaw budowę swojej pozycji w nowym przedsiębiorstwie. Często zgadza się na niższe stanowisko i pensję, byle tylko wyrwać się z poprzedniej firmy. Pozostaje mu też niechęć do byłego pracodawcy i poczucie zmarnowanego czasu. Firma zaś traci nie tylko doświadczonego pracownika, ale także pojawia się rysa w postrzeganiu jej na rynku (pracownik, który odszedł, na pewno podzieli się opinią na temat firmy z kolegami w nowej pracy). Nie zyskuje nic - bo nie ma żadnej gwarancji, że pozostali albo nowi pracownicy poradzą sobie z feralnym zadaniem lepiej.

Powiesić kowala

Odpowiedzialność za takie zachowania pracownika ponoszą przede wszystkim jego przełożeni. Często bowiem zachowują się wg zasady: "Kowal zawinił, Cygana powiesili". Tam, gdzie zawinili menedżerowie, karze się informatyków. W sytuacji gdy zespół informatyczny poniósł porażkę, najgorsze, co można zrobić, to go ukarać. Na pozór brzmi to niezbyt rozsądnie, ale spróbujmy się nad tym zastanowić.

Wyobraźmy sobie sytuację, w której zespół nie jest w stanie stworzyć pewnego rozwiązania, gdyż brakuje mu podstaw merytorycznych. Dobry menedżer powinien przeprowadzić projekt pilotażowy, aby sprawdzić, czy jego podwładni dysponują wiedzą, która będzie niezbędna w rozwiązywaniu rzeczywistego zadania. Jednak nie zrobił tego. Zarząd w tej sytuacji uzna informatyków za niekompetentnych i głośno im o tym powie. Tymczasem oni w całej tej sytuacji są najmniej winni - nigdy przecież nie twierdzili, że poradzą sobie z zadaniem! Winę ponosi szef, który dopuścił do rozpoczęcia prac bez weryfikacji wykonalności projektu.

Typową przyczyną porażki projektów informatycznych jest przyjęcie przez osoby odpowiedzialne za kontrakty zobowiązań przekraczających (pod względem wielkości, czasu albo stopnia trudności) możliwości zespołu informatyków. Może więc przyczyn fiaska w dziale informatyki należy szukać w dziale handlowym?

W przypadku nieudanego projektu menedżerowie często podejmują niewłaściwe działanie. Otóż, znajdują kozła ofiarnego - kogoś w zespole, kto, ich zdaniem, w największym stopniu odpowiada za porażkę. Często nawet wina tej osoby jest uzasadniona. Usuwają ją z pracy, a potem starają się przekonać zespół, iż teraz, pozbawieni "balastu", na pewno odniosą sukces. Takie postępowanie ma kilka wad. Największą jest to, że pozbywając się jednego pracownika rzadko usuwa się przyczyny problemu i zwykle będą one występować w następnym projekcie. Druga to taka, że przeciętny informatyk ma więcej zaufania do swoich kolegów niż do szefów. Trzecią jest to, że każdy pracownik w takiej sytuacji zada sobie pytanie: "Czy ja będę następny?"

Między starym a nowym

Naturalnym odruchem menedżerów w sytuacji porażki jest zwołanie zebrania, na które zaprasza się wszystkich zainteresowanych - zespół, jego kierownika, a także osobę z zarządu firmy bezpośrednio odpowiedzialną za dział informatyki. Takie spotkanie często przeradza się w mniej lub bardziej chaotyczne wylewanie żalów - kierownictwa względem zespołu, zespołu względem kierownictwa. Tworzą się dwie strony, a między nimi powstaje barykada.

A przecież wszystkim chodzi o to samo! I zarząd chciałby mieć działające rozwiązanie, i pracownicy tego chcą. Informatycy chcą się rozwijać, menedżerowie natomiast chcieliby mieć wysoko kwalifikowane kadry. Pracownicy chcą pracować nad ciekawymi problemami, dobrze zarabiać i mieć jak najwięcej satysfakcji z pracy, kierownictwo chciałoby mieć oddanych, zadowolonych i chętnych do pracy pracowników.

Uświadomienie sobie tych prostych faktów może bardzo pomóc w rozmowie między kierownikiem a informatykami. Kiedy więc wszyscy powiedzą, co mają do powiedzenia, nawet wkładając w to dużą dawkę emocji, prowadzący zebranie powinien zauważyć, że wszyscy zmierzają do jednego celu. Zamiast więc wypominać sobie, kto i co zepsuł, lepiej zastanowić się, jak nie dopuścić do powtórzenia się takiej sytuacji?

Spotkanie takie z jednej strony pozwala rozładować emocje, które inaczej wybuchłyby ze zdwojoną siłą. Z drugiej pozwala wszystkim uświadomić sobie wspólnotę celów. Jeżeli każdy ma sposobność bycia wysłuchanym, a potem współtworzyć nowe rozwiązanie, czuje się odpowiedzialny za jego realizację.

Dobrym pomysłem jest postawienie "fizycznej" granicy między starym a nowym. Można wysłać informatyków na tygodniowe szkolenie poza firmą, zmienić organizację działu, wymienić przestarzały sprzęt. Można też znieść przepis, który pracownicy uważali za dokuczliwy i bezsensowny (np. nakaz chodzenia w krawacie albo zakaz surfowania po Internecie). Ktoś powie, że to działania pozorne i typowo psychologiczne. Tak, ale psychologia to niezwykle istotny element zarządzania.

Takie działania, o ile zostały dobrze przeprowadzone, są "punktem przegięcia" na krzywej motywacji pracowników. Do tego momentu ich motywacja spadała, od tej chwili zaczyna rosnąć.

Wizja, charyzma i technologia

Jednak jeden impuls to za mało, żeby nadać zespołowi impet, który pozwoli mu w przyszłości osiągać sukcesy. Informatykom potrzeba teraz trzech rzeczy: wizji, charyzmy i technologii.

Wizja powinna zostać wypracowana podczas spotkań w zespole i uzgodniona z szefami. Powinna być zarysowana zgodnie z regułą SMART (Simple/Specific, Measurable, Agreed, Realistic, Timely), czyli być prosta i dobrze zarysowana, łatwo mierzalna i osiągalna, mieć ramy czasowe i - co najważniejsze - każdy z członków zespołu powinien czuć się odpowiedzialny za jej realizację. Wizja taka, choćby najpiękniejsza, nie może być zbyt odległa. Zespół po porażce potrzebuje sukcesu - nawet niewielkiego. Warto więc wyznaczyć sobie pewien cel minimum - bliski i łatwy do osiągnięcia.

Ważne, aby wizja była pociągająca z profesjonalnego, a także czysto ludzkiego punktu widzenia. W jednym z podręczników zarządzania zespołami informatycznymi podany jest przykład kierownictwa, które zapragnęło, aby informatycy podjęli wzmożony wysiłek w celu budowy systemu informatycznego dla firmy, która chciała, dzięki nowemu narzędziu, zakończyć okres obrachunkowy rekordowym zyskiem. Propozycja ta spotkała się z całkowitym lekceważeniem ze strony informatyków, mimo stworzenia zachęty finansowej. Dlaczego? Ponieważ klientem była firma udzielająca osobom, które znalazły się w tarapatach, krótkoterminowych pożyczek na wysoki procent (rzecz działa się w USA, a biznes był legalny tylko w niektórych stanach). Nie jest to działalność, z którą przyzwoity człowiek mógłby się identyfikować, cel więc nie dał energii informatykom.

Drugi z czynników, które dadzą zespołowi codzienną motywację, to charyzmatyczny przywódca. Osoba znakomicie przygotowana merytorycznie, pracowita, oddana firmie, mająca dobre kontakty z pracownikami potrafi pociągnąć za sobą cały zespół. W źródłach anglojęzycznych taka osoba nazywana jest czasami hornblower (dmący w róg), co natychmiast kojarzy projekt informatyczny z bitwą albo polowaniem. Taki przywódca nie musi być kierownikiem czy dyrektorem, ale musi mieć osobistą charyzmę, autorytet i upór. Firma, która ma takiego człowieka, nie powinna wzbraniać się przed odciągnięciem go od innych zadań i skierowania jego energii w zespół, który właśnie przeszedł kryzys.

Trzeci czynnik jest bardzo charakterystyczny dla zespołów informatycznych. W ich pracy sukces w dużym stopniu zależy od technologii. Zdarza się, iż projekt kończy się fiaskiem, dlatego że zawiodły produkty, na których chciano zbudować rozwiązanie. Nowy projekt musi zakończyć się sukcesem, bo zespół, który przetrwał jedną porażkę, raczej nie przetrwa drugiej. Ryzyko płynące z technologii powinno być więc zminimalizowane. Najlepiej zastosować rozwiązania znane i sprawdzone, choćby nawet przestarzałe.

Między optymizmem a ostrożnością

Tradycyjne reguły zarządzania nakazują tchnąć w ludzi możliwie dużo optymizmu. W księgarniach można nawet kupić podręczniki pozytywnego myślenia, które nakazują kilka razy dziennie powtarzać sobie mantrę w rodzaju: "Na pewno mi się uda". Niektórzy menedżerowie stosują tę regułę wobec zespołów, powtarzając im, że są wspaniali i na pewno odniosą wielki sukces.

Można jednak się obawiać, czy wpajanie optymizmu w ten sposób nie spowoduje postawienie sobie zbyt ambitnych celów i zanik krytycyzmu wobec swojej pracy. Jest tylko jedna rzecz gorsza od porażki - powtórna porażka. Tym bardziej wtedy, gdy najpierw stworzono sobie wielkie nadzieje. Zespołom, które przeszły kryzys, warto zalecić ostrożność zamiast optymizmu.

Przyjdzie taki moment, kiedy informatycy sami się zorientują, że już wiele dokonali. Będzie to pierwsze wdrożenie systemu, pierwszy laur na targach czy wystawie albo pochlebny artykuł w tygodniku branżowym. Sukces będzie wiarygodny tylko wtedy, gdy zostanie odnotowany przez kogoś nie zależnego ani od zespołu, ani od kierownictwa firmy.

Gotowi na porażkę, gotowi na sukces

W projektach informatycznych, tak jak w życiu, zdarzają się porażki. Na szczęście, nie tylko one. Dobry menedżer, który przeprowadzi swój zespół przez fiasko, może liczyć, że po jednym nieudanym projekcie przyjdzie następny, który przyniesie zwycięstwo. Zespoły informatyczne, które są przygotowane, aby przetrwać klęskę, będą też lepiej przygotowane na sukces.

Na szczęście, sukces to w zarządzaniu znacznie łatwiejsze zagadnienie niż porażka.

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

TOP 200