Wstęp
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.
Dokumentacja projektu
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.
Jaki wybrać sposób odbioru: jednorazowy czy częściowy?
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.
Odbiór etapów projektu
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ć:
Szczegółowy test oddanych modułów oprogramowania. Należy wówczas znaleźć czas, aby przeprowadzić szczegółowe testy działania modułów jakie są odbierane. Na etapie odbioru częściowego nie powinno być sytuacji, że moduł, który jest przedmiotem odbioru nie działa.
Podsumowanie pod względem realizacji specyfikacji. Dobrym rozwiązaniem jest stworzenie zestawienia, które zawiera dwa elementy: Opis ze specyfikacji i Ocenę realizacji.
Odbiór warunkowy
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.
Harmonogram odbioru etapów projektu
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.
Odbiór końcowy
W przypadku występowania błędów w oprogramowaniu podczas odbioru końcowego można zastosować następujące warianty:
Przełożyć odbiór oprogramowania na kolejny termin, w którym zostaną poprawione wykazane błędy.
Podpisać z Wykonawcą aneks do umowy, który będzie zawierał opisane błędy wraz z terminem ich poprawy.
Określić błędy w protokole odbioru i ustalić ich poprawę w ramach świadczonej gwarancji. Istotne jest określenie czasu w jakim błędy zostaną poprawione.
Protokół odbioru
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.
Spotkanie ewaluacyjne zespołu projektowego
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:
Czy cele projektu zostały osiągnięte w mniemaniu zespołu projektowego i klienta?
Czy projekt został zrealizowany na czas, w określonym budżecie i czy spełnia wymagania określone w specyfikacji?
Czy klient był zadowolony z efektów projektu?
Czy udało się osiągnąć wartość biznesową?
Jakie wnioski dotyczące metodyki projektu można wyciągnąć?
Co zadziałało, a co nie?
Podsumowanie
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.