Jak skutecznie definiować nowe wymagania i zgłaszać nieprawidłowości?

Czy zdarzyło Ci się, że Twoje zgłoszenie dotyczące nowej funkcji lub błędu w systemie zostało źle zrozumiane, albo wykonawca zadał pytania, które z Twojej perspektywy są „oczywiste”? W Ageno wiemy, jak ważna jest skuteczna komunikacja w projektach IT. Dlatego przygotowaliśmy prosty przewodnik z najlepszymi praktykami, który pomoże Ci szybko i skutecznie zgłaszać wymagania oraz nieprawidłowości/usterki/bugi.

Dlaczego to jest ważne?

Kompletne, klarowne wymagania, zawierające User Story, Kryteria akceptacji i inne materiały:

  • przyspieszają realizację;
  • oszczędzają czas;
  • minimalizują nieporozumienia;
  • redukują liczbę błędów w oprogramowaniu (bugfixing);
  • zapewniają szybszą reakcję i naprawę potencjalnych problemów (w przypadku zgłoszeń).

Co to jest Wymaganie?

Udokumentowana reprezentacja warunku lub zdolności, które użytkownik lub system musi spełnić, aby rozwiązać problem, osiągnąć cel.

  • Wymagania funkcjonalne: Określają, jakie funkcje system ma realizować. (np. interakcja z użytkownikiem).
  • Wymagania niefunkcjonalne: Dotyczą działania samego systemu (np. prędkość, wydajność, skalowalność, bezpieczeństwo).

Zasada INVEST

Określając wymagania, należy kierować się zasadą INVEST:

  • I – Independent — tworzenie jak najmniejszych jednostek, które są niezależne od innych zadań.
  • N – Negotiable — wymagania powinny być wynikiem dyskusji zespołu z Klientem i pozostawiać pole do dyskusji.
  • V – Valuable — User Story powinno nieść wartość dla użytkownika końcowego i być istotne dla biznesu.
  • E – Estimateable — User Story powinno być możliwe do oszacowania w zakresie wymaganego nakładu pracy.
  • S – Small — User Story powinno być na tyle niewielkie, aby można było go łatwo zaplanować i wykonać w kilka, do kilkunastu dni.
  • T – Testable — User story powinno posiadać określone kryteria akceptacyjne, umożliwiające jego przetestowanie niezależnie od innych i opracowanie w dowolnej kolejności.

Proces definiowania wymagań

  • Określenie zakresu –  Precyzyjne zdefiniowanie, co będzie objęte wymaganiem.
  • Opracowanie wymagania – Szczegółowe opisanie, co system ma robić i jakie kryteria musi spełniać. ​
  • Priorytetyzacja – Ustalenie, które wymagania są najważniejsze.

Jak zgłaszać nowe wymagania?

Definicja Gotowości (Definition of Ready, DoR) to zestaw kryteriów, które muszą zostać spełnione, aby zadanie mogło optymalnie zostać podjęte przez zespół deweloperski. Aby Twoje wymaganie/zgłoszenie było kompletne i pozwalało na jego sprawną realizację, powinno zawierać:

  • Tytuł – krótki i precyzyjny, wskazujący na istotę wymagania.
  • Opis – szczegółowe informacje: co dokładnie powinno zostać wdrożone i dlaczego?
  • User Story – kto, co i dlaczego chce osiągnąć dzięki tej zmianie? (Jako )
  • Materiały dodatkowe – linki, przykłady, inspiracje.
  • Kryteria akceptacji – jak sprawdzimy, czy wymaganie zostało poprawnie zrealizowane. Jest to lista określająca warunki, na podstawie których wymaganie jest spełnione. Zwięźle napisane kryteria pomagają uniknąć niejednoznaczności. Dzięki nim można określić, jaki powinien być rezultat danego zadania.

Oprócz powyższych elementów, korzystamy nadrzędnie z Definition of Done.

Przykład 1: Zgłoszenie problemu z logowaniem

❌ Przykład złego zgłoszenia:

Tytuł: Mam problem
Opis: Nie mogę się zalogować.

Dlaczego to jest złe zgłoszenie?

  • Tytuł karty nie wskazuje, czego dotyczy problem.
  • Brakuje informacji: gdzie klient próbuje się zalogować (panel administracyjny, blog, konto użytkownika)?
  • Nie podano komunikatu błędu – czy pojawia się jakiś komunikat, czy strona się nie ładuje?
  • Brak informacji o urządzeniu i przeglądarce.
  • Nie wiadomo, czy problem dotyczy wszystkich użytkowników czy tylko konkretnego konta.

✅ Przykład prawidłowego zgłoszenia:

Tytuł: Błąd logowania przy próbie dostępu do panelu administracyjnego
Opis: Podczas próby logowania na konto użytkownika testowego w panelu administracyjnym (test@domena.pl) otrzymuję komunikat: „Błąd autoryzacji. Kod błędu 42291047” mimo że dane są poprawne (sprawdzałem).

Dodatkowe informacje:

  • Problem występuje na przeglądarce Chrome (wersja 120.3.1) na systemie Windows 11.
  • Logowanie działa poprawnie w trybie incognito.
  • Link do strony logowania: projekt1624.pl/admin-e3x91a0b/login.

Przykład 2: Błędna cena wyświetla się na karcie produktu

Opis problemu:
W sklepie internetowym wystąpiła sytuacja, w której dla kilku produktów na karcie produktu wyświetla się cena sprzed zmiany cennika w systemie ERP. Ceny nie zostały poprawnie zaimportowane dla całej Marki Z.

❌ Przykład A złego zgłoszenia:

Tytuł: W sklepie internetowym źle wyświetlają się ceny.
Opis: Błędne ceny!

Dlaczego to jest złe zgłoszenie?

  • Tytuł karty nie wskazuje, gdzie wyświetlają się błędne ceny.
  • Opis jest zbyt ogólny, brak konkretnych informacji.

❌ Przykład B złego zgłoszenia:

Tytuł: Dlaczego cena w produkcie 5987734235 jest zła?
Opis: Nie działa synchronizacja z systemem ERP.

Dlaczego to jest złe zgłoszenie?

  • Tytuł nie powinien mieć formy pytającej.
  • Brakuje informacji o oczekiwanym stanie (jaka cena powinna się wyświetlać?).

❌ Przykład C złego zgłoszenia:

Tytuł: Widok produktu – zła cena w produkcie 5987734235
Opis: W produkcie 5987734235 cena źle się wyświetla.

Dlaczego to jest złe zgłoszenie?

  • Brak informacji o oczekiwanym stanie, czyli jaka cena powinna być wyświetlona.

❌ Przykład D złego zgłoszenia:

Tytuł: Widok produktu – zła cena w produkcie 5987734235
Opis: W produkcie 5987734235 cena źle się wyświetla, powinno być 39,90. Kolor zmienić na czerwony i wielkość czcionki powiększyć.

Dlaczego to jest złe zgłoszenie?

  • Zgłoszenie zawiera zarówno informację o błędzie, jak i nowe wymaganie (zmiana koloru i czcionki). Te kwestie powinny być zgłoszone oddzielnie.

✅ Przykład poprawnego zgłoszenia:

Tytuł: Widok produktu – złe ceny dla produktów marki Z
Opis: Dla produktów marki Z wyświetlają się błędne ceny. Była aktualizacja cen w systemie ERP.
Lista produktów z cenami jakie powinny być:
– 5983735233 – 59,90
– 5987734235 – 39,90
– 5987735235 – 49,90

Przykład 3: Wymaganie spoza branży IT

❌ Przykład złego wymagania:

Tytuł: Posprzątać kuchnię
Opis: Kuchnia powinna być czysta.

Dlaczego to jest złe wymaganie?

  • Nie określono, co dokładnie oznacza „czysta kuchnia”.
  • Wymaganie bazuje na domysłach i jest trudne w interpretacji.
  • Brakuje konkretnych działań, jakie należy podjąć.
  • Brak kryteriów akceptacji i terminu realizacji.
  • Czy oznacza to, że należy umyć okna? Odkurzyć za lodówką?

✅ Przykład prawidłowego wymagania:

Tytuł: Cykliczne sprzątanie kuchni w biurze raz dziennie.
User Story: Jako pracownik biura chcę pracować w estetycznych i higienicznych warunkach aby móc wydajnie pracować.
Opis:

  • Wytarcie blatów i stołów wilgotną, świeżą ściereczką z detergentem.
  • Umycie naczyń.
  • Opróżnienie kosza na śmieci i włożenie nowego worka.
  • Umycie podłogi mopem świeżą, czystą wodą z detergentem.
  • Sprzątanie powinno odbywać się codziennie do godziny 18:00.

Kryteria akceptacji:

  • Podłoga jest umyta, sucha i bez plam.
  • Blaty i stoły są czyste, bez widocznych zabrudzeń.
  • Wszystkie naczynia zostały umyte lub umieszczone w zmywarce.
  • Kosz na śmieci jest opróżniony, a worek wymieniony.

W Ageno udostępniamy klientom dokument „Procedura definiowania wymagań i zgłaszania nieprawidłowości”. Jest to krótka instrukcja jak tworzyć wymagania i zgłaszać błędy, aby realizacja była jak najbardziej efektywna. Chciałbyś zobaczyć, jak wygląda taki dokument? Skontaktuj się z nami.