Odbiory w projektach IT – jak powinna wyglądać procedura odbioru oprogramowania?

Aby zamawiający mógł zacząć korzystać z oprogramowania zaprojektowanego przez software house, niezbędne jest przeniesienie praw autorskich lub udzielenie licencji na stworzony utwór. Zanim to nastąpi firma musi dokonać odbioru projektu, co często wiąże się z wieloma komplikacjami, zwłaszcza jeżeli strony nie zadbały o dokładne udokumentowanie tego, co ma zostać zrobione. O czym pamiętać na etapie ustalania warunków współpracy, aby dało się ją zakończyć z sukcesem dla zamawiającego i wykonawcy? Jak powinna wyglądać procedura odbioru projektów IT?

Dlaczego odbiór projektu w IT bywa problemem?

Na przestrzeni lat metodyki stosowane w branży IT stopniowo ulegają zmianie. Coraz mniejszą popularnością cieszą się klasyczne rozwiązania typu kaskadowego (ang. waterfall), które stopniowo są wypierane przez metodyki zwinne (ang. agile). Te z kolei są bardziej intuicyjne, dynamiczne i – jak pokazuje praktyka – zwykle przynoszą lepszy rezultat w postaci dopasowania rynkowego.

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

Jest tylko jedno ale. Decydując się na tworzenie oprogramowania metodą kaskadową strony umowy jasno określają, co ma zostać stworzone. Umowa, a ściślej stanowiąca załącznik do niej, dokumentacja techniczna, w sposób precyzyjny określa wszystkie funkcjonalności, wykorzystane technologie i rozwiązania.

W metodykach zwinnych takie kwestie niekiedy traktuje się po macoszemu, strony płynnie wymieniają między sobą informacje, zmieniając założenia projektowe na bieżąco. Często jednak zapomina się o wprowadzeniu do umowy definicji wykonanej pracy (ang. Definition of Done, DoD). Ujęcie go w sposób mało precyzyjny może powodować, że trudno ustalić czy wykonawca zachował się w sposób właściwy, a co za tym idzie, sam odbiór może być problematyczny i prowadzić do eskalacji roszczeń.

Sprawdź również: Procedura odbioru w umowie wdrożeniowej – o czym należy pamiętać określając procedurę odbiorową?

Zamów wzory umów IT!

Odbiór w całości czy częściami?

Już na wstępie warto zaznaczyć, że projekty IT potrafią być bardzo rozległe zwłaszcza tam, gdzie chodzi o połączenie ze sobą kilku usług, np. zaprojektowania aplikacji, migracji danych oraz zintegrowania kilku systemów.

O ile w projektach, gdzie dokumentacja techniczna jest niezwykle rozległa, a zamawiający nie pozostawia wykonawcy zbyt dużego pola manewru, sprawdzić może się odbiór całościowy, o tyle w przypadku metody zwinnych z reguły warto wprowadzić odbiór prac partiami.

Polega on na tym, że zamawiający akceptuje kolejne funkcjonalności systemu w miarę, jak są one wdrażane. Wymaga to oczywiście kontroli prac wykonawcy na bieżąco, ale często daje znacznie lepszy rezultat, ponieważ ewentualne uwagi i zastrzeżenia są zgłaszane do poszczególnych, relatywnie niewielkich części usługi, więc też wdrożenie ewentualnych poprawek nie jest tak czasochłonne i kosztowne dla stron.

O tym w jaki sposób podzielić usługę na kolejne części decydują strony umowy. Może on wynikać np. z backlogu, dokumentu zawierającego kolejne etapy, których wykonanie jest niezbędne do osiągnięcia rezultatu. Łatwo wyznaczyć w nim kolejne kamienie milowe, których osiągnięcie wymaga przeprowadzenie obliguje strony do przeprowadzenia procedury odbioru.

Niekiedy też umowa może przewidywać odbiór warunkowy. Polega on na tym, że zamawiający akceptuje część prac pomimo występujących w nich nieprawidłowości, zobowiązując jednocześnie wykonawcę do ich usunięcia do czasu kolejnego odbioru. W ten sposób można zwiększyć dynamikę prac, ponieważ software house może pracować nad kolejnym etapem zadania bez konieczności skupiania się na naniesieniu zmian tu i teraz.

Jak może wyglądać procedura odbioru?

Dla dobrej współpracy stron konieczne jest wprowadzenie do odbioru terminu w jakim zamawiający powinien zgłosić poprawki do projektu. Taki termin należy określić precyzyjnie, np. jako 14 dni lub 30 dni od dnia zgłoszenia, że prace zostały zakończone. W ten sposób również zamawiający jest motywowany, aby prace przebiegały sprawnie, ponieważ brak zgłoszenia zastrzeżeń zwykle będzie skutkował przyjęciem, że prace zostały zrealizowane w sposób prawidłowy, a to z kolei eliminuje możliwość zgłaszania ewentualnych roszczeń. Pominięcie takiego postanowienia może spowodować, że uwagi będą zgłaszane wielokrotnie do tych samych elementów projektu.

Kto może takie poprawki zgłosić? Dobrze jest zadbać, aby konieczność akceptacji prac nie spoczywała bezpośrednio na osobach zajmujących główne stanowiska decyzyjne. Będą to np. członkowie zarządu w spółce z o.o. Choć taki tryb może wydawać się intuicyjny, w rzeczywistości znakomicie utrudnia współpracę i niepotrzebnie ją przedłuża, ponieważ osoby zarządzające spółką zwykle nie mają czasu (a niekiedy także kompetencji), aby zajmować się oceną szczegółów każdego projektu. Dlatego warto wskazać w umowie, że w procedurze odbioru będzie brała udział osoba upoważniona przez zarząd, np. kierownik działu rozwoju.

Zadbaj o protokół odbioru

Jednym z kluczowych załączników do umowy powinien być protokół odbioru częściowego i końcowego. Podpisują go przedstawiciele zamawiającego i wykonawcy po każdym etapie. Dzięki temu powstaje dowód tego, że prace na danym etapie zostały zaakceptowane.

Teoretycznie może dojść do sytuacji, w której zamawiający wezwany do odbioru końcowego prac będzie zwlekał z podjęciem działań. Dlatego umowa powinna przewidywać, że wykonawca po przekroczeniu określonego terminu i ponownym wezwaniu do dokonania odbioru na piśmie może dokonać akceptacji prac samodzielnie. W ten sposób unika się patowej sytuacji, kiedy prace są nieodebrane, a wynagrodzenie pozostaje niewypłacone.

Co z przeniesieniem praw autorskich do projektu IT?

Z reguły znaczna część projektu IT będzie stanowiła utwór w rozumieniu ustawy o prawie autorskim i prawach pokrewnych. Oznacza to, że aby zamawiający mógł z niego korzystać, konieczne jest przejście na niego praw autorskich majątkowych – czy to w drodze umowy o przeniesienie praw czy też udzielenia licencji.

Umowa IT powinna dokładnie wskazywać:

• oznaczenie utworu
• moment przejścia praw na zamawiającego (często będzie to zapłata wynagrodzenia);
• pola eksploatacji, czyli zakres przejścia uprawnień do korzystania z utworu na zamawiającego;
• wynagrodzenie za przeniesienie praw autorskich, jeżeli zostało przewidziane.

Dobrze jest również wskazać, czy zamawiający zachowuje prawo do wykonywania przysługujących mu autorskich praw osobistych, których przenieść nie można, np. poprzez żądanie oznaczenia autorstwa.

Jak określać Definition of Done?

Tym co pozwala jednoznacznie określić, czy zamawiający wywiązał się z powierzonego mu zadania jest konkretny rezultat. Niezależnie od tego w jakim przedmiocie i w jaki sposób jest realizowana umowa, ten rezultat powinien być opisany maksymalnie precyzyjnie.

Definition of Done można opisać jako minimalne kryteria, które muszą zostać spełnione, aby produkt mógł zostać dostarczony klientowi i przez niego zaakceptowany. Tym produktem jest oczywiście przedmiot umowy IT.

To w jaki sposób zostaną zobrazowane kryteria brzegowe dla DoD zależy przede wszystkim od zakresu współpracy, ale na przykład dla umowy o wdrożenie aplikacji do obsługi pacjentów w placówce medycznej może on wyglądać następująco:

• wszystkie procedury testowe zostały zrealizowane;
• podczas testów wykonawca lub przedstawiciel zamawiającego nie natrafili na błędy techniczne, które wskazywałyby na wadliwość aplikacji;
• kod źródłowy został pozytywnie zweryfikowany;
• aplikacja spełnia standardy ochrony danych osobowych wymaganych przez RODO;
• aplikacja spełnia założenia w zakresie bezpieczeństwa ustalone przez strony (np. szyfrowanie AES 256-bitów, uwierzytelnianie wieloskładnikowe).

Jeżeli wykonawca będzie w stanie wykazać, że powyższe warunki zostaną spełnione, uznaje się, że wykonał swoje zadanie poprawnie, co z kolei zobowiązuje zamawiającego do zaakceptowania prac i wypłaty wynagrodzenia. Oczywiście tych warunków może być mniej lub więcej, ale ważne jest, aby oddawały one istotę zamówienia. Dlatego tak ważna jest współpraca stron i wspólne ustalenie DoD.

Przeoczenia na tym etapie są niekorzystne dla obu stron umowy. Zamawiający nie będzie pewien czy otrzymał dokładnie to, co zamawiał. Z kolei wykonawcy trudno będzie wykazać, że dostarczył usługę lub produkt odpowiadające oczekiwaniom zamawiającego. Zupełnie niepotrzebnie rodzi to pole do sporów.

Kancelaria Linke Kulicki – profesjonalne umowy IT

Odbiory projektów w IT to nie tylko część umów o stworzenie i wdrożenie aplikacji. Pojawiają się one bardzo często i równie często rodzą wątpliwości. Jeśli chcesz mieć pewność, że zawarta umowa należycie zabezpiecza Twoje interesy, możemy Ci pomóc!

Kancelaria Linke Kulicki od lat specjalizuje się w bieżącej obsłudze prawnej podmiotów działających w sektorze IT. Nasi prawnicy przygotują umowę odpowiadającą oczekiwaniom oraz celom biznesowym stron, a także zadbają o jej prawidłowe wykonanie w aspekcie formalnoprawnym.

Potrzebujesz wsparcia prawnika IT? Napisz do mnie!