Jak uniknąć realizacji nie przewidywanych zadań?

Planowanie nie powinno w sposób niejawny doprowadzać do przewartościowania ustalonych celów oraz zmiany hierarchii wymagań, jakie wcześniej zdefiniowano.

Planowanie nie powinno w sposób niejawny doprowadzać do przewartościowania ustalonych celów oraz zmiany hierarchii wymagań, jakie wcześniej zdefiniowano.

W wielu przypadkach praca kierowników jest mało dostrzegana lub doceniana tylko wtedy, gdy w jej wyniku powstają produkty takiego samego typu, jak produkty pozostałych członków zespołu. Jest to z pewnością cecha charakterystyczna dla organizacji, w których proces wytwórczy nie jest dojrzały i odpowiednio zdefiniowany, a kariera zawodowa odbywa się poprzez obdarzanie funkcjami kierowniczymi najlepszych programistów lub projektantów. Tymczasem dobry kierownik z pewnością musi rozumieć i "czuć" proces wytwórczy, ale nie jest prawdą, że najlepszy kierownik to najlepszy programista lub najlepszy projektant. Przy realizacji małych projektów rola kierownika często jest łączona z rolą głównego projektanta lub głównego programisty, gdyż obciążenie kierownika zadaniami kierowniczymi jest niewielkie. Trzeba jednak wyraźnie powiedzieć, że rola kierownika sprowadza się do wytwarzania specyficznych dla niego produktów menedżerskich, a dojrzałość organizacji to w dużej mierze jej zdolność do posługiwania się tymi produktami w codziennej pracy. Są to następujące produkty: plany prac, analiza ryzyka, harmonogramy realizacji zadań, kosztorysy, definicje punktów kontrolnych. Jakość tych produktów to jakość pracy kierownika.

Kłopoty z planowaniem

Być może rola kierowników jest często pomniejszana, gdyż plany pracy są często nieaktualne i nierzadko różnią się od rzeczywistego przebiegu projektu. W takiej sytuacji nie sposób uwierzyć, iż kierownik wykonuje pożyteczną pracę. Co jest więc potrzebne do tego, by plan mógł być uważany za wiarygodny i miarodajny? Przede wszystkim konieczna jest znajomość wszystkich zadań niezbędnych do wykonania produktu. Należy także oszacować wielkość pracy, jaką trzeba wykonać przy każdym zadaniu, oraz określić wydajność, na jaką można liczyć przy realizacji każdego zadania. A wszystkie te wyliczenia są przeprowadzane przy założeniu niezmienności wymagań, czyli zakresu pracy do wykonania. W zasadzie nie potrzeba do tego niczego więcej niż kilka wskazań, które zawierają wszystkie podręczniki i wszelkiego rodzaju szkolenia. Dlaczego więc w praktyce nie jest to takie proste?

W zdecydowanej większości przypadków plany zawodzą, gdyż nie uwzględniają wielu (często z pozoru drobnych) czynności, koniecznych do wykonania podczas realizacji systemu informatycznego. Dobre planowanie to dobra znajomość zadań, jakie muszą być wykonane, aby produkt mógł powstać. Jak konstruować plan, by z jednej strony nie był zbyt trywialny (czyli nie ograniczał się do podania terminu zakończenia prac), z drugiej - zbyt rozbudowany (by nie okazało się, że pracochłonność i czasochłonność jego ciągłego zmieniania wykracza poza nasze możliwości i w związku z tym przestajemy go aktualizować)? Z pomocą powinien przyjść zdefiniowany cykl wytwórczy. Pielęgnowany niezależnie od planów pracy ustanawia standardy i normy wykonania określonych prac. Odpowiednio upowszechniony nie zmusza do każdorazowego wprowadzania ustalonej sekwencji czynności do planu pracy. Wystarczy, że w planie znajdą się zdefiniowane w cyklu wytwórczym punkty kontrolne, a z każdym punktem będzie stowarzyszona lista kontrolna. Standaryzacja czynności może z pewnością rodzić wiele oporów przed zbyt rutynowym traktowaniem produkcji i budzić obawy, czy pracownicy nie zostaną sprowadzeni do roli zaprogramowanych maszyn. Jest jednak bezwzględnie potrzebna, jeśli myślimy o skutecznym i wiarygodnym planowaniu prac.

W planach zbyt często czas realizacji zadania jest ustalany nie na podstawie oszacowania wielkości zadania, lecz według oczekiwań: kierownika projektu, przełożonych, klienta. Jaki termin zaakceptuje przełożony? Jaki termin będzie satysfakcjonował klienta? Oszacowanie wielkości pracy jest dla nas wciąż jednym z największych problemów przy planowaniu terminów realizacji. Sięganie od razu po formalne metody szacowania jest być może nadmiarowe, zwłaszcza przy małych projektach. Wydaje się jednak, że w większości przypadków wystarczy proste wypisanie elementów składowych projektu lub oprogramowania (liczba zdefiniowanych wymagań, formatek ekranowych, tabel w bazie danych, raportów, procesów przetwarzania okresowego, przypadków testowych itp.), aby uzmysłowić sobie, czy oczekiwany czas realizacji jest realny. Dlaczego więc tak rzadko wykonujemy szacowania wielkości pracy? Czyżbyśmy nie mieli zaufania do naszych specyfikacji wymagań i projektów?

Problematyczna wydajność pracy

O ile wielkość produktu poddaje się szacunkom dającym się uzgodnić na bazie wielu wspólnych doświadczeń, o tyle znacznie trudniej oszacować wydajność pracy. Po pierwsze, zależy od pracy ludzi, a w bardzo wielu przypadkach od sprawności umysłowej, a nie pracy ich rąk. Jakże proste byłoby szacowanie wydajności, gdyby pisanie dokumentacji projektowej lub kodu oprogramowania było wprost proporcjonalne do szybkości pisania na klawiaturze. Niestety, wydajność myślenia w niewielkim stopniu poddaje się pomiarowi - zwłaszcza jeśli zależy nam na myśleniu wysokiej jakości. Z pomocą może przyjść statystyka, głównie statystyka własnych poprzednich projektów. Problem szacowania wydajności to również problem poziomu znajomości narzędzi. Pojawiają się nowe: język programowania, motor bazy danych, narzędzie do zarządzania kodem źródłowym, biblioteka komponentów, natomiast poprzednie statystyki dotyczące wydajności "biorą w łeb". Jak skutecznie radzić sobie z tym problemem? Nie pozostaje chyba nic innego, jak próbkowanie i pomiar w odniesieniu do reprezentatywnego dla nas przykładu.

Jak te rady zastosować w praktyce? Większość sponsorów projektów nie godzi się na to, że projekt ma trwać dłużej niż planowano, trzeba wykonać więcej czynności niż się to wydawało na początku. Wcześniej ustalony termin oddania produktu lub ogłoszona i zaprezentowana jego docelowa postać nie mogą zmienić się, gdyż narażają na szwank dobre imię jego sponsora. Wiele prac, które kierownik projektu uważa za konieczne do wykonania, nie spotyka się ze zrozumieniem ze strony zlecającego, a czasem są one traktowane wręcz jako "zjadacze czasu". Czym więc są nasze plany? W większości przypadków to oczekiwane terminy realizacji, szkice realizacji. Zapewne skuteczniejszym środkiem, stosowanym przez wiele firm, jest przejście od planowania do budżetowania i kosztorysowania. Brak sprzężenia zwrotnego między decyzją o tym, co jest konieczne i niezbędne, a realną oceną skutków podjętych decyzji zawsze będzie powodować tego typu dywagacje.

Wymowny przykład

Podczas realizacji jednego z projektów pojawił się pomysł wykonania konwertera, który (prezentując problem w nieznacznym uproszczeniu) dokonywałby scalenia 26 różnych plików (każdy o jednolitej strukturze, będących prostą reprezentacją 26 tabel bazy danych, o łącznej liczbie ok. 350 atrybutów) w jeden plik, w którym każda linia mogłaby reprezentować jeden z 26 możliwych typów rekordów. Konwerter miałby działać również w odwrotną stronę, tzn. z jednego pliku zawierającego rekordy 26 możliwych rodzajów tworzyłby 26 osobnych plików, nadających się bezpośrednio do wczytania do bazy danych. Nieznacznym utrudnieniem było to, że 16 plików stanowiło w rzeczywistości 8 zależnych od siebie par, będących reprezentacją 8 relacji master-detail. Konieczne stało się kontrolowanie spójności danych zawartych w tych 16 plikach (czy np. w plikach reprezentujących tabele podrzędne nie ma "osieroconych" rekordów). Pobieżna ocena - problem do rozwiązania przez jednego programistę w co najwyżej 2 tygodnie. Uruchomienie prac nad konwerterem miało sens tylko wówczas, gdy czas jego realizacji nie będzie dłuższy niż dwa tygodnie (termin uruchomienia systemu, po którym uruchomienie konwertera było bezcelowe). Bliższa analiza problemu pokazała, że szacowana pracochłonność wynosiłaby ok. 54 osobodni, a minimalny czas realizacji nie trwałby dłużej niż 3 tygodnie (prawdopodobnie wynosiłby ponad 4). Skąd takie wyliczenia?

Jeśli zadamy pytanie, czy po tych kilku (jakby się mogło wydawać) dniach pracy będziemy mogli uznać konwerter za odpowiedni do powszechnego, eksploatacyjnego użytku (setki uruchomień dziennie dla różnych zestawów danych) i to w dodatku przez osoby trzecie, to pojawi się zapewne zwątpienie i zaczniemy się zastanawiać, ile czasu wymaga upewnienie się, czy konwerter działa bezbłędnie (tzn. z akceptowalnym, stosunkowo niskim poziomem błędów np. jeden na 100 uruchomień). Jeśli uzmysłowimy sobie, że przygotowywanie przypadków testowych wykonywane równolegle z kodowaniem wymaga projektu, to pojawiają się kolejne osobodni. Jeśli ponadto zadamy pytanie, czy po tych kilku dniach będzie dostępna dokumentacja opisująca postronnemu użytkownikowi strukturę wszystkich plików wejściowych i wyjściowych oraz zasady transformacji, okaże się, że kilka dni roboczych to naprawdę niewiele. Jeśli do tego dodamy udokumentowany i sprawdzony przed oddaniem produktu do eksploatacji sposób obsługi wszystkich błędów (zarówno niezgodności formatu plików, jak i nieprzestrzeganie dziedziny wartości oraz łamanie reguł spójności), to liczba przewidywanych dni rośnie w mgnieniu oka. A do tego musimy dodać parę osobodni na skoordynowanie i wzajemne uzgodnienie wyników prac tych kilku osób (obok programisty pojawił się już projektant, tester i dokumentalista). Przerost formy nad treścią? Nie, jeśli myślimy o dobrej inżynierskiej robocie, za którą chcemy zainkasować zapewne spore pieniądze.

Pułapki interpretacji

Werbalnie sformułowane wymagania użytkownika, zarówno funkcjonalne, jak i niefunkcjonalne, związane z wydajnością, dostępnością, pielęgnowalnością systemu, często pozostawiają bardzo duży poziom swobody interpretacji. Wielokrotnie okazują się "czarną dziurą", pochłaniającą wszystkie dostępne zasoby. Musimy pamiętać, że o ilości pracy, jaką mamy do wykonania przy budowie oprogramowania, decyduje oczekiwany przez nas poziom jakości produktu, rozumianego zarówno w kategoriach zgodności z oczekiwaniami użytkownika, bezawaryjności działania, jak i w sensie kompletności i jakości towarzyszącej mu dokumentacji. Bardzo często za termin realizacji oprogramowania uznajemy powstanie pierwszego skompilowanego, względnie poprawnie funkcjonującego programu. Rzadko kalkulujemy czas potrzebny na testowanie, poprawę znalezionych błędów czy na szkolenia. Nie uwzględniamy czasu potrzebnego na zapoznanie końcowych użytkowników z produktem. Nie widzimy potrzeby wykonania przewodnika po systemie. Planujemy optymistycznie, zbyt optymistycznie.

Jest ryzyko

Dojrzały plan uwzględnia ocenę ryzyka. Zapobieganie zdarzeniom, które mogą mieć zgubny wpływ na projekt, to bodaj najważniejsze zadanie w pracy kierownika projektu. Zdefiniowany cykl wytwórczy, będący podstawą do planowania prac, ma m.in. taką właśnie funkcję - zapobiega przeoczeniu zadań, bez których produkt nie mógłby powstać lub powstałby z wątpliwą jakością. Jednak cykl wytwórczy nie ogarnie całego spektrum możliwych wydarzeń, które trzeba przewidzieć i należy uwzględnić w planach pracy. Najtrudniejsze przy analizie ryzyka jest zachowanie równowagi między niczym nie uzasadnionym czarnowidztwem a nadmierną pobłażliwością dla siebie i swojej firmy podczas oceny aktualnej sytuacji projektu. Ponieważ każdy, nawet najmniejszy fragment oprogramowania zależy od kierownika projektu i jego zespołu, od ich wiedzy i pomysłowości, to niejednokrotnie brakuje im odwagi, aby powiedzieć, że coś może się nie udać, czegoś nie da się wymyślić, coś można przeoczyć. Jednocześnie łatwo popaść w przesadę w ocenie zagrożeń, które pochodzą od osób postronnych i czynników zewnętrznych. Wyolbrzymianie wpływu tych czynników na projekt może być spowodowane chęcią usprawiedliwienia się, potrzebą znalezienia "kozła ofiarnego", który w sytuacji kryzysowej posłuży jako alibi.

Miary dla kierownika

Aktualność planów to miara, jaką możemy zastosować do oceny pracy kierownika. Aktualność nie oznacza niezmienności. Wręcz przeciwnie - praca kierownika musi sprowadzać się do bieżącej analizy sytuacji, analizy zmian, jakie zachodzą w projekcie i jego otoczeniu, i na tej podstawie musi być przeprowadzona aktualizacja planów. Obejmuje ona określoną pracochłonność, którą trzeba brać pod uwagę przy planowaniu własnego czasu pracy. Tym, co nie powinno zmieniać się w całym procesie aktualizacji planów, jest wcześniej ustalony cel produktu. Planowanie nie powinno w sposób niejawny doprowadzać do przewartościowania ustalonych celów i zmiany hierarchii wcześniej zdefiniowanych wymagań. Tego typu zmiany muszą być wprowadzane jawnie, a dopiero w wyniku ich podjęcia może nastąpić reorganizacja planów. Ważne, by o tej drobnej różnicy pamiętać i akcentować ją w swojej pracy.

Znana jest maksyma, która głosi, że same plany nie są nic warte, cenne jest planowanie. Nic dodać, nic ująć. Ułożenie dobrego planu z pewnością jest sztuką, a praca nad nim może okazać się interesującą wędrówką intelektualną po procesie wytwórczym oprogramowania. Mam nadzieję, że kolejne, nie dotrzymywane punkty kontrolne w naszych planach będą dla nas chwilą głębszej refleksji nie nad sposobem dotrzymania kolejnych terminów, ale nad analizą przyczyn ich niedotrzymania.

Włodzimierz Serwiński jest pracownikiem Prokom Software SA, kierownikiem projektu Oprogramowanie KSI ZUS.

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

TOP 200