Szablon zadania z błędu klienta ma pozwolić drugiej osobie zobaczyć ten sam problem i rozpoznać, kiedy został usunięty. Samo „nie działa zmiana terminu” nie określa ani miejsca awarii, ani warunków próby. Poniżej znajdziesz nasz wypełniony, fikcyjny przykład formularza, w którym po wyborze nowego terminu przycisk zapisu pozostaje nieaktywny. Możesz wykorzystać ten opis w dowolnej tablicy zadań, zachowując rozróżnienie między relacją klienta, własnym testem i niepotwierdzoną hipotezą.
Opisz obserwację, zanim nazwiesz przyczynę
Zacznij od działania, które klient chciał wykonać, oraz miejsca, w którym utknął. „Po wybraniu jutra o 10:00 przycisk Zapisz pozostaje nieaktywny” opisuje zachowanie; „zepsuta walidacja daty” przypisuje już przyczynę. Jeśli nie sprawdzono kodu, drugie zdanie zapisuj wyłącznie jako hipotezę. Taki podział pozwala wykonawcy zbadać również dostępność terminu, stan formularza czy regułę zmiany, zamiast szukać potwierdzenia pierwszego domysłu.
Oznacz pochodzenie każdego faktu. Klient zgłosił jeden przypadek, a operator wykonał trzy własne próby i uzyskał trzy niepowodzenia w podanych warunkach. To nie oznacza, że problem występuje u wszystkich klientów ani na każdym urządzeniu. Decyzję, czy sprawa wymaga osobnego zadania, opisuje poradnik od zgłoszenia do zadania; tutaj skupiamy się na jakości opisu po podjęciu tej decyzji.
Skopiuj wypełniony szablon z dziesięcioma polami
Poniższe dane dotyczą wymyślonego formularza i służą pokazaniu sposobu zapisu, a nie opisaniu awarii Meetlead. W rzeczywistym zadaniu zamień „jutro” na konkretną datę oraz dopisz zmierzone wersje systemu i przeglądarki. W tym przykładzie ich numery pozostają nieustalone, co jest jawnym brakiem informacji, a nie zgodą na zgadywanie.
Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Pole | Wypełniony przykład | Znaczenie dla wykonawcy |
|---|---|---|
| Tytuł | Zmiana terminu: po wyborze jutra, 10:00 przycisk Zapisz jest nieaktywny. | Wskazuje ekran, działanie i widoczny objaw zamiast ogólnego „problem z rezerwacją”. |
| Cel klienta | Przenieść istniejący termin na jutro o 10:00, bez tworzenia drugiej rezerwacji. | Zmiana dotyczy tego samego wpisu; nowa rezerwacja nie jest równoważnym wynikiem. |
| Warunki wejścia | Testowa rezerwacja istnieje, zmiana jest dozwolona, a wskazany termin jest dostępny według reguł testu. | Jeśli warunek nie zachodzi, najpierw wyjaśnij ograniczenie oferty, zamiast klasyfikować je jako awarię. |
| Środowisko | Android, Chrome, polski język strony, ekran w pionie, WiFi; wersje do uzupełnienia. | To granica potwierdzonej obserwacji, nie lista wszystkich potencjalnie dotkniętych konfiguracji. |
| Kroki | Otwórz zmianę terminu → wybierz jutro → wybierz 10:00 → sprawdź przycisk Zapisz. | Przed próbą przywróć tę samą testową rezerwację i zanotuj konkretną datę. |
| Wynik oczekiwany | Poprawna zmiana aktywuje zapis; jedno zatwierdzenie zmienia termin dokładnie raz i pokazuje wynik. | Sprawdź trwały stan rezerwacji, nie tylko kolor lub aktywność przycisku. |
| Wynik faktyczny | Przycisk nadal nieaktywny; nie można zapisać zmiany i nie widać komunikatu wyjaśniającego blokadę. | Nie wiadomo jeszcze, który mechanizm zatrzymuje zapis. |
| Częstość i wpływ | Trzy próby operatora, trzy niepowodzenia; jeden znany klient, zasięg u pozostałych nieustalony. | Klient nie może sam zmienić terminu; nie ma potwierdzenia utraty danych ani szerszej awarii. |
| Dowód i obejście | Zamaskowany zrzut po wyborze godziny; operator może ręcznie zmienić termin po sprawdzeniu i potwierdzeniu klienta. | Obejście wymaga uprawnienia oraz kontroli dostępności; nie zakładaj, że zawsze istnieje. |
| Odbiór i kontakt | Poprawna zmiana zapisuje się raz, niedozwolona pokazuje powód; właściciel zadania i osoba kontaktowa są wskazani. | Obsługa wraca do zgłaszającego po weryfikacji poprawki, bez obiecywania nieustalonej daty. |
Gdy brakuje informacji, napisz dokładnie, czego nie sprawdzono: wersji Chrome, zachowania na komputerze albo drugiego konta. Unikaj wpisu „wszystko standardowo”, bo odbiorca może rozumieć go inaczej. Formularz nie wymaga pełnej historii rozmowy; potrzebuje faktów, które wpływają na przebieg i odbiór tej konkretnej zmiany.
Szablon zgłoszenia błędu Atlassian uwzględnia środowisko, kroki oraz wynik oczekiwany i faktyczny. Wypełniony przykład i zasady odbioru są naszą propozycją.
Poproś drugą osobę o odtworzenie kroków
Przekaż opis osobie, która nie uczestniczyła w rozmowie, i poproś ją o próbę bez ustnych podpowiedzi. Niech rozpocznie od wskazanego stanu początkowego, a po każdym kroku odnotuje, co widzi. Jeśli musi dopytać, skąd otworzyć zmianę albo jak przygotować rezerwację, uzupełnij opis właśnie w tym miejscu. Test sprawdza odtwarzalność instrukcji, a nie umiejętność domyślania się zamiaru autora.
Drugi wynik dołącz jako osobną obserwację: inne urządzenie, inna data próby, powodzenie lub niepowodzenie. Gdy na komputerze zapis działa, nie usuwaj pierwotnego zgłoszenia; zawęź potwierdzony zakres do badanych konfiguracji. Jeżeli osoba nie znajduje funkcji zmiany, problem nawigacji analizuj odrębnie według testów użyteczności strony. Zagubienie użytkownika i zablokowanie poprawnego zapisu mogą wymagać różnych poprawek.
Dołącz dowód potrzebny do weryfikacji
Zrzut powinien pokazywać wybrany termin, stan przycisku i ewentualny komunikat, bez nazwiska, adresu, telefonu czy prywatnych szczegółów usługi. Zasłoń dane trwale przed dołączeniem materiału, a nie tylko dekoracyjną nakładką w podglądzie. Podpisz plik etapem próby i godziną obserwacji. Odbiorca ma rozumieć, co obraz potwierdza, nawet bez dostępu do całej rozmowy.
Jeśli potrzebne jest krótkie nagranie, pokaż wyłącznie istotną sekwencję i użyj testowej rezerwacji. Nie proś klienta o hasło, pełny ekran konta ani eksport ruchu sieciowego tylko dlatego, że „może się przydać”. Dodatkowe logi powinien dobrać uprawniony specjalista do konkretnej hipotezy. Zachowaj odnośnik do źródła oraz ustal dostęp do dowodów, zamiast rozsyłać kopie osobom niezwiązanym z zadaniem.
Gdy prosisz o obraz problemu technicznego, sprawdź poradnik: Zrzut ekranu do pomocy technicznej: pokaż problem, ukryj dane.
Ustal kryteria odbioru przed rozpoczęciem poprawki
Kryterium „przycisk działa” jest zbyt wąskie. Dla poprawnej zmiany sprawdź, że zapis jest dostępny, zatwierdzenie zmienia istniejący termin dokładnie raz, a ponowne otwarcie pokazuje nową wartość. Dla zmiany niedozwolonej formularz ma podać zrozumiały powód, pozostawiając dotychczasowy termin bez zmian. Ustal oba scenariusze przed pracą, żeby samo odblokowanie przycisku nie zostało uznane za pełne rozwiązanie.
Odbiór wykonaj w środowisku zgłoszenia oraz w dodatkowym wariancie wskazanym przez wykonawcę. Powtórne naciśnięcie zapisu lub odświeżenie nie powinno tworzyć drugiego wpisu; wynik trzeba sprawdzić w trwałym stanie, nie wyłącznie w komunikacie. Oddziel konieczne warunki odbioru od pomysłów na przebudowę całego formularza. Pilność ustal według wpływu i dostępnego obejścia, korzystając z priorytetów w kolejce zgłoszeń. Skutek techniczny i pilność poprawki oceniaj przy tym osobno, według poradnika priorytet a ważność błędu.
Zanim zakwalifikujesz zgłoszenie jako błąd, sprawdź poradnik: Błąd czy nowa funkcja: jak sklasyfikować prośbę klienta.
Powiąż zadanie, właściciela i powrót do klienta
W zadaniu wskaż właściciela realizacji, a w zgłoszeniu osobę odpowiedzialną za odpowiedź klientowi. Dodaj wzajemne odnośniki, aby zmiana statusu zadania nie zerwała kontaktu z pierwotnym zgłaszającym. Gdy potrzebna jest decyzja innego zespołu, zapisz pytanie i oczekiwaną odpowiedź zamiast przesyłać sam link. Szerszy proces przekazania odpowiedzialności omawia eskalacja zgłoszeń.
Z gotowym opisem możesz ręcznie utworzyć zadanie w Projektach Meetlead i powiązać je ze zgłoszeniem, rozmową lub odpowiednim nagraniem. Właściciel i status pomagają śledzić realizację, lecz produkt nie odtwarza automatycznie błędu ani nie wysyła go do Jira. Do pracy potrzebujesz konta, aktywnej aplikacji Projekty oraz dostępu wynikającego z planu i uprawnień. Po sprawdzeniu poprawki obsługa przekazuje klientowi wynik i prosi o potwierdzenie, gdy jego warunki były odmienne.
Pytania o przekazywanie błędów
Czy brak odtworzenia pozwala zamknąć zadanie? Nie przesądza o braku problemu. Zapisz warunki nieudanej próby odtworzenia i porównaj je z relacją klienta. Jeśli brakuje dostępu lub wersji środowiska, wskaż tę lukę i następny sposób jej wyjaśnienia, zamiast oznaczać zgłoszenie jako nieprawdziwe.
Czy muszę od razu wskazać przyczynę? Nie, opis ma przede wszystkim przekazywać sprawdzalne zachowanie. Hipotezę możesz dodać osobno wraz z przesłanką, ale nie wpisuj jej w wynik faktyczny. Przyczyna ustalona po analizie nie powinna zastąpić pierwotnych kroków potrzebnych do odbioru poprawki.
Czy obejście wystarczy do zamknięcia sprawy? Ręczna zmiana może odblokować konkretnego klienta, ale formularz nadal wymaga naprawy. Rozróżnij rozwiązanie doraźnego zgłoszenia od odbioru zadania technicznego. Ustal, kto obserwuje kolejne przypadki i kto wróci z informacją o trwałej poprawce, zanim zakończysz bieżącą rozmowę.
