Wiesz, co zamawiasz.
Wiesz, co odbierasz.
Od wyboru pierwszego zadania do sprawdzenia gotowej wersji. Tak porządkujemy zakres, rozmowę o postępie i decyzje przed uruchomieniem.
Zakres, który można sprawdzić.
Zapisujemy, kto korzysta z aplikacji, jakie dane widzi i po czym poznajemy, że zadanie zostało wykonane. W pierwszej wersji wybieramy jeden pełny proces. Dodatkowe funkcje zapisujemy osobno, żeby nie mieszać startu z dalszym rozwojem.
Przykład: klient wybiera wolny termin, zgłoszenie trafia do obsługi, a klient otrzymuje status. Warunek odbioru opisuje też brak wolnych miejsc, zmianę terminu i brak uprawnień. Nie wystarczy samo stwierdzenie „aplikacja do rezerwacji”.
Ekrany przed programowaniem.
Przechodzimy przez najważniejsze czynności użytkownika na projekcie interfejsu. Omawiamy nazwy, formularze, komunikaty i zachowanie na telefonie. Uwagi do przebiegu łatwiej uporządkować, zanim powstanie całe oprogramowanie.
Zakres ekranów i rund uwag ustalamy w ofercie. Projekt mobilny, panel firmy i część dostępna dla klienta mogą mieć różne widoki, ale powinny opisywać tę samą sprawę.
Postęp na działającym produkcie.
Wersja testowa pozwala sprawdzić uzgodnione scenariusze i zgłosić uwagi. Rozdzielamy błędy w ustalonym zakresie od nowych pomysłów. Zmianę funkcji oceniamy razem z jej wpływem na pracę, cenę i termin.
Ustalamy sposób udostępniania wersji, zbierania uwag i potwierdzania zmian. Częstotliwość rozmów oraz osoby odpowiedzialne są częścią ustaleń projektu.
Odbiór na konkretnych scenariuszach.
Przygotowujemy uzgodnione przypadki sprawdzenia: poprawny przebieg, błędne dane, puste wyniki, uprawnienia i reakcję na problemy połączenia. Lista urządzeń i zakres testów wynikają z wybranych platform i funkcji.
Przed startem potwierdzamy wynik sprawdzenia, znane ograniczenia i sposób zgłaszania problemów. Możesz pobrać checklistę rozmowy o odbiorze i dopasować ją do własnego projektu.
Start i dostęp do obsługi.
Uzgadniamy środowisko uruchomienia, konta właściciela, instrukcje obsługi i odpowiedzialność za usługi zewnętrzne. Dla publikacji mobilnej ustalamy również materiały i konta potrzebne w sklepach.
Termin oceny aplikacji przez sklep nie jest automatycznie terminem wykonania projektu. Zakres przekazania materiałów, dostępów i dokumentacji opisujemy w ustaleniach.
Utrzymanie po uruchomieniu.
Aktualizacje, monitoring, kopie danych i sposób reagowania na zgłoszenia dobieramy do aplikacji. Ustalamy, co obejmuje opieka, jakie koszty są okresowe oraz co jest osobnym rozwojem produktu.
Dla aplikacji z danymi określamy także sposób odtwarzania po problemie. Nie zakładamy automatycznie całodobowej obsługi ani dowolnej liczby nowych funkcji.
Poukładajmy pierwszą wersję.
Wybierz odbiorców i jedno zadanie. Na tej podstawie przygotujemy rozmowę o zakresie.
Test obejmuje także nieudany przebieg.
Zapis na trening powinien uwzględniać pełną grupę i zmianę terminu. Zamówienie potrzebuje obsługi braku produktu, a panel pracownika błędnych danych i braku dostępu. Takie przypadki zapisujemy razem z działaniem, które ma się udać.
Przy odbiorze sprawdzamy uzgodnione urządzenia, role i scenariusze. Zakres może obejmować testy logiki, integracji oraz interfejsu. Automatyzacja pomaga powtarzać wybrane sprawdzenia, lecz nie zastępuje oceny użyteczności i wymagań konkretnej firmy.