NAJWAŻNIEJSZA ODPOWIEDŹ
Discovery porządkuje problem, użytkowników, kluczową ścieżkę i zależności techniczne. Wynikiem powinny być uzgodniony zakres, prototyp najważniejszego procesu, ryzyka oraz podstawa estymacji. Głębokość analizy dopasuj do skali niewiadomych.
Jakie pytania trzeba rozstrzygnąć?
Kto korzysta z produktu, jakie zadanie wykonuje i jak robi to dziś? Kto podejmuje decyzję o zakupie? Jakie systemy trzeba połączyć i skąd pochodzą dane? Odpowiedzi zmieniają zakres bardziej niż wybór koloru przycisku. Jeśli różne osoby opisują cel inaczej, discovery powinno ujawnić tę różnicę przed implementacją.
Zbieraj fakty oddzielnie od założeń. „Klienci chcą panelu” może być hipotezą opartą na jednej rozmowie. „Handlowcy otrzymują codziennie pytania o status” da się sprawdzić na wiadomościach. Dla każdej istotnej niewiadomej wybierz sposób weryfikacji: rozmowę, analizę materiałów, prototyp albo krótki test integracji.
Kontekst i materiały: Google Design: Design Sprint Kit
Jakie materiały warto otrzymać?
Przydatny zestaw obejmuje opis problemu, grupy użytkowników, mapę kluczowej ścieżki, zakres pierwszego wydania i elementy odłożone. Prototyp powinien pokazywać ważne decyzje oraz błędy, nie wyłącznie idealny przebieg. Dodaj zależności techniczne i listę pytań, na które nadal nie ma odpowiedzi.
Materiały powinny być zrozumiałe i dostępne dla klienta. Ich wartość polega na możliwości podjęcia decyzji lub kontynuowania pracy, także z innym zespołem. Nie potrzebujesz setek stron, jeżeli kilka konkretnych diagramów i dobrze opisanych scenariuszy usuwa główne ryzyka. Rozmiar dokumentu nie jest miarą jakości analizy.
Dlaczego wycena nadal może mieć zakres?
Discovery zmniejsza niepewność, ale nie usuwa każdej zależności. Dostępność API, jakość historycznych danych i decyzje po testach użytkowników mogą wpływać na pracę. Estymacja powinna pokazywać założenia, warianty i elementy wymagające potwierdzenia. Jedna dokładna liczba bez tych informacji może dawać fałszywe poczucie pewności.
Porównuj oferty dla tego samego zakresu. Sprawdź, czy zawierają testy, wdrożenie, migrację, dokumentację i obsługę pierwszego okresu działania. Uzgodnij sposób zatwierdzania zmian. Jeśli jedna oferta pomija integrację, a druga ją obejmuje, różnica ceny nie mówi jeszcze nic o efektywności wykonawcy.
Kiedy analiza jest wystarczająca?
Można rozpocząć budowę, gdy zespół rozumie najważniejszy proces, potrafi wskazać granice wydania i wie, jak sprawdzi efekt. Nie czekaj na projekt każdego przyszłego ekranu. Niektóre pytania taniej rozstrzygnąć na działającym fragmencie z użytkownikami.
Na koniec przeprowadź wspólny przegląd: co wiemy, co nadal ryzykujemy i jaka jest najbliższa decyzja. Zapisz odpowiedzialność za dostarczenie materiałów oraz dostępów. Dobre discovery skraca drogę do sensownego wdrożenia. Jeśli stale dodaje kolejne dokumenty bez zmniejszania niewiadomych, warto zawęzić jego cel.
OD CZEGO ZACZĄĆ
Zabierz to do swojego projektu.
- Oddziel potwierdzone fakty od założeń.
- Odbierz prototyp pełnego kluczowego procesu.
- Poproś o zakres, wyłączenia i zależności wyceny.
- Ustal, które niewiadome sprawdzi pierwsze wydanie.
Wybierz jeden punkt, którego dziś brakuje w Twoim procesie. To dobry temat na pierwszą rozmowę z zespołem.
PYTANIA I ODPOWIEDZI
Pytania, które pojawiają się najczęściej.
Czy każdy projekt potrzebuje osobnego discovery?
Nie w tej samej formie. Mała, dobrze opisana zmiana może wymagać krótkiego warsztatu. Nowy produkt z wieloma rolami i integracjami potrzebuje głębszej analizy. Zakres dobierz do ryzyka, nie do szablonu sprzedażowego.
Czy po discovery muszę zamówić realizację?
Warunki współpracy ustala się w umowie. Warto zadbać, aby materiały były użyteczne niezależnie od dalszej decyzji i żeby własność rezultatów oraz zasady przekazania były jasne od początku.
Źródła i kontekst
- Google Design: Design Sprint Kit ↗
Zestaw Google jest materiałem pomocniczym do pracy nad problemem, prototypem i testem. Opis rezultatów discovery w tym artykule jest propozycją ALGOV.
Opracowanie: Zespół ALGOV. Stan wiedzy: 8 września 2026. Przykłady opisują możliwe scenariusze i nie są wynikami projektów klientów. Jak powstają nasze poradniki.
