Artykuł pochodzi z wydania: Marzec 2024
Rozpoczęcie korzystania z narzędzia informatycznego, przekazanie wynagrodzenia na rzecz wykonawcy, przeniesienie majątkowych praw autorskich – to tylko przykładowe zdarzenia, które mogą zostać kontraktowo powiązane z dokonaniem odbioru. Właściwe ukształtowanie klauzul umowy IT w zakresie zasad odbioru może mieć niebagatelne znaczenie zarówno prawne, jak i finansowe.
Aktualne trendy w świecie IT – w tym powszechne odchodzenie od realizacji projektów w metodykach kaskadowych i zastępowanie ich metodyką zwinną – powodują, że z radaru praktyki kontraktowej często znika kwestia odbioru projektów lub usług. O ile bowiem w przypadku realizacji projektu waterfallowego odbiór stanowi jego najistotniejszy moment i jest obudowany procedurami umownymi oraz rygorami prawnymi, o tyle w zakresie metodyk zwinnych staje się czymś naturalnym, dokonywanym przez strony w sposób stały i odformalizowany (często całkowicie nieformalny i nieobjęty jakimikolwiek procedurami), wpisując się w zasady bezpośredniej i codziennej komunikacji projektowej.
Bliska współpraca zespołów projektowych oraz ich „zagęszczona” komunikacja to nieodłączna cecha każdego projektu realizowanego w metodyce zwinnej. O kluczowej roli tego czynnika wspomina sam „Manifest agile”: „Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu”, „Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz” (agilemanifesto.org/iso/pl/principles.html).
Jednocześnie komunikacja powinna być nacechowana dużym stopniem odformalizowania, pozwalającym na płynny przebieg współpracy, i nie stanowić formalnej bariery utrudniającej realizację projektu. Tyczy się to również odbiorów, które w procesie zwinnym powinny przebiegać w sposób naturalny, oddolny, w ramach cyklu sprintów.
Do lamusa zdają się więc odchodzić praktyki polegające na sporządzaniu rozległych protokołów zdawczo-odbiorczych projektów i usług, dokumentujących wykonanie projektu czy też należyte świadczenie usług IT w danym okresie. Takie „rozluźnione” podejście rynkowe do kwestii odbioru stwarza jednak liczne wyzwania prawne, z jakimi muszą się zmierzyć zarówno uczestnicy projektu, jak i osoby odpowiadające za jego rozliczenie, udokumentowanie czy też wyegzekwowanie efektów.
W artykule omówiono najistotniejsze kwestie dotyczące odbiorów, które powinny być wzięte pod uwagę w procesie przygotowywania, a także wykonywania umów na realizację projektów i usług informatycznych, niezależnie od ich charakteru oraz przyjętych zasad współpracy.
> ODBIÓR W WATERFALL I AGILE
Na początek warto rozprawić się z mitem, jakoby odbiór stanowił przedmiot zainteresowania kontraktowego i operacyjnego wyłącznie w projektach wdrożeniowych – zwłaszcza tych realizowanych w metodykach kaskadowych.
Umowa na realizację projektu IT, zwłaszcza w metodyce zwinnej, to często skomplikowana układanka wzajemnych praw i obowiązków stron. Role stron umowy – w klasycznych projektach kaskadowych z góry zdefiniowane i przyporządkowane – w aktualnej praktyce kontraktowej często się mieszają i przenikają z powodu licznych obowiązków współdziałania, co dodatkowo utrudnia wprowadzanie rozbudowanych zapisów dotyczących odbioru.
Odbiór nie jest przy tym wyłącznie przedmiotem zainteresowania stron umowy wdrożenia. Również w zakresie kontraktów czysto usługowych odgrywa kluczowe znaczenie – i to nawet w sytuacji, w której sprowadza się do czystej akceptacji raportu wykonawcy ze świadczenia usługi w danym okresie. Wiele usług IT zawiera w sobie świadczenia, w których istotne znaczenie prawne i finansowe ma jakość. Aby parametry świadczenia tych usług miały charakter mierzalny i „policzalny”, należy nadać kluczowe znaczenie metodom ich kontraktowej i biznesowej weryfikacji oraz akceptacji przez usługobiorcę.
Odbiór z prawnego punktu widzenia ma więc wciąż niezwykle istotne znaczenie, a skutki prawne złożenia takiego oświadczenia wynikające z przepisów prawa łączą się dodatkowo ze skutkami wynikającymi z regulacji stricte kontraktowych. W zakresie samych wdrożeń odbiór nie jest przy tym domeną wyłącznie waterfallu i wbrew pozorom ma niebagatelne znaczenie również w projektach zwinnych.
Najistotniejszym komponentem odbiorów w procesie, którym rządzi agile, są skrojone na miarę projektu, kompletne i obiektywnie weryfikowalne kryteria odbioru, przybierające często postać Definition of Done (DoD). Najczęściej DoD mają operacyjną postać list kryteriów, formułowanych na kilku poziomach (dla user stories, poszczególnych sprintów, release’ów). Na poziomie umowy komplikację powoduje przy tym całkowita odmienność podejścia agile od modelu kaskadowego – czyli zmiana jako główny „motyw” realizacji projektu (za „Manifestem agile”: „Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju”). Komplikację wprowadza również właściwa dla agile zasada ustalania wszelkich szczegółów (czyli także tych dotyczących samego opisu oczekiwanego produktu oraz kryteriów akceptacji) najpóźniej, jak to tylko możliwe, w ramach bieżących ustaleń projektowych, bez znacznego usztywnienia tych kwestii „z góry” i zawierania stosownych regulacji w samym kontrakcie IT.
Odpowiedzią na te utrudnienia powinna być odpowiednio opracowana procedura definiowania rezultatów prac oraz DoD, przewidująca dokonywanie ich bieżącego przeglądu (w ramach retro), codziennej weryfikacji zadań oraz ustalania priorytetów i uszczegółowiania ich opisów w dokumentacji, np. product backlog czy też w ramach narzędzi przyjętych dla komunikacji projektowej oraz kontroli nad backlogiem.
[…]
Mateusz Kozieł
Autor jest radcą prawnym w kancelarii Barta Łochowski Kancelaria Prawna. Specjalizuje się w zagadnieniach przygotowywania i negocjowania kompleksowych umów w międzynarodowym obrocie gospodarczym (ze szczególnym uwzględnieniem umów w obszarach TMT i IT) oraz prawie własności intelektualnej.
