Umowa wdrożeniowa IT: Waterfall czy Agile? Jak dobrze ułożyć kontrakt na wdrożenie oprogramowania?

Umowa wdrożeniowa IT to kontrakt, który reguluje proces dostarczenia, konfiguracji, integracji, uruchomienia lub rozwoju oprogramowania. Może dotyczyć systemu ERP, CRM, platformy e-commerce, aplikacji SaaS, systemu dedykowanego albo rozbudowy istniejącego rozwiązania.

W praktyce taka umowa często bywa mylona z prostą umową o dzieło albo umową o świadczenie usług. To uproszczenie jest ryzykowne. Wdrożenie oprogramowania rzadko polega tylko na napisaniu kodu. Zwykle obejmuje analizę potrzeb, projektowanie, konfigurację, integracje, migrację danych, testy, odbiory, szkolenia, utrzymanie, SLA, prawa autorskie, licencje i odpowiedzialność za błędy.

Ministerstwo Cyfryzacji w swoich wzorcowych klauzulach wskazuje, że umowy wdrożeniowe wymagają starannego opisania etapów, odbiorów, utrzymania i odpowiedzialności. Dokument ten powstał przede wszystkim z myślą o klasycznych wdrożeniach, w których istotne są zakres, harmonogram i odbiór rezultatu.

Najważniejszy wniosek jest prosty: najpierw trzeba ustalić, jak naprawdę ma być realizowany projekt, a dopiero potem pisać umowę. Inaczej strony mogą podpisać dokument, który dobrze wygląda formalnie, ale nie działa w rzeczywistym projekcie.

Waterfall to model kaskadowy, w którym projekt przechodzi przez kolejne etapy: analiza, specyfikacja, projektowanie, budowa, testy, odbiór i wdrożenie. Najpierw strony ustalają, co ma powstać, a potem wykonawca realizuje projekt według przyjętego planu.

Agile to model zwinny, w którym produkt powstaje iteracyjnie, czyli w kolejnych przyrostach. Zakres nie jest zamrożony w całości na początku. Strony pracują na backlogu, sprintach, priorytetach i kryteriach akceptacji poszczególnych elementów.

Oficjalne dobre praktyki dotyczące Agile w projektach informatycznych wskazują, że Agile nie oznacza braku planu ani braku dokumentacji. Oznacza raczej inny sposób planowania: częstszy, krótszy i bardziej nastawiony na reagowanie na zmianę.

Może być, ale nie zawsze. W polskim prawie nie ma jednego ustawowego typu „umowy wdrożeniowej IT”. Strony budują ją na podstawie zasady swobody umów, przepisów Kodeksu cywilnego, prawa autorskiego, RODO i postanowień szczególnych.

Kodeks cywilny definiuje umowę o dzieło jako zobowiązanie do wykonania oznaczonego dzieła za wynagrodzeniem. To dobrze pasuje do części projektów Waterfall, w których rezultat jest opisany z góry i można go ocenić według konkretnych kryteriów.

Problem pojawia się wtedy, gdy rezultat nie jest jasno określony. Jeżeli strony umawiają się raczej na pracę zespołu, kolejne sprinty, konsultacje, rozwój backlogu i bieżące decyzje biznesowe, projekt może mieć charakter usługowy albo mieszany.

Dla zamawiającego oznacza to, że nie wystarczy napisać w umowie: „wykonawca wykona system”. Trzeba wskazać, jaki system, według jakich wymagań, z jakimi kryteriami akceptacji i jakimi skutkami odbioru.

Dla software house’u oznacza to, że nie warto przyjmować odpowiedzialności za pełny sukces wdrożenia, jeśli powodzenie projektu zależy od danych, decyzji, dostępów, środowisk i zaangażowania klienta.

Najwięcej sporów powstaje wtedy, gdy strony mieszają modele bez świadomości skutków. Pseudo-Agile wygląda w ten sposób, że umowa nazywa projekt zwinnym, ale jednocześnie przewiduje stały zakres, stałą cenę, sztywną datę końcową i prawo klienta do bieżącej zmiany priorytetów. To prowadzi do konfliktu, bo nie da się jednocześnie swobodnie zmieniać zakresu i gwarantować tej samej ceny oraz terminu.

Pseudo-Waterfall wygląda odwrotnie, to znaczy – strony podpisują klasyczną umowę fixed price, ale specyfikacja jest ogólna, klient może stale dodawać wymagania, a wykonawca nie ma procedury zmiany zakresu. Wtedy każda funkcjonalność staje się potencjalnym sporem: czy była w cenie, czy jest dodatkowo płatna.

Dobra umowa musi więc odpowiedzieć na jedno pytanie: co jest stałe, a co może się zmieniać? W Waterfall zwykle stałe są zakres, cena i harmonogram, a zmiana wymaga formalnego change requestu. W Agile stała może być pojemność zespołu, budżet albo długość sprintu, ale zakres powinien być zarządzany przez backlog i priorytety.

W Waterfall zakres powinien być opisany tak, aby dało się sprawdzić, czy wykonawca dostarczył umówiony rezultat.

Dobrze przygotowana umowa powinna zawierać:

1. opis systemu i jego celu biznesowego,
2. specyfikację funkcjonalną,
3. wymagania pozafunkcjonalne,
4. integracje z innymi systemami,
5. wymagania dotyczące danych i migracji,
6. środowiska testowe i produkcyjne,
7. scenariusze testów odbiorowych,
8. wyłączenia z zakresu,
9. procedurę zmiany zakresu.

W Waterfall spór zwykle dotyczy tego, czy dana funkcjonalność była częścią pierwotnej specyfikacji. Dlatego w umowie powinny znaleźć się także wyłączenia. Czasem równie ważne jak to co jest w zakresie jest czego w zakresie nie ma.

W Agile zakres powinien być opisany przez cel produktu, backlog, role decyzyjne i zasady priorytetyzacji. Umowa powinna wskazywać:

1. product vision, czyli cel produktu,
2. backlog bazowy,
3. sposób dodawania i usuwania elementów backlogu,
4. zasady priorytetyzacji,
5. długość sprintu,
6. role po obu stronach,
7. Definition of Done,
8. kryteria akceptacji,
9. zasady rozliczania zmian ponad uzgodnioną pojemność.

Dobre praktyki Ministerstwa Cyfryzacji dotyczące Agile wskazują, że w projektach zwinnych szczególne znaczenie mają współpraca, procedury zmiany, krótkie fazy, częściowe rozliczenia i exit plan.

Odbiór to moment, w którym strony potwierdzają, czy dany element projektu spełnia ustalone wymagania. Bez dobrej procedury odbioru trudno rozliczyć wynagrodzenie, uruchomić gwarancję, naliczyć kary albo wykazać wadę. W Waterfall odbiór powinien być powiązany ze specyfikacją i testami. Umowa powinna wskazywać, kiedy zamawiający może odmówić odbioru, czym jest wada istotna, czym jest wada nieistotna i czy możliwy jest odbiór warunkowy. W Agile odbiór powinien dotyczyć przyrostów. Jeżeli sprint kończy się dostarczeniem konkretnego elementu, Product Owner powinien mieć umocowanie do jego akceptacji. Inaczej pojawi się spór, czy decyzja podjęta podczas sprint review była wiążąca.

Praktyczny zapis w Agile powinien odróżniać wadę od nowej potrzeby biznesowej. Jeżeli element nie spełnia kryteriów akceptacji, jest wadliwy. Jeżeli klient po obejrzeniu działającego przyrostu chce czegoś więcej, zwykle jest to zmiana backlogu.

Model wynagrodzenia powinien odpowiadać temu, kto ponosi ryzyko zmienności zakresu. W Waterfall często stosuje się fixed price, czyli wynagrodzenie za określony rezultat lub etap. To ma sens, gdy zakres jest dobrze opisany, a zmiany są obsługiwane przez procedurę change request.

W Agile częściej stosuje się T&M, capped T&M albo rozliczenia sprintowe/release’owe. Zamawiający płaci za pracę zespołu w określonej pojemności, ale powinien jednocześnie otrzymywać mierzalne przyrosty produktu.

Najbardziej ryzykowny jest model to Agile, ale z gwarancją całego zakresu za stałą cenę i w stałym terminie. Taki model może działać tylko wtedy, gdy umowa zawiera jasny mechanizm trade-off: dodanie jednego elementu oznacza usunięcie innego, zwiększenie budżetu albo przesunięcie terminu.

Exit plan to procedura bezpiecznego zakończenia współpracy i przekazania projektu.

Wdrożenie może się nie udać. Strony mogą też zakończyć współpracę po pierwszym etapie, po kilku sprintach albo po produkcyjnym uruchomieniu systemu. Bez exit planu zamawiający może zostać bez kodu, dokumentacji, dostępów, instrukcji odtworzeniowych i wiedzy projektowej.

Exit plan powinien określać:

1. co wykonawca przekazuje,
2. w jakim terminie,
3. w jakim formacie,
4. kto potwierdza kompletność,
5. jak rozliczane są prace w toku,
6. co dzieje się z danymi klienta,
7. jak wygląda handover do nowego dostawcy.

W Agile exit plan ma szczególne znaczenie, bo projekt rozwija się iteracyjnie. Jeżeli umowa kończy się po kilku sprintach, strony muszą wiedzieć, co dzieje się z częściowo wykonanym backlogiem, dokumentacją, repozytorium i przyrostami.

Nie ma jednego najlepszego modelu dla wszystkich wdrożeń. Model trzeba dobrać do projektu, organizacji i poziomu niepewności.

Waterfall będzie zwykle lepszy, gdy:

1. zakres jest stabilny,
2. wymagania można dobrze opisać na początku,
3. projekt jest regulowany formalnymi odbiorami,
4. zamawiający oczekuje fixed price,
5. system ma jasno określony rezultat.

Agile będzie zwykle lepszy, gdy:

1. potrzeby będą się zmieniać,
2. produkt ma być rozwijany iteracyjnie,
3. klient chce szybko testować przyrosty,
4. biznes jest gotowy do aktywnej współpracy,
5. zakres wymaga priorytetyzacji.

Model hybrydowy może być dobry, gdy analiza i główne kamienie milowe są opisane kaskadowo, ale development i rozwój funkcjonalności odbywają się sprintami. Z danych branżowych  wynika, że modele zwinne i hybrydowe są dziś powszechne, ale Waterfall nadal funkcjonuje, zwłaszcza w większych organizacjach i projektach formalnych.

Przy wdrożeniach dobra obsługa prawna IT polega na zrozumieniu modelu projektu, ryzyk technicznych i interesów obu stron.

Silesia Legal House H wspiera branżę IT, e-commerce, fintech, gamedev, cybersecurity i social media, a także zajmuje się prawem własności intelektualnej oraz prawem AI. Przy umowie wdrożeniowej pomoc może obejmować przygotowanie lub analizę kontraktu, negocjacje z software house’em albo zamawiającym, ułożenie procedury odbioru, opis praw autorskich, klauzule SLA, RODO, poufność i exit plan.

Dla software house’u dobra umowa ogranicza ryzyko niekontrolowanego rozszerzania zakresu. Dla zamawiającego zabezpiecza możliwość egzekwowania jakości, odbioru, dokumentacji, praw do systemu i ciągłości działania.