Procedura odbioru oprogramowania w umowie wdrożeniowej. Poradnik dla software house’ów #11

Zasady dokonywania odbiorów są często jedną z długo negocjowanych elementów umowy wdrożeniowej – odbiór pociąga bowiem za sobą szereg konsekwencji prawnych czy umownych. Dzięki lekturze tego artykułu dowiesz się, jakie główne ryzyka wykonawcy należy zabezpieczyć określając w umowie procedurę odbioru.

Procedura odbioru oprogramowania – na co zwrócić uwagę?

O czym należy pamiętać określając procedurę odbiorową?

Podstawą jest dokonanie wyboru pomiędzy odbiorem jednorazowym (pod koniec wdrożenia) a odbiorami częściowymi (sukcesyjne dokonywanie odbiorów danych części wdrożenia).

Wybór między odbiorem jednorazowym a częściowym (sukcesywnym) ma fundamentalne znaczenie dla zarządzania ryzykiem i kontroli projektu.

Odbiory sukcesywne są szczególnie rekomendowane przy większych projektach wdrożeniowych, ponieważ zapewniają zamawiającemu bieżącą kontrolę nad postępem prac i umożliwiają regularne przekazywanie informacji zwrotnych wykonawcy, co jest kluczowe dla dostosowywania się do zmieniających się oczekiwań.

Korzyści z odbiorów sukcesywnych dla zamawiającego obejmują: większą kontrolę nad wykonywaniem projektu, regularny przepływ informacji zwrotnych dla wykonawcy oraz znaczące obniżenie ryzyka rozczarowania przy odbiorze końcowym, zwłaszcza jeśli efekty końcowe mogłyby znacznie odbiegać od początkowych wyobrażeń.

Dla wykonawcy, odbiory sukcesywne oznaczają regularne potwierdzenie postępu prac i możliwość wcześniejszego fakturowania, co poprawia płynność finansową i stabilność projektu.

Dzielenie projektu IT na mniejsze, podlegające odbiorowi etapy, stanowi proaktywne zarządzanie ryzykiem. Wszelkie problemy wykryte na wczesnym etapie są zazwyczaj łatwiejsze i tańsze do naprawienia, niż te, które kumulują się i zostają odkryte dopiero pod koniec projektu.

Takie podejście minimalizuje ryzyko ,,wielkiego wybuchu” związanego z jednorazowym odbiorem, gdzie nie wykryte problemy mogą prowadzić do katastrofalnej porażki projektu lub znacznych przekroczeń kosztów po odbiorze końcowym.

Sprawdź również: Jak powinna wyglądać procedura odbioru oprogramowania?

Zamów wzór umowy wdrożeniowej IT!

Znaczenie szczegółowej specyfikacji i kompleksowej dokumentacji w procesie odbioru

Precyzyjne opisanie przedmiotu umowy, np. w postaci specyfikacji dołączonej w formie załącznika, ma ogromne znaczenie dla wykonawcy w kontekście zgłaszania błędów. Zapobiega to ryzyku zgłaszania przez zamawiającego jako nieprawidłowości braku funkcjonalności, które nie zostały uwzględnione w specyfikacji lub nie zostały opisane wystarczająco precyzyjnie.

Kompleksowa dokumentacja projektu IT, w tym specyfikacje wymagań (funkcjonalnych i niefunkcjonalnych), architektura systemu, dokumentacja kodu źródłowego, plany testów oraz instrukcje wdrożenia i utrzymania, jest niezbędna do zapewnienia wspólnego zrozumienia między stronami i uniknięcia nieporozumień.

Dokumentacja służy jako ,,mapa drogowa” projektu, ułatwia transfer wiedzy, zapewnia zgodność z normami i standardami, zwiększa efektywność zespołu i współpracę, a także buduje zaufanie zewnętrznych interesariuszy.

Wymagania funkcjonalne definiują, co system musi robić (np. funkcje logowania, przetwarzania płatności), podczas gdy wymagania niefunkcjonalne opisują, jak system działa (np. szybkość, dostępność, bezpieczeństwo, użyteczność, skalowalność).

Dokumentowanie obu typów wymagań jest kluczowe dla uniknięcia porażki projektu, zapewnienia, że system działa zgodnie z oczekiwaniami, pracy w ramach budżetu i precyzowania zakresu.

W metodykach Agile, kryteria akceptacji (często nazywane ,,definition of done”) to zbiór predefiniowanych wymagań, które muszą być spełnione, aby uznać historyjkę użytkownika za ukończoną.

Efektywne kryteria akceptacji powinny być testowalne, jasne, zwięzłe, zrozumiałe dla wszystkich i przedstawiać perspektywę użytkownika.

Sprawdź również: Metodyki projektowe – Agile vs. Waterfall

Harmonogram odbiorów poszczególnych etapów projektu

Należy precyzyjnie opisać samą procedurę odbioru, a harmonogram odbiorów powinien stanowić część umowy. Termin przedstawienia danego etapu do obioru może zostać wyrażony w konkretnej dacie lub poprzez upływ czasu, np. 3 miesiące od odebrania projektu technicznego.

Konieczne jest nałożenie na zamawiającego limitu czasowego na zgłaszanie nieprawidłowości w oprogramowaniu przedstawionym do odbioru (np. 3 dni robocze) – takie rozwiązanie motywuje zamawiającego do współdziałania, a tym samym pozwala wykonawcy na terminowe wykonywanie umowy w ramach dalszych etapów i zapobiega opóźnieniom.

Czas udzielony zamawiającemu na zgłoszenie uwag powinien zostać oczywiście uwzględniony przez wykonawcę przy tworzeniu harmonogramu wdrożenia.

Klauzule dotyczące terminów na zgłaszanie uwag stanowią przykład zaawansowanego projektowania umów, które ma na celu pozytywne oddziaływanie na dynamikę projektu.

Nie chodzi tu jedynie o zdefiniowanie obowiązków, ale o kształtowanie pożądanych zachowań, takich jak współpraca i terminowość, oraz odstraszanie od niepożądanych działań, jak bezczynność czy celowe opóźnianie.

Takie mechanizmy prawne przekształcają pasywny obowiązek w aktywny czynnik napędzający tempo projektu, co jest niezwykle istotne w dynamicznym środowisku IT.

Uwagi do przedmiotu odbioru projektu IT

Warto również ustalić, jak często zamawiający może zgłaszać uwagi do przedmiotu odbioru. Dla wykonawcy najbardziej preferencyjne jest ustalenie jednorazowej możliwości zbiorczego zgłoszenia uwag. Zamawiający niechętnie jednak przystają na takie rozwiązanie, w związku z czym należy wprowadzić do umowy postanowienia regulujące postępowanie w przypadku, w którym oprogramowanie ponownie przedstawione do odbioru nadal będzie posiadać błędy.

Z perspektywy wykonawcy warto uwzględnić w umowie brak możliwości zgłaszania przez zamawiającego nieprawidłowości w oprogramowaniu, które zostało już odebrane bez zastrzeżeń w ramach poprzednich etapów.

Zamów wzór umowy wdrożeniowej od prawnika!

Czym jest odbiór warunkowy?

Nieodzowne jest także określenie dla wykonawcy czasu na usunięcie nieprawidłowości w zgłaszanym do odbioru oprogramowaniu. Termin ten powinien być odpowiednio długi – tak, aby nie narażać wykonawcy na zapłatę kar umownych za ewentualne opóźnienia.

Możliwe jest wprowadzenie do umowy mechanizmu tzw. odbiorów warunkowych – w takim przypadku zamawiający dokonuje odbioru pomimo istnienia nieprawidłowości niższej kategorii, których usunięcie jednak powinno zostać dokonane w ramach kolejnego odbioru.

W temacie zgłaszania błędów łatwo zauważyć, że ogromne znaczenie dla wykonawcy ma tutaj precyzyjne opisanie przedmiotu umowy, np. w postaci specyfikacji dołączonej w formie załącznika. Zapobiega to ryzyku zgłaszania przez zamawiającego jako nieprawidłowości np. braku funkcjonalności, które nie zostały uwzględnione w specyfikacji (lub nie zostały opisane wystarczająco precyzyjnie).

Bardzo częstym (oraz rekomendowanym) rozwiązaniem jest wprowadzenie procedur testowych celem weryfikacji poprawności wykonanego oprogramowania. 

Potwierdzeniem dokonania odbioru jest zazwyczaj protokół odbioru (wzór takiego protokołu najczęściej załącza się do umowy). W umowie należy określić tryb proceduralny podpisywania takiego protokołu (np. czy jest wymagana forma pisemna, kto jest upoważniony do jego podpisania itp.).

Końcową fazą procedury odbioru jest dokonanie odbioru końcowego, podczas którego zamawiający odbiera całość przedmiotu umowy. Moment ten jest często poprzedzony istnieniem tzw. okresu stabilizacji, podczas którego weryfikowane jest, czy oprogramowanie spełnia standardy wydajności i funkcjonalności określone w umowie.

Sprawdź również: Testy oprogramowania w umowie wdrożeniowej

Co w sytuacji, w której zamawiający nie zgłasza uwag ani nie dokonuje odbioru pomimo upływu terminu?

W praktyce dość często zdarzają się przypadki, w którym zamawiający ani nie zgłasza istnienia nieprawidłowości w przedmiocie odbioru w określonym terminie, ani nie dokonuje odbioru w trybie opisanym w umowie (np. poprzez podpisanie protokołu).

Aby minimalizować ewentualne skutki takiego ryzyka zaleca się wprowadzenie do umowy możliwości dokonania jednostronnego odbioru przez wykonawcę w sytuacji, w której zamawiający nie dokonuje odbioru ani nie zgłasza nieprawidłowości.

W tym przypadku za moment odbioru uznaje się moment podpisania protokołu odbioru przez wykonawcę. Na powyższy tryb zamawiający oczywiście niechętnie się zgadzają, jednak zdecydowanie jest to pole warte negocjacji.

Dla zabezpieczenia się przed powyższą sytuacją rekomendujemy także uzależnienie momentu przejścia autorskich praw majątkowych do oprogramowania (lub momentu udzielenia licencji) co najmniej od momentu dokonania odbioru bez zastrzeżeń (a najlepiej od momentu zapłaty wynagrodzenia) – takie rozwiązanie będzie motywować klienta do regularnego dokonywania odbiorów i zgłaszania uwag.