Antywzorce w zarządzaniu projektami informatycznymi

0
1318

Artykuł o zarządzaniu projektami informatycznymi w czasopiśmie dla deweloperów? Czyżby i już tutaj sięgały macki wszechmocnych menadżerów? Otóż nie, artykuł ten jest adresowany do Ciebie – dewelopera, biorącego udział w projekcie informatycznym.

Na co dzień żyjesz w świecie pełnym wyzwań, być może tworzysz przełomowe rozwiązanie lub utrzymujesz starożytny system informatyczny. Musisz dokonywać cudów w piątkowy wieczór i uczyć się podczas snu. Na biurku wśród stosów dokumentacji, gdzieś pod kubkiem od kawy leży ponowienie ponowienia prośby o wykorzystanie zaległych urlopów. Realizujesz zadanie, do którego potrzeba 1.4241 dewelopera. Brzmi znajomo? Jeśli tak, ten artykuł jest właśnie dla Ciebie.

Postaram się wskazać najczęściej pojawiające się błędy w zarządzaniu projektami. Tematyka poruszona w artykule to antywzorce projektowe, złe praktyki rozpoznawane i opisywane od lat. Jeśli chcesz wiedzieć, dlaczego tak wiele projektów kończy się niepowodzeniem, a idolem dla większości z Nas jest Dilbert i Chuck Norris – zapraszam do lektury.

Antywzorce projektowe

Podstawowe informacje dotyczące antywzorców zawarłem w artykule „Antywzorce projektowe” (SDJ 21 2006), dla przypomnienia jednak – kilka podstawowych faktów.

Antywzorzec to opis złej praktyki – błędu popełnianego na tyle często, iż został zidentyfikowany, nazwany i udokumentowany. Podczas gdy wzorce projektowe prezentują poprawne rozwiązania pewnych klas problemów, antywzorce wykorzystujemy w celu identyfikacji błędów w sztuce. Okazuje się, że człowiek jest na tyle skomplikowany, iż łatwiej zapamiętuje przykłady negatywne niż pozytywne – z tego też powodu antywzorce są poręcznym narzędziem dydaktycznym.

Antywzorzec nie byłby przydatny, gdyby zawierał tylko opis błędu. To, czego potrzebujemy i co zostanie zaprezentowane również w niniejszym artykule, to przykłady działań, które należy podjąć, aby naprawić popełniony błąd. Większość antywzorców jest efektem konkretnej postawy członków zespołu, w którym go zidentyfikowano. Poprzednio opisane zachowania ludzkie prowadzące do powstawania złych praktyk to między innymi duma, lenistwo, zachłanność, pycha czy ignorancja.

Wzorce projektowe często kojarzone są jedynie z konstrukcjami programistycznymi. Antywzorce projektowe omówione poprzednio, dotyczyły głównie zadań związanych z tworzenia oprogramowania. Nie można jednak zapomnieć, iż wzorce i antywzorce w projektach informatycznych napotykamy na każdym etapie. Czy to podczas zbierania wymagań, tworzenia architektury systemu, kodowania, czy też w zarządzaniu projektem.

Błędy w zarządzaniu projektami

Nim przejdziemy do omówienia poszczególnych antywzorców projektowych, pragnę poprosić Cię o jedno. Jeśli zauważysz, iż w Twoim projekcie wystąpił antywzorzec, porozmawiaj o tym z członkami zespołu. Zgłoś to menadżerowi i nie poddawaj nawet jeśli nie spotkasz się z pozytywną reakcją. Podstawowy antywzorzec to brak świadomości istnienia antywzorców. Być może brzmi to enigmatycznie, zauważ jednak, iż gdy potrafisz zidentyfikować błąd, potrafisz się przed nim ustrzec wszak po to właśnie opracowuje się antywzorce!

„Don’t Worry, Be Happy”

Tytuł piosenki Bobby’ego McFerinn’a świetnie oddaje stan jaki panuje w wielu projektach informatycznych. Pośpiech, lenistwo lub brak doświadczenia w prowadzeniu projektami, stwarza sytuacje, w których nikt nie pomyślał o zastosowaniu choćby podstawowych zasad zarządzania procesem wytwarzania programowania. Antywzorzec ten, zwany też inaczej „nil desperandum” (łac. nie ma powodu do rozpaczy) jest dość łatwo zidentyfikować. Jeśli słyszysz lub być może sam niedawno wypowiedziałeś magiczne zaklęcie „Powiedz mi, czego chcesz, a ja to zakoduję” – masz do czynienia z tym antywzorcem. Myślisz, że nie potrzebujesz projektu systemu? Nie ma potrzeby kłopotać klienta i spotykać się w celu przedyskutowania wymagań? Piszesz doskonały kod, który nie potrzebuje testów? Proszę powiedz, że na żadne pytanie nie odpowiedziałeś twierdząco.

Niestety, brak świadomości istnienia procesu wytwarzania oprogramowania prowadzi do przekroczenia kosztów budowy rozwiązania informatycznego, zerwania kontraktu, czy też stworzenia nikomu nie potrzebnego systemu.

Przykładem może być tu projekt dotyczący stworzenia Intranetu w pewnej firmie. Projekt został zaplanowany na 2 tygodnie, deweloperzy, aby lepiej współpracować pojechali kodować do siedziby klienta. Po 2 miesiącach stworzono zalążek systemu, który pracownicy klienta przeklinali, bo chociaż był piękny, to pracował bardzo wolno. Nikt nie przewidział, że zespół klienta to ponad 2 tysiące pracowników, znaczne obciążających serwer Intranetu. Co więcej, mimo, że deweloperzy twierdzili, iż spełnili wymagania klienta, ten nie chciał zapłacić uzgodnionej kwoty. Jako powód podał brak 75% wymaganej funkcjonalności. Czy tylko zbiegiem okoliczności było to, że pozostałe 25% zostało wykonane perfekcyjnie i pracowało na potrzeby działu HR, z którym sąsiadował pokój programistów? Na całe szczęście tego typu sytuacje zdarzają się dość rzadko.

Większość menadżerów ma już świadomość istnienia procesu zarządzania projektem informatycznym, a i dla deweloperów znajomy jest Rysunek 1.

rys1-2

Jeśli jednak nie wiesz, czym jest proces wytwarzania oprogramowania, ten artykuł Ci nie pomoże. Temat ten stanowczo wymaga zgłębienia i jest zbyt rozległy, aby poruszyć go na tych kilku stronach. Nie muszę chyba mówić, że to będzie także Twoja wina, jeśli np. nie przetestowane/rozwiązanie zostanie (w najlepszym przypadku) zwrócone do kosztownych poprawek. Jeśli więc posiadasz odpowiednie doświadczenie, nie zgadzaj się na łamanie podstawowych zasad i dobrych praktyk wytwarzania oprogramowania. Podstawowy antywzorzec rozwiązuje się bardzo prosto – należy wprowadzić proces zarządzania projektem. Niestety bez pracy nie ma kołaczy lub jak mawiają Anglosasi „No pain, no gain”.

Nieracjonalne zarządzanie

Załóżmy, że dysponujemy kierownictwem zespołu rozumiejącym, że planowanie jest potrzebne. Konieczne jest upewnienie się, że menadżerowie nie popełniają podstawowych błędów w planowaniu. Śledzenie projektu na każdym z etapów prac jest niewątpliwie potrzebne, jednak nikt nie potrafi poprawnie oszacować zadań zależnych od specyfikacji wymagań klienta, które jeszcze nie zostały dostarczone.

Błędy w zarządzaniu projektem zdarzają się zawsze, mogą przyjąć rozmiar antywzorców opisanych poniżej, takich jak Marsz ku klęsce, czy Zamrożenie w fazie analizy. Najczęściej powodują je tzw. „Trudni ludzie”, których obecność w projekcie jest także jednym z antywzorców. Nie potrafiąc lub nie znając specyfiki projektu podejmują błędne decyzje. Nowy menadżer w projekcie, który realizuje pewne zadania niespełna od roku, może błędnie alokować ludzi. Brak mocy decyzyjnej może powodować, iż przez kilka pierwszych miesięcy tworzy się dokumenty zamiast rozpocząć kodowanie. Na efekty nie trzeba długo czekać. Systemy, które powstawały w przeciągu kliku tygodni nie są odpowiednio przetestowane, najczęściej dlatego, iż menadżer nie założył tego typu zadania.

Można zaryzykować stwierdzenie, że jeśli podejmiemy się zarządzania projektem i zatrudnimy menadżera, niemal w 100% pewne jest, iż podejmie on, choć jedną nieracjonalną decyzję. Nie ma ludzi nieomylnych i kontrola samego procesu zarządzania też jest konieczna. W przeciwnym przypadku otrzymamy projekt, który stanie się typowym źródłem antywzorców w zarządzaniu. Akcje zapobiegawcze w tym przypadku sprowadzają się praktycznie do podnoszenia kwalifikacji menadżerów. Wraz ze zbieraniem doświadczenia, osoby kierujące projektem zdają sobie sprawę z najczęściej popełnianych błędów i potrafią ich unikać. Z punktu widzenia programisty warto zaznaczyć, iż to właśnie Nas często pyta się o oszacowanie czasu projektu – jeśli zrobimy to źle, lub przeoczymy pewne zadania, z pewnością zapłacimy za to w przyszłości.

Marsz ku klęsce

W znanej większości menadżerów książce Edwarda Yourdon’a „Death March”, autor opisał i zdefiniował grupę projektów z góry skazaną na niepowodzenie. Podana definicja zakłada, iż projekt skazany na klęskę to taki, w którym brakuje ponad 50% zasobów. Z pewnością powierzono Ci nie raz zadanie, które powinno wykonać kliku programistów To przykład braku prawidłowego oszacowania kadry potrzebnej do realizacji projektu. Analogicznie, o 50% za niski budżet lub zadeklarowany czas trwania projektu krótszy od porównywalnych projektów o 50%, prowadzi do fiaska danego przedsięwzięcia. Podobne założenie dotyczy także celów projektu, które często nie tylko trochę, ale nawet o ponad 50% mają przewyższać standardowo opracowywane rozwiązania.

Doświadczenie uczy, iż niemal każdy projekt informatyczny to marsz ku klęsce, według definicji Yourdon’a. Nie należy, więc od razu załamywać rąk. To co potrafi dobry menadżer projektu, to identyfikacja tych zasobów, które są krytyczne i stwarzają ryzyko w projekcie. Następnie z wykorzystaniem dostępnych środków, ryzyko to można próbować minimalizować.

Przykładem może być mała firma programistyczna, która choć posiada bardzo niewielkie środki zobowiązała się stworzyć złożony system o bardzo specjalistycznej funkcjonalności (nie trzeba chyba wspominać, iż o dziedzinie problemu, który miał wspierać system, w zespole programistów nikt nic nie wiedział). Jedyne, co przemawia na jej korzyść to czas projektu, który jest dość luźno określony.

W takim przypadku, sprawny menadżer może zaproponować klientowi dostarczanie kolejnych modułów, jako wyników kolejnych etapów projektu. Firma miast narażać się na kredyt, będzie miała stałe źródło dochodów, mały zespół łatwiej przetestuje, zaprojektuje, wykona i wdroży niewielkie moduły. Korzyść zaś z przyrostowego wytwarzania oprogramowania, to w tym przypadku możliwość szybkiej reakcji na potrzeby klienta, który przecież niekoniecznie musi posiadać całą oczekiwaną funkcjonalność od razu. Najważniejsze w przypadku zidentyfikowania antywzorca „marsz ku klęsce” jest odpowiednie zidentyfikowanie przyczyny marszu. Gdy nic innego już nie pomaga, proponuję uciekać. Marsz trwa często do kilku lat, w zależności od zasobów organizacji. Niestety kadra kierownicza, która nie potrafi odpowiednio zareagować i zapobiec skutkom marszu, przyczyni się tylko do klęski projektu.

„Mushroom management”

W kolejnej kultowej już niemal książce „The Soul Of A New Machinę” Trący Kidder opisuje projekt informatyczny, w którym udział biorą młodzi deweloperzy oddzieleni od oczekiwań klientów. Hodowla grzybów, jak potocznie można przetłumaczyć anglojęzyczną nazwę antywzorca, to sytuacja niestety nazbyt częsta w projektach.

Kierownictwo projektu, architekci, specjaliści analizujący wymagania klientów, tworzą dokumentację oraz modele opisujące przyszły system. Sami programiści, czyli autorzy rozwiązania nie są dopuszczani do rozmów z klientem. Skutkiem tego dostarczone rozwiązanie często nie dostarcza oczekiwanej przez klienta funkcjonalności.

Często programiści padają także ofiarą dość swobodnego traktowania dokumentacji projektowej przez samego klienta. Osobiście byłem świadkiem projektów, w których klient odrzucił przedstawione mu rozwiązanie, mimo iż wcześniej zaakceptował przygotowaną dokumentację. Bardzo prostą akcją zapobiegawczą jest opracowanie prototypu systemu. Przy możliwościach oferowanych przez nowoczesne środowiska i technologie, przygotowanie tego typu przykładowego rozwiązania, nie pochłania dużych zasobów, a jest nieocenione w trakcie rozmów z klientem. Aby uniknąć sytuacji, gdy programista pisze program dla siebie, a nie dla użytkownika, należy go oswoić z problemem. Mimo, iż nasze środowisko jest postrzegane przez pryzmat stereotypów, programista nie może być izolowany od klienta i od jego potrzeb. Jeśli odpowiednio wcześnie nie zasygnalizujesz, że brakuje Ci jasnej wizji systemu, nie mówiąc już o szczegółach realizacji poszczególnych procesów – sam przyczynisz się do porażki tego projektu.

Zamrożenie w fazie analizy

Brak fazy analizy w projekcie informatycznym jest niemal niewyobrażalny. Wszak, zarówno klient jak i zespół budujący rozwiązanie informatyczne musi uzgodnić zakres funkcjonalności tworzonego systemu, i choć nieczęsto można mówić o doskonale przeprowadzonej analizie, istnieją projekty, w których za cel postawiono sobie stworzenie idealnego zbioru wymagań funkcjonalnych oraz projektu systemu. Projekty, w których faza analizy przeciąga się, są szczególnie niebezpieczne, gdyż najprawdopodobniej nigdy nie przejdą w fazę implementacji systemu. Szczególnie dobrze znają ten antywzorzec osoby, które miały okazję pracować w projektach wielokrotnie rozpoczynanych całkiem od nowa. Przyczyną może być tu zmiana kierownictwa lub głównego celu projektu.

Faza analizy służy do nakreślenia wizji przyszłego systemu, w możliwe dokładny sposób. Nie należy jednak kierować się zasadą, iż jeśli raz dokonaliśmy analizy systemu nigdy już nie wrócimy do tej fazy. Doświadczenie uczy, że dobrze przeprowadzona analiza, to nie ta, która dostarcza kompleksowej wiedzy o budowanym rozwiązaniu, w tym o najmniejszych jego szczegółach. Dobra analiza to taka, która pozwala na łatwe wprowadzanie zmian, które z pewnością pojawią się w przyszłości.

Jak widzimy na Rysunku 1. projekt informatyczny można traktować zgodnie z modelem wodospadowym, w którym kolejne fazy następują po sobie. Doświadczony menadżer wie jednak, że budowanie systemu informatycznego to proces przyrostowy. Po wykonaniu pracy, np. w fazie implementacji lub testowania, być może będziemy musieli powrócić do faz początkowych w celu weryfikacji pierwotnych założeń.

Menadżerowie mogą nalegać na dostarczanie im kompletnej analizy systemu przed podjęciem prac projektowych. Być może kierownictwo projektu boi się podjąć decyzję o realizacji systemu bez kompleksowej wiedzy o dziedzinie problemu. Możemy mieć do czynienia ze szczególnie mocnym przywiązaniem do pewnej technologii, pochodzącej z poprzedniego projektu menadżera, a nie adekwatnej do potrzeb aktualnego projektu. Zachowania tego typu blokują postęp prac projektowych lub jak sugeruje nazwa antywzorca – zamrażające.

Nawet w sytuacji, gdy projekt wyszedł poza fazę analizy, zazwyczaj długą i dostarczającą bardzo dokładnej wiedzy, antyzworzec ten może ujawnić się ponownie. Czasem podczas projektowania, implementacji lub testowania, okazuje się, że analiza nie przewidywała pewnych sytuacji lub po prostu jest sprzeczna z rzeczywistymi wymaganiami klienta. Menadżerowie, którzy już poświęcili zasoby projektu na wykonanie analizy, najczęściej będą bronili już istniejących założeń. A przecież proces wytwarzania oprogramowania zakłada zmiany. Jeśli więc pojawi się konieczność ich wprowadzenia, należy odpowiednio na nie zareagować, szacując wpływ zmiany na już istniejący system. Pod żadnym pozorem nie można stwierdzić, iż raz wykonana analiza jest już dziełem ostatecznym.

Jeśli jako programista zauważasz tego typu błędy w zarządzaniu projektem, zwróć proszę uwagę kierownictwu. Dobrze wykonana analiza to analiza, którą można zmieniać.

Panujące obecnie podejście obiektowe do projektowania programowania z definicji jest przygotowane na rozszerzanie. Coraz popularniejsze podejście architektur zorientowanych na usługi (ang. Service Oriented Architecture) również zakłada, iż rozwiązanie – kompletny system informatyczny, zostanie oparte o zestaw usług podatnych na zmiany (z tego to powodu usługa najczęściej prezentuje jedynie interfejs, ukrywając szczegóły implementacyjne).

Nie należy więc dążyć do zamknięcia fazy analizy i jej zamrożenia. Wręcz przeciwnie, w dobrze zarządzanym projekcie, faza analizy istnieje w tle. Każda zmiana wynikająca czy to z zmiany wymagań klienta, czy to z dostrzeżonych niespójności lub luk w analizie, powoduje powrót do już poczynionych założeń i ich rewalidację.

Podsumowując, faza analizy jest niewątpliwie kluczowa i bardzo ważne jest prawidłowe jej przeprowadzenie. Należy, jednak pamiętać, aby nie przesłoniła nam ona celu, jakim jest stworzenie rozwiązania informatycznego. A podczas prowadzenia prac projektowych należy zapewnić dobre zarządzanie zmianami wpływającymi na już poczynione założenia.

Plan

Każdy kto pamięta czasy poprzedniego ustroju (PRLu), z pewnością wie czym jest PLAN. Kto zaś nie pamięta, wystarczy, że rzuci okiem na kroniki filmowe z poprzedniej epoki. Plan na kilka lat, pomagał zarządzać całym krajem. Scentralizowane centrum dowodzenia, najpierw plan taki tworzyło, następnie go egzekwowało, tzn. wymagało jego wykonania. Realna realizacja była najczęściej nierealna, a raportowane postępy i wyniki istniały jedynie na papierze.

Sytuacja podobna ma niestety miejsce w wielu projektach informatycznych. Z własnego doświadczenia mogę przywołać taką oto historię.

Menadżer projektu, niekoniecznie dysponujący wiedzą informatyczną zbudował zręby planu. Podlegli mu kierownicy zespołów zdefiniowali grupy zdań, wreszcie programiści wyodrębnili pojedyncze zadania. Oczywiście dzieło takie było nie do zaakceptowania przez zarząd firmy wykonującej projekt. Plan przekraczał terminy, zakładał szkolenia oraz powiększenie zespołu. Zasiedliśmy więc do planowania raz jeszcze. Tym razem koszty się zgadzały, a kilka zadań sprytnie ukryliśmy tak, że projekt został zaakceptowany. Gdy po prawie dwóch tygodniach wystartowaliśmy, okazało się, że w planie nie przewidziano połowy zadań. Natomiast metodę oszacowania czasu wykonania pozostałych zdań z powodzeniem można byłoby wykorzystać w systemach gier losowych.

Plan w projekcie jest tylko narzędziem, pomagającym oszacować koszt i czas. Za pomocą spisanych zadań, ułożonych w piękny wykres Gantta, nie oszczędzimy pieniędzy ani tez nie wstrzymamy czasu. Jeśli menadżer projektu naciska na wykonanie planu, kiedy widzisz, że zdania uległy zmianie, musisz to zasygnalizować.

Głównym zadaniem menadżera w projekcie jest zapewnienie dobrej komunikacji między osobami zespołu i zarządzanie planem projektu. To ta osoba jest odpowiedzialna za aktualizowanie danych i śledzenie postępów w projekcie. Jeśli nie otrzyma sygnału o zmieniających się wymaganiach klienta, lub o przeciągającym się czasie wykonania szczególnie skomplikowanego zdania, nie jest w stanie prawidłowo zareagować, w tym między innymi oszacować ryzyka powodzenia projektu. Jeśli więc menadżer projektu ignoruje zgłaszane problemy z wykonaniem planu, jego kompetencje należy postawić pod znakiem zapytania.

Odważę się stwierdzić, że nie istnieje projekt w którym nie było problemów z oszacowaniem prawidłowego czasu i wysiłku jaki będzie potrzebny do stworzenia systemu informatycznego. Zawsze należy być otwartym na zmiany w planie projektu, odpowiednio zarządzać terminami, kierować się tym, że dostarczony ma być system informatyczny (lub jego komponenty) a nie doskonale zrealizowany plan.

Nawiązując do wstępu tej sekcji, wszyscy wiemy jak zakończył się projekt PRL. Obecnie coraz więcej projektów wykorzystuje narzędzia służące do zarządzania czasem oraz planowania, nie jest jednak ważne to czy się te narzędzia wykorzystuje, ale jak się to robi. Plan w projekcie jest narzędziem, które ma pomóc w realizacji celu, nie jest celem samym w sobie – należy o tym pamiętać eliminując ten antywzorzec.

Projekt – drukarnia

W każdym projekcie nadchodzi moment tworzenia dokumentacji. Zbieramy wymagania użytkowników, projektujemy rozwiązanie, proponujemy interfejs użytkownika. Tworzymy coraz więcej dokumentów, czytanych bądź też nie przez kierownictwo i klientów. Jednak, gdy programiści, testerzy, projektanci skupiają się tylko na tworzeniu dokumentacji, projekt zmienia się w efektowną fabrykę makulatury.

Pewien poziom dokumentacji jest jak najbardziej konieczny w celu zapewnienia sprawnej komunikacji między klientem a zespołem wykonującym powierzone zadanie. Również wewnątrz zespołu, pomiędzy osobami pełniącymi różne role, dokumentacja umożliwia zapisanie podjętych decyzji, ich uzasadnienie oraz stanowi punkt odniesienia w przyszłych dyskusjach.

W sytuacji, gdy tworzenie dokumentów przybiera formę głównego celu projektu, mamy do czynienia z antywzorcem. Programiści powoli zapominają jak wygląda kod, projektanci są coraz bardziej sfrustrowani wprowadzaniem kolejnych poprawek do pieczołowicie wersjonowanych dokumentów. Jedynie menadżerowie cieszą się, że coś się dzieje w projekcie, że są efekty. Klient, zaś od czasu do czasu występuje z zapytaniem, jak postępują prace Jednak szybko milknie przywalony setkami stron oraz prośbami o komentarze. Jedyny plus istnienia tego typu projektów to system hyperlinków, na którym opiera się Internet. Gdyby nie tomy dokumentacji i konieczność szybkiego odwoływania się pomiędzy stronami, zapewne nigdy nieprędko wymyślono by tego typu rozwiązanie.

Gdy czujesz, że już tak dalej nie możesz, że przenoszenie dokumentów do nowego szablonu już Cię nie cieszy, a funkcje popularnych pakietów biurowych znasz lepiej niż język programowania, którym zarabiasz na życie – czas powiedzieć dość! Zaproponuj kierownikowi, iż zamiast kolejnego dokumentu „do 20 stron” stworzysz prototyp. Jeśli jesteś projektantem, może zaproponujesz doświadczenie architektoniczne. Nie musisz przecież znać szczegółów działania wszystkich warstw aplikacji, zawsze można stworzyć moduły symulujące działanie jeszcze nie zaprojektowanych elementów.

Przede wszystkim nie pozwól, aby wycięto więcej drzew tylko na potrzeby kolejnego dokumentu, którego nikt nie przeczyta. Jeśli wiesz, że dokumentacja, którą przyszło Ci pisać, nie zostanie przeczytana zgłoś to kierownikowi projektu. Antywzorzec ten naprawdę łatwo rozwiązać, a wspomniane tworzenie prototypowych implementacji naprawdę bardzo pomoże zarówno w prowadzeniu projektu jak i w rozmowach z klientem.

Oczywiście są sytuacje, w których wykonanie dokumentacji jest konieczne. Większość projektów dotyczących administracji publicznej musi zapewniać łatwość zmiany firmy dostarczającej rozwiązanie, stąd wszelkie dokumenty projektowe są pieczołowicie przygotowywane i analizowane. Lecz nawet i w tym przypadku, nikt nie podejmuje się sporządzania interpretacji np. ustaw, które wpływają na realizację zadań w programie. Jeśli np. Twój zespół buduje światowej klasy komponent do zarządzania hodowlą słoni afrykańskich, musisz dokładnie opisać API. Należy oprócz kodu dostarczyć przykłady, ich opis słowny, może także prezentacje multimedialne. Jednak mija się z celem np. pisanie esejów o samej hodowli słoni – klient najprawdopodobniej zna temat dużo lepiej niż Ty.

Budując rozwiązanie informatyczne zawsze patrz na cel, który masz osiągnąć, dokumentacja jest tylko jednym z narzędzi, które ma Ci w tym pomóc.

Marudy

Jak już zapewne zauważyliście niemal wszystkie akapity dotyczą zachowań ludzi biorących udział w projektach. Jednym z bardzo powszechnych zachowań jest narzekanie na realizowany projekt. Brak entuzjazmu, nadziei na sukces jest bardzo częsty, szczególnie wśród programistów, którzy mieli za sobą kilka projektów. Nawet ciekawy projekt, wykonany w technologii, której się dopiero uczymy, z bogatym sponsorem, czyli marzenie każdego programisty, może stać się koszmarem, gdy wciąż powtarzamy sobie, że to się nie uda. Mówimy „miało być tak pięknie, a wyszło jak zawsze” – jednak czy mamy podstawy, aby tak mówić już przy pierwszym niepowodzeniu?

Z pewnością nie – utrzymanie dobrych morali i zarządzanie zasobem w postaci Ciebie – programisty, to obowiązek kierownika projektu. Czy będzie to piątkowe wyjście na miasto, czy zajęcia z budowania zespołu (ang. team-building), a może pizza zamówiona na koszt firmy w tą szczególnie ciężką noc przed oddaniem produktu – wszystko ma na celu jedno, podtrzymanie ducha zespołu. W przywołanej już książce „The soul in the New Machinę”, autor słusznie zauważa, że to ludzie są najważniejsi w projekcie. Dobrze przeszkoleni, zadowoleni z wykonywanych zadań, pracujący w zgranym zespole, są wydajni.

Zespół marud, rzadko odnosi sukces i choć pracują tyle samo czasu, używając tych samych technologii, wykonuje znacznie gorszą pracę. Czujesz, że już powinien być piątek i siedzisz w pracy za karę, idź do menadżera – jest przecież także po to, aby zmienić ten stan rzeczy. Jeśli Twój przełożony jeszcze nie wie, że zadowolony pracownik to dobry pracownik, być może czas mu to uświadomić. Tylko w taki sposób można naprawić, antywzorzec „marudy”.

Trudni ludzie

Często w projekcie trafiają się osoby, które ogólnie można określić jako trudne. Czy to zwolennik jednej konkretnej technologii, który podważa sensowność rozwiązań proponowanych przez inne osoby. Może to być osoba egocentryczna, która w każdym działaniu musi widzieć personalną korzyść. Zdarzają się także programiści introwertycy, którzy cierpią po każdym zgłoszeniu błędu do modułu, który był ich dziełem.

Trudne osoby są wszędzie, mogą nimi też być osoby kierujące projektem. Zazwyczaj osoba taka wprowadza niezdrową atmosferę w zespole, doprowadzając do podwyższania i tak już dużego stężenia stresu towarzyszącego projektom informatycznym.

Każdy zna sytuacje, gdy prowadzenie projektu utrudniały nadplanowe inspekcje kodu, nadzorowanie każdej minuty pracy pracowników. Dostęp do zasobów sieciowych ograniczony do kilku podstawowych stron, zablokowane narzędzia do komunikacji interpersonalnej (ang. Instant Messa-ging), tego typu ograniczenia swobody pracowników, wprowadzają niekorzystna atmosferę pracy. „Trudni ludzie” na stanowiskach kierowniczych najczęściej nie zauważają problemu dziwiąc się tylko iż zespół staje się coraz mniej efektywny, ma kłopoty z wymianą wiedzy, a z czasem z podstawową komunikacją.

Zachowań tego typu osób nie sposób uniknąć, chcąc budować własną karierę lub promują z uporem narzędzia, które poznali w poprzednich projektach, a nie są adekwatne do problemu. Wszak nawet prosty system F-K może być polem do popisu i można go zrealizować z wykorzystaniem rozproszonej bazy XML. Z drugiej strony, może natrafiłeś na osobę, która odkąd nauczyła się posługiwać narzędziami CASE w celu budowania diagramów ERD, nie może się przełamać i wykorzystać możliwości UML’a.

W szczególnie niebezpiecznych przypadkach mamy do czynienia nawet z sabotażystami. Osoby takie potrafią rozsiewać plotki np. o redukcji zatrudnienia, powodując, iż członkowie projektu zmieniają miejsce pracy. Tego typu zachowanie na całe szczęście jest dość sporadyczne i ma na celu głównie nieuczciwą eliminację konkurencji.

Nie życzę też nikomu pracować z osobami broniącymi swojej pozycji w firmie. Istnieją projekty widma, które tak naprawdę nie mają celu. Prowadzone jest fikcyjne raportowanie, klient otrzymuje sprzeczne komunikaty, efekty ciężkiej pracy programistów są pieczołowicie testowane, po czym nigdy nikt ich nie wykorzystuje. Cel – ochrona kadry zarządzającej, posiadającej poparcie kierownictwa firmy.

Temat problemu trudnych osobowości z pewnością można rozwijać. Każdy z Nas ma też zapewne w sobie, choć część cech tego typu osób. Tylko odpowiednie kontrolowanie własnych emocji i skupienie się na celu projektu może przynieść powodzenie przedsięwzięcia.

Muszę jednak zmartwić tych, którzy szukają podpowiedzi, jak rozwiązać problem „trudnych” współpracowników. Stosowanych rozwiązań jest naprawdę wiele, jednak tego typu osoby są odporne na wszelką krytykę i sugestie. Spotkałem się z sytuacją, gdy dla pewnego menadżera stworzono specjalny odrębny dział, w nim miał stanowisko z bardzo ważną i ledwo mieszczącą się na wizytówce nazwą. W przypadku sprawnie zarządzanych organizacji, trudne osobowości konfrontuje się ze sobą, np. powierzając im prowadzenie wspólnego projektu. W niektórych przypadkach wystarczy szczera rozmowa, w innych odseparowanie problemu, którym zajmuje się trudna osoba – tak, aby nie paraliżowała ona prac całego zespołu.

Gdy jednak tego typu metody nie odnoszą skutków, pozostaje polecić naszą czarną owcę agencji rekrutacyjnej. Pozbycie się z zespołu tego typu osoby, która najczęściej szczęśliwa jest, gdy otwierają się przed nią drzwi do kariery, jest najlepszym rozwiązaniem problemu.

Wiedza plemienna

Z pewnością znasz projekty, które mimo braku formalnej fazy projektowania odniosły sukces. Stworzenie portalu internetowe-go w przeciągu tygodnia przez zespół sprawnych programistów, z wykorzystaniem praktyk XP jest jak najbardziej możliwe. Ktoś rozszerza tego typu system o moduł integrujący z jednym źródłem danych, ktoś inny zapewnia mechanizmy synchronizacji ze starszym, ale wciąż używanym systemem firmy. System się rozrasta, początkowo prowadzony mały projekt, wymyka się spod kontroli, ale że wszyscy pracują w zgranym zespole, nikt nie widzi potrzeby dokumentowania zmian, czy też tworzenia projektu lub choć ogólnej architektury.

Pewnego dnia do projektu przychodzi nowa osoba – i okazuje się, iż nie znając zastanych mechanizmów nie jest w stanie rozpocząć pracy. Nikt, sam przecież obciążony poprawianiem wciąż wychwytywanych błędów, nie ma czasu, aby pomóc świeżemu członkowi zespołu.

Napotykamy kolejny antywzorzec w zarządzaniu projektami. To co z początku było atrakcyjne, czyli szybkie budowanie rozwiązania informatycznego oraz rozszerzanie jego możliwości bez obciążenia dokumentacją, mści się, gdy należy dokonać zmian w systemie, lub wprowadzić do prac nową osobę. Trudno jest, bowiem wskazać wszystkie zależności pomiędzy istniejącymi komponentami nie posługując się przy tym dokumentacją architektoniczną…

Wiedza, którą posiadają najczęściej tylko osoby bezpośrednio zaangażowane w projekt, musi być przenoszona do postaci formalnej. Samo spisanie i udokumentowanie procesów zachodzących w aplikacji powoduje najczęściej poprawienie kilku do kilkuset błędów. Nie mówiąc już o zaletach związanych z ułatwionym rozszerzaniem systemu oraz jego konserwacją.

Warto zauważyć, że nowy członek zespołu projektowego może obawiać się o swój wizerunek i przez długi czas nie przyzna się, że nie rozumie jak system działa. Co więcej osoba, którą oddelegowano do wprowadzenia nowego programisty w zadanie może posługiwać się nieznaną mu terminologią lub opisywać wykorzystywanie technologii dotąd nieznanej programiście?
Mamy tu do czynienia z kolejnym antywzorcem. Nowy członek zespołu nawet, jeśli dotąd programował jedynie w C++ wykorzystując bibliotekę Qt do generowania GUI, będzie nadzwyczaj często przytakiwał osobie tłumaczącej zaawansowane wykorzystanie Windows.Forms i platformy .NET.

Jeśli jesteś w tej sytuacji, powiedz, że czegoś nie rozumiesz. Skorzystasz z wiedzy zespołu, a zespół zyska nowego kolegę – przecież każdy lubi poczuć, iż jego dzieło lub wiedza, są przydatne.

Nie pozwól, aby wiedza czy to merytorycznie dotycząca projektu, czy ogólnie dostępna, ale Ci nie znana była zamknięta wewnątrz plemienia. Starszyzna projektowa ma obowiązek podzielić się wiedzą, aby uniknąć błędów w komunikacji. Nie ma gorszej sytuacji od tej, gdy jedna ze stron myśli, iż jest w pełni zrozumiana tylko dlatego, iż widzi nieśmiałe potrząsanie głową (na której widać oznaki rwania włosów).

Podsumowanie

Powyżej przeprowadzone rozważania nie wyczerpują oczywiście tematu. Problem błędów w zarządzaniu projektami, wykrycia antywzorców i wskazania prawidłowych rozwiązań to niewyczerpany materiał na wiele książek. Punkt widzenia uczestnika projektu – programisty, architekta, testera – jest szczególnie ważny. Musimy zdać sobie sprawę z tego, że większość ludzi niemal naturalnie wychwytuje działania błędne i tylko lenistwo, duma, czasem brak asertywności powoduje, iż tkwimy w potrzasku. Skutkiem tego pracujemy w projekcie, w którym rozpoznajemy Antywzorzec. Stresuje to Nas, demotywuje, w efekcie zniechęca do pracy. W niedługim okresie to my możemy stać się powodem powstawania kolejnych problemów, a cały projekt będzie coraz bliżej klęski niż sukcesu.

Pamiętając o tym oraz o tych kliku wskazówkach, które starałem się przekazać w tym tekście, proszę o odrobinę zaangażowania. Nie twierdzę, że zebrane tu uwagi wyczerpują temat. Poruszają go jednak choćby pobieżnie, dostarczając Ci podstawowej wiedzy do identyfikacji antywzorców.

Jeśli więc wiesz, jak możesz poprawić nie tylko swój kod, ale i otoczenie, czemu tego jeszcze nie zrobiłeś?

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ