Oprogramowanie to produkt niezwykle ciekawy - w całości jest niematerialne i w całości "wymyślane". Tworzywem, z jakiego powstaje, jest niczym nie skrępowana myśl ludzka, możliwa do zapisania na nieskończenie wiele sposobów, przy użyciu skończonej liczby poleceń znanych nam języków programowania.

Sięgając pamięcią wstecz do moich poprzednich projektów oraz obserwując kolegów prowadzących swoje przedsięwzięcia, zadałem sobie pytanie: co trzyma nas przez wiele miesięcy przy projektach, które wymagają ogromnego wysiłku, wielu wyrzeczeń i samozaparcia, a ponadto, statystycznie rzecz ujmując, łatwiej tam o porażkę i wszelkiego rodzaju zarzuty niż o sukces i glorię chwały. Bez wątpienia najważniejszym elementem jest wypracowana przez każdego z nas wizja produktu. Rozpoczynając projekt i chcąc przetrwać, trzeba taką wizję zbudować, a także zadbać o to, aby kluczowe osoby w projekcie taką wizję również wypracowały. Wcale nie musi to być jedna i ta sama wizja dla każdego - ważne, by każdy w realizowanym projekcie widział szansę na urzeczywistnienie własnej wizji i by nie były one ze sobą sprzeczne.

Kiedy już powstanie wizja projektu, trzeba pomyśleć o wsparciu. Bez niego bowiem po stronie zamawiającego produkt nie można myśleć o skutecznym działaniu i sukcesie projektu. Nie oznacza to jednak, że można go rozpocząć dopiero wtedy, gdy zdobyło się sponsora. Każdy szef projektu przekonuje się jednak o jego niezbędności, np. gdy coraz trudniej przebiega proces zbierania wymagań, zatwierdzanie dokumentacji projektowej lub kolejnych prototypów napotyka opory użytkowników, zaczyna brakować funduszy na dokończenie projektu, choć wcześniej je zaplanowano, gdy z nieznanych przyczyn termin uruchomienia systemu oddala się, a decyzja o rozpoczęciu wdrożenia zaczyna być podważana. Być może zdarzy się wiele innych, z pozoru niezrozumiałych i nieracjonalnych wydarzeń, które mogą świadczyć o zmniejszeniu się zainteresowania klienta produktem. Realizując projekt, trzeba być wyczulonym na takie sygnały. W większości przypadków są one oznaką braku odpowiednio umocowanego sprzymierzeńca po stronie zamawiającego, kogoś, kto będąc rzecznikiem swoich interesów byłby jednocześnie rzecznikiem projektu. Bez takiego sprzymierzeńca niezwykle trudno poruszać się w labiryncie formalnych i nieformalnych układów, panujących w firmie, w której uruchamiany jest system.

Praca po myśli szefa

Realizując własną wizję systemu, trzeba sterować pracą wielu ludzi. Im większy system, a co za tym idzie, większy zespół, tym mniej czasu na zajęcie się każdym z osobna. Jak więc, mimo krótkiego czasu spędzanego z wykonawcami oprogramowania, zapewnić oczekiwaną postać systemu? Należy jasno precyzować kryteria sukcesu, które będą przydatne przy ocenie pracy zespołu. Im więcej menedżer projektu chce osiąg-nąć, tym większy ma dylemat - które kryteria są najważniejsze, na których zadaniach skoncentrować uwagę swoją i kolegów, co uznać za miary osiągniętego sukcesu?

Problemem kierowników jest wiara w możliwości twórcze podwładnych. Akceptowanie błędów popełnianych przez pracowników jest niezwykle trudne. Przede wszystkim irytuje, że produkt jest zły, a przynajmniej nie tak dobry, jak kierownik by sobie życzył. Podświadomie jest przekonany, że sam wykonałby go lepiej, nie popełniłby tych oczywistych błędów, które popełnili pracownicy. Dlaczego tak sądzi? Gdyż uważa siebie za doświadczonego i kompetentnego pracownika, który z niejednego pieca chleb jadł, i wie, jak należy to zrobić. Dlaczego więc inni popełnili te błędy? Zadaje pytanie: jak nie dopuścić do powstawania dalszych niewłaściwych i nieadekwatnych rozwiązań? Jeśli uważa podwładnych za równie doświadczonych i kompetentnych jak on, to rzeczywiście problem istnieje. Jeśli jednak jest to grupa młodych (i nie myślę tutaj tylko o wieku) pracowników, musi uzbroić się w cierpliwość i stworzyć im dogodne warunki do dojrzewania i nabierania kompetencji. Jakość oprogramowania to przede wszystkim jakość myślenia pracowników. Narzędzia są sprawą wtórną. Jeśli doświadczonej i kompetentnej kadry nie można znaleźć na rynku pracy, pozostaje mu ją wykreować spośród swoich pracowników.

Dylematy twórców

Powszechne jest przekonanie, iż największe korzyści w procesie wytwórczym oprogramowania może przynieść stosowanie "reużywalnych" komponentów. "Reuse" robi karierę zarówno w świecie gotowych produktów reklamowanych jako klocki nadające się do wkomponowania w większą całość, jak i w świecie projektowym, gdzie metodologia obiektowa jest uważana za antidotum na wielokrotne rozwiązywanie podobnych problemów kolejnych klientów. Oprócz aspektów technologicznych, umożliwiających realizację tej idei, ważnym elementem jest aspekt psychologiczny.

Wiele zespołów szermując ideą "reużywalnych" komponentów, zamiast użyć w swoich produktach gotowych komponentów, decyduje się na pisanie nowych, własnych, również teoretycznie "reużywalnych" komponentów. Pozostaje jednak pytanie, kto skorzysta z ich komponentów, skoro kolejny zespół postąpi dokładnie, tak jak oni, czyli napisze od nowa kolejny, własny, "reużywalny" komponent? Jak przekonać zespół, aby wykorzystał komponent opracowany przez innych? Jak przekonać go o tym, że funkcjonalność komponentu będzie zgodna z potrzebami, bo przecież nikt nie ma wątpliwości, iż początkowa specyfikacja jest zazwyczaj daleka od rzeczywistych potrzeb? Jak przekonać, że poziom błędów będzie niewielki i z tego tytułu nie przysporzy dodatkowych problemów, ponieważ nikt nie lubi odpowiadać za nie swoje winy? Jak przekonać zespół, że modyfikacje komponentu i jego dalszy rozwój będą zapewnione i dostosowane do tempa prac nad głównym produktem?

"Reużywalność" to nie technologia, to nie szczycenie się możliwościami ponownego wykorzystania, lecz podejmowanie decyzji o ponownym wykorzystaniu. Problem wzajemnego zaufania w jednym czy w dwóch blisko ze sobą współpracujących zespołach zazwyczaj nie występuje. Realizacja dużego systemu informatycznego to równoczesna praca kilku bądź kilkudziesięciu osób, zorganizowanych zazwyczaj w kilka, bardzo rzadko w kilkanaście zespołów. Komunikacja i przepływ informacji między poszczególnymi zespołami jest podstawą do tworzenia wzajemnego zaufania i poczucia tożsamości. Brak trwale wbudowanych w organizację projektu (czy szerzej - w organizację firmy) mechanizmów komunikacji i wymiany informacji oraz odpowiednich zasobów wspierających działanie tych mechanizmów będzie przeszkodą w efektywnym i wydajnym zarządzaniu zasobami i skutecznym stosowaniu reuse.

Kłopoty z planowaniem

Obecna wiedza o tym, czym jest oprogramowanie, jak się je tworzy i uruchamia, powinna wystarczać do tego, aby proces wytwórczy mógł być w pełni zaplanowany i przewidywalny. Dlaczego więc w tak wielu uruchamianych przez nas projektach terminy są permanentnie przekraczane, a większość zadań wykonywanych "za pięć dwunasta"? Wytłumaczenie, że przyczyną opóźnień i spiętrzeń zadań jest zmiana wymagań użytkownika, przychodzi nam chyba zbyt łatwo. Rzeczywiście, jest ona najczęstszą przyczyną opóźnień, lecz nie jedyną. Przy ustalaniu terminów realizacji produktów zapomina się o dostępnym nam bogactwie wiedzy z zakresu inżynierii oprogramowania i poddaje tzw. myśleniu życzeniowemu. Wprawdzie wiadomo, jakie czynności powinno się wykonać i ile czasu powinny trwać, jednak przyjmuje się optymistycznie, iż będą trwały krócej i będą możliwie najprostsze. Zamiast planować na podstawie zebranych doświadczeń i posiadanej wiedzy, planowanie przeprowadza się według oczekiwań - własnych, przełożonych, klienta. Realizując oprogramowanie, stale myślimy w kategoriach optymistycznych. Ponieważ każdy, nawet najmniejszy fragment oprogramowania zależy od kierownika projektu i jego zespołu, od jego wiedzy i pomysłowości, lecz niejednokrotnie brakuje mu odwagi, by powiedzieć, że coś może się powieść, czegoś nie da się wymyślić i coś można przeoczyć. Realna ocena pracochłonności przygotowania oprogramowania jest wciąż piętą achillesową. Zbyt mało czasu i uwagi w naszych planach poświęcamy analizie zagrożeń i przyczyn, które powodują przekroczenie kolejnych terminów i punktów kontrolnych.

Niesforne zmiany

Jednym z największych wyzwań, przed jakimi stoi zarządzanie projektami, jest uporanie się z problemem wprowadzania zmian do oprogramowania czy też szerzej do systemu informatycznego. Być może w mniejszym stopniu jest to problem inżynierii oprogramowania, w większym - problem organizacji pracy. Plastyczność tworzywa, z jakiego powstaje oprogramowanie, nie stawia naturalnych barier przed wprowadzaniem zmiany. Jedyną ochroną, która nas może przed tym bronić, jest wytworzona przez nas procedura wprowadzania zmian, a właściwie nie tyle sama procedura co reżim jej przestrzegania. Procedurę łatwo stworzyć, lecz jeszcze łatwiej jej nie stosować. Wbudowanie w proces produkcyjny mechanizmów ułatwiających wprowadzanie i zarządzanie zmianami jest wyzwaniem dla każdego projektu. Sedno problemu kryje się w niewinnym sformułowaniu "zarządzanie zmianami". Niestety, prawdopodobnie większość z nas daje się "ponosić zmianom". Oprócz tzw. czynników politycznych, które często wymuszają taką postawę, istotnym elementem są: przygotowanie do monitorowania wprowadzanych zmian, śledzenie ich wpływu na istniejący już system oraz dokładność szacowania pracochłonności jej wykonania. Kierownik projektu intuicyjnie wyczuwa, że zmodyfikowanie produktu powoduje jego potencjalną destabilizację. Zdaje sobie sprawę, że produkt wygrzewany od długiego czasu może nagle okazać się niewyjaśnialną zagadką. W większości konsekwencje wprowadzania zmian są nieprzewidywalne w ogóle bądź w stopniu zadowalającym szefa projektu i klientów. Stabilność i niezmienność wymagań to cechy, o które zabiega każdy szef projektu, i których prawdopodobnie nikt nie osiągnie.

Próba czasu

Wytworzenie dobrego produktu to nie wszystko. O sukcesie produktu decyduje bowiem to, czy jest on używany i czy przetrwał próbę czasu. Czy użytkownicy nauczyli się pracować przy użyciu produktu i stosują go efektywnie? Czy produkt nie "ugiął się" pod naporem zgłaszanych błędów? Czy nie trzeba wycofać się z eksploatacji w wyniku niespełnienia oczekiwań i potrzeb użytkowników? Czy produkt nie starzeje się szybciej niż tempo, w którym autorzy są w stanie go rozwijać? Mogłoby się wydawać, iż pozytywna odpowiedź na te pytania zależy przede wszystkim od poprawnie zdefiniowanego i dobrze przeprowadzonego cyklu wytwórczego oprogramowania. Niestety, tak nie jest. Uruchomienie systemu informatycznego to kolejny element nierozerwalnie związany z cyklem "życia" systemu, który wykracza poza ramy typowej inżynierii oprogramowania. Więcej w tym przypadku można wysnuć stosując elementy psychologii, a niekiedy socjologii.

Przystępując do uruchomienia systemu, trzeba zdać sprawę, że jest to proces naszpikowany ludzkimi obawami, zmartwieniami, rozczarowaniami, troskami oraz poczuciem zagrożenia i niepewności. Uruchamiany system zmienia sposób funkcjonowania firmy lub jej części. Im większy jest system, tym trudniej wyobrazić sobie i opisać, jak poszczególni jego użytkownicy będą funkcjonować po jego uruchomieniu. Im większy system, tym czas jego wdrażania dłuższy, a co za tym idzie potencjalnie większy wysiłek i zmęczenie jego nowych użytkowników. Nawet drobne i pozornie nieistotne dla systemu niepowodzenia procesu jego uruchamiania mogą zamieniać się w lawinę porażek: od utraty entuzjazmu i biernego przyglądania się uczestników projektu począwszy, poprzez nagłaśnianie nawet drobnych niepowodzeń procesu i zauważonych usterek systemu, aż po jawną negację i odrzucenie produktu. Silne wsparcie procesu uruchomienia systemu, pełna dyspozycyjność personelu w tym okresie oraz błyskawiczne reagowanie na zgłaszane problemy to czynniki mogące przechylić szalę projektu w stronę sukcesu.

Dużej delikatności wymaga zadanie komuś pytania, dlaczego coś mu się nie udało. Kontrola postępu prac jest jednak jedynym sensownym próbnikiem tego, co dzieje się w projekcie. Oczekiwanie na powstanie gotowego fragmentu programu to zdecydowanie za niski poziom kontroli. Jak skutecznie przeprowadzać kontrolę? Przede wszystkim trzeba pozbyć się negatywnych konotacji, związanych z procesem przeprowadzania kontroli, i skupić na zrozumieniu przyczyn, które powodują niedotrzymanie terminów punktów kontrolnych. Proces kontroli powinien prowadzić do usuwania przyczyn opóźnień tak, by kolejne nie pojawiały się. Dobrym i chyba w dłuższej perspektywie najskuteczniejszym sposobem kontroli prac jest wprowadzanie na szeroką skalę wzajemnych przeglądów i weryfikacji przez "drugą rękę". Jawne i świadome wprowadzanie tego typu punktów kontrolnych spełnia podwójną funkcję. Z jednej strony dyscyplinuje zespół do zamknięcia produktu lub etapu prac w określonym terminie, z drugiej zaś służy jako element działań projakościowych. Zanim powstanie działający kod programu, testowanie nie jest możliwe - wzajemne przeglądy, inspekcje kodu oraz weryfikacje i recenzje są praktycznie jedynymi możliwymi do podjęcia działaniami o charakterze weryfikacyjno-walidacyjnym.

Pobudki do działania

Największym wyzwaniem dla każdego kierownika projektu jest poziom wewnętrznej motywacji i osobistego zaangażowania ludzi wchodzących w skład jego zespołu. Wszystkie wymienione czynniki sukcesu projektu informatycznego są ważne, ale każdy z nich bezpośrednio ma podstawę w ludzkich charakterach. Z punktu widzenia procesu produkcyjnego najlepiej byłoby, aby proces wytwórczy oprogramowania był w możliwie największym stopniu zautomatyzowany - mniej podatny na ludzkie błędy. W pewnym stopniu - mniej bądź bardziej świadomie - dążymy do budowania fabryk oprogramowania, sterowalnych i wysoko wydajnych kombinatów do przetwarzania myśli ludzkiej. Stale powracająca rozterka, czy produkcja oprogramowania to sztuka, czy raczej rzemiosło, jest wyrazem wątpliwości, czy ludzka myśl - budulec, z którego powstaje oprogramowanie - może stać się materiałem przemysłowym. Pracując na co dzień nad produkcją oprogramowania, balansujemy między rutynowymi czynnościami, sprowadzającymi nas do roli niezwykle inteligentnych maszyn, a momentami powstawania niezwykle wyrafinowanych rozwiązań, które dają poczucie tworzenia i zmiany otaczającej nas rzeczywistości. Jeśli prowadząc projekt, udało się wytworzyć produkty, które noszą piętno osobowości jego szefa, jeśli udało się wytworzyć w zespole postawy i zachowania harmonizujące z jego wyobrażeniami o sposobie budowania systemu informatycznego, z pewnością był to dla niego udany projekt.

I tak powstała lista dziesięciu najważniejszych zagadnień, które należy brać pod uwagę prowadząc projekt informatyczny:

- wizja pojektu

- sponsor

- kryteria sukcesu

- doświadczona i kompetentna kadra

- komunikacja i przepływ informacji

- planowanie i analiza ryzyka

- zarządzanie zmianami

- silne wsparcie wdrożenia

- kontrola postępu prac

- motywacja i zaangażowanie ludzi.

Analizując poszczególne punkty tej lity, można dostrzec, że nie ma w niej nic, czego nie zawierałby podręcznik inżynierii oprogramowania i o czym dotychczas nie słyszelibyś-my. Dlaczego więc warto o nich pisać? Odnoszę wrażenie, że sposobów na osiągnięcie sukcesów w projekcie upatruje się w innych, mniej istotnych czynnikach. Wydaje mi się, że wciąż wśród osób zamawiających produkty informatyczne i tych, które je realizują, brak wystarczającego zrozumienia procesu wytwórczego i poszczególnych jego elementów oraz świadomości praw, jakie nim rządzą. Problem jest tym większy, gdyż skala realizowanych systemów informatycznych z roku na rok wzrasta i zmusza do postrzegania projektów informatycznych z zastosowaniem czynników zamieszczonych na ww. liście.

Włodzimierz Serwiński jest pracownikiem Prokom Software SA, kierownikiem projektu oprogramowania Kompleksowy System Informatyczny ZUS.