Lekcja 2 z 10Relacja z Klientem45 minut naukiKluczowa Lekcja • Masterclass

Kompletny Wywiad z Klientem: Zbieranie Zakresu i Zabezpieczenie Projektu

Arcyważny warsztat: jak poprowadzić Discovery Call, wyciągnąć ukryte wymagania, zneutralizować pułapki i stworzyć żelazną kartę ustaleń.

Cel lekcji: Opanowanie psychologii i techniki prowadzenia rozmowy wstępnej ze zleceniodawcą, zadawania właściwych pytań i formułowania zakresu projektu wykluczającego późniejsze spory.
AI
Lektor Kurak PM

Posłuchaj wyjaśnienia lekcji i praktycznych wskazówek

Program Lekcji Krok po Kroku (1 etapów)

1

Struktura 6 Faz Badania Potrzeb Klienta (Discovery Framework)

Nigdy nie zaczynaj rozmowy od pytania: 'Jaki design Panu się podoba?' albo 'Ile ma Pan budżetu?'. Klient najczęściej sam nie wie, czego potrzebuje technologicznie, ale doskonale wie, co go boli w biznesie.

Profesjonalny wywiad składa się z 6 precyzyjnych faz: 1. Kontekst biznesowy i mierzalny cel (Po co to robimy?), 2. Użytkownicy i Persony (Kto w to klika, a kto za to płaci?), 3. Podstawowe procesy biznesowe (Jak przepływa wartość?), 4. Zakres funkcjonalny MoSCoW (Must / Should / Could / Won't), 5. Wymagania niefunkcjonalne i integracje (Bezpieczeństwo, RODO, urządzenia, systemy zewnętrzne), 6. Warunki brzegowe, harmonogram i budżet.

Twoim celem podczas wywiadu jest zamiana nieostrych przymiotników klienta ('nowocześnie', 'szybko', 'intuicyjnie') na precyzyjne kryteria akceptacji ('czas ładowania < 1.5s', 'rejestracja w 2 krokach z kodem SMS').

Złota Zasada PM-a & Klucze Wdrożenia:Zasada Żelaznego Dociekania: Na każde życzenie klienta zadaj pytanie: 'Jaki problem biznesowy to rozwiązuje i co się stanie, jeśli w pierwszej wersji tego nie będzie?'.
Główny Warsztat Biznesowy: Scenariusze z Życia PM-a

Kompletny Wywiad z Klientem & Pytania Diagnostyczne

Kompleksowy zestaw 25 realnych pytań diagnostycznych zadawanych klientowi wraz z autentycznymi (często nieprecyzyjnymi) odpowiedziami klientów, reakcją pogłębiającą PM-a oraz ostatecznym zapisem w specyfikacji technicznej.

Kategoria: Cel biznesowyFaza 1: Wizja Biznesowa, Cele i Mierzalny Sukces
1. Pytanie diagnostyczne PM-a do klienta:

"Jaki jest główny cel biznesowy tego wdrożenia i co musi się wydarzyć w ciągu pierwszych 3 miesięcy od startu, aby uznał Pan ten projekt za pełen sukces?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"Chcemy mieć nowoczesną aplikację dla naszych klientów, bo konkurencja już taką ma i nasi handlowcy mówią, że przez to tracimy zamówienia."

3. Pytanie pogłębiające PM-a (Clarification):

"Rozumiem. A czy możemy to zmierzyć liczbami? Na przykład: czy celem jest pozyskanie 100 nowych zamówień miesięcznie bez telefonu do handlowca, czy skrócenie czasu obsługi z 2 dni do 15 minut?"

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Cel projektu: Uruchomienie samoobsługowego portalu zamówień B2B redukującego czas składania zamówień powtarzalnych z 48h do 3 minut oraz zmniejszenie obciążenia handlowców o 40% w Q1 po wdrożeniu.
5. Wskazówka z aktówki Kuraka:

Nigdy nie akceptuj celu 'chcemy być nowocześni'. Nowoczesność nie płaci faktur – mierzalna oszczędność czasu i zysk tak!

Kategoria: Priorytet Czas vs ZakresFaza 1: Wizja Biznesowa, Cele i Mierzalny Sukces
1. Pytanie diagnostyczne PM-a do klienta:

"Gdybyśmy musieli wybierać między terminem 15 listopada a wdrożeniem wszystkich 20 dodatkowych opcji, co jest dla Pana ważniejsze?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"Wszystko jest ważne! Chcemy wszystko na 15 listopada."

3. Pytanie pogłębiające PM-a (Clarification):

"Z punktu widzenia inżynierii projektu: 15 listopada startują Państwa targi branżowe. Czy lepiej mieć wtedy przetestowany, działający moduł sprzedaży, czy opóźnić premierę o 2 miesiące dla drugorzędnych raportów?"

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Kryterium sukcesu: Sztywny termin wydania MVP (15 listopada) z zablokowanym zakresem MUST-HAVE. Wszystkie funkcje opcjonalne (NICE-TO-HAVE) trafiają do Wydania 2 (grudzień/styczeń).
5. Wskazówka z aktówki Kuraka:

Klient zawsze powie, że wszystko jest ważne. Twoim zadaniem jest uświadomić mu konsekwencje braku priorytetów.

Kategoria: Profil użytkownikaFaza 2: Użytkownicy, Persony i Urządzenia
1. Pytanie diagnostyczne PM-a do klienta:

"Kto będzie codziennym użytkownikiem systemu i w jakich warunkach będzie z niego korzystał?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"Wszyscy nasi klienci – zarówno młodzi ludzie z biura, jak i starsi majstrzy na budowach."

3. Pytanie pogłębiające PM-a (Clarification):

"Świetna uwaga! Majster na budowie korzysta ze smartfona w słońcu, często w rękawicach lub przy słabym zasięgu LTE. Czy priorytetem jest więc wersja mobilna (PWA) działająca offline z dużymi przyciskami i wysokim kontrastem?"

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Architektura UI: Mobile-First PWA z obsługą trybu Offline (Service Worker cache). Minimalny rozmiar elementów dotykowych: 48x48px, zgodność kontrastu WCAG AA, automatyczna synchronizacja zamówień po powrocie zasięgu sieci.
5. Wskazówka z aktówki Kuraka:

Warunki otoczenia użytkownika (słońce, rękawice, brak zasięgu) decydują o sukcesie aplikacji bardziej niż kolorystyka logo!

Kategoria: Poziom uprawnień i roleFaza 2: Użytkownicy, Persony i Urządzenia
1. Pytanie diagnostyczne PM-a do klienta:

"Jakie typy kont i uprawnień muszą istnieć w systemie?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"No, musi być logowanie dla klienta i dla nas jako administratora."

3. Pytanie pogłębiające PM-a (Clarification):

"Czy po stronie klienta jedna firma może mieć kilku pracowników (np. pracownik składa koszyk, a dyrektor zatwierdza budżet), czy wystarczy jedno wspólne konto na firmę?"

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Model RBAC (Role-Based Access Control): 3 role w systemie: 1. Klient-Kupiec (tworzenie koszyka), 2. Klient-Dyrektor (akceptacja zamówień powyżej limitu 5000 PLN), 3. SuperAdmin (zarządzanie cenami i stanami magazynowymi).
5. Wskazówka z aktówki Kuraka:

Doprecyzowanie ról na etapie wywiadu oszczędza 3 tygodnie przebudowywania bazy danych w trakcie sprintu!

Kategoria: Metody PłatnościFaza 3: Zakres Funkcjonalny i Płatności (Model MoSCoW)
1. Pytanie diagnostyczne PM-a do klienta:

"Jakie formy płatności są bezwzględnie wymagane w pierwszym etapie?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"Wszystkie możliwe: karty, BLIK, przelewy tradycyjne, leasing, odroczone płatności PayPo i kredyt kupiecki."

3. Pytanie pogłębiające PM-a (Clarification):

"Integracja 6 bramek płatności wydłuży prace i wymaga podpisania 4 oddzielnych umów finansowych. Czy na start wystarczy szybka bramka Stripe/Przelewy24 obsługująca 92% transakcji (BLIK, szybki przelew, karta), a leasing dodamy w etapie 2?"

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Bramka płatności MVP: Jednolity operator Stripe z aktywnym modułem BLIK i kart płatniczych. Płatności odroczone i leasing przeniesione do fazy 2 po weryfikacji wolumenu transakcji.
5. Wskazówka z aktówki Kuraka:

Jedna sprawdzona bramka płatności na start to szybszy launch i brak chaosu w księgowości klienta.

Kategoria: Powiadomienia i KomunikacjaFaza 3: Zakres Funkcjonalny i Płatności (Model MoSCoW)
1. Pytanie diagnostyczne PM-a do klienta:

"W jaki sposób klienci mają otrzymywać powiadomienia o statusie zamówienia?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"Chcemy SMS-y, maile i powiadomienia push na telefon."

3. Pytanie pogłębiające PM-a (Clarification):

"Bramki SMS generują stały koszt (ok. 0.18 PLN za każdego SMS-a) i wymagają rejestracji nazwy nadawcy. Czy w MVP zgadza się Pan na bezpłatne, automatyczne maile transakcyjne (Resend/SendGrid) oraz darmowe web-push w PWA, a bramkę SMS dodamy na życzenie?"

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Komunikacja transakcyjna: Szablony e-mail HTML zintegrowane z Resend API (potwierdzenie zamówienia, zmiana statusu, faktura PDF). Powiadomienia Web-Push w PWA. Integracja SMS odsunięta do etapu płatnego rozszerzenia.
5. Wskazówka z aktówki Kuraka:

Chroń klienta przed zbędnymi kosztami operacyjnymi na start – zapamięta to i wróci po kolejne projekty.

Kategoria: Integracja z ERP/MagazynemFaza 4: Integracje Zewnętrzne i Baza Danych
1. Pytanie diagnostyczne PM-a do klienta:

"Z jakim systemem magazynowo-księgowym aplikacja musi się synchronizować i czy ten system udostępnia otwarte API?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"Mamy w biurze program Subiekt GT na komputerze w piwnicy. Musi pobierać stany co minutę."

3. Pytanie pogłębiające PM-a (Clarification):

"Subiekt GT na lokalnym komputerze stacjonarnym nie posiada chmurowego REST API bez dedykowanego serwera lub dodatku Sfera. Czy na start wystarczy automatyczny import stanów raz dziennie przez plik CSV/Excel z możliwością ręcznego wywołania, a pełne API zrobimy jako oddzielny etap infrastrukturalny?"

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Integracja magazynowa MVP: Moduł bezpiecznego importu stanów i cennika z pliku XLSX/CSV (przeciągnij i upuść w panelu admina z walidacją schematu) + eksport zamówień do formatu EDI++ akceptowanego przez Subiekta.
5. Wskazówka z aktówki Kuraka:

Lokalne programy księgowe klienta to największa pułapka budżetowa w IT. Zawsze proponuj sprawdzony etap pośredni (CSV/Excel)!

Kategoria: Zgody i RODOFaza 5: Wymagania Prawne, RODO i Bezpieczeństwo
1. Pytanie diagnostyczne PM-a do klienta:

"Kto dostarcza regulamin sklepu, politykę prywatności i klauzule RODO?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"Myśleliśmy, że to programista wkleja ze swoich innych projektów."

3. Pytanie pogłębiające PM-a (Clarification):

"Kopiowanie regulaminu z internetu grozi karami UOKiK i naruszeniem praw autorskich. W aplikacji przygotujemy techniczne checkboxy, mechanizm rejestracji zgód ze znacznikiem czasu i adresem IP, ale treść prawną musi zweryfikować Państwa radca prawny lub możemy polecić zaprzyjaźnioną kancelarię e-commerce."

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Moduł zgodności prawnej: Techniczna ewidencja zgód marketingowych i akceptacji regulaminu w bazie danych (data, godzina, wersja regulaminu, IP). Klient dostarcza ostateczną treść regulaminu i polityki prywatności do 10 dni przed premierą.
5. Wskazówka z aktówki Kuraka:

Nigdy nie bierz na siebie odpowiedzialności prawnej za treść regulaminu klienta. Ty dostarczasz mechanizm techniczny, prawnik dostarcza treść.

Kategoria: Struktura PłatnościFaza 6: Budżet, Płatności Etapowe i SLA
1. Pytanie diagnostyczne PM-a do klienta:

"Jak ma wyglądać harmonogram płatności za projekt?"

2. Surowa, nieprecyzyjna odpowiedź klienta:

"Zapłacimy całość po wdrożeniu, jak wszystko sprawdzimy przez miesiąc."

3. Pytanie pogłębiające PM-a (Clarification):

"Jako profesjonalna pracownia cyfrowa pracujemy w standardzie 3 transz powiązanych z mierzalnymi kamieniami milowymi: 40% zaliczki przy podpisaniu karty zakresu i uruchomieniu środowiska, 40% po akceptacji wersji demonstracyjnej na serwerze testowym, 20% po wdrożeniu produkcyjnym na Państwa domenie."

4. Zapis w Karcie Zakresu (Scope Spec / DoD):
Harmonogram płatności: Transza 1 (40% - rozpoczęcie prac i prototyp), Transza 2 (40% - akceptacja środowiska staging), Transza 3 (20% - publikacja na domenie docelowej i przekazanie dostępów). Gwarancja techniczna: 90 dni.
5. Wskazówka z aktówki Kuraka:

NIGDY nie zaczynaj pracy bez zaliczki (minimum 30-40%). Zaliczka to jedyny dowód, że klient traktuje projekt poważnie!

Szablon: Żelazna Karta Zakresu Projektu (Project Scope Agreement)

Skopiuj ten szablon i wypełniaj go na bieżąco podczas spotkań z klientem, by zablokować niekontrolowany Scope Creep i zabezpieczyć budżet.

SZABLON ŻELAZNEJ KARTY ZAKRESU (Project Scope Agreement):

1. CEL PROJEKTU: [Jednozdaniowy cel biznesowy z metryką KPI]
2. ZAKRES WCHODZĄCY W MVP (IN-SCOPE):
   - [Moduł 1 z kryteriami akceptacji]
   - [Moduł 2 z kryteriami akceptacji]
   - [Moduł 3 z kryteriami akceptacji]
3. ZAKRES JEDNOZNACZNIE WYŁĄCZONY Z ETAPU 1 (OUT-OF-SCOPE):
   - Wszystkie integracje niewymienione w punkcie 2
   - Dedykowane aplikacje natywne AppStore/Google Play (zastąpione PWA)
   - Wprowadzanie bazy produktów (odpowiedzialność klienta)
4. WARUNKI ODBIORU (UAT):
   - 5 dni roboczych na testy scenariuszowe wg listy kontrolnej
   - Brak zgłoszenia uwag w terminie oznacza automatyczną akceptację etapu
5. PROCEDURA CHANGE REQUEST:
   - Każda nowa funkcja zgłoszona po podpisaniu karty wymaga oddzielnej wyceny i wydłużenia terminu.
Kluczowe Wnioski z Lekcji
  • Wywiad z klientem to badanie biznesu, a nie dyskusja o kolorach przycisków.
  • Kluczem do braku konfliktów jest precyzyjna lista OUT-OF-SCOPE (co robimy później).
  • Płatność w 3 transzach (40/40/20) chroni płynność finansową i motywuje klienta do terminowych odbiorów.
Porada z Aktówki Kuraka

Złota rada Kuraka: Jeśli nie wpiszesz w umowie tego, czego NIE ROBISZ, klient założy, że w cenie jest wszystko, łącznie z promem kosmicznym! Zawsze miej sekcję OUT-OF-SCOPE!

AI
Niebieski Kurak AI PM • Zawsze weryfikuj fakty, a nie deklaracje.
Quiz Sprawdzający Wiedzę z Lekcji 2

Klient podczas wywiadu mówi: 'Chcemy, żeby aplikacja była bardzo szybka i nowoczesna'. Jak powinien zareagować profesjonalny Project Manager?