Priorytet a ważność błędu to pytanie, które wraca przy każdym przeglądzie zgłoszeń od klientów. Ważność (ang. severity) opisuje skutek techniczny: co przestało działać i czy da się to obejść. Priorytet odpowiada na inne pytanie: kiedy zespół się tym zajmie, biorąc pod uwagę klientów, terminy i pozostałą pracę. Gdy obie oceny siedzą w jednym polu, każda dyskusja o kolejności zamienia się w spór o to, „jak bardzo boli”.

Ten poradnik jest dla małego zespołu, w którym ta sama osoba bywa testerem, obsługą klienta i właścicielem produktu. Pokazujemy skalę ważności opisaną skutkiem, dowody, które realnie podnoszą priorytet, oraz moment, w którym zgłoszenie dostaje opiekuna. Nie zajmujemy się tu kolejnością odpowiedzi w skrzynce supportu, tylko kolejnością poprawek w produkcie.

Ważność opisuje skutek, priorytet opisuje termin

Ważność ocenia się, patrząc na sam błąd: która funkcja jest dotknięta, czy dane są zagrożone, czy istnieje obejście. Ta ocena rzadko się zmienia, dopóki nie zmieni się wiedza o błędzie. Priorytet zależy od otoczenia: ile osób trafia na błąd, czy blokuje sprzedaż, czy za tydzień startuje kampania. Ten sam błąd może więc mieć stałą ważność i priorytet, który rośnie albo spada z tygodnia na tydzień.

Dokumentacja Bugzilli rozdziela oba pola: ważność opisuje, jak poważny jest problem (od „aplikacja bezużyteczna” po kosmetykę), a priorytet ustala osoba przypisana albo ktoś, kto kieruje pracą zespołu. To opis konwencji jednego narzędzia, nie norma obowiązująca każdy zespół.

Praktyczna reguła brzmi tak: ważność nadaje osoba, która odtworzyła błąd i zna jego skutek, a priorytet osoba, która decyduje o planie prac. W małej firmie mogą to być te same ręce, ale warto zapisać obie oceny osobno. Dzięki temu po miesiącu widać, czy błąd czekał, bo był drobny, czy dlatego, że ktoś świadomie odłożył poważny problem.

Skala ważności opisana skutkiem, nie emocją

Poziomy ważności działają tylko wtedy, gdy każdy rozumie je tak samo. Dlatego opisz je skutkiem widocznym dla użytkownika, a nie przymiotnikami w rodzaju „pilne” czy „masakra”. Poniższa skala ma cztery stopnie i dwa fikcyjne przykłady: sklep internetowy z herbatą oraz gabinet fizjoterapii przyjmujący rezerwacje online.

Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.

PoziomSkutek technicznyFikcyjny sklepFikcyjny gabinet
S1 krytycznaGłówna funkcja nie działa i nie ma obejścia albo dane są tracone lub ujawnianePłatność kończy się błędem przy każdej metodzieFormularz nie zapisuje żadnej rezerwacji
S2 poważnaGłówna funkcja działa częściowo albo tylko z obejściemKod rabatowy działa dopiero po odświeżeniu koszykaTermin się zapisuje, ale potwierdzenie e-mail nie wychodzi
S3 umiarkowanaFunkcja poboczna działa błędnie, cel da się osiągnąćSortowanie po cenie myli kolejność produktówFiltr po lokalizacji pokazuje zbędną pozycję
S4 drobnaKosmetyka: tekst, wyrównanie, literówkaLiterówka w stopce stronyPrzesunięta ikona w cenniku usług

Ważność opieraj na tym, co zostało sprawdzone, a nie na pierwszej wiadomości klienta. „Nic nie działa” po odtworzeniu często okazuje się poziomem S2 z prostym obejściem. Dlatego ocenę wpisuj dopiero po wypełnieniu szablonu zadania z błędu klienta, gdy znasz kroki, środowisko i faktyczny wynik.

Cztery połączenia ważności i priorytetu

Najwięcej uczą przypadki, w których obie oceny się rozjeżdżają. Poważny błąd w rzadko używanej funkcji może spokojnie poczekać, a drobna pomyłka na stronie głównej bywa pilniejsza niż awaria w panelu administracyjnym. Tabela pokazuje fikcyjne przykłady i decyzję, którą warto przy nich zapisać.

Przesuń tabelę w bok, aby zobaczyć wszystkie kolumny.

PołączenieFikcyjny przykładDecyzja
Wysoka ważność, wysoki priorytetPłatność nie działa w dniu startu kampaniiOpiekun od razu, bieżąca praca czeka
Wysoka ważność, niski priorytetEksport w starym formacie zawiesza panel; używa go jedna osoba raz na kwartał i zna obejścieBacklog z opisanym obejściem i datą przeglądu
Niska ważność, wysoki priorytetBaner na stronie głównej podaje złą datę końca promocjiSzybka poprawka, bo dotyczy obietnicy wobec klientów
Niska ważność, niski priorytetLiterówka na rzadko odwiedzanej podstronieBacklog, przy okazji innej zmiany

Artykuł Sauce Labs opisuje ważność jako techniczny wpływ błędu, a priorytet jako kolejność naprawy zależną od wpływu na użytkowników i biznes, z podobnymi czterema połączeniami. Proponuje też przykładową skalę od 1 do 10 z ogólnymi opisami przedziałów. To propozycja jednego dostawcy narzędzi testowych, nie standard, więc opis poziomów dopasuj do własnego produktu.

Co podnosi priorytet: rozmowy, nagrania i wpływ na cel

Priorytet bez dowodów szybko staje się nagrodą za najostrzejszy ton. Zanim go nadasz, zbierz kilka faktów, które da się sprawdzić i pokazać innym. Każdy z nich odpowiada na pytanie, ile kosztuje czekanie z poprawką.

  • Liczba różnych klientów, którzy zgłosili ten sam objaw, a nie liczba wiadomości.
  • Nagranie sesji pokazujące krok, na którym klient utknął, i to, czy porzucił zadanie.
  • Wpływ na cel strony: czy błąd stoi na drodze do zakupu, rezerwacji albo kontaktu.
  • Obejście, które obsługa może podać w jednej wiadomości.
  • Zewnętrzny termin: kampania, sezon albo wydarzenie, na które klient się zapisał.
  • Zasięg: jedno konto, jedna przeglądarka czy wszyscy użytkownicy.

Liczbę zgłoszeń czytaj ostrożnie. Pięć wiadomości od jednej osoby to wciąż jeden przypadek, a dziesięć podobnych opisów może dotyczyć dwóch różnych usterek. Jeśli ten sam objaw wraca mimo poprawek, szukaj wspólnej przyczyny według poradnika o powracających zgłoszeniach klientów. Nagranie oglądaj z konkretnym pytaniem, tak jak opisujemy w tekście o tym, jak analizować nagrania sesji, zamiast przewijać je w poszukiwaniu czegokolwiek.

Kto decyduje i kiedy błąd dostaje opiekuna

Triage, czyli wstępny przegląd nowych błędów, warto robić w stałym rytmie, na przykład dwa razy w tygodniu, a krytyczne zgłoszenia omawiać od razu. Poniższa kolejność kroków sprawdza się w zespole kilkuosobowym.

  1. Potwierdź, że to błąd.Porównaj wynik z uzgodnionym działaniem. Jeśli klient prosi o coś nowego, sprawa trafia gdzie indziej niż poprawki.
  2. Oceń ważność.Robi to osoba, która odtworzyła błąd. Wpisuje poziom S1–S4 i jedno zdanie uzasadnienia.
  3. Dołącz dowody.Powiązane zgłoszenia, nagranie, wpływ na cel i obejście. Bez nich priorytet zostaje roboczy.
  4. Nadaj priorytet.Decyduje osoba odpowiedzialna za plan prac, nie autor najgłośniejszej wiadomości.
  5. Przypisz opiekuna.Wysoki priorytet dostaje opiekuna od razu. Niski może czekać w backlogu, ale z datą kolejnego przeglądu.

Pierwszy krok rozstrzyga poradnik błąd czy nowa funkcja, bo prośba o rozszerzenie nie powinna konkurować z usterkami na tej samej liście. Pamiętaj też, że kolejność odpowiedzi w skrzynce to osobna sprawa: zgłoszenie może mieć wysoki priorytet w kolejce zgłoszeń, bo klient czeka na obejście, a sama poprawka w produkcie średni.

Jak zapisać obie oceny w Projektach Meetlead

W Projektach Meetlead zadanie ma typ „błąd”, priorytet (wysoki, średni lub niski) i opiekuna. Możesz je powiązać ze zgłoszeniem klienta, nagraniem sesji i innymi zadaniami, a kolejne zgłoszenie tego samego problemu oznaczyć jako duplikat. Tablicę i backlog przefiltrujesz po priorytecie, typie lub osobie. Projekty nie mają osobnego pola ważności, dlatego zapisz ją jako stałą pierwszą linię opisu.

Wzór opisu

Wzór początku opisu: „Ważność: S2 – zapis terminu działa, potwierdzenie e-mail nie wychodzi. Obejście: obsługa wysyła potwierdzenie ręcznie. Dowody: 4 powiązane zgłoszenia, 2 nagrania. Wpływ na cel: brak, rezerwacje się zapisują”.

Priorytet ustawia człowiek; produkt nie ocenia treści zgłoszeń i nie nadaje go automatycznie. Historia zmian zadania pokazuje, kto i kiedy zmienił priorytet, więc decyzję o odłożeniu poważnego błędu łatwo później odtworzyć. Do pracy w Projektach potrzebujesz konta, aktywnej aplikacji Projekty i odpowiednich uprawnień.

Pytania o ważność i priorytet

Czy klient może sam określić priorytet błędu? Klient najlepiej opisze skutek dla siebie: co chciał zrobić, czego nie zrobił i do kiedy musi. To cenny materiał do oceny, ale decyzja o kolejności poprawek należy do zespołu, który widzi wszystkie zgłoszenia naraz. Zapisz jego termin jako dowód, nie jako gotowy priorytet.

Ile poziomów priorytetu potrzebuje mały zespół? Zwykle trzy wystarczą: teraz, w najbliższym cyklu prac i w backlogu. Więcej poziomów rodzi spory o granice między nimi. Usprawnień, które nie są błędami, nie wrzucaj do tej samej skali; do nich lepiej pasuje osobna metoda opisana w poradniku o priorytetach poprawek UX.