Konstrukcja umowy wdrożeniowej – modele wdrożeń Waterfall i Agile w praktyce

Według badań i raportów, jedynie około 30% projektów wdrożeniowych kończy się pełnym sukcesem, a około 70% wdrożeń ocenianych jest jako nieudane - z różnych przyczyn, takich jak przekroczenia terminu lub budżetu projektu, niespełnienia zakładanych wymagań lub w ogóle anulowania (porzucenia) wdrożenia. Dlaczego? 

Doświadczenie pokazuje, że przedsiębiorców rozpoczynających wdrożenie oprogramowania / systemu IT można co do zasady podzielić na trzy grupy. 

• Tych, którzy mają wiedzę o procesach i mechanice wdrożenia i są świadomi konieczności włączenia doświadczonego doradcy prawnego we współpracę od samego początku aż do odbioru końcowego wdrożenia. 

• Tych, którzy opierając się na dokumentach kontraktowych przygotowanych przez dostawcę rozwiązania przekazują je do weryfikacji prawnej tak jak każda inną zawieraną umowę, na którym to etapie najczęściej kończy się wsparcie prawne projektu. 

• Jak też tych, w których organizacji weryfikacją dokumentów wdrożeniowych zajmują się osoby skierowane do poprowadzenia wdrożenia od strony organizacyjnej / merytorycznej, pracując „w zaufaniu” na wzorcach przedstawionych przez wybranego dostawcę IT. 

W efekcie, według dostępnych badań około 50% wdrożeń kończy się przekroczeniem założonego budżetu lub niespełnieniem oczekiwanych wymagań, a odsetek projektów porzuconych sięga niemal 20%. Powstaje zatem pytanie – co poszło nie tak?  

Niepowodzenia wdrożeń mogą wynikać zarówno z przyczyn leżących po stronie zamawiającego, jak i dostawcy IT

Czy to wina zamawiającego? – Często. Jedną z przyczyn jest, niestety, nieprzygotowanie do wdrożenia. Tak pod względem organizacyjnym (zasoby, kompetencje), jak i pod względem prawnym (zakres i sposób prowadzenia wdrożenia, kryteria odbioru, warunki płatności i odpowiedzialności). 

Czy to wina dostawcy IT? – Często. Również z różnych przyczyn, w tym związanych z niewłaściwym oszacowaniem zakresu lub ryzyk projektu. 

Jednak ponad to wszystko niemal zawsze przyczyną lub współprzyczyną niepowodzenia jest niezrozumienie przez strony wzajemnych potrzeb, niewłaściwe dobranie charakteru umowy wdrożeniowej i brak zapewnienia równowagi kontraktowej pomiędzy stronami umowy. 

Obecnie najpopularniejsze modele wdrożenia to podejście typu Waterfall (czyli tradycyjne, etapowe) oraz podejście typu Agile (czyli zwinne, oparte na sekwencji krótkich powtarzających się iteracji); ewentualnie kombinacja obydwu modeli. Choć każdy model ma ten sam cel – dostarczyć oczekiwaną wartość, działają zupełnie inaczej i wiążą się z innymi konsekwencjami prawnymi. Każdy wymaga zupełnie innego rodzaju umowy wdrożeniowej i nie zawsze da się je stosować zamiennie. A zatem pokrótce – czym się charakteryzują? 

Waterfall – praca krok po kroku, bez cofania się

To tradycyjny, sekwencyjny, model prowadzenia projektu wdrożeniowego. Etapy następują jeden po drugim: najpierw planowanie, później projektowanie, potem budowa, testowanie i uruchomienie. Przyjmuje się, że dopóki nie zakończymy jednego etapu, nie przechodzimy dalej i nie rozpoczynamy kolejnego. Dopóki nie zakończymy tworzenia projektu, nie rozpoczynamy budowy oprogramowania itd. Jest to model sztywny i liniowy, tworzący „kaskadę” następujących po sobie działań, co widać w typowych grafikach przedstawiających spływający w dół „wodospad” faz projektu.  

Model ten sprawdza się m.in. wtedy, gdy dobrze znamy wymagania i nie przewidujemy ich zmienności. Pozwala na szczegółowe zaplanowanie harmonogramu i budżetu prac. Z drugiej strony, modyfikacja już rozpoczętego projektu może być kosztowna i skomplikowana. 

Agile – praca w małych cyklach i gotowość na zmiany

To podejście zwinne i iteracyjne. Rozbija projekt na drobne części, obejmujące często pojedyncze funkcje lub zadania. Zamiast jednego dużego etapu realizowane są krótkie cykle zwane sprintami. W każdym z nich powstaje działający fragment produktu, który można od razu sprawdzić, ocenić i udoskonalić. Jest to model stawiający na elastyczność, częste dostarczanie mniejszych, ale kompletnych wartości, które można rozwijać w wybranym kierunku. Ważna jest jednak stała bieżąca współpraca dostawcy z klientem. Grafiki przedstawiają podejście Agile jako pętli iteracji, w przeciwieństwie do jednego, liniowego strumienia Waterfall. 

Model ten sprawdza się m.in. tam, gdzie nie da się zaplanować wszystkiego z góry, a wymagania mogą zmieniać się w trakcie prac wdrożeniowych. Pozwala na ciągłą adaptację, eksperymentowanie i doskonalenie efektów prac. Z drugiej strony, z reguły nie można przewidzieć, jaki będzie ostateczny rezultat i jaki będzie jego koszt; przy podejściu tego typu często to budżet wyznacza, jaki będzie końcowy rezultat. 

I jak do tego podejść? 

W szczególności biorąc pod uwagę wyniki badań pokazujące odsetek udanych i nieudanych wdrożeń poszczególnych typów. Czy fakt, że zakończone sukcesem wdrożenia typu Agile to 42%, a wdrożenia typu Waterfall to tylko 13% oznacza, że podejście zwinne zawsze będzie lepsze? Czy fakt, że jako porażka oceniane jest aż 59% wdrożeń typu Waterfall oznacza, że z podejścia tradycyjnego należy zrezygnować? 

Zdecydowanie nie. W każdym przypadku kluczowe jest bowiem zrozumienie wzajemnych potrzeb i właściwe dobranie modelu wdrożenia i charakteru umowy do danego stanu faktycznego. A często np. ukształtowania umowy jako łączącej elementy metodologii Waterfall z metodologią Agile. 

W kolejnym wpisie omówimy szczegółowo umowy typu Waterfall, ze szczególnym uwzględnieniem ich charakteru prawnego, kluczowych uregulowań i rozkładu odpowiedzialności.