Klient pisze: „Eksport jest zepsuty, bo nie ma w nim numeru umowy”. Możliwe, że pole powinno już trafiać do pliku, ale możliwe również, że klient prosi o rozszerzenie działającego eksportu. Najpierw ustal podstawę oczekiwania i rzeczywisty wynik, zanim wybierzesz kategorię.
Poniżej znajdziesz kartę rozstrzygnięcia i przykłady odpowiedzi. To procedura kwalifikacji potrzeby, nie metoda automatycznego wykrywania usterek. Klient opisuje swój problem własnymi słowami; zespół odpowiada za sprawdzenie zachowania produktu.
Ustal, skąd wynika oczekiwane działanie
Zapytaj, co klient chciał osiągnąć, a potem sprawdź opis funkcji, potwierdzone ustalenia albo wcześniejszy wynik. To trzy różne źródła.
Dokumentacja może opisywać wariant innego planu, a wcześniejszy plik pochodzić z innego narzędzia. Porównuj tę samą funkcję i warunki zamiast samej nazwy przycisku.
Brak słowa w instrukcji nie dowodzi, że zachowanie jest prawidłowe. Gdy przycisk zapisania danych nie zachowuje zmiany, sprawdź oczekiwany wynik całego kroku.
Jednocześnie przyzwyczajenie do podobnego produktu nie ustanawia możliwości obecnego narzędzia. Zapisz osobno potrzebę klienta i podstawę, według której oceniasz działanie.
W przykładzie eksportu znajdź informację o jego polach oraz potwierdź wybrany wariant pliku. Nie zapewniaj od razu, że numer umowy zostanie dodany.
Jeżeli dokumentacja jest sprzeczna z konfiguracją, zachowaj oba wskazania. Wyjaśnienie rozbieżności jest częścią sprawdzenia, a nie powodem do przerzucenia odpowiedzialności na klienta.
Rozróżnij usterkę, konfigurację i rozszerzenie
Ta tabela pomaga uporządkować pierwszą decyzję, ale nie zastępuje weryfikacji. „Do sprawdzenia” jest uczciwym wynikiem, gdy nie znasz warunków.
Nie zmieniaj go na „nowa funkcja” tylko po to, żeby skrócić kolejkę usterek. Klient potrzebuje odpowiedzi na problem, nawet jeśli początkowa nazwa kategorii okaże się inna.
Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.
| Ustalenie | Dalsze sprawdzenie |
|---|---|
| Opisane działanie nie daje oczekiwanego wyniku | Sprawdź możliwą usterkę w tych samych warunkach. |
| Funkcja wymaga innego ustawienia lub dostępu | Zweryfikuj warunek i wyjaśnij istniejący sposób użycia. |
| Klient potrzebuje wyniku poza obecnym zakresem | Zapisz potrzebę jako propozycję zmiany. |
| Podstawa oczekiwania lub wynik są nieznane | Pozostaw kwalifikację otwartą do zebrania faktów. |
Ograniczenie planu, brak uprawnienia i błąd wykonania wymagają różnych odpowiedzi. Nie nazywaj każdego z nich usterką ani nie sugeruj zakupu wyższego planu bez sprawdzenia.
Jeśli obecna funkcja rzeczywiście rozwiązuje zadanie, opisz właściwy sposób. Propozycja obejścia ma odpowiadać potrzebie i nie tworzyć nowej obietnicy.
Zbierz tylko fakty potrzebne do kwalifikacji
Nie żądaj od razu pełnego nagrania, wszystkich logów i kolejnych obrazów. Dla eksportu zacznij od nazwy wariantu, oczekiwanego pola i opisu otrzymanego pliku.
Gdy potrzeba istniejącego potwierdzenia, poproś o odpowiedni fragment. Nie zbieraj całej umowy tylko po to, żeby sprawdzić jedną obietnicę dotyczącą funkcji.
- Nazwij rezultat klienta.Zapisz, co ma być możliwe po wykonaniu kroku, bez narzucania rozwiązania.
- Sprawdź podstawę oczekiwania.Znajdź opis lub uzgodnienie dotyczące tej funkcji i jej warunków.
- Porównaj wynik.Ustal, co faktycznie wydarzyło się po tym samym działaniu i co pozostaje nieznane.
- Zapisz kwalifikację z powodem.Wskaż usterkę, istniejący sposób użycia, propozycję zmiany albo dalsze sprawdzenie.
Po potwierdzeniu usterki skorzystaj z szablonu zadania z błędu klienta, zamiast rozwijać pełny raport w tym miejscu. Sama kwalifikacja powinna pozostać krótka. Druga osoba ma rozumieć, dlaczego zgłoszenie trafiło daną ścieżką i na jakiej informacji oparto decyzję.
Przykładowy zapis po pierwszej rozmowie: „Potrzeba: połączyć eksport z ewidencją umów. Obserwacja: wybrany plik nie zawiera numeru; nie sprawdzono jeszcze opisu jego pól. Kwalifikacja: otwarta, oczekuje porównania z zakresem tego wariantu”. To wystarcza do wskazania następnego sprawdzenia bez udawania diagnozy. Gdy druga osoba potwierdzi opis, dopisz źródło ustalenia i jego wynik. Nie zastępuj wcześniejszej obserwacji ogólnym słowem „rozwiązane”, jeśli potrzeba klienta nadal pozostaje otwarta.
Rozdziel regresję i nową potrzebę w tej samej wiadomości
W fikcyjnym przykładzie eksport dawniej zawierał uzgodnioną kolumnę daty, a teraz jej nie ma. Klient prosi też o nową kolumnę numeru umowy.
Pierwszą zmianę sprawdź jako możliwą regresję, drugą jako rozszerzenie zakresu. Jedna wiadomość nie wymaga jednej kategorii dla wszystkich zawartych w niej potrzeb.
„Wcześniej działało” jest istotną informacją, lecz wymaga porównania. Sprawdź, czy plik pochodzi z tej samej funkcji, a konto i ustawienia są porównywalne.
Wcześniejszy niezamierzony efekt także wymaga wyjaśnienia. Nie obiecuj jego przywrócenia przed decyzją o właściwym działaniu produktu.
Jeśli podobne sprawy wracają, sprawdź powracające zgłoszenia klientów.
Nie traktuj liczby kontaktów jako dowodu, że każda prośba jest tą samą usterką. Identyczny opis może dotyczyć innych warunków. Zachowaj powiązanie bez usuwania potrzeb, które są odrębne. Gdy usterka jest już potwierdzona, liczba różnych klientów, którzy na nią trafili, pomoże ustalić kolejność poprawek, co opisujemy w poradniku priorytet a ważność błędu.
Wyjaśnij wynik sprawdzenia bez obietnicy dostarczenia
Możliwa usterka: „Opis tej funkcji przewiduje wskazane pole w wybranym eksporcie, a otrzymany plik go nie zawiera. Przekazujemy tę różnicę do sprawdzenia. Nie mamy jeszcze potwierdzonej przyczyny ani terminu poprawki”. Ten komunikat wymaga faktycznie odnalezionej podstawy oraz przekazania sprawy.
Istniejąca możliwość: „To pole jest dostępne w innym wariancie eksportu. W sprawdzonych warunkach wybierz wskazany wariant i porównaj wynik”. Podaj dokładne kroki dopiero po ich potwierdzeniu. Nie przedstawiaj instrukcji dla innego planu jako rozwiązania dostępnego na koncie klienta.
Nowa potrzeba: „Obecny eksport nie obejmuje numeru umowy. Zapisaliśmy potrzebę połączenia pliku z Twoim zestawieniem oraz jej zastosowanie. Przyjęcie propozycji nie oznacza decyzji o wdrożeniu”. Jeśli nie prowadzicie dalszego przeglądu, nie sugeruj, że propozycja już trafiła do zaplanowanych prac. Jak zorganizować taki przegląd, gdy podobnych potrzeb zbiera się wiele, opisuje poradnik o tym, jak prośby klientów przekładać na roadmapę.
Zachowaj powód kwalifikacji przy zadaniu w Meetlead
W Projektach Meetlead możesz utrzymać opis, typ zadania, komentarze i powiązanie ze zgłoszeniem. Wpisz potrzebę, porównane zachowanie oraz powód kwalifikacji.
Typ wybiera zespół; nie jest automatyczną diagnozą. Konto, zainstalowana aplikacja i odpowiednie uprawnienia są potrzebne do pracy w Projektach.
Przejście od zgłoszenia do zadania ma zachować kontekst klienta. Zmiana typu po nowych ustaleniach nie powinna go zgubić.
Nie dopisuj w komentarzu daty wdrożenia, której nikt nie przyjął. Zadanie w kolejce nie jest potwierdzoną obietnicą produktu.
- Potrzeba klienta jest oddzielona od proponowanego rozwiązania.
- Podstawa oczekiwania dotyczy właściwych warunków.
- Kwalifikacja zawiera krótki powód lub otwarte pytanie.
- Mieszane potrzeby nie zostały sprowadzone do jednej etykiety.
- Odpowiedź nie zamienia przyjęcia zgłoszenia w obietnicę wdrożenia.
Po wykonaniu prac potrzebny jest osobny dowód wykonania zadania. Początkowa klasyfikacja nie potwierdza poprawienia wyniku. Zachowaj możliwość sprawdzenia rezultatu przez drugą osobę przed powrotem do klienta z wiadomością o rozwiązaniu.
Pytania o niejednoznaczne zgłoszenia
Czy nazwa „błąd” podana przez klienta przesądza kategorię? Nie. Zapisz jego problem i sprawdź oczekiwany wynik.
Nie poprawiaj samego słownictwa kosztem zrozumienia potrzeby. Kwalifikacja powinna wynikać z faktów.
Czy brak dokumentacji oznacza nową funkcję? Nie automatycznie.
Ustal zamierzone działanie z właściwą osobą i sprawdź dostępne ustalenia. Brak opisu jest luką w informacji, a nie gotową decyzją o zakresie.
Czy kategorię można zmienić później? Tak, gdy nowe fakty zmieniają ocenę.
Zachowaj krótki powód i powiązany kontekst. Nie przedstawiaj zmiany etykiety jako zakończenia pracy ani potwierdzenia terminu.
Atlassian opisuje prośbę o funkcję jako propozycję nowych możliwości lub ulepszeń. Nie oznacza to automatycznej realizacji: czym jest feature request.
