Zamykanie i odbiór projektu informatycznego

Umowa wdrożeniowa może przewidywać jednorazowy odbiór przedmiotu prac po zakończeniu projektu, bądź  kilka odbiorów po zakończeniu poszczególnych etapów. Podstawowym celem odbioru jest potwierdzenie należytego wykonania prac. W przypadku projektów programistycznych, z reguły będzie to wymagało przeprowadzenia testów oprogramowania przez techników zamawiającego. Strony powinny oszacować czas trwania testów i uwzględnić go w harmonogramie. Dodatkowo, odbiór może pełnić również inne funkcje, np. warunkować uruchomienie płatności lub rozpoczęcie kolejnego etapu prac.

Pierwszym etap odbioru po uzyskaniu potwierdzenia odbioru stworzonej w ramach projektu aplikacji jest jej instalacja na serwerze produkcyjnym. 

Czasami zakończenie projektu jest wymuszone i wówczas nie wymaga formalnej akceptacji ze strony klienta. Zakończenie w ten sposób projektu występuje, kiedy np. określona jest sztywna data na kiedy aplikacja musi być gotowa w związku z konkretnym wydarzeniem. Na przykład strona eventu musi zostać wykonana przed dniem startu rejestracji uczestników. Klient jest zmuszony zaakceptować produkt niezależnie od tego, czy spełnia on wszystkie wymagania. 

Bardzo dużą grupę stanowią projekty, które nie mają aż tak sztywnej daty zakończenia oraz wymagają szczegółowej weryfikacji. Wymagają one jednak nakładów pracy po stronie klienta i zespołu projektowego i są tworzone na wczesnych etapach realizacji projektu. W uproszczeniu jest to lista funkcjonalności, która musi zostać zweryfikowana przez jednego z członków projektu i odebrana przez klienta. 

Kolejnym elementem zamykania projektu jest przygotowanie dokumentacji. Jest ona szczególnie istotna, jeśli produkt powstały w wyniku realizacji projektu będzie dalej rozwijany, czy ulepszany. W takim przypadku dokumentacja będzie punktem wyjścia dla kolejnego projektu, niezależnie od tego, czy będzie on realizowany przez ten sam czy inny zespół projektowy. 

Dokumentacja ma również znaczenie z punktu widzenia uczenia się i optymalizacji pracy organizacji. Dokumentacja nie powinna się ograniczać do przedstawienia jak projekt zaplanowano, ale powinna również uwzględniać jak projekt zrealizowano, jakie pojawiły się odchylenia od planu i dlaczego. 

Zagadnienie dokumentacji w projektach informatycznych bardzo często kojarzone jest jedynie z dokumentacją techniczną. Jest to dokumentacja przeznaczona dla programistów, którzy będą modyfikować program. Możliwość zautomatyzowania tworzenia dokumentacji technicznej niestety wymaga również dodatkowej pracy programisty, dlatego niezależnie od tego czy zostanie ona opracowana tradycyjnie, czy też wygenerowana czas poświęcony na jej przygotowanie powinien zostać uwzględniony w harmonogramie projektu. 

Oprócz dokumentacji technicznej funkcjonuje również dokumentacja użytkowa przeznaczona dla użytkowników i administratorów systemu. 

Każdy dokument powinien uwzględniać wprowadzone w nim podczas realizacji projektu aktualizacje, zmiany i poprawki.

Odbiór częściowy stosowany jest przy obszernych i skomplikowanych projektach. Odbiór jednorazowy dokonywany jest na finalnym etapie wdrożenia, odbiór częściowy natomiast w trakcie dokonywania wdrożenia.

Odbiór częściowy pozwala na większą kontrolę nad wykonaniem danego projektu. Można wówczas na bieżąco śledzić etapy wdrożenia oraz zgłaszać uwagi, co do realizacji projektu. Takie działanie zmniejsza ryzyko niezgodności na etapie końcowym przy ostatecznym odbiorze.

Podczas odbiorów częściowych należy wykonać podsumowanie wraz z Wykonawcą i wyciągnąć wnioski, które usprawnią projekt w dalszych etapach.

Podczas odbiorów częściowych warto przeprowadzić:

Możliwe jest wprowadzenie do umowy wdrożeniowej pojęcia odbioru warunkowego. Oznacza to, że Zamawiający dokonuje odbioru pomimo nieprawidłowości niskiej kategorii, których usunięcie powinno zostać dokonane podczas kolejnego odbioru częściowego.

Dla dobrej współpracy stron konieczne jest precyzyjne określenie harmonogramu odbiorów poszczególnych etapów projektu. Termin odbioru etapu może być wyrażony konkretną datą lub jako upływ czasu tj. po 14 dniach, po 2 miesiącach.

Warto też pamiętać o określeniu terminu na zgłaszanie wszelkich nieprawidłowości w oprogramowaniu przygotowanym do odbioru. Czas udzielony Zamawiającemu powinien być uwzględniony przez Wykonawcę przy powstawaniu harmonogramu wdrożenia.

Innym ważnym aspektem jest ustalenie częstotliwości zgłaszania uwag dotyczących przedmiotu odbioru przez Zamawiającego. Z punktu widzenia Wykonawcy warto też uwzględnić w umowie brak możliwości zgłaszania nieprawidłowości w oprogramowaniu, które zostało już wcześniej odebrane bez zastrzeżeń na poprzednim etapie.

W przypadku występowania błędów w oprogramowaniu podczas odbioru końcowego można zastosować następujące warianty:

Protokół odbioru jest potwierdzeniem odbioru. Najczęściej wzór protokołu jest załącznikiem do umowy. Finalnym etapem procedury odbioru jest dokonanie odbioru końcowego.

W umowie należy dokładnie określić tryb proceduralny podpisywania protokołu odbioru, jego formę oraz wskazać osoby upoważnione do jego podpisania.

Dla zabezpieczenia warto również uzależnić moment przejścia praw majątkowych do oprogramowania lub moment udzielenia licencji co najmniej od momentu dokonania odbioru bez zastrzeżeń, a najbardziej optymalnym rozwiązaniem – od momentu zapłaty wynagrodzenia.

To czy takie spotkanie się w ogóle odbędzie zazwyczaj stoi pod dużym znakiem zapytania. Najczęściej koniec jednego projektu, to początek kolejnego i brakuje czasu na spędzenie dodatkowych godzin nad już zamkniętym projektem, choć praktycy przekonują, że warto. Podczas takiego spotkania warto odpowiedzieć na następujące pytania: 

Dzisiejszy wpis poświęcony tematyce procedury odbioru oprogramowania przede wszystkim dowodzi potrzebie dokładnego i precyzyjnego sformułowania postanowień umownych. 

W praktyce współpraca z DevsPower nie kończy się w momencie podpisania protokołu odbioru gdyż po etapie wdrożenia, uruchomienia i wprowadzenia aplikacji w życie następuje kolejny. Dalsza współpraca to spotkania z zespołem klienta, podczas których przekazujemy wiedzę dotyczącą jego dalszej edycji, aktualizacji i skalowania.