Na głębokiej wodzie

Awansowanie programisty na szefa projektu informatycznego nie jest rzadkim przypadkiem. W jaki sposób awansowany może odnaleźć się w nowej sytuacji?

Awansowanie programisty na szefa projektu informatycznego nie jest rzadkim przypadkiem. W jaki sposób awansowany może odnaleźć się w nowej sytuacji?

Twój szef ściska twoją rękę i życzy ci powodzenia. Wracasz do swojego biurka, nieco oszołomiony, podekscytowany i zadowolony, ale jednocześnie gdzieś w głębi czujesz niepokój. Będziesz kierował projektem informatycznym.

Gratulacje... czy może kondolencje?

Nie robiłeś czegoś takiego nigdy przedtem. Owszem - masz ogromne doświadczenie w programowaniu czy testowaniu. Być może zetknąłeś się również z analityką biznesową, czy też byłeś zaawansowanym użytkownikiem ważnych aplikacji w firmie. Jednak nigdy nie zajmowałeś się bezpośrednio zarządzaniem całym projektem czy nadzorowaniem i kierowaniem procesu wytwórczego oprogramowania. Ale z drugiej strony jesteś bystry i wiesz co to znaczy ciężko pracować, rozumiesz, że powierzenie tobie kierowania projektem jest dowodem zaufania twoich zwierzchników. Czy to będzie bardzo trudne?

Rzucasz się do pracy. Zastanawiasz się nad produktem, nad tym, kto będzie z niego korzystał. Rozważasz, które narzędzia wykorzystać, jakie najbardziej efektowne technologie można zastosować. Wyobrażasz sobie zadowolenie wszystkich, gdy powstanie już finalny produkt. Po chwili przerywasz, przychodzi refleksja: kilka kłopotliwych myśli:

- Nikt nie powie ci, jak masz wykonać tę pracę.

- Ogromnie dużo będzie zależało od tak wielu ludzi, którzy muszą wykonać zleconą przez ciebie pracę.

- Oni będą czekali na to, co im powiesz.

To pierwsza trudność dla menedżera nowicjusza - zrozumieć swoje zadanie. Nie polega ona na dokładnym wykonywaniu szczegółowych instrukcji. Nie pozwala na zachowanie twórczej kontroli nad całym dziełem. Oczekuje się od ciebie, że w jakiś sposób będziesz umiał przewodzić. Zarazem aż za dobrze wiesz, że będziesz odpowiedzialny za rezultaty projektu. Co zatem powinieneś zrobić?

Co gorsza, nagle masz pod sobą zespół, którym musisz kierować, a to oznacza konieczność podejmowania licznych decyzji. Wiele z nich dotyczy spraw (co sobie rychło uświadomisz), na których bardzo mało się znasz. Zdajesz sobie sprawę, że istnieje jakaś właściwa droga postępowania, ale przecież nie masz teraz czasu, by zgłębiać sążniste, fachowe podręczniki teorii zarządzania (zresztą zazwyczaj nastawione na duże, złożone i stabilne projekty)" - tak obrazuje największe trudności, stojące przed niedoświadczonym kierownikiem projektu, Patricia Ensworth we wstępie do swojej książki The Accidental Project Manager: Surviving the Transition from Techie to Manager (Przypadkowy kierownik projektu, czyli jak przetrwać przejście od roli technicznej do menedżerskiej).

Życie jak program

Tom DeMarco, znany autorytet w świecie informatyki, specjalista od zarządzania projektami tworzenia oprogramowania, uważa, że programiści przez lata uczą się pewnych zachowań, które są typowe dla wirtualnego świata komputerów, ale trudno je zastosować w świecie rzeczywistym. Istotne jest, by świeżo upieczony menedżer, który jeszcze wczoraj był programistą, zdawał sobie z tego sprawę. Przykładem jest typowe dla kompilowanego kodu źródłowego odnajdywanie pojedynczych błędów. Może to trwać długo, ale gdy się wreszcie uda odszukać jeden konkretny punkt, który trzeba zmienić, by moduł czy program zadziałał prawidłowo, to uzyskanie dobrego wyniku trwa zaledwie sekundy. Zdaniem T. DeMarco często tak sądzą kierownicy projektów - eksprogramiści - rozważając przyczyny kłopotów w realizacji konkretnego projektu. Trzeba znaleźć jedną małą rzecz, od której wszystko zależy, zmienić ją i wszystko będzie w porządku. Czy trzeba podkreślać, że przekonanie to jest utopijne?

Oprócz balastu przyzwyczajeń mentalnych, były programista ma ogromne braki wiedzy dotyczącej zarządzania, w szczególności w kontekście relacji międzyludzkich. Dostępne są liczne podręczniki, ale te wszystkie spisane mądrości, zapewne pełne przydatnych i słusznych uwag, niestety nie bardzo przystają do sytuacji, w jakiej znajduje się świeżo upieczony kierownik projektu. To trochę tak, jakby uczyć się żeglowania z podręcznikiem w ręku, gdy dookoła wzmaga się wiatr i fale są coraz większe. Co prawda wspomniany Tom DeMarco pocieszał, że kierowanie ludźmi w pracy jest bardzo trudnym zadaniem, ale i tak zdecydowanie łatwiejszym niż wychowywanie dzieci. Wielu doskonałych specjalistów nie radzi sobie w sytuacji, w której zamiast zajmować się programowaniem musi nagle zarządzać nieprzewidywalnymi ludźmi.

Wielopostaciowość

Według Patricii Ensworth, praca kierownika projektu informatycznego sprowadza się do pełnienia trzech podstawowych ról.

Przedsiębiorcy, czyli kogoś, kto kieruje podległym mu działem z takim zaangażowaniem jakby to był własny biznes, ma klientów i zamawiających (czyli sponsorów). Musi dbać o budżet, uzasadniać wydatki.

Ten sam kierownik projektu czasem staje się partnerem technologicznym. W tym kontekście jest jeszcze jedną z komórek wykorzystujących zasoby firmowego działu informatyki. Musi umieć pozyskać te zasoby, a do tego potrzebne są dobre kontakty z innymi kierownikami, musi sprawić, by jego projekt nie był traktowany jako podrzędny.

Trzecia rola jest typowo menedżerska - kierownik projektu informatycznego musi być szefem zespołu. Dodatkowa trudność polega jednak na tym, że zarządzanie specjalistami od różnych technologii informatycznych, w szczególności programistami, nie jest łatwe. Czasem bowiem są to osoby o nie najlepiej wykształconej umiejętności współdziałania z innymi. Jeśli w zespole będzie wielu wybitnych specjalistów, to wiedza jaką on dysponuje nie wystarczy, aby zespół zaczął pracować jako całość. Trzeba bowiem stworzyć mechanizmy komunikacji, poznać poszczególnych członków zespołu, ich zalety i słabe strony. Wyznaczyć cele, zbudować procedury działania. Żaden nowicjusz nie zdaje sobie sprawy, jak wiele czasu i wysiłku zajmie mu utrzymywanie spójności zespołu. Ogólnie potrzeba umiejętności kierowniczych trenera zespołu piłkarskiego i empatii psychoterapeuty.

W książce opisano kolejne etapy realizacji projektu informatycznego, odwołując się do trzech ról kierownika projektu. W efekcie powstał dość spójny receptariusz zalecanych sposobów postępowania, jak również mapa potencjalnych zagrożeń i błędów, które można popełnić.

Kierowanie projektem jest całkowicie nowym dla dotychczasowego programisty (technika) zakresem odpowiedzialności. W tym przypadku kierownik musi również, oprócz odpowiedzial- ności za projekt i zespół, wziąć odpowiedzialność za użytkowników. To oni będą przecież wykorzystywać stworzony system. Tymczasem często użytkownikom brakuje informatycznej wyobraźni, nie potrafią precyzyjnie sformułować swoich potrzeb i oczekiwań. Kierownikowi projektu musi zależeć na właściwym ich odczytaniu. Umiejętność ta, dla kogoś, kto do tej pory realizował zlecone konkretne zadania programistyczne (zamknięte we wnętrzu komputera), jest czasem wyjątkowo trudna. Stąd tak częsta ucieczka w zagadnienia techniczne (czego ekstremalnym przykładem jest kierownik projektu, który sam zaczyna programować, uważając, że kod napisany przez innych nie jest wystarczająco dobry), trzymanie się raz ustalonej wersji założeń, brak umiejętności budowania biznesowych relacji pomiędzy twórcami systemu a jego użytkownikami.

Warto jednak podjąć wysiłek i ryzyko, jeśli nie chce się do końca życia być tylko programistą.

Patricia Ensworth, "The Accidental Project Manager: Surviving the Transition from Techie to Manager", Wiley & Sons 2001 r.

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

TOP 200