Zgłoszenie zaczyna się od sytuacji użytkownika.
Prośba „dodajmy więcej przycisków” nie wyjaśnia jeszcze, co przeszkadza w pracy. Zapytaj o zadanie, ekran, wykonane kroki i oczekiwany wynik. Przydatne jest wskazanie, czy problem pojawia się zawsze, czy w konkretnych warunkach. Dane przykładowe powinny pozwalać odtworzyć sytuację bez zbędnych informacji o klientach.
Przykładowo technik nie widzi zmienionego terminu wizyty po powrocie do aplikacji. Najpierw ustalamy, czy aktualizacja została zapisana i jaki widok pozostał otwarty. Rozwiązanie może dotyczyć odświeżenia stanu albo komunikatu, a nie nowego modułu. Sytuacja użytkownika pomaga wybrać właściwy zakres.
Błąd, trudność obsługi i pomysł to różne sprawy.
Błąd oznacza rozbieżność z uzgodnionym działaniem. Trudność obsługi może wynikać z niejasnej etykiety lub przebiegu, mimo poprawnego zapisu. Pomysł na dodatkowy raport rozszerza funkcje produktu. Te sprawy warto rozdzielić, ponieważ wymagają innego rozpoznania i sposobu odbioru.
Sprawdź wersję aplikacji, rolę użytkownika i warunki wystąpienia. W przypadku problemu z dostępem istotne jest, czy użytkownik miał widzieć tę sprawę. Przy prośbie o raport najpierw określamy decyzję, którą ma umożliwić. Samo dodanie kolejnych danych na ekranie nie musi skracać pracy zespołu.
Priorytet wynika ze skutku w pracy.
Weź pod uwagę, czy problem blokuje zadanie, jakich osób dotyczy i czy istnieje uzgodnione obejście. Jedno zgłoszenie o niewłaściwym zapisie może być ważniejsze od wielu próśb o zmianę koloru. Z kolei powtarzający się niejasny komunikat może powodować dodatkowe kontakty z obsługą.
Firma i wykonawca ustalają kolejność oraz odpowiedzialność za dostarczenie materiałów. Nie każda uwaga powinna od razu trafić do najbliższej wersji. Warto zapisać cel, zależności i warunek zakończenia pracy. Dzięki temu plan pokazuje decyzje, a nie tylko rosnącą listę funkcji.
Opisz zmianę tak, żeby dało się ją sprawdzić.
Dla technika celem może być zobaczenie aktualnego terminu po powrocie do widoku sprawy. Wymaganie określa, kiedy pobieramy dane i co pokazujemy przy braku odpowiedzi. Potrzebne próby obejmują nowy termin, brak zmiany i niedostępne połączenie. Wynik nie powinien udawać świeżej informacji, jeżeli nie został sprawdzony.
Przed realizacją oceniamy wpływ na inne ekrany, role i integracje. Zmiana ma uzgodniony zakres oraz warunki odbioru. Wdrożenie poprawki różni się od uruchomienia nowej funkcji, ale obie prace wymagają sprawdzenia właściwego przebiegu. Możesz użyć formularza opisu zgłoszenia.
Po wdrożeniu wróć do pierwotnego zadania.
Sprawdź z użytkownikiem, czy zmiana pomaga wykonać zadanie. Porównanie może obejmować liczbę potrzebnych kroków, błędów lub pytań do obsługi, jeśli firma zbiera takie dane w odpowiedni sposób. Sam fakt opublikowania nowej wersji nie potwierdza, że problem został rozwiązany w codziennej pracy.
Nowe wnioski trafiają do planu dalszego rozwoju. Zachowujemy opis decyzji i oddzielamy wsparcie działającej wersji od kolejnych funkcji. Poznaj zakres utrzymania, koszty po uruchomieniu oraz sprawdzenie wyniku przez firmę.
Jaką decyzję podjąć dalej?
Aby sprawdzić rezultat z perspektywy pracownika firmy, zobacz Jak zorganizować odbiór przez osobę z firmy?.
Po uruchomieniu zakresu przyda się plan opisany w artykule Rozwój i utrzymanie aplikacji po uruchomieniu.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Utrzymanie aplikacji.