W jaki sposób odkrywanie i 5 powodów zapewniają tworzenie tego, czego klienci naprawdę potrzebują - a nie tylko tego, o co proszą.

Inżynierowie oprogramowania wiedzą, że komputery działają dokładnie według instrukcji — niekoniecznie zgodnie z naszymi intencjami. Luka ta powiększa się, gdy wymagania pochodzą od nietechnicznych interesariuszy lub gdy żądanie dotyczy symptomów, a nie podstawowych problemów.

Jak więc zmniejszyć ryzyko wdrożenia niewłaściwego rozwiązania? Dwie proste praktyki bardzo pomagają:

• Odkrycie zrozumienie kontekstu i pożądanych rezultatów
• 5 powodów odkrycie pierwotnej przyczyny (aby problem nie powrócił w innej formie)

W Notas IT używamy obu na wczesnym etapie procesu, zazwyczaj podczas pierwszego spotkania po otrzymaniu wymagań.

Odkrywanie: zacznij od kontekstu, nie od kodu

Za każdym razem, gdy klient wysyła żądanie typu "zbuduj X" lub "dodaj Y", traktujemy je jako punkt wyjścia — a nie jako ostateczne wymaganie. W rozmowie Discovery staramy się odpowiedzieć:

• Kto doświadcza problemu (role, zespoły, klienci)?
• Kiedy to się dzieje (częstotliwość, godziny szczytu, konkretne scenariusze)?
• Jaki jest wpływ (pieniądze, czas, błędy, churn, ryzyko zgodności)?
• Gdzie się pojawia (granice systemu, integracje, etapy procesu)?
• Jak wyglądałby sukces (wymierny rezultat, a nie dostarczona funkcja)?

Dopiero gdy je zrozumiemy, możemy użyć 5 powodów, aby sprawdzić, czy faktycznie rozwiązujemy problem.

5 powodów: zamień "prośbę" na "przyczynę".

Zasada "5 powodów" jest prosta: weź stwierdzenie problemu i pytaj "dlaczego?", aż dojdziesz do przyczyny, na którą możesz działać. Nie chodzi o przesłuchiwanie klienta – chodzi o budowanie wspólnej jasności. Często nie trzeba ich dokładnie pięciu. Czasami potrzebne są trzy. Czasami potrzeba siedmiu. W projektach związanych z oprogramowaniem istnieje dodatkowy szczegół: nawet jeśli objaw jest widoczny w jednym miejscu, przyczyna może znajdować się w zupełnie innej warstwie.

"Pięć warstw", w których kryją się problemy (i dlaczego pasuje to do Discovery + 5 Whys)

W większości przypadków użytkownik zauważa błąd lub niespójne zachowanie w interfejsie użytkownika. Systemy są jednak bardziej złożone. Typowy system biznesowy ma wiele warstw, a każda z nich może powodować objawy, które pojawiają się w innych miejscach. Dlatego też, gdy badamy problem i pracujemy nad jego rozwiązaniem, zazwyczaj przekopujemy się przez pięć warstw:

1. Kod interfejsu użytkownika
2. Logika backendu i frameworki
3. Struktura bazy danych i zestawy danych
4. Interfejs użytkownika, backend i serwery baz danych
5. System operacyjny (i środowisko uruchomieniowe)

Warstwy te w naturalny sposób zmuszają do wielokrotnego zadawania pytania "dlaczego?". Reklamacja interfejsu użytkownika może być w rzeczywistości spowodowana walidacją zaplecza, indeksem bazy danych, limitami zasobów serwera lub problemem na poziomie systemu operacyjnego. Pięć powodów zapewnia strukturę, która pozwala uniknąć zbyt wczesnego zatrzymywania się — a Discovery pomaga wybrać właściwą ścieżkę przez te warstwy w oparciu o wpływ na biznes, rzeczywiste przepływy pracy oraz ograniczenia. W praktyce Discovery nadaje kierunek, a 5 Whys zapewnia głębię.

Przykład 1: "Potrzebujemy przycisku eksportu do Excela."

Żądanie klienta: "Dodaj przycisk Eksportuj do Excela na stronie zamówień."

Pytania odkrywcze:

• Kto potrzebuje operacji eksportowych, finansów i sprzedaży?
• Co później robią z plikiem Excel?
• Jak często eksportują dane i jak duży jest zbiór danych?
• Co się dzisiaj stanie, jeśli nie będą eksportować?

5 powodów: przyczyna źródłowa i mapowanie warstw

1. Dlaczego potrzebny jest eksport?
2. "Potrzebujemy cotygodniowych numerów zamówień dla kierownictwa." (Objaw interfejsu użytkownika / potrzeba raportowania)
3. Dlaczego trzeba je wysyłać ręcznie?
4. "Nie ma niezawodnego pulpitu nawigacyjnego." (interfejs użytkownika / możliwości produktu)
5. Dlaczego nie ma niezawodnego pulpitu nawigacyjnego?
6. "Statusy zamówień są niespójne, a raportowanie jest przerwane." (backend + baza danych)
7. Dlaczego statusy są niespójne?
8. "Różne zespoły używają różnych statusów i czasami pomijają kroki." (UI + backend)
9. Dlaczego pomijają kroki?
10. "Przepływ pracy nie jest egzekwowany, a interfejs użytkownika ich nie prowadzi." (UI + backend)

Co wdrażamy zamiast tego

Zamiast dodawać tylko przycisk eksportu, możemy zaimplementować:

• Prosty tygodniowy widok KPI (zamówienia, anulacje, opóźnienia)
• Czyszczenie modelu stanu + walidacja (ograniczenie "zaśmiecania")
• Kierowany przepływ pracy w interfejsie użytkownika w celu zapewnienia spójności statusów.
• A jeśli eksport jest nadal potrzebny: zaplanowane raportowanie zamiast ręcznego eksportu

Wynik: mniej pracy ręcznej, bardziej wiarygodne liczby, mniej "prawd Excela".

Przykład 2: "System działa wolno – potrzebujemy szybszego serwera."

Żądanie klienta: "System działa wolno. Czy możemy zaktualizować serwer?"

Pytania odkrywcze:

• Kiedy jest wolno (przez cały dzień czy w godzinach szczytu)?
• Dla jakich działań (wyszukiwanie, zapisywanie, logowanie, raporty)?
• Ilu użytkowników jest aktywnych w tym czasie?
• Co jest "powolne" w liczbach (2s vs 20s)?

5 powodów: przyczyna źródłowa i mapowanie warstw

1. Dlaczego działa wolno?
2. "Wyszukiwanie klientów trwa 10–15 sekund." (symptom UI)
3. Dlaczego wyszukiwanie trwa tak długo?
4. "Backend oczekuje zapytania do bazy danych." (backend)
5. Dlaczego zapytanie działa wolno?
6. "Skanuje ogromną tabelę." (baza danych)
7. Dlaczego skanowana jest cała tabela?
8. "Nie ma indeksu pasującego do filtrów." (projekt bazy danych)
9. Dlaczego nie wykryto tego wcześniej?
10. "Brak linii bazowej wydajności oraz wzrost danych nie były częścią przeglądu." (proces - i często wskaźniki serwera)

Co wdrażamy zamiast tego

Zamiast modernizować serwery (rozwiązanie tymczasowe), lepszym rozwiązaniem jest np:

• Właściwe indeksy i optymalizacja zapytań (baza danych)
• Paginacja / ograniczenia, które pasują do rzeczywistego użycia (UI + backend)
• Linia bazowa wydajności i alarmowanie (monitorowanie serwerów/OS)

Wynik: szybszy UX i zazwyczaj niższe koszty infrastruktury.

Przykład 3: "Potrzebujemy etapu zatwierdzania przed wysłaniem faktur."

Żądanie klienta: "Dodaj krok zatwierdzania przed wysłaniem faktur." Pytania Discovery (kontekst)

• Jakie ryzyko próbujesz ograniczyć?
• Czy problemem są niewłaściwe faktury, niewłaściwi odbiorcy, niewłaściwe kwoty lub terminy?
• Jak często się to zdarza i ile to kosztuje?

5 powodów (przyczyna źródłowa) + mapowanie warstw

1. Dlaczego potrzebujesz zgody?
2. "Czasami faktury są wysyłane z nieprawidłowymi cenami." (Objaw UI)
3. Dlaczego ceny są nieprawidłowe?
4. "Zasady dotyczące rabatów nie są stosowane konsekwentnie." (logika backendu)
5. Dlaczego zasady nie są stosowane konsekwentnie?
6. "Dział sprzedaży wprowadza rabaty ręcznie w polach tekstowych." (Projekt interfejsu użytkownika)
7. Dlaczego jest ręczny/beztekstowy?
8. "System nie obsługuje poprawnie typów rabatów." (model danych + backend)
9. Dlaczego ich nie wspiera?
10. "Rozwijał się organicznie, bez modelu cenowego." (baza danych + projekt produktu)

Co wdrażamy zamiast tegoZamiast dodawać krok zatwierdzania dla każdej faktury (tarcie), możemy:

• Wprowadzenie ustrukturyzowanego modelu cenowego/zniżkowego (baza danych)
• Dodaj reguły walidacji i wyczyść kontrolki interfejsu użytkownika (UI + backend)
• Dodanie obiegu wyjątków tylko dla ryzykownych przypadków (UI + backend)

Rezultat: mniej błędów przy mniejszym obciążeniu operacyjnym.

Praktyczna lista kontrolna, którą można wykorzystać podczas następnego spotkania z klientem

Gdy klient przedstawi rozwiązanie, spróbuj zastosować następującą sekwencję:

1. Sformułuj żądanie w jednym zdaniu.
2. Zapytaj: "Co się stanie, jeśli nic nie zrobimy?" (wpływ)
3. Zapytaj: "Jak to dzisiaj rozwiązać?" (obejścia ujawniają prawdziwą potrzebę).
4. Zapytaj: "Jak wygląda sukces?" (wymierny rezultat).
5. Wykonaj test 5 powodów i świadomie sprawdź, w której warstwie się znajdujesz:
   • UI
   • backend
   • baza danych
   • serwery
   • System operacyjny/środowisko

Odkrywanie nadaje kierunek. Pięć powodów zapewnia głębię. Pięciowarstwowy model mentalny pomaga nie utknąć w niewłaściwej warstwie.

Myśl końcowa

Discovery i 5 Whys nie spowalniają dostawy – zmniejszają liczbę przeróbek. Nadal dostarczasz rozwiązania, ale te, które faktycznie poruszają igłę dla klienta.