Eksploracja i adaptacja zamiast planu i kontroli

Metodyki spod znaku agile wyszły poza programowanie systemów IT i weszły w obszar zarządzania projektami. W przypadku wdrożeń systemów ERP ich zastosowanie może mieć głęboki sens.

Metodyki spod znaku agile wyszły poza programowanie systemów IT i weszły w obszar zarządzania projektami. W przypadku wdrożeń systemów ERP ich zastosowanie może mieć głęboki sens.

Eksploracja i adaptacja zamiast planu i kontroli

Agile Project Management, czyli adaptacyjne (lub "zwinne") zarządzanie projektami, w szczególności projektami IT, nie jest niczym nowym. Jest raczej uporządkowaniem i legitymizacją praktyk stosowanych od dawna przez tysiące kierowników projektów uciekających przed nadmiernym sformalizowaniem ich pracy i poddaniem jej rygorom powtarzalnych procesów. Jest protestem przeciwko nierzeczywistemu założeniu, że można przewidzieć przebieg projektu zawierającego jakąkolwiek dawkę nietypowości jeszcze przed jego rozpoczęciem. Jest usankcjonowaniem zdroworozsądkowego i odważnego podejścia do zarządzania zespołem projektowym, wyżej ceniącego dyskusję i rozwiązywanie nieuchronnych problemów niż tworzenie schematów organizacyjnych i opisów kompetencji.

Metodyki spod znaku agile (Extreme Programming, Scrum, Agile Modeling) ściągnęły na siebie krytykę jeszcze zanim zaczęły być dobrze znane. Antagoniści oskarżali ich twórców o próbę uprawomocnienia chaosu panującego w wielu projektach informatycznych, usprawiedliwienia lenistwa odpowiedzialnego za niechlujną i niekompletną dokumentację i ucieczkę przed odpowiedzialnością za dotrzymanie założonego kosztu, zakresu i harmonogramu projektu. Nie można jednocześnie twierdzić, że żyjemy w świecie, który podlega nieustannym zmianom i nie akceptować zmian nieuchronnie pojawiających się w każdym projekcie - odpowiadali zwolennicy podejścia adaptacyjnego. Nie można jednocześnie wychwalać organizacji uczących się i blokować wpływu owego uczenia się na przebieg ściśle zaplanowanych projektów. Wiedza pojawia się w trakcie trwania projektu. Planowaniu zawsze towarzyszy niepewność. Najlepsze, co możemy zrobić, to jak najszybciej uzyskać jak najwięcej informacji zwrotnych i planować dalej w oparciu o nie, nie porywając się na planowanie w zbyt daleko zakreślonych horyzontach czasowych.

Zakres, harmonogram, koszt

Nie jest prawdą, że zarządzanie adaptacyjne lekceważąco odnosi się do harmonogramu, kosztu i zakresu projektu. Wręcz przeciwnie, traktuje je o wiele poważniej i bardziej realistycznie niż tradycyjne zasady zarządzania. Tradycjonaliści spod znaku PMBOK zakładają na starcie, że mają do zrealizowania pewien zakres projektu w pewnym określonym czasie przy określonych kosztach. Benchmarki podpowiadają im, że czas realizacji i koszty przekraczane są zazwyczaj w dobrze zaplanowanych projektach o 15% w stosunku do planu, biorą więc pod uwagę owe 15% i dalsze przekroczenia traktują jako problem i sygnał alarmowy. Stosunkowo najmniej elastyczną zmienną jest tu zakres, który domyślnie ma być zrealizowany w całości.

Dla zwolenników podejścia adaptacyjnego zakres projektu jest zmienną stosunkowo najbardziej elastyczną, natomiast jego harmonogram i koszt są ściśle określone i niezmienne, co stymuluje zespół projektowy do dostarczenia gotowych, działających, zintegrowanych produktów w skończonym czasie i budżecie - nawet wówczas, gdy będą to produkty niekompletne pod względem funkcjonalnym. Myślenie adaptacyjne jest zbliżone do myślenia pana Kowalskiego wybierającego się na miesięczną wycieczkę po Europie. Wiadomo, że wycieczka nie może trwać dłużej niż miesiąc, bo Kowalski dostał tylko miesiąc urlopu; i wiadomo, że nie może kosztować więcej niż 7000 zł, bo Kowalski więcej po prostu nie ma. Jeśli w połowie miesiąca okaże się, że Kowalski dotarł dopiero do Mediolanu (a miał w planach opalanie się na plażach wybrzeża Algavre i obiad w Mount St. Michel), a w dodatku wydał już 5000 zł, to adaptacyjny Kowalski ograniczy po prostu zakres wycieczki (włoskie plaże zamiast portugalskich), nie porywając się na jazdę autostopem i spanie na poboczu w celu realizacji założonego planu za wszelką cenę.

Nie jest to reguła. Priorytety harmonogram-zakres-koszt określane są na etapie tworzenia - na samym początku projektu - macierzy kompromisów, czyli tablicy ilustrującej, co dla zespołu projektowego, sponsora projektu i klienta końcowego jest najważniejsze (Dostarczenie choćby okrojonego produktu na czas? Zmieszczenie się w budżecie? Realizacja założonej funkcjonalności za wszelką cenę?), a co może zostać poświęcone w chwili nieuchronnego zderzenia z rzeczywistością. Tradycjonaliści zastanawiają się nad tym zazwyczaj dopiero na etapie ratowania tonącego projektu, gdy z bólem serca decydują się zrezygnować z połowy funkcjonalności i dedykować dodatkowe zasoby, by uratować harmonogram (zazwyczaj nie do uratowania, bo o problemach projektu dowiadują się blisko daty jego planowanego zakończenia).

Papierologia czy niezbędna informacja?

Adaptacyjnym zarzuca się, że nie przywiązują wystarczającej wagi do tworzenia dokumentacji, obrazującej zarówno stan zaawansowania projektu, jak i charakterystykę tworzonego rozwiązania. Adaptacyjni odpowiadają z kolei, że w tradycyjnie prowadzonych projektach dokumentacja zbyt często zastępuje dyskusję i wymianę informacji. Zbyt często stanowi produkt sam w sobie, zastępujący to, co ma być dostarczone klientowi i zacierający faktyczny cel projektu. Adaptacyjni mówią: "Interesuje nas nie dokumentacja, ale działający produkt". Skąd jednak wiadomo, że ten produkt w ogóle powstaje? Skąd wiadomo, jaki jest status prac? Wykonanie planu? Przyjęty zakres zmian? Odpowiedzią na to jest zarządzanie poprzez kolejne iteracje. Iteracja jest swoistym "podprojektem", obejmującym sprecyzowanie wymagań klienta, określenie odpowiadającej im funkcjonalności, stworzenie i wdrożenie odpowiedniego fragmentu oprogramowania, integrację z resztą systemu, testy i odbiór przez klienta. Kolejne iteracje to tak naprawdę kamienie milowe, określające postęp projektu. W wytwarzaniu oprogramowania iteracja może trwać od dwóch do sześciu tygodni, czasem nieznacznie dłużej. Podzielenie projektu na iteracje o stałej długości i trzymanie się tego podziału pozwala szybko uzyskać informację zwrotną na temat tempa i jakości prac i nie pozostawia złudzeń co do przebiegu projektu. Tu nie ma miejsca na zwodzenie zarządu informacjami typu "na dziś wdrożenie zostało wykonane w 40%". Szybkie odbiory kolejnych produktów cząstkowych mobilizują zespół i są dowodem faktycznych postępów (lub ich braku), mobilizują też klienta i szybko weryfikują jego wymagania, a do tego czynią dla niego zrozumiałym proces wytwarzania oprogramowania i jego efekty. Krótkie iteracje i presja czasu zmuszają zespół projektowy do wypracowania najlepszych metod pracy i współpracy z innymi zespołami; metod, które będą mogły być wykorzystane już w następnej iteracji i doskonalone do końca trwania projektu.

Czy to jest jeszcze plan?

I tu dochodzimy do planowania, czyli podstawowej rozbieżności między tradycjonalistami i adaptacyjnymi. Tradycjonaliści dążą do jak najlepszego zaplanowania projektu w oparciu o estymacje bazujące na doświadczeniach z podobnych projektów o podobnym zakresie realizowanych w podobnych firmach. Adaptacyjni twierdzą, że w niepowtarzalnych projektach (każdy projekt wdrożenia dowolnego systemu w dowolnej firmie jest niepowtarzalny) w zasadzie trudno mówić o planach, należy mówić raczej o spekulacjach, czyli przypuszczeniach opartych na niekompletnej informacji. Adaptacyjne zespoły planują, ale spodziewają się, że plany będą systematycznie zmieniane. Dlaczego? Ponieważ w trakcie projektu zmienia się rozumienie wymagań przez klienta, ponieważ ze względu na wcześniejszą niewiedzę następują odchylenia od szacowanej pracochłonności, ponieważ ludzie przychodzą i odchodzą z zespołów projektowych.

Im więcej niepewności na starcie projektu, w tym większym stopniu planowanie powinno ograniczać się do najbliższych iteracji. Spektrum możliwości rozciąga się od kompletnego planu, w którym wszystkie przewidziane elementy funkcjonalności są przypisane do wszystkich przewidzianych iteracji, poprzez dwuczęściowy plan obejmujący tylko następną iterację i "całą resztę projektu", do planowania z iteracji na iterację. Oczywiście, każdy projekt zawiera dłuższą lub krótszą iterację "0", w której definiowane są znane wymagania klienta, architektura systemu i interfejsy.


TOP 200