Planowanie projektu

Marek Rafałowicz · 04/04/2006 · Link

Planowanie projektu informatycznego jest jak planowanie wyprawy do mgliście określonego celu, przez nieznane tereny. Planujemy trochę po omacku, wiedząc, że w trakcie wyprawy czeka nas mnóstwo zdarzeń niemożliwych do przewidzenia, które wymuszą zmianę pierwotnych założeń. Czy wobec tego w ogóle warto planować? Jak się do tego zabrać?

Istota planowania

Główne problemy z planowaniem w projektach informatycznych wynikają z tego, że tworzenie oprogramowania jest działalnością twórczą. Spróbujmy przyjrzeć się analogii: wymyślenie i wytworzenie żarówki. W tym przypadku celem projektu jest "urządzenie, które będzie zamieniać prąd w światło". Czy jest sens planować przebieg projektu? Oczywiście nie. Na szczęście zwykle wizja rozwiązania jest lepiej sprecyzowana, nie co dzień budujemy IPody czy tworzymy Skype'a. Gdy mamy dokładniejsze wyobrażenie docelowego produktu (na przykład: zbudowanie urządzenia, które świeci na skutek rozgrzania elementu, przez który przepływa prąd), to planowanie istotnie zwiększa szanse na powodzenie jego realizacji. Mimo tego, że wciąż nie jest znany ostateczny kształt rozwiązania (materiały, kształt, proces wytwarzania), to możliwe jest planowanie serii eksperymentów, w różnych warunkach, z użyciem różnych materiałów, sprawdzania wybranych właściwości i cech. Takich, które w ocenie prowadzących projekt dają największe szanse na sukces.

W ogromnej większości projektów informatycznych, w ogóle nie jest potrzebne wymyślanie niczego zupełnie nowego (wbrew naszej informatycznej dumie!). Oczywiście każdy projekt jest na swój sposób innowacyjny, ale raczej wykorzystuje się pewną kompilację wcześniej znanych koncepcji i idei. Przebieg takich projektów jest zasadniczo powtarzalny a niepewność występuje na poziomie rozwiązań szczegółowych. Błędy planowania wynikające z tej niepewności mogą zostać "zamortyzowane" w trakcie trwania projektu, co pozwala, z pewnym prawdopodobieństwem, zidentyfikować listę zadań i oszacować długość trwania poszczególnych etapów.

Cele planowania

Jakie są wobec tego główne cele planowania? W czym może nam ono pomóc w takiej sytuacji? Główne korzyści można zaliczyć do trzech grup:

• planowanie porządkuje przebieg projektu,
• planowanie ułatwia życie uczestnikom projektu,
• planowanie tworzy ramy kontroli przebiegu projektu

Porządkowanie przebiegu projektu

Pierwsza z tych korzyści jest mało postrzegana przy niewielkich projektach, dlatego jest często niedoceniana przez osoby z doświadczeniem z małych projektów. Niemniej im większy projekt i im więcej zadań się na niego składa, tym rola systematycznego podejścia staje się ważniejsza. Planowanie pozwala między innymi na:

• zapewnienie ciągłości pracy dla programistów
• zrównoważenie wysiłku nad poszczególnymi zadaniami z uwzględnieniem celu całego projektu
• zmniejszenie ryzyka, dzięki identyfikacji szczególnie trudnych zadań

Brak ciągłości pracy jest śmiertelnym zagrożeniem projektu. Nie tylko powoduje stratę czasu, ale jest również szalenie demoralizujące. Straconego czasu nie da już się w projekcie odzyskać, każdy dzień spędzony nieefektywnie odsuwa końcowy termin wykonania prac. Dlatego krytycznie ważne jest, by każdego dnia wszyscy uczestnicy projektu mieli nad czym pracować, a to oznacza, że zadania dla nich muszą być przygotowane wcześniej. Codziennym pytaniem kierownika projektu powinno być: czy jutro każdy z programistów będzie miał nad czym pracować? Czy są przemyślane zadania? Zebrane wymagania? Spisane specyfikacje? W większym projekcie, w którym jest wiele osób, zadań i zależności pomiędzy nimi, nie da się tego zapewnić bez starannego planowania.

To było dosyć oczywiste, spójrzmy na mniej ewidentne korzyści z planowania. Planowanie pozycjonuje poszczególne zadania w kontekście całego projektu. Pozwala to na skupienie uwagi wykonawców na celach całego produktu i ocenę danego podzadania w kontekście roli jaką wnosi do ostatecznego rozwiązania. Łatwiej wtedy, przykładowo, zrozumieć progamiście, że okienko do wyboru opcji jest już dostatecznie dobre, by spełnić cele oprogramowania do zarządzania zleceniami. W zespole pracującym bez planu pojawiają się tendencje do wydłużania czasu realizacji poszczególnych zadań jak i całości projektu dosłownie w nieskończoność, chyba, że wszystkie osoby wchodzące w jego skład mają ogromną wewnętrzną dyscyplinę.

Następną ważną sprawą jest ułożenie kolejności zadań. Wczesne zidentyfikowanie ryzykownych zadań pozwala na wprowadzania działań pozwalających na zminimalizowania ich wpływu na projekt. Typową techniką zaradczą jest przesunięcie najtrudniejszych zadań na początek projektu, bo jeżeli czarne scenariusze się zrealizują, to pozostanie czas na inne działania zaradcze (zmiana zakresu projektu, wielkości zespołu itp.). Nie ma nic gorszego, niż dowiedzieć się tuż przed dostawą do klienta, że na ostatnie zadanie, które - bo tak wyszło - jest krytyczne i trudne, potrzeba jeszcze kilku miesięcy pracy (nawiasem - ludzie mają tendencję do zostawiania trudnych zadań na koniec). Innym dobrym pomysłem może być wczesne wykonanie prototypów najbardziej krytycznych i skomplikowanych fragmentów oprogramowania i zostawienie ich doszlifowania na później (będzie to już praca przewidywalna).

Ułatwienie życia uczestnikom projektu

Druga duża korzyść z planowania to możliwość synchronizacji pomiędzy członkami zespołu (lub osobami z zewnątrz). W małych zespołach pracujących nad niewielkimi projektami odbywa się to zwykle nieformalnie, choćby poprzez rozmowy w bufecie. W większych projektach, gdy nie wszyscy członkowie zespołu widują się ze sobą codziennie, gdy zespół jest podzielony na podgrupy pracujące nad różnymi fragmentami projektu, lub gdy współpracuje się z podwykonawcami, rola pisemnego planu działań staje się krytyczna.

W projektach biznesowych, punkty węzłowe projektu, w których dostarczane są działające fragmenty całego produktu, są zwykle zapisane w umowie. Są z nimi związane terminy płatności a ich niedotrzymanie może skutkować karami finansowymi (a przynajmniej utratą wiarygodności). Wtedy planowanie trzeba wykonać, czy się w jego skuteczność wierzy, czy nie. Co gorsza z zaplanowanych dat zespół zostanie później rozliczony.

Spisana lista zadań ma psychologiczną zaletę dla członków zespołu. Pozwala przedstawić poszczególne zadania jako część większej całości. Wizualizując powiązania między zadaniami dodatkowo motywuje członków zespołu do zakończenia fragmentu pracy, od którego zależą zadania innych osób. Wzmacnia poczucie wspólnoty zespołu oraz znaczenia osobistego wkładu w wykonanie projektu. Stanowi naturalny element dopingujący do zakończenia zadania, który, w przeciwieństwie do nacisku od strony kierownika, nie wpływa drażniąco na ego programisty. Uwaga - warunkiem, by plan spełnił tę rolę, jest zaangażowanie wykonawców w jego opracowanie, w przeciwnym razie raczej zostanie ignorowany.

Planowanie pozwala na lepsze rozdzielenie zadań pomiędzy osoby z uwzględnieniem ich umiejętności i zainteresowań. Przydzielenie zadań zbyt trudnych dla poszczególnych osób jest nie tylko nieefektywne (osoba, która musi cały czas prosić o pomoc inną, nie tylko pracuje wolniej, jeszcze zakłóca pracę innym), ale również demotywujące, bo wywołuje poczucie porażki i słabej samooceny. Przydzielenie nudnych, nużących, banalnych prac ekspertowi od trudnych algorytmów, jest nie tylko marnowaniem jego talentu, ale również proszeniem go o odświeżenie swojego CV.

Kontrola przebiegu projektu

Spisany plan prac z określonymi datami zakończenia poszczególnych zadań i punktów kontrolnych stanowi gotowe narzędzie do kontroli prac projektu (stąd narzędzia posługujące się schematami Gantta typu Microsoft Project mają blisko zintegrowane cechy planowania i kontroli wykonania zadań).

Przy pracach murarskich wszyscy uczestnicy zdają sobie sprawę, że im później rozpocznie się etap murowania, tym później zakończy się budowa - bo nie da się istotnie skrócić czasu potrzebnego na układanie cegieł czy wiązanie zaprawy. W informatyce jest inaczej. Powszechne jest jednak przekonanie, że spóźnienie jednego etapu da się nadrobić w następnym.

Harmonogram już na wczesnym etapie projektu pozwala stwierdzić, czy projekt nie ma opóźnienia, które zagrażałoby lub wręcz niweczyło szansę na zakończenie w ustalonych terminach. Stosowanych jest tu dużo interesujących technik w zależności od wielkości projektu, stosowanej metodyki oraz szczebla zarządzania; wszystkie sprowadzają się zasadniczo do porównania, jaka część prac została wykonana do obecnego momentu w stosunku do planów zawartych w harmonogramie.

Problemy z planowaniem

Większość harmonogramów się nie sprawdza. Bez zrozumienia przyczyn, dla których tak się dzieje, niemożliwe jest opracowanie dobrego planu. Główne przyczyny błędów w harmonogramie to:

• Brak wizji projektu i nieprecyzyjne wymagania.
• Niekompletna lub niewłaściwa lista prac.
• Brak (skutecznych) miar określania wielkości prac.
• Brak uwzględnienia prac innych niż ściśle programistyczne
• Przesadny optymizm
• Błędne założenia dotyczące efektywnego czasu pracy
• Polityka

Żeby zaplanować drogę, trzeba najpierw wiedzieć, dokąd się dąży. Często ze względu na uwarunkowania pozaprojektowe (na przykład biznesowe), plan i harmonogram tworzone są zanim zostanie ustalona wizja projektu i zanim wypracowana zostanie lista celów, co do której panuje zgoda między odbiorcą a wykonawcą. Tak stworzony plan jest obarczony ogromnym ryzykiem błędu. Ustabilizowana lista wymagań w projekcie, jest nie tylko potrzebna do oszacowania jego pracochłonności, bez niej grozi to, że projekt w ogóle nigdy nie zostanie zakończony!

Jeżeli mamy określony stabilny zakres projektu, to jest on następnie przekładany na listę prac, a ta lista jest z kolei podstawą do oceny pracochłonności. W takim procesie szacowania tkwią dwa główne źródła błędów: niewłaściwe szacunki poszczególnych zadań oraz niewłaściwa lista prac (najczęściej nieuwzględnienie części zadań).

Ten drugi problem jest główną przyczyną grubych błędów w harmonogramie i nie ma na niego specjalnie prostej rady. Przy projektach większych niż wymagających kilku osobomiesięcy pracy, określenie wszystkich zadań na starcie jest niezmiernie trudne. Jedną z desek ratunktu może być próba określenia bloków funkcjonalnych (modułów) systemu i próba oszacowania ich stopnia skomplikowania. Niestety nie ma dobrych obiektywnych miar pozwalających określić wielkość oprogramowania, które ma zostać wytworzone. Z oczywistych względów w grę nie wchodzą na przykład linie kodu. Na tym etapie potrzebne jest oszacowanie skomplikowania funkcjonalności. Stosowaną czasami heurystyką jest zliczanie punktów funkcyjnych, wiążących ilość zapytań, źródeł danych (tabel) i formularzy dla użytkownika. Metoda ta jest możliwa do zastosowania tylko w pewnej klasie projektów i stanowi zgrubne przybliżenie. Niestety najczęściej pozostaje skorzystanie z intuicji (warto poprosić o pomoc kilka osób, które oszacują zadania niezależnie) i wsparcie się poprzednimi doświadczeniami z podobnych projektów.

Jeżeli zdecydujemy się na takie subiektywne metody, to pamiętajmy: programiści są optymistami. Jeśli zostaną poproszeni o oszacowanie zadania, to otrzymana liczba raczej będzie za mała; będzie określała czas potrzebny na samo programowanie i to prawdziwy tylko przy założeniu, że wszystko pójdzie dobrze. Niestety zwykle nie wszystko pójdzie dobrze i trzeba to próbować uwzględnić: zawiesi się komputer; kod, który ma być wykorzystany nie będzie działał; wkradnie się usterka, której wykrycie zajmie pół dnia itp. Co więcej, po pierwszym uruchomieniu kodu będzie potrzebne jeszcze raz tyle czasu na jego uporządkowanie, przegląd, udokumentowanie i testowanie. Nie od rzeczy jest założyć, że samo programowanie (w całym projekcie) zajmuje nie więcej niż 1/3 czasu.

No i oczywiście przy szacowaniu należy pamiętać, że nawet najbardziej sumienny człowiek nie poświęca całego pobytu w pracy na programowanie. Nieuniknione są różnego rodzaju przerwania - narady, rozmowy z kierownictwem, klientem, telefony, maile, pomoc innym pracownikom itd. Wydaje się, że realną wartością jest zaangażowanie w granicach 50-80%, w zależności od charakteru projektu i warunków panujących w firmie. Na to dodatkowo nakładają się urlopy, delegacje i zwolnienia lekarskie oraz, przy dłuższych projektach, rotacja pracowników (wymiana programisty doświadczonego na nowicjusza zabiera zwykle co najmniej kilkanaście tygodni).

Jeszcze za mało problemów z planowaniem? Teraz trudno się dziwić, że osoba planująca, po wymyśleniu liczby mnoży ją dla bezpieczeństwa przez dwa, prawda? Ale nie ma obaw, menadżer wyższego szczebla (który też przecież kiedyś szacował!) podaną liczbę podzieli przez dwa i zadekretuje, że projekt ma się skończyć do grudnia. Jeżeli harmonogram nie jest poparty niczym więcej niż intuicją, to będzie stanowił łatwy cel nacisków politycznych. Często naciski te poparte są przekonaniem, że jeśli się nie przykręci śruby, to projekt rozciągnie się w nieskończoność, więc naciska się na wdrożenie fikcyjnego harmonogramu po to, aby projekt zakończył się przynajmniej w pierwotnie planowanym terminie. Trzeba się przed tym bronić, bo nierealny harmonogram ma wiele wad - nie jest skutecznym narzędziem kontroli postępu projektu, deprymuje osoby starające się o dotrzymanie terminów, powoduje, że w walce o czas w sposób niekontrolowany obcinany jest zakres funkcjonalny (lub częściej, świadomie bądź nie, obniżana jakość produktu).

Podejście do planowania

Jest ogromna liczba czynników, które wpływaja na postęp prac i można je tylko częściowo uwzględnić podczas planowania. Dlatego planowanie projektu zawsze oznacza próbę określenia tego co wydarzy się w przyszłości z określonym prawdopodobieństwem. Poniżej przedstawiono parę wskazówek, które mogą pozwolić osiągnąć bardziej prawdopodobne estymaty i lepiej wykorzystać harmonogram do kontroli postępu.

• Ogólnie z daleka - szczegółowo z bliska
• Podział na prace implementacyjne, projektowe i wdrożeniowe
• Podział na etapy kończące się wykonaniem użytecznej funkcjonalności (zamknięte ze wszystkimi artefaktami)
• Krótkie etapy
• Etap projektowania na początku

Na początku projektu niewiele wiadomo o tym, jak ma wyglądać ostateczny produkt i jak będzie przebiegać jego realizacja. Z reguły w miarę dokładnie wiadomo, jak poradzić sobie w najbliższym etapie. Przebieg dalszych może bardzo zależeć od wiedzy pozyskanej w jego trakcie. Dlatego czasem nie ma sensu szczegółowo planować przyszłych etapów. Im dalszy, tym bardziej ogólnie powinien być ujęty w planie. Oszczędzi to wysiłku przy tworzeniu harmonogramu i zwiększy jego wiarygodność.

Każdy projekt ramowo składa się z trzech faz: projektowania (odkrywania, co właściwie należy zrobić), implementacji (właściwej pracy) i przygotowania wydania (identyfikacji i usuwania usterek, przygotowywania dokumentacji, wykonania prac wdrożeniowych itp.). Czasami te fazy się wielokrotnie powtarzają, przykładowo często na początku projektu wykonuje się jedną inicjalną faza planowania a implementacja jest rozłożona na etapy, na końcu których jest testowanie. Tak czy owak te trzy "tryby" pracy występują. Zwykle najłatwiej wyobrazić sobie wymaganą pracochłonność implementacji, gdyż praca w tej fazie jest najbardziej konkretna. Skutkiem tego wysiłek niezbędny na pozostałe fazy bywa niedoszacowany. Ramowo można przyjąć, że fazy planowania, implementacji i wydania wymagają porównywalnego wysiłku. Innymi słowy każda z tych faz zajmie z grubsza 1/3 całej pracy. Oczywiście w konkretnym specyficznym przypadku mogą być dobre powody, by założyć, że proporcje te będą inne, jednak takie założenie powinno być przyjęte świadomie i poparte argumentami.

Projekt warto planować tak, by zakończenie każdego etapu projektu wiązało się z wykonaniem pewnej funkcjonalności użytecznej dla końcowego odbiorcy systemu. O ile to możliwe, to również pojedyncze zadania rozdzielane członkom zespołu powinny się kończyć oddaniem postrzegalnej dla użytkownika cechy systemu (formularz do wpisania nazwiska) a nie fragmentu wewnętrznej struktury produktu (trzy nowe metody). Ma to kilka zalet - po pierwsze ukończenie trzech nowych metod nic nie mówi o stopniu zaawansowania, bo może się okazać, że one wcale nie będą potrzebne do zrealizowania wymaganej funkcjonalności (za to będzie potrzeba czterech innych). Po drugie, wcześniej można zweryfikować, czy funkcjonalność spełni oczekiwania użytkownika. Po trzecie, wraz zakończeniem takiej funkcjonalności powinno się wiązać przygotowanie dokumentacji, testów i innych nieprogramistycznych produktów, dzięki czemu pod kontrolą jest proces ich wytwarzania. W przeciwnym razie cały wysiłek związany z ich przygotowaniem skumuluje się na końcu projektu.

Dla osiągnięcia możliwie rzetelnego harmonogramu i poprawienie skuteczności kontroli postępu projektu, warto spróbować tak go zaplanować, by na początku była większa faza inicjalnego projektowania. Na bazie wypracowanej w niej wiedzy, dalszą część projektu dobrze jest podzielić na możliwie krótkie etapy (2-4 tygodni). Długie okresy pomiędzy dostawami znacznie utrudniają ocenę stanu zaawansowania, ograniczają wpływ klienta na ostateczny kształt systemu, nie pozwalają na większą elastyczność. Tego typu podejście leży u podstaw wielu metodyk programowania (na przykład w Feature Driven Development).

Podsumowując

• Planowanie polepsza efektywność prac w (dużym) projekcie, bo dzięki niemu działa się w sposób bardziej systematyczny
• Harmonogram stanowi naturalny czynnik mobilizujący dla programistów (pod warunkiem zaangażowania ich w proces planowania) oraz gotowe narzędzie do kontroli przebiegu projektu
• Harmonogramowanie jest zawsze pewną estymatą obarczoną ryzykiem; tym większym im więcej prac pozostało jeszcze do wykonania
• Podstawą do planowania jest dobre zrozumienie wymagań i wizji projektu. Poświęć na to czas na początku.
• Wiele czynników wpływa na niedoszacowanie wielkości projektu, do najważniejszych należy możliwość przeoczenia zadań i błędne założenia co do efektywnego czasu pracy zespołu
• Projektowanie, implementacja i wydanie wymagają ramowo tyle samo wysiłku
• Każdy etap (praca) powinna kończyć się wykonaniem funkcjonalności użytecznej dla odbiorcy systemu

Więcej na temat planowania

• Painless Software Schedules - Joel Spolsky - o planowaniu z użyciem Excela, polska wersja znajduje się tutaj.
• "The Art of Project Management" - Scott Berkun - znakomita książka o prowadzeniu projektów informatycznych. W szczególności zawiera rozdziały o tym, jak dowiedzieć się, co zrobić w ramach projektu, po co planować, jakich błędów unikać oraz jak kontrolować przebieg projektu. Nie odnosi się do żadnych konkretnych metodyk lub narzędzi, lecz jest opisem obserwacji i wniosków mających zastosowanie w szerokim spektrum projektów.
• Nu Cardboard: How to Estimate a Software Project
• Nu Cardboard: Project Planning Checklist - Alan Green - listy kontrolne dla planowania projektu i innych czynności związanych z zarządzaniem projektami. Warte szybkiego przejrzenia w kluczowych momentach projektu.

---