Przykład kryteriów akceptacji dla filtrowania listy (faktur)

Mój wpis o checkliście dotyczącej kryteriów akceptacji bardzo przypadł Wam do gustu! Widzę, że szukacie wiedzy na ten temat, dlatego pójdziemy w jeszcze większe konkrety!  

Dzisiaj na przykładzie listy faktur w aplikacji pokażę Ci: 

  • Co uwzględniam w kryteriach akceptacji? 
  • Na jakie „detale” zwracam uwagę? 
  • Do czego służą kryteria akceptacji i jaki mają sens?

Mam nadzieję, że to jeszcze lepiej pomoże Ci zrozumieć ten temat! To zaczynamy!

 

Kryteria akceptacji dla filtrowania listy faktur

 

Cel zadania: 

Określenie kryteriów akceptacji dla wyszukiwania faktury po jej danych poprzez wpisanie znaków w pole wyszukiwania.

Lista kryteriów: 

 

  • Na stronie listy faktur jest dostępne pole wyszukiwania:
    • pole wyszukiwania jest zgodne z designem XYZ,
    • pole przyjmuje litery, cyfry i znaki specjalne,
  • Wyszukiwanie rozpoczyna się, po naciśnięciu przycisku ‘szukaj’ lub kliknięciu ‘enter’,

lub 

  • Wyszukiwanie rozpoczyna automatycznie się po wprowadzeniu co najmniej 2 liter z opóźnieniem 2s,
  • Faktury są wyszukiwane po następujących danych:
    • imię i nazwisko klienta
    • adres klienta
    • nazwy pozycji na fakturze
    • wartość faktury netto
    • wartość faktury brutto
    • numer faktury
  • Lista faktur jest wyfiltrowana po wprowadzonej zmiennej
  • Wyfiltrowana lista faktur jest widoczna po Xs
  • Dla pustej listy wyników wyświetla się komunikat „Nie znaleziono pasujących wyników”
  • Filtrowanie jest usuwane, poprzez kliknięcie przycisku ‘resetuj’

lub

  • Filtrowanie jest usuwane poprzez usunięcie wprowadzonej frazy

 

Dlaczego takie kryteria akceptacji?

Teraz proszę o uwagę, bo to samo mięso tego wpisu! Każde kryterium ma swój powód. Przeczytaj uzasadnienie dla każdego z nich i zobacz, na co zwracać uwagę! 

Na stronie listy faktur jest dostępne pole wyszukiwania:

  • pole wyszukiwania jest zgodne z designem XYZ,
  • pole przyjmuje litery, cyfry i znaki specjalne,

Jeżeli masz szczęście pracować z designerem — good for you!

Wklejasz po prostu linka do designu. 

Jeżeli nie masz tego szczęścia, to masz dwa wyjścia:

  1. Możesz odwołać się do widoku, który już istnieje w aplikacji (np. “pole wyszukiwania na liście faktur” wygląda i jest umiejscowione w ten sam sposób, co “pole wyszukiwania” na liście klientów).
  2. Możesz samodzielnie stworzyć prostą makietę — nawet w Paint!  Lepsza taka, niż żadna. Chodzi o dostarczenie jak największej ilości informacji zespołowi developerskiemu. Sama bez oporów sięgałam po Paint’a, teraz przy tworzeniu makiet często korzystam z narzędzia LightShot,  gdzie można rysować na screenshocie. 

Ważne jest, aby określić rodzaj znaków, jakie akceptujemy w polu. W tym wypadku będą to wszystkie znaki, ale np. dla pola „numer telefonu” ograniczylibyśmy ten zakres wyłącznie do cyfr.

 

☑ Wyszukiwanie rozpoczyna się po naciśnięciu przycisku ‘szukaj’ lub kliknięciu ‘enter’,

lub 

☑ Wyszukiwanie rozpoczyna automatycznie się po wprowadzeniu co najmniej 2 liter z opóźnieniem 2s,

Dużo zależy od tego, jakie zależności i jakie standardy przyjęliście w systemie. Jeżeli macie przyciski — sprawa jest prosta. Choć warto dodać “lub po kliknięciu enter”, ze względu na UX.

Jeżeli wyszukiwanie ma być dynamiczne, trzeba dodać opóźnienie z dwóch powodów:

  • Żeby odciążyć bazę danych zapytaniami (performance),
  • Żeby polepszyć UX — jeżeli wyniki będą zmieniały się, po każdej literze jest to uciążliwe dla użytkownika (cały czas coś „miga” i się przeładowuje)

 

☑ Faktury są wyszukiwane po następujących danych:

  • imię i nazwisko klienta
  • adres klienta
  • nazwy pozycji na fakturze
  • wartość faktury netto
  • wartość faktury brutto
  • numer faktury

Po co męczyć się i  wypisywać dane, po których mamy wyszukiwać? Łatwiej byłoby napisać “po wszystkich danych faktury” 😉

Nie chcemy tego robić, z paru powodów:

  •  Słowa takie jak „wszystkie”, „każde” mogą być interpretowane różnie, nie są jednoznaczne dla każdego interesariusza.
  • Możesz minąć się z prawdą, bo czy na przykład chcemy szukać po wartości podatku vat dla pojedynczej pozycji? Prawdopodobnie nie, bo taka informacja rzadko jest wyszukiwana — prędzej będziemy wyszukiwać po nazwie produktu (co uwzględniliśmy w naszym przykładzie kryteriów akceptacji).
  • Wyszukiwanie po absolutnie wszystkich danych może nie dać nam dobrych wyników, ponieważ wtedy wyszukiwalibyśmy również po etykietach (które są takie same dla wszystkich faktur, więc tak naprawdę wynikiem byłaby pełna lista). Przez etykiety na fakturze rozumiem takie słowa jak np. „NIP”, „Data wystawienia”, „Sprzedający”, „Ilość”.
  • Wyszukiwanie po wszystkich danych faktury (nawet po tych nieprzydatnych) znacząco obciążałoby bazę danych i performance takiego zapytania mógłby być słaby, zwłaszcza jeżeli w systemie jest sporo faktur.

 

☑ Lista faktur jest wyfiltrowana po wprowadzonej zmiennej 

Dosyć oczywiste, ale jednak najważniejsze kryterium akceptacji! Bez tego nie można uznać implementacji za dowiezioną! 

 

☑ Wyfiltrowana lista faktur jest widoczna po Xs

Tutaj zwracamy uwagę na performance rozwiązania. Są różne sposoby implementacji zapytań do bazy i wyświetleniu wyników — deweloperzy muszą wiedzieć, jakie są oczekiwania, żeby odpowiednio zaimplementować rozwiązanie (poprzez np. optymalizację zapytań, tworzenie cache itd.)

 

☑ Dla pustej listy wyników wyświetla się komunikat „Nie znaleziono pasujących wyników”

Tutaj obsługujemy przypadek brzegowy, ważny element z punktu widzenia UX. Unikamy w tym miejscu pisania “jeżeli”, aby ułatwić zrozumienie kryterium. Ludzki mózg analizuje od razu zależności w przypadku zaczynania zdań od warunków tj. “jeżeli”, a nie ma takiej potrzeby. Nie zawsze da się tego uniknąć, ale tam, gdzie się da, bardzo polecam!

 

☑ Filtrowanie jest usuwane poprzez kliknięcie przycisku ‘resetuj’ 

lub

☑ Filtrowanie jest usuwane poprzez usunięcie wprowadzonej frazy 

Alternatywnie można napisać “filtrowanie jest usuwane poprzez usunięcie wprowadzonej frazy” w zależności od tego, jaki jest UX Twojego systemu.

Tutaj zwracamy uwagę na przywrócenie systemu do poprzedniego stanu.

 

Twórz specyfikację z innymi interesariuszami.

 

Prawdopodobnie jesteś pierwszą i główną osobą odpowiedzialną za pisanie kryteriów akceptacji. Ale nie jedyną!

Sprawdź to, co zostało przez Ciebie zapisane, ze swoimi interesariuszami i zespołem deweloperskim (oni też są Twoimi interesariuszami!). Nie frustruj się pytaniami „a co jeżeli…” – właśnie w ten sposób powstaje świetna specyfikacja uwzględniająca wszystkie przypadki!

Czy powyższy przykład to pełna lista kryteriów akceptacji? Pewnie nie… 

W końcu sama wymyśliłam wymaganie i sama stworzyłam listę kryteriów akceptacji w oderwaniu od jakiegokolwiek systemu. Może więc ona się różnić w zależności od specyfiki systemu. Brakuje mi również interesariuszy z ich “koncertem życzeń” 😉 

Postaram się co jakiś czas publikować różne przypadki dotyczące kryteriów akceptacji, żeby każdy znalazł coś dla siebie! 

Jeżeli interesuje Cię konkretny temat — daj znać w komentarzu, dopiszę go do kolejki!

Podaj dalej:

💌 Napakowany newsletter Product Ownera na start

  • PDF z roadmapą nauki dla Product Ownerów
  • Cotygodniowy mailing pełen wiedzy
  • Materiały demo prosto ze Szkoły Product Ownera

Warto przeczytać: