Koniec projektu powinien być wyznaczony przez osiągnięcie celu. Aby przygotować początkowy, wysokopoziomowy plan działania, czyli nakreślić drogę (po niemiecku Fahrplan, po angielsku road map), powinniśmy określić zakres przedsięwzięcia. Czy warto szczegółowo planować jeszcze przed startem, czy może postawić na planowanie krótkich odcinków? Wśród metodyków łatwo znaleźć zwolenników obu opcji.
Początek drogi
If you don’t know where you are going, how can you expect to get there? – Basil S. Walsh
Dzięki planowaniu możemy łatwiej zdefiniować zadania do wykonania, ustalić zachodzące między nimi zależności i ramy czasowe, zdefiniować ryzyka, przygotować plan zasobów, zaplanować koszty oraz ROI, przygotować plan finansowania projektu i tym podobne. Gdy planujemy, łatwiej nam też podjąć decyzję, jak wiele jesteśmy w stanie zainwestować w nasze przedsięwzięcie. Jak widać, na pytanie, co jest powodem, dla którego warto planować, najszybsza odpowiedź to: pieniądze. Jak w takim razie planować efektywnie?
W przypadku tradycyjnych wdrożeń w projektach SAP-owych metodyka jest oparta głównie na hierarchicznej strukturze zadań (tzw. WBS-y, czyli work breakdown structure), która prowadzi do uzyskania określonych produktów i jest zgodna z tradycyjnym podejściem do realizacji projektów (tzw. waterfall). W praktyce wygląda to następująco: na podstawie zakresu prac do wykonania tworzymy listę zadań, która w kolejnym kroku zostaje uporządkowana w logicznej kolejności. Planujemy, jakie działanie poprzedzi inne, a także, które z nich można prowadzić równolegle. Może się bowiem okazać, że nie ma przeszkód, by nad paroma kwestiami pracować jednocześnie. Takie podejście jest bardzo popularne w projektach SAP-owych.
W tradycyjnym podejściu na początku opracowujemy szczegółową koncepcję, która następnie zostaje zatwierdzona, podpisana i odebrana przez klienta. Dopiero po tym procesie możemy rozpocząć pracę nad implementacją. To jest zamknięty okres – w zależności od skali projektu trwający czasami trzy miesiące, czasami rok – podczas którego nie ma punktów kontrolnych ze strony klienta. Oznacza to, że testy prowadzone są dopiero po odbiorze gotowego produktu przygotowanego ściśle według specyfikacji. Jak jednak pokazują statystyki, w większości projektów na etapie tworzenia koncepcji jest za mało informacji, żeby spełnić oczekiwania i zrealizować w pełni cel klienta. W związku z tym w trakcie końcowych testów, zgodnie z procedurą, realizuje się dodatkowe prace, które zostały zidentyfikowane jako luki między tym, co klient na początku uważał, że potrzebuje, a tym, czego rzeczywiście potrzebował.
Web do planowania
Plans are worthless. Planning is essential – Dwight D. Eisenhower
W projektach webowych, napisanych na przykład w java, .net czy w aplikacjach mobilnych, częściej używa się metodyk zwinnych zarządzania projektami (agile project management), z frameworkiem Scrum na czele. Takie podejście zasadza się na tworzeniu wysokopoziomowego backlogu produktu, czyli rejestru zadań koniecznych do zrealizowania danego projektu informatycznego, który ciągle poddaje się weryfikacji pod kątem wartości biznesowej. To wartość biznesowa, ze względu na istniejące zależności, „decyduje” o kolejności wykonywanych prac. Podejście zwinne nie narzuca, jaką postać zadania powinny przybrać – często są to na przykład user stories, dzięki którym możemy spojrzeć na dane zadanie oczami użytkownika (wszyscy użytkownicy na początku projektu są zdefiniowani i scharakteryzowani pod kątem ich potencjalnej interakcji z systemem) i dowiedzieć się, co on sam chciałby w systemie zrobić. Inna postać zadań to use cases, czyli przypadki użycia, opisujące konkretne sytuacje i funkcjonalności w systemie, które użytkownik chce wykorzystać.
Podejście zwinne zakłada pracę w krótkich okresach, tzw. iteracjach. Zgodnie z założeniem jedna iteracja nie powinna trwać dłużej niż cztery tygodnie. Po tym czasie wspólnie z klientem sprawdzamy, czy udało się osiągnąć cel, jak wygląda efekt i czy jest gotowy do przekazania odbiorcom. Dzięki takiemu podejściu klient regularnie sprawdza i upewnia się, czy prace idą w dobrym kierunku, a efekty są tym, czego faktycznie potrzebuje. Wprowadzanie zmian lub korygowanie błędów po zakończeniu pojedynczej iteracji jest dużo mniej kosztowne niż na późnym etapie. Im bliżej realizacji pracy, tym zadania w backlogu muszą być dokładniej zdefiniowane, aby zespół mógł przyjąć je do realizacji w kolejnej iteracji. Jednak w trakcie trwania danej iteracji nie wprowadza się w jej zakresie żadnych zmian. Może się tak wydarzyć tylko w przypadku, gdy cel iteracji straci na aktualności. Jeżeli taka sytuacja nie ma miejsca, przemyślenia zostają wdrożone dopiero przy układaniu listy zadań do backlogu kolejnej iteracji.
Czy to jest niepewność? Czy ryzykowanie?
Expect the best, plan for the worst, and prepare to be surprised – Denis Waitley
Ponoć menedżerowie nie lubią ryzyka, co często prowadzi do tego, że wolą o nim nie myśleć. Z kolei przedsiębiorcy są świadomi ryzyka, potrafią je wycenić i ustalić jego granice. Jak je określają? Poprzez zdefiniowanie ryzyka, które jest integralną częścią planowania. Każdą zmianę warunków należy rozpatrzyć pod kątem aktualności planu. Warto więc uświadomić sobie, że planowanie jest procesem ciągłym, który towarzyszy każdemu etapowi prac nad projektem.
Ryzyko jest możliwe do zdefiniowania, a jego przyczyny i skutki są łatwe do określenia. Jeśli jednak przyczyny nie są sprecyzowane i mogą być bardzo różnorodne, a skutki mimo to są do przewidzenia – mówi się o niepewności. Projektom informatycznym zawsze towarzyszy pewna – mniejsza lub większa – doza niepewności. Jej główne źródła to wymagania, technologia i ludzie. W zależności od źródła i poziomu niepewności dobierana jest strategia realizacji projektu.
Źródło niepewności związane z wymaganiami może dotyczyć zbyt ogólnych lub niespójnych wskazówek udzielonych przez klienta czy braku osoby kontaktowej, która na bieżąco może tłumaczyć oczekiwania. Kolejne źródło niepewności, czyli technologia, może się pojawić, gdy po raz pierwszy realizujemy jakiś bardzo innowacyjny projekt albo nie mamy pewności, czy dane rozwiązanie się sprawdzi. W przypadku ludzi jako źródła niepewności najczęściej mamy do czynienia z brakiem wystarczających kompetencji, nieznajomością procesów biznesowych klienta lub brakiem doświadczenia w realizowaniu podobnych projektów.
Tradycyjnie nie znaczy nieefektywnie
A vision without a strategy remains an illusion – Lee Bolman
Gdy rodzaj niepewności zostaje określony, dobranie odpowiedniej strategii realizacji projektu jest o wiele łatwiejsze. Jeśli technologia jest niepewna, efektywniejsze wydaje się podejście zwinne. Dzięki temu w krótkim czasie możemy się upewnić, czy praca zmierza w dobrą stronę, a wybrana technologia pomoże zrealizować cele biznesowe naszego klienta. Podobną taktykę wybrałabym, gdyby niepewne były wymagania, dzięki czemu na bieżąco moglibyśmy wspólnie z klientem walidować wymagania pod kątem ich ważności i użyteczności. Systemy informatyczne klasy ERP są najczęściej bardzo kompleksowymi produktami i definiowanie na samym początku detali rozwiązania jest bardzo często nieefektywne. Można to zobrazować w następującym przykładzie: planowanie detali w systemie informatycznym to trochę jak wybieranie firanek do domu, którego jeszcze nie wybudowano.
Jeśli jednak wszystkie trzy źródła niepewności, albo przynajmniej technologia lub wymagania, są stabilne – możemy rozpatrzyć podejście waterfall, czyli tradycyjne. Rośnie co prawda rzesza project managerów, którzy uważają, że zwinny Scrum jest najlepszy do rozwoju produktów, ponieważ pozwala relatywnie szybko skonfrontować rozwiązanie z rynkiem i odbiorcami, a przy tym sterować nim tak, aby stosunek kosztu do osiągniętej wartości biznesowej był jak najbardziej korzystny. Wciąż jednak część projektów możemy prowadzić w sposób tradycyjny. Jeżeli wiadomo, że zakres projektu jest w pełni określony i szczegółowo opisany, a nie ma w nim wielu zależności – waterfall prawdopodobnie sprawdzi się lepiej, a wprowadzanie reguł frameworku Scrum nie będzie miało większego sensu.
Project management wpisuje się w model PDCA (plan-do-check-act), który ma zapewnić podnoszenie jakości i efektywności działań. Gdy nagle pojawi się nowe ryzyko czy opóźnienia, gdy coś trzeba dostosować do zmieniającej się sytuacji… plan powinien być na bieżąco uaktualniony. Sceptycy twierdzą, że Scrum to działanie bez planu, ja jednak jestem zdania, że projekt realizowany zwinnie oznacza codzienne planowanie. Jeśli z jakichś powodów pojawia się ryzyko niezrealizowania zadań w ramach sprintu (czyli maksymalnie czterech tygodni), cały zespół developerski zastanawia się, jak przeplanować prace w ramach iteracji tak, aby zrealizować cel. To planowanie należy do obowiązków zespołu developerskiego.
Ludzie od planowania
Vision without action is a dream. Action without vision is simply passing the time. Action with vision is making a positive difference – Joel Barker
Rozpoczęcie planowania wyznacza określenie celu i zakresu projektu czy przedsięwzięcia. Celem może być na przykład zautomatyzowanie jakiegoś procesu. W ramach zakresu definiujemy, że zautomatyzujemy go za pomocą narzędzia informatycznego – może to być na przykład konkretny moduł SAP-a, inne przeznaczone do tego narzędzie informatyczne lub kilka narzędzi naraz.
Za przygotowanie takiego planu odpowiada kierownik projektu (project manager). Harmonogram prac jest tworzony zgodnie z wiedzą dotyczącą pracochłonności zadań, zależności między nimi oraz dostępności zespołu. Kolejność wykonywanych zadań często wynika z treści technicznych lub biznesowych. Dlatego też w zespole znajdują się eksperci, którzy doradzają podjęcie odpowiednich kroków, aby praca nad realizacją projektu przebiegała efektywnie. To oni dostarczają informacji na temat zależności między zadaniami i ryzyka, jakie może przynieść ich implementacja. W przygotowanie danych, na podstawie których powstaje plan, mogą być zaangażowani: architekt rozwiązania, analitycy biznesowi, wiodący programista czy klient, który w przypadku projektów zwinnych dostarcza informacji o tym, jakie wymagania mają największą wartość i co jest najważniejsze dla niego i docelowych odbiorców systemu.
Produkt wystarczająco gotowy
Done is better than perfect – maksyma zdobiąca główną ścianę siedziby Facebooka
Plan projektu może być bardzo krótki i mieścić się na jednej stronie A4, może też być bardzo złożony – wszystko zależy od przedsięwzięcia. Najważniejsze, aby zawierał kluczowe informacje o projekcie. Przy bardziej złożonych projektach, w których równolegle pracuje kilka streamów, a między zadaniami są duże zależności, przeznaczonym do tego i polecanym narzędziem jest diagram Gantta. Kierownik projektu musi potrafić dobrać narzędzie tak, aby jego przedstawienie było czytelne dla wszystkich zainteresowanych. Nie ma sensu robić i utrzymywać skomplikowanego diagramu Gantta dla małego zespołu, który pracuje nad tym samym niezłożonym produktem, bez większych zależności.
W przypadku projektów zwinnych najczęściej używa się takich narzędzi jak Confluence oraz Jira, które są jednymi z najpopularniejszych. Im mniej złożony projekt, tym prostsze powinno być także narzędzie do jego planowania i śledzenia. Przy zwinnych, mniej skomplikowanych projektach, świetnie sprawdzi się prosta tablica zadań (na przykład Jira) dzielona z całym zespołem. Mało tego, jeśli zespół nie jest rozproszony i wszyscy jego członkowie znajdują się w jednym miejscu, wtedy jako narzędzie do planowania doskonale sprawdzi się zwyczajna ściana, na której zostaną umieszczone samoprzylepne karteczki.
Takie zwinne planowanie często zmierza do jak najszybszego oddania produktu użytkownikowi. Często nie jest to w 100% ukończony produkt, nie oznacza to jednak, że nie działa poprawnie. Dobrze widać to na przykładzie sklepu internetowego. Jeżeli naszym zadaniem byłoby uruchomienie takiej witryny, to na pierwszym etapie nie musimy wyposażać jej w obsługę wszystkich dostępnych na rynku rodzajów płatności. Sklep internetowy może wystartować z opcją tradycyjnych przelewów, a z czasem rozszerzyć metody płatności o kolejne możliwości, poszerzając tym samym krąg użytkowników. Taki nie całkiem wykończony produkt już na początkowym etapie ma szanse przynieść korzyści biznesowe. Podejście waterfall z założenia wyklucza możliwość oddania takiego niepełnego produktu.
NIC się nie stało?
I am prepared for the worst, but hope for the best – Benjamin Disraeli
Jeśli nie będziemy planować, bardzo prawdopodobne jest, że w kwestii realizacji naszego zadania nie wydarzy się NIC, co znaczy, że ryzyko nieosiągnięcia przez nas celu będzie bardzo wysokie. Zmarnujemy za to czas, pieniądze i pomysł.
W związku z tym należy planować tak szczegółowo jak to możliwe. Umiejscowienie projektu w jednej z czterech kategorii: simple, complicated, complex, chaotic pozwala lepiej określić, z jak mocnym naciskiem na detale powinniśmy układać harmonogram. Proste projekty możemy zaplanować bardzo szczegółowo. Im bardziej skomplikowany, złożony czy niesprecyzowany projekt, tym mniej możemy zaplanować i przewidzieć. Wtedy właśnie może nam pomóc Scrum i przyrostowy rozwój oprogramowania w formie krótkich iteracji. Czterotygodniowe sprinty zmieniają perspektywę, tak samo jak Scrum zmienił podejście do planowania projektów.
Jeśli projekt niesie ze sobą większą dozę niepewności, a kolejne etapy prac powinny podlegać dyskusji – zrezygnuj z tradycyjnego podejścia waterfall. Zwinne planowanie zapewnia nie tylko efektywniejszą pracę, wprowadzanie szybszych (a co za tym idzie także tańszych) poprawek, ale również transparentność projektu – klienci zobaczą, nad czym aktualnie pracuje twój zespół, a to zbuduje waszą wiarygodność.
Możesz zobaczyć ten artykuł, jak i wiele innych w naszym portalu Controlling 24. Wystarczy, że klikniesz tutaj.
