„U mnie działa” potrafi być prawdziwym zdaniem i jednocześnie niewystarczającym wynikiem odbioru. Autor uruchamia aplikację na znanym koncie, z przygotowanymi danymi i dobrą znajomością kolejności kliknięć. Pracownik może mieć inne uprawnienia, niepełny dokument oraz telefon z małym ekranem. Dlatego odbiór aplikacji powinien sprawdzać ustalone zadania w uzgodnionych warunkach. Pokaz wykonawcy jest pomocny, ale nie zastępuje samodzielnego przejścia procesu przez zamawiającego.
Warunki odbioru warto zapisać, gdy ustalacie zakres. Jeśli aplikacja ma skrócić obsługę zgłoszenia, opiszcie, co użytkownik wprowadza, jaki wynik otrzymuje i które sytuacje wymagają przekazania sprawy dalej. Dzięki temu pod koniec projektu nie musicie dopiero ustalać znaczenia słowa „kompletne”. W przeciwnym razie finał zaczyna przypominać negocjacje definicji, choć obie strony wolałyby już pracować na działającym systemie.
Testuj całe zadanie na danych, które mają sens
Przygotuj kilka spraw odpowiadających rzeczywistej pracy. Dla portalu zamówień może to być zwykły zakup, zmiana ilości i brak dostępnego produktu. Dla narzędzia serwisowego: przydział zlecenia, odrzucenie terminu oraz zamknięcie protokołu. Nie chodzi o mnożenie przypadków dla samej liczby. Chodzi o sprawdzenie reguł, na których opiera się zamówione oprogramowanie, i o możliwość powtórzenia tej samej próby po poprawce.
Wyniki testowania prototypu z pracownikami są dobrym materiałem wejściowym. Jeśli wcześniej poprawialiście niejasny status lub komunikat po zapisie, sprawdźcie, czy gotowa aplikacja realizuje uzgodnienie. Sam fakt, że ekran przypomina makietę, nie oznacza jeszcze poprawnego zachowania. Użytkownik powinien wiedzieć, jaki skutek miała jego czynność i co może zrobić dalej, bez odgadywania intencji programu.
Błąd również jest częścią umówionego działania
W czasie odbioru warto celowo pominąć wymagane pole, powtórzyć kliknięcie i spróbować wejść do sprawy bez odpowiednich praw. Jeżeli aplikacja łączy się z innym systemem, sprawdźcie ustalone zachowanie przy jego niedostępności. Czy użytkownik otrzymuje zrozumiały komunikat? Czy zadanie można bezpiecznie wznowić? Czy operator potrafi znaleźć nieudaną wymianę? Takie próby nie są złośliwością wobec wykonawcy. Chronią obie strony przed kosztownymi niespodziankami po publikacji.
Osobno sprawdź role. Konto administratora potrafi ukryć problem, bo zwykle może zrobić najwięcej. Przejdź zadania jako pracownik, koordynator i klient, jeśli takie role przewidziano. Zwróć uwagę także na eksporty oraz pliki do pobrania. Widok pozbawiony przycisku nie jest dowodem, że niedozwolone dane nie są dostępne inną drogą. Zakres takich testów trzeba dopasować do systemu, szczególnie gdy obsługuje poufne sprawy lub wiele organizacji.
Nadaj uwagom wagę i właściciela
W rejestrze uwag przy każdej sprawie zapisz kroki odtworzenia, oczekiwany rezultat i wynik rzeczywisty. Zrzut ekranu może pomóc, ale sam komentarz „formularz nie działa” nie wystarczy do diagnozy. Ustalcie też, które problemy blokują uruchomienie, a które mogą trafić do uzgodnionej poprawki po starcie. Ta decyzja powinna wynikać ze skutku dla użytkownika oraz danych, a nie z tego, ile dni zostało do prezentacji.
Odbiór pierwszej wersji nie powinien po cichu rozszerzać produktu. Jeśli w trakcie próby pojawi się nowy pomysł, zanotujcie go osobno i oceńcie jako zmianę zakresu. To szczególnie ważne przy MVP aplikacji. Można odkryć potrzebną funkcję i nadal rzetelnie ocenić to, co było przedmiotem zamówienia. Łączenie obu rozmów w jedną listę usterek szybko odbiera jasność nawet dobrze prowadzonemu projektowi.
Sprawdź, kto będzie właścicielem systemu jutro
Dodatkową uwagę poświęć miejscom wymiany danych. Integracja między systemami powinna mieć uzgodniony wynik także po przerwaniu połączenia. Gdy zakres próby ujawni nową funkcję, wróćcie do założeń wyceny zamiast dowolnie rozszerzać listę usterek. Dzięki temu można równocześnie dopilnować jakości zamówienia i uczciwie zdecydować o kolejnych pracach, bez mieszania odpowiedzialności z nowymi pomysłami.
Przed zakończeniem prac przejdźcie również przez przekazanie kodu, kont i dokumentacji. Zespół powinien znać sposób zgłoszenia błędu, wykonania wydania i odzyskania danych. Jeśli uzgodniono kopie zapasowe, przydatny jest dowód próby odtworzenia, a nie sama informacja o włączonej opcji. Odbiór dotyczy narzędzia, które ma działać w firmie, dlatego potrzebuje również podstaw codziennej obsługi.
W Archifutura możemy ustalić scenariusze odbioru razem z zakresem, zamiast dopisywać je na końcu. Na rozmowę o projekcie warto zaprosić osobę, która będzie decydować o gotowości do uruchomienia, oraz przedstawiciela użytkowników. Ich perspektywy są różne i obie potrzebne. Kiedy wiadomo, co sprawdzacie oraz kto podejmuje decyzję, zakończenie projektu przestaje zależeć od tego, kto pierwszy napisze „chyba już wszystko”.
