logo DevsPower

Usługi

Firma

PL

Osoba przekazująca teczkę oznaczoną napisem "Project" drugiej osobie nad biurkiem, co ugeruje wymianę dokumentacji projektowej lub przekazanie projektu

Zamykanie i odbiór projektu informatycznego

Procedura odbioru oprogramowania jest niezwykle ważną częścią umowy wdrożeniowej, która powinna szczegółowo opracowana przez strony: zamawiającego i wykonawcę. Dzisiejszy wpis poświęcony jest zagadnieniom związanym z odbiorem prac programistycznych.

DevsPower Logo
DevsPower

28. wrzesień 2022

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ć:

  1. 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.

  2. 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:

  1. Przełożyć odbiór oprogramowania na kolejny termin, w którym zostaną poprawione wykazane błędy.

  2. Podpisać z Wykonawcą aneks do umowy, który będzie zawierał opisane błędy wraz z terminem ich poprawy.

  3. 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: 

  1. Czy cele projektu zostały osiągnięte w mniemaniu zespołu projektowego i klienta?

  2. Czy projekt został zrealizowany na czas, w określonym budżecie i czy spełnia wymagania określone w specyfikacji? 

  3. Czy klient był zadowolony z efektów projektu?

  4. Czy udało się osiągnąć wartość biznesową?

  5. Jakie wnioski dotyczące metodyki projektu można wyciągnąć?

  6. 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.

DevsPower Logo
DevsPower

4 minuty czytania

Spis treści:
1. Wstęp
2. Dokumentacja projektu
3. Jaki wybrać sposób odbioru: jednorazowy czy częściowy?
4. Odbiór etapów projektu
5. Odbiór warunkowy
6. Harmonogram odbioru etapów projektu
7. Odbiór końcowy
8. Protokół odbioru
9. Spotkanie ewaluacyjne zespołu projektowego
10. Podsumowanie

DEVS Sp. z o.o.

ul. Święty Marcin 29/8, 61-806 Poznań, Polska

NIP

7831851750

REGON

52124537900000

KRS

0000954492

© DevsPower. 2024. All rights reserved

Kiedy odwiedzasz lub wchodzisz w interakcję z naszymi witrynami internetowymi, usługami lub narzędziami, my lub nasi autoryzowani usługodawcy możemy używać plików cookie do przechowywania informacji, aby pomóc Ci zapewnić lepsze, szybsze i bezpieczniejsze doświadczenie oraz w celach marketingowych