Coraz częściej kiedy rozmawiamy z klientami na temat nowego przedsięwzięcia, pojawia się pytanie: czy ten projekt możemy zrealizować w podejściu agile? W jego tle czai się dylemat: co jest „lepsze” dla mojej organizacji i projektu: tradycyjny model kaskadowy (wodospadowy, z ang. waterfall), czy może nowsze i zachwalane przez niektórych przedstawicieli biznesu i IT podejście lekkie/zwinne (ang. agile).

Odpowiedź na to pytanie nie jest niestety ani tak łatwa, ani jednoznaczna. Ze względu na wpływ dokonanego wyboru na dalsze losy projektu, decyzję o wyborze podejścia warto podjąć, oceniając na zimno gotowość projektu, organizacji oraz zespołu do jego przyjęcia.

W tym celu najlepiej posłużyć się listą kilku kluczowych pytań opisujących przedsięwzięcie, organizację, która je planuje, oraz zespół, który będzie w nim uczestniczyć:

  • Czy jasno określony jest problem/problemy organizacji, który należy rozwiązać?
  • Czy istnieje pomysł na rozwiązanie tego problemu?
  • Czy znane i sprecyzowane są wszystkie wymagania biznesowe co do rozwiązania oraz zależności między nimi?
  • Czy priorytety tych wymagań dla organizacji są jednoznacznie określone?
  • Jak dużo czasu będą mogli poświęcić interesariusze na prace w projekcie?
  • Jak duża jest elastyczność budżetu przeznaczonego na projekt?
  • Jak duża jest elastyczność harmonogramu planowanego projektu?
  • Jak duża jest zmienność otoczenia biznesowego organizacji wdrażającej?

Znając odpowiedzi na te pytania, można ocenić, w jakim stopniu każde z podejść do projektu może wesprzeć (lub ograniczyć) doprowadzenie prac projektowych do szczęśliwego końca.

Waterfall

Prawie pół wieku od zdefiniowania przez Winstona W. Royce’a w 1970 r. model kaskadowy jest dobrze zakorzeniony w praktyce realizacji projektów IT. Większość metodyk wdrożeniowych, w tym metodyka ASAP 8, opierają się na jego założeniach. Podejście kaskadowe, traktujące tworzenie oprogramowania jak inne dziedziny inżynierskie, definiuje tworzenie oprogramowania jako uporządkowany proces, naturalny w architekturze czy budownictwie.

Najważniejszą zaletą takiego podejścia jest jego duża przewidywalność. Opierając się na precyzyjnie zdefiniowanych wymaganiach, zarówno klient, jak i partner wdrożeniowy mogą dobrze oszacować zakres, czas, pracochłonność, ryzyka i związany z nimi koszt projektu. To bardzo istotny argument z perspektywy budżetowania. Zarząd firmy, planując tak ważną inwestycję jak wdrożenie systemu ERP, zwykle potrzebuje jak najdokładniejszego oszacowania całkowitych kosztów wdrożenia (m.in. platformy sprzętowej, licencji na oprogramowanie, usług konsultingowych czy szkoleniowych). Trudno wyobrazić sobie, że CEO podejmie decyzję o uruchomieniu projektu, kiedy na pytanie „Ile ta inwestycja będzie kosztować i kiedy się zwróci?”, usłyszy odpowiedź „Trudno dokładnie powiedzieć”.

Precyzyjnie zdefiniowane wymagania oznaczają także, że wszystkie strony (klient, partner wdrożeniowy, ale także firmy trzecie, np. dostawca systemu MES czy WTR) od początku dość dobrze będą w stanie wyobrazić sobie, jakie funkcje będzie miał końcowy produkt. Z jednej strony pozwala to na wczesne zbudowanie oczekiwań co do tworzonego rozwiązania. Z drugiej plan zadań stworzony na początku projektu pozwala z odpowiednim wyprzedzeniem zaplanować dostępność kluczowych przedstawicieli biznesu, IT i konsultantów, dostosować plany urlopowe czy uwzględnić cykle koniunkturalne w danej branży. Dodatkowo plan ten nie powinien znacząco odbiegać od rzeczywistości. Dzięki temu działa jako dodatkowy element porządkujący i dyscyplinujący rytm prac w projekcie.

Z perspektywy osoby zarządzającej wdrożeniem kompleksowy plan zadań ma jeszcze jedną ważną zaletę: stanowi prosty i zrozumiały wyznacznik postępów prac. Zadania projektowe i produkty prac mogą być łatwo zweryfikowane i ocenione co do kompletności, spójności czy oczywiście terminowości dostarczenia. Odpowiednia szczegółowość zadań (np. zaprogramowanie, zakończone pozytywnie testy jednostkowe lub stworzenie scenariusza testów dla wydruku zamówienia) pozwala jasno określić, kto, co i na kiedy powinien wykonać jako następny krok.

Zaplanowane z góry etapy projektu pozwalają zrównoleglić prace wielu osób, np. podczas gdy trwają prace programistyczne, osoba odpowiadająca za testy może kończyć przygotowanie scenariuszy testowych na podstawie zapisów koncepcji.

W tym momencie warto także przypomnieć za Dwightem D. Eisenhowerem, że najistotniejszy jest nie tyle plan jako produkt, co sam proces planowania. Kierując firmą czy złożonym projektem, często zbytnio przywiązujemy się do stworzonych planów, podczas gdy niemal zawsze ulegają mniejszej lub większej korekcie. Autorzy i zwolennicy planów przedsięwzięć wypracowanych w pocie czoła muszą zwykle w końcu zmierzyć się ze zmianą (np. odejściem pracownika, nieprzewidzianym w zakresie raportem albo cichą – do czasu – reorganizacją działu sprzedaży).

Podejście kaskadowe niestety nie ułatwia „obsługi” tej zmiany. Po pierwsze konieczność powtórzenia sekwencji działań projektowych znacząco podnosi koszt wprowadzenia zmiany (konieczność przejścia przez część lub całość cyklu od wymagań do realizacji). Po drugie „magia” przewidywalności planu (budżet, harmonogram, zakres) zamienia się we frustrację, kiedy rzeczywistość zaczyna od tego planu odbiegać („miało być tak pięknie, a wyszło jak zwykle”). Tej frustracji można jednak uniknąć, koncentrując wysiłki nie na produkcie (plan), ale na procesie (planowanie), czyli… rozmowie i współpracy nad alternatywnymi strategiami działania, harmonogramami czy ocenie czynników ryzyka.

Obecna w podejściu klasycznym struktura organizacyjna uzupełniona o macierz odpowiedzialności (ang. Responsibility Assignment Matrix) precyzyjnie określa zadania wymagające zaangażowania przedstawicieli klienta podczas projektu. Bezpośrednia współpraca klienta z konsultantami ogranicza się zwykle do spotkań podczas koncepcji, testów, szkoleń i zaplanowanych spotkań zespołów roboczych. Poza tym członkowie zespołu pracują niezależnie, dzieląc czas między bieżące obowiązki operacyjne i inne projekty. Z perspektywy organizacji realizującej projekt można na to spojrzeć dwojako.

Z jednej strony ograniczone zaangażowanie w projekt pozwala utrzymać wsparcie danej osoby dla bieżących działań operacyjnych. To dobra wiadomość dla firm, które nie mogą sobie pozwolić na oddelegowanie kluczowych pracowników wyłącznie do projektu. Jednak z drugiej strony stosunkowo niewielka częstotliwość interakcji między zespołem realizacyjnym a klientem (oraz między tworzonym rozwiązaniem a klientem) może zaowocować rozwiązaniem nie do końca odzwierciedlającym potrzeby i wymagania odbiorcy rozwiązania.

Oczywiście klient może oddać decyzyjność w kluczowych sprawach konsultantom. Przypomina to jednak sytuację, kiedy podczas budowy domu robotnicy podejmują decyzje o sposobie położenia płytek albo podłączenia instalacji, kierując się doświadczeniami zebranymi podczas wcześniejszych budów. Może zaowocować to zadowoleniem klienta („świetny pomysł z tym wyprowadzeniem”), albo głębokim niezadowoleniem („dlaczego te płytki położył pan pod kątem 45 stopni?”).

Wreszcie model kaskadowy mocno podkreśla także znaczenie dokumentacji. Tworzona w trakcie prac, zabezpiecza organizację wdrażającą przed skutkami czasowej lub trwałej niedostępności uczestników projektu. O wiele łatwiej jest też wprowadzić do prac nową osobę, jeśli konieczne jest zwiększenie potencjału realizacyjnego zespołu. Łatwiej jest także przekazywać zadania między członkami zespołu. Dodatkową wartość dokumentacja zyskuje w momencie przekazania systemu do wsparcia przez organizację serwisową, w której znajomość zakresu wdrożenia będzie dużo mniejsza niż w przypadku zespołu projektowego.

Aktualna dokumentacja zyskuje też na wartości wraz z czasem upływającym od momentu wdrożenia. Docenią ją zarówno nowi pracownicy klienta, jak i konsultanci pracujący nad usprawnieniami i rozwojem systemu. Oczywiście, aby dokumentacja dobrze pełniła swoją rolę, powinna być tworzona zgodne z ustalonymi standardami i regularnie aktualizowana.

Brak lub nieprzestrzeganie istniejących standardów owocuje dokumentami o niskiej przydatności: niekompletnymi i/lub nieprecyzyjnymi. Z kolei częstotliwość aktualizacji bywa krytykowana ze względu na „podwójną” pracochłonność: związaną z opracowaniem rozwiązania i jego szczegółowym opisaniem. Z dokumentacją wiąże się wreszcie jeszcze jedno zagrożenie: jeśli zaczyna dominować i sterować pracami w projekcie, to może zamienić się w biurokrację.

Agile

Podejście zwinne wyrosło na początku XXI wieku na gruncie krytyki wad modelu klasycznego. Uważam jednak, że ocena te dotyczy raczej jego wypaczonej postaci (zbytniej biurokracji, skupienia na procesach i narzędziach zamiast na końcowym produkcie, koncentracji na podążaniu za procedurami zamiast na elastyczności i zdrowym rozsądku). Warto także zaznaczyć, że od początku podejście zwinne dotyczyło raczej tworzenia nowego oprogramowania, a nie np. projektów infrastrukturalnych czy wdrażania gotowych produktów. Początkowo traktowano je nieufnie, całkiem niesłusznie postrzegając pracę w tym modelu jako „wolną amerykankę”.

W rzeczywistości podejściu agile towarzyszy kilka bardzo istotnych zasad i wymagań. Konkretne  metodyki zwinne (np. SCRUM, Extreme Programming, Lean Development) mogą uzupełniać te zasady o specyficzne praktyki. Typowy proces dostarczenia końcowego produktu przedstawiono na schemacie.

Najważniejszą cechą podejścia agile jest wczesny i regularny kontakt klienta z tworzonym oprogramowaniem. Zespół projektowy regularnie udostępnia działające funkcje, które klient na bieżąco ocenia i testuje. Dzięki temu może od razu weryfikować jakość i kierunek rozwoju produktu oraz wprowadzać do niego zmiany bądź poprawki. Takie podejście doskonale wpisuje się w sytuacje, w których klient ma początkowo słabo sprecyzowane cele biznesowe i/lub szczegółowe wymagania co do projektu. W rezultacie kolejnych iteracji cel i wymagania będą się stopniowo krystalizować.

W ten sposób agile trafnie odpowiada na bolączkę wielu organizacji usztywnionych procedurami, „imposybilizmem” pracowników czy zwyczajnym niedostatkiem czasu poświęconego na prace projektowe. Podkreślając wydajność i skuteczność częstej, właściwie ciągłej komunikacji (najlepiej bezpośredniej rozmowy) między twórcami i odbiorcami oprogramowania, jasno pokazuje, że stworzenie oprogramowania, które spełnia wymagania i oczekiwania biznesu, wymaga intensywnej współpracy, adekwatnego czasu i równie ciężkiej pracy zarówno ze strony programistów, jak i klienta.

Przedstawiciele biznesu i osoby tworzące oprogramowanie są integralną częścią zespołu. Pracują razem, codziennie, przez cały czas trwania projektu. To istotna różnica w stosunku do podejścia klasycznego, w którym wspólna praca klienta i partnera wdrożeniowego ma miejsce sporadycznie (np. wspólne omawianie koncepcji, wspólne testy funkcjonalne). Do efektywnej współpracy konieczne jest jednak, aby członkami projektu były osoby zmotywowane, posiadające wsparcie, zaplecze i czas niezbędne do realizacji przedsięwzięcia. Istotna jest także stabilność zespołu projektowego: zarówno po stronie klienta, jak i partnera wdrożeniowego.

Taka strategia pozwala też w założeniu na szybsze udostępnienie oprogramowania do codziennej pracy operacyjnej. Kiedy czas rozpoczęcia pracy w systemie ma znaczenie, podejście zwinne sprawdzi się dużo lepiej niż tradycyjne metodyki. Należy jednak pamiętać, że szybsze udostępnienie oprogramowania zdecydowanie nie oznacza szybszego udostępnienia kompletnego, w pełni działającego produktu (takie przekonanie czasem pokutuje wśród niektórych osób). „Szybciej” oznacza jednak w tym przypadku dostarczenie w pierwszej kolejności najważniejszych w danym momencie funkcji oprogramowania. W praktyce najlepiej sprawdza się wariant, kiedy okres między kolejnymi wydaniami wynosi od dwóch do czterech tygodni.

Regularny kontakt i bieżący wpływ na kształt tworzonego rozwiązania oznacza jednak także większe zaangażowanie i większą odpowiedzialność za przebieg prac. Poprzez regularny kontakt z zespołem projektowym klient obejmuje „nadzór właścicielski” nad oprogramowaniem, które powstaje, niemal dosłownie, pod jego dyktando. Zmieniając priorytety funkcji i wpływając na projekt systemu, klient powinien także zdawać sobie sprawę z wpływu tych zmian na harmonogram prac oraz ich pracochłonność.

Kolejną istotną zaletą zwinnych metodyk jest ich nastawienie na zmianę. W tradycyjnym podejściu zmiana jest niepożądanym skutkiem ubocznym niedoskonałych wymagań lub zmian w otoczeniu biznesowym organizacji. Tutaj zmiana jest wpisana w proces tworzenia oprogramowania. Zespół projektowy rozpoczyna pracę od uzgodnionej i uporządkowanej pod kątem priorytetów biznesowych listy funkcji, które powinny być udostępnione w systemie. W trakcie trwania projektu klient ma możliwość regularnej oceny i zmiany priorytetów, tak aby w rezultacie osiągnąć produkt oferujący najważniejsze, w jego ocenie, funkcje. To podejście dobrze wpisuje się także w rozpropagowaną przez Toyotę filozofię ciągłego doskonalenia i poprawy (Kaizen/Kata), np. zespół projektowy powinien regularnie weryfikować swoją efektywność, a dostosowując swoje zachowanie, ciągle ją doskonalić.

Otwartość na zmianę ma jednak co najmniej dwie istotne konsekwencje. Po pierwsze jeśli zaczynamy od ogólnie sformułowanych wymagań i dopiero stopniowo doprecyzowujemy kształt rozwiązania, to znaczy, że powinniśmy liczyć się z nie do końca znanym zewnętrznym (czas pracy konsultantów) i wewnętrznym (czas pracy zaangażowanych pracowników) kosztem prac projektowych. Budżet projektu można oprzeć albo na „otwartym” funduszu projektowym (finansowanie poszczególnych, wybranych funkcji oprogramowania w kolejnych iteracjach), albo na szacunkach dotyczących kluczowych komponentów rozwiązania. W obu wariantach należy jednak liczyć się, że ostateczny budżet rozwiązania będzie równie niedookreślony co ewoluujące wymagania.

Po drugie, to klient a nie konsultanci czy programiści powinien podejmować decyzje co do tego, które nowe funkcje lub zmiany już w istniejących mają być realizowane. Decyzje te powinny być oparte przede wszystkim na wartości (np. zmiana logo na fakturze vs zmiana logo na wewnętrznym wydruku zlecenia remontowego) i priorytecie (np. implementacja nowego modelu produkcji vs automatyzacja manualnego interfejsu wykorzystywanego raz na kwartał), jaki dana funkcja niesie dla działalności operacyjnej danej organizacji.

Oczywiście te decyzje nie są zwykle łatwe, bo poza wymiarem merytorycznym mają także wymiar polityczny i integracyjny. Dlatego też sterowanie procesem dostarczenia oprogramowania jest złożone i wymaga efektywnej współpracy pomiędzy interesariuszami projektu po stronie klienta.

Jedną z takich trudnych kwestii jest także np. definicja akceptowalnego rozwiązania. Oprogramowanie musi działać – to oczywisty warunek konieczny. Trzeba jednak wiedzieć, kiedy powiedzieć „stop”, aby nie wpaść w pułapkę „dopieszczania” mało istotnych elementów rozwiązania w nieskończoność („przesuńmy tytuł faktury o 2 mm w lewo i zmieńmy czcionkę na bardziej czytelną na wydruku”). Elementy stanowiące niską wartość dodaną dla organizacji można sobie pozostawić na koniec, o ile w ogóle zapadnie decyzja o ich finansowaniu i realizacji.

Projekt realizowany w podejściu agile nie posiada kompleksowego, szczegółowego planu dostarczenia wszystkich funkcji. Nie należy jednak mylić tej sytuacji z całkowitym brakiem planowania. W podejściu zwinnym planowanie ma krótszą perspektywę czasową (kilkutygodniowe iteracje/wydania) oraz ograniczoną listę funkcji, która powinna zostać w tym czasie dostarczona (np. konfiguracja kilku konkretnych rabatów zamiast kompletnej konfiguracji modułu SD). Osoba zarządzająca projektem wykorzystuje te miniplany do śledzenia postępów prac, ale w nieco inny sposób niż w tradycyjnym podejściu. Koncentruje się jedynie na działających funkcjach rozwiązania, pomijając (lub przywiązując znacznie mniejszą wagę) do kwestii dokumentacji czy np. dyskusji koncepcyjnych. Działające (tj. zaakceptowane przez klienta) oprogramowanie jest jedynym miernikiem postępów prac w projekcie.

Wreszcie, nieco paradoksalnie, podejście zwinne podkreśla wagę wartości stricte „inżynierskich”. Tworząc nowe funkcje oprogramowania, programiści powinni koncentrować się na doskonałości od strony technicznej i dobrym projektowaniu architektury rozwiązania. Sam proces tworzenia oprogramowania powinien mieć charakter zrównoważony. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymania stałego tempa prac. Lekkie metodyki doceniają także pragmatyzm i prostotę, pamiętając o „ludzkiej stronie projektu”, podkreślając w jednej z praktyk, że najlepsza architektura, wymagania i projekty powstają w samoorganizujących się zespołach.

Być albo nie być (agile)

Projekt wyboru, zakupu i wdrożenia oprogramowania klasy ERP jest wyzwaniem o dużym stopniu ryzyka. Dobierając metodykę do realizacji tego przedsięwzięcia, warto kierować się dwiema kluczowymi wskazówkami:

  • dobra metodyka to taka, która jest wykorzystywana i przestrzegana,
  • podejmując decyzję o wyborze konkretnej metodyki, znamy i rozumiemy konsekwencje tego wyboru

Decydując się na metodykę klasyczną, opieramy się na modelu procesu. Zyskujemy większą przewidywalność i komfort poruszania się w znanych, utartych schematach działania. Tracimy natomiast na elastyczności i szybkości odpowiadania na zmiany w dynamicznym środowisku biznesowym. Wybierając podejście zwinne, decydujemy się na prowadzenie projektu w myśl innej filozofii działania. Projekt jest w stanie bardzo szybko odpowiadać na zmieniające się oczekiwania i dostarczać produkt w trybie kontrolowanego „odkrywania” kolejnych wymagań. Taka „eksploracja” rozwiązania niesie jednak ze sobą większą niepewność co do kosztów i harmonogramu prac.

Wdrożenie ERP to przedsięwzięcie różne od klasycznego dużego projektu IT.  W typowym projekcie IT główny nacisk jest położony na pozyskanie szczegółowych wymagań, które zamienione na zadania programistyczne, kończą się dostarczeniem klientowi wymaganych funkcji biznesowych. Tymczasem projekt ERP zwykle zastępuje (lub co najmniej zmienia) zakonserwowane przyzwyczajeniami procesy biznesowe organizacji nowymi, dostępnymi w ramach konfiguracji systemu ERP. Wdrożenie opiera się na gotowym oprogramowaniu opartym na ustandaryzowanych komponentach i procesach. Dojrzałe rozwiązania, takie jak systemy SAP, pozwalają na daleko posuniętą konfigurację i rozszerzanie standardowych funkcji.

Podejmując decyzję o wyborze metodyki wdrożeniowej ERP, warto rozważyć także podejście hybrydowe, łączące ze sobą elementy metodyki klasycznej z praktykami agile. Przykładem takiego mariażu może być zaczerpnięte z metodyk zwinnych iteracyjne dostarczanie oprogramowania obecne w klasycznej metodyce All for One GoForward.