Protokół odbioru oprogramowania: wzór odbioru etapu i całego wdrożenia

• Odesłanie do umowy i etapu z harmonogramu. Protokół rozlicza konkretne zobowiązanie.
• Jednoznaczną identyfikację wersji: numer wydania, tag w repozytorium, środowisko.
• Zakres wymagań objętych odbiorem.
• Wynik testów akceptacyjnych z raportem jako załącznikiem.
• Listę błędów z kategoriami zgodnymi z umową lub SLA.
• Listę przekazanych elementów: kod, dokumentacja, dostęp, licencje komponentów.
• Decyzję (odbiór, odbiór warunkowy, odmowa) i jej skutek dla płatności.

Definicje błędów, czasy reakcji i naprawy najlepiej ustalić wcześniej w umowie. Wzór takiej umowy znajdziesz przy umowie SLA i wdrożeniowej IT.

Zamawiający nie może odmówić odbioru dowolnie: ma obowiązek odebrać dzieło wykonane zgodnie z umową. Odmowa jest uzasadniona, gdy system nie spełnia uzgodnionych wymagań, a najczęściej, gdy są błędy krytyczne. Dobra praktyka:

• Scenariusze testowe przed testami. Strony akceptują je wcześniej, żeby odbiór nie zamienił się w dopisywanie nowych wymagań.
• Kategorie błędów z przykładami. Krytyczny: brak logowania, błędne naliczenie kwot, utrata danych. Istotny: raport generuje się z błędem, ale jest obejście. Drobny: literówka w etykiecie.
• Odbiór warunkowy przy błędach istotnych i drobnych z terminem naprawy, zamiast blokowania całej płatności.
• Termin na testy. Bez niego odbiór może ciągnąć się miesiącami.

Gdy wykonawca w toku prac tworzy system wadliwie lub niezgodnie z umową, zamawiający może wezwać go do zmiany sposobu wykonania i wyznaczyć termin (art. 636 § 1 KC). Za wady po odbiorze odpowiada wykonawca z rękojmi, do której stosuje się odpowiednio przepisy o sprzedaży (art. 638 § 1 KC), chyba że umowa ją wyłącza lub ogranicza w dopuszczalnym zakresie. Usunięcie usterek po odbiorze warunkowym potwierdza protokół usunięcia usterek.

Program komputerowy jest chroniony jak utwór literacki (art. 74 ust. 1 pr. aut.). Z odbiorem łączą się trzy przepisy:

• Forma przeniesienia. Umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności (art. 53 pr. aut.), czyli podpisu odręcznego albo kwalifikowanego.
• Chwila przejścia praw. Umowa zobowiązująca do przeniesienia praw przenosi je na nabywcę z chwilą przyjęcia utworu, chyba że postanowiono inaczej (art. 64 pr. aut.). Właśnie dlatego data odbioru ma znaczenie.
• Pola eksploatacji. Przeniesienie i licencja obejmują tylko pola wyraźnie wymienione w umowie (art. 41 ust. 2 pr. aut.).

Praktyczny układ: umowa wdrożeniowa z klauzulą o przeniesieniu praw na wymienionych polach eksploatacji jest podpisana na piśmie, a protokół odbioru (podpisany online) potwierdza przyjęcie utworu i tym samym moment przejścia praw. Nie dopisuj w protokole nowych pól eksploatacji ani przeniesienia praw, których nie było w umowie: to byłaby nowa umowa przenosząca prawa, a ta wymaga formy pisemnej. Gdy wykonawca udziela tylko licencji niewyłącznej, patrz umowa licencyjna. Więcej o formie przeniesienia praw we wpisie umowa o przeniesienie praw autorskich: jaki podpis.

Uwaga na przyjęcie dorozumiane: jeśli zamawiający w ciągu sześciu miesięcy od dostarczenia utworu nie zawiadomi twórcy o przyjęciu, nieprzyjęciu albo warunkach przyjęcia, utwór uważa się za przyjęty bez zastrzeżeń; strony mogą ustalić inny termin (art. 55 ust. 4 pr. aut.). Umowy IT zwykle go skracają.

1. Zapisz protokół i raport z testów w jednym PDF (do 6 MB). Długą listę zgłoszeń dołącz jako eksport z systemu zgłoszeń.
2. Dodaj sygnatariuszy: osoby wskazane w umowie jako uprawnione do odbiorów po obu stronach, np. kierownik projektu zamawiającego i kierownik projektu wykonawcy.
3. Ustaw kolejność. Najpierw wykonawca potwierdza zgodność listy błędów, potem zamawiający podejmuje decyzję.
4. Odrzucenie z uzasadnieniem. Zamawiający, który nie zgadza się z treścią, odrzuca dokument i opisuje powód, a wykonawca poprawia protokół.
5. PDF z Kartą Podpisów trafia do obu stron. Znaczniki czasu wskazują dzień odbioru, ważny dla faktury i przejścia praw. Przy wielu wydaniach w miesiącu wysyłkę można podpiąć przez API i webhooki.

Obieg dokumentów w firmie programistycznej omawiamy przy podpisywaniu dokumentów w software house, a w serwisie i utrzymaniu przy dokumentach serwisu IT.

• Protokół bez wersji. Po roku nikt nie wie, którą wersję odebrano, a spór dotyczy właśnie tego.
• Odbiór „na produkcji” bez testów. Zamawiający zaczyna używać systemu, a protokołu nie podpisuje. Wykonawca twierdzi, że dzieło przyjęto przez korzystanie.
• Brak kodu źródłowego przy przeniesieniu praw. Prawa przechodzą, ale bez kodu i dokumentacji trudno je wykorzystać.
• Nowe wymagania jako błędy. Zamawiający zgłasza jako błąd funkcję, której nie było w specyfikacji. To zmiana zakresu, nie powód odmowy odbioru.
• Podpisy niewłaściwych osób. Protokół podpisuje tester zamiast osoby uprawnionej według umowy.

Przed zakupem systemu w jednostce publicznej potrzebę opisuje często protokół konieczności, a ogólne zasady odbiorów prac znajdziesz na stronie protokół odbioru z podpisem elektronicznym.