Co zrobić, gdy klient nie potrafi określić swoich potrzeb?

Klient nie musi znać gotowego rozwiązania

Klient zatrudnia specjalistę między innymi dlatego, że sam nie wie, jak najlepiej rozwiązać swój problem. Właściciel firmy może zauważać, że strona nie przynosi zapytań, pracownicy tracą czas na ręczne przepisywanie danych albo marka wygląda mniej profesjonalnie niż konkurencja. Nie musi jednak wiedzieć, czy potrzebuje przebudowy formularza, nowej architektury informacji, integracji z CRM, repozycjonowania marki czy zupełnie innego rozwiązania.

Oczekiwanie, że klient przygotuje kompletną i poprawną specyfikację, bywa nierealistyczne. To trochę tak, jakby mechanik oczekiwał, że kierowca przed wizytą samodzielnie zdiagnozuje usterkę i wskaże części wymagające wymiany. Klient powinien umieć opisać objawy, kontekst i oczekiwany rezultat. Zadaniem specjalisty jest pomóc mu przejść od tych informacji do właściwego rozwiązania.

Nie oznacza to jednak, że freelancer ma samodzielnie wymyślić cały projekt na podstawie jednego zdania. Odkrywanie potrzeb wymaga współpracy. Klient wnosi wiedzę o firmie, odbiorcach, ograniczeniach i wcześniejszych doświadczeniach. Wykonawca wnosi wiedzę branżową, umiejętność zadawania pytań oraz ocenę wykonalności proponowanych rozwiązań.

Klient nie musi wiedzieć, jak zbudować rozwiązanie. Powinien jednak uczestniczyć w ustalaniu, jaki problem rozwiązujemy i po czym poznamy, że projekt się udał.

Briefstreak

Dlaczego klient nie potrafi określić swoich potrzeb?

Niejasne wymagania nie zawsze wynikają z braku przygotowania. Czasami projekt znajduje się po prostu na bardzo wczesnym etapie. Klient dostrzega problem, ale jeszcze go nie przeanalizował. W innych przypadkach zna rezultat, którego chce, lecz nie rozumie dostępnych możliwości ani ograniczeń technicznych.

Zna problem, ale nie zna możliwych rozwiązań

Klient wie, że zbyt wiele osób rezygnuje z zakupu, ale nie potrafi wskazać przyczyny. Może zakładać, że potrzebuje nowego sklepu internetowego, choć problemem jest skomplikowany formularz dostawy. Może prosić o aplikację mobilną, mimo że jego odbiorcom wystarczyłby dobrze działający panel internetowy.

To naturalne, że klient opisuje potrzebę przez pryzmat rozwiązania, które zna. Twoim zadaniem nie jest automatyczne odrzucenie jego pomysłu, lecz sprawdzenie, dlaczego właśnie o nim pomyślał i jaki efekt chce dzięki niemu osiągnąć.

W firmie nie ma jednej wersji potrzeb

Osoba zamawiająca usługę może reprezentować tylko jeden punkt widzenia. Właściciel chce zwiększyć sprzedaż, marketing chce łatwo publikować treści, dział obsługi oczekuje mniejszej liczby powtarzalnych pytań, a użytkownicy potrzebują prostszego procesu. Wszystkie te potrzeby mogą być prawidłowe, ale nie zawsze są ze sobą zgodne.

Jeżeli projekt ma kilku interesariuszy, nie wystarczy zapytać jednej osoby, czego potrzebuje. Trzeba ustalić, kto będzie korzystał z rozwiązania, kto je zatwierdza, kto finansuje projekt i czyja codzienna praca zostanie zmieniona.

Klient nie potrafi oddzielić priorytetów od pomysłów

Podczas rozmowy klient może wymienić kilkadziesiąt funkcji, inspiracji i luźnych koncepcji. Nie oznacza to, że wszystkie są wymaganiami. Część jest próbą wyobrażenia sobie projektu, część dodatkiem na przyszłość, a część pomysłem zasłyszanym od konkurencji.

Jeżeli wszystko zostanie potraktowane jako równie ważne, zakres szybko stanie się zbyt duży i kosztowny. Dlatego potrzeby trzeba uporządkować według znaczenia, wpływu na cel oraz konsekwencji rezygnacji z danego elementu.

Klient obawia się podania budżetu

Niektórzy klienci unikają konkretnych odpowiedzi, ponieważ sądzą, że wykonawca wykorzysta każdą informację do podniesienia ceny. Nie chcą podać budżetu, oczekiwanego zakresu ani ważności poszczególnych elementów. Liczą, że najpierw otrzymają pełną propozycję i dopiero wtedy zdecydują, co naprawdę jest im potrzebne.

W takiej sytuacji warto wyjaśnić, że te same cele można realizować na różnych poziomach. Budżet nie służy do automatycznego ustalania ceny, lecz do dobrania realistycznego rozwiązania. Bez tej informacji możesz przygotować propozycję całkowicie nieadekwatną do możliwości klienta.

Klient nigdy wcześniej nie zamawiał podobnej usługi

Osoba zamawiająca pierwszą stronę internetową, identyfikację wizualną, kampanię reklamową czy system informatyczny może nie wiedzieć, jakie decyzje będzie musiała podjąć. Nie zna branżowego procesu, typowych etapów ani elementów wpływających na cenę.

Zamiast oceniać takie zapytanie jako nieprofesjonalne, trzeba poprowadzić klienta przez proces. Dobre pytania powinny być zrozumiałe bez specjalistycznej wiedzy i dotyczyć przede wszystkim firmy, użytkowników, problemów oraz oczekiwanych rezultatów.

Problem jest jeszcze zbyt słabo rozpoznany

Czasami żadna ze stron nie zna odpowiedzi na początku. Nie wiadomo, dlaczego klienci rezygnują z formularza, które procesy pochłaniają najwięcej czasu ani czy użytkownicy potrzebują planowanej funkcji. Odpowiedzi wymagają analizy danych, rozmów z użytkownikami, audytu, warsztatu lub wykonania prototypu.

W takim projekcie nie należy udawać, że zakres jest znany. Pierwszym produktem współpracy powinno być lepsze zrozumienie problemu, a dopiero drugim właściwe rozwiązanie.

Najpierw oddziel potrzebę od proponowanego rozwiązania

Jednym z najważniejszych elementów discovery jest rozróżnienie między tym, czego klient rzeczywiście potrzebuje, a tym, co proponuje zbudować. Zdanie „potrzebujemy aplikacji mobilnej” opisuje rozwiązanie. Nie wyjaśnia, kto będzie z niej korzystał, w jakiej sytuacji, jaki problem ma zniknąć ani dlaczego istniejące narzędzia nie wystarczają.

Podobnie jest z prośbą o nowe logo, redesign strony, kampanię w mediach społecznościowych czy automatyzację procesu. Każdy z tych pomysłów może być trafny, ale przed rozpoczęciem realizacji trzeba poznać stojący za nim powód.

Nie zaczynaj od pytania: „Co mamy stworzyć?”. Zacznij od pytania: „Co ma się zmienić po zakończeniu projektu?”.

Briefstreak

Pomocne jest przeformułowanie odpowiedzi klienta. Jeśli mówi, że chce nową stronę, możesz podsumować: „Rozumiem, że głównym problemem jest mała liczba zapytań od klientów biznesowych, a celem projektu jest zwiększenie liczby wartościowych kontaktów. Nowa strona jest obecnie rozważanym sposobem osiągnięcia tego celu”. Takie zdanie pozostawia przestrzeń na sprawdzenie, czy przebudowa całej strony rzeczywiście jest potrzebna.

Zacznij od obecnej sytuacji, a nie od listy funkcji

Gdy klient nie potrafi zdefiniować potrzeb, pytanie „Jakie funkcje ma mieć system?” zwykle nie pomoże. Odpowiedź będzie bardzo ogólna albo oparta na przypadkowych inspiracjach. Łatwiej rozmawiać o tym, co dzieje się obecnie.

• Jak obecnie wykonywany jest ten proces?
• Kto bierze w nim udział?
• Co uruchamia cały proces?
• W którym miejscu pojawia się najwięcej problemów?
• Co zajmuje najwięcej czasu?
• Jakie błędy powtarzają się najczęściej?
• Z jakich narzędzi klient korzysta dzisiaj?
• Co w obecnym rozwiązaniu działa dobrze i powinno zostać zachowane?
• Jakie obejścia stosują pracownicy lub użytkownicy?
• Co dzieje się, gdy problem nie zostanie rozwiązany?

Opis realnego procesu daje znacznie więcej informacji niż abstrakcyjna lista oczekiwań. Klient może nie pamiętać, że potrzebuje eksportu danych, ale podczas opisywania pracy wspomni, że co piątek ręcznie przepisuje wyniki do arkusza. Właśnie w takich szczegółach często ukrywają się najważniejsze wymagania.

Ustal, co klient próbuje osiągnąć

Projekt powinien prowadzić do określonej zmiany. Samo stworzenie strony, filmu, identyfikacji czy aplikacji jest dostarczeniem produktu, ale nie wyjaśnia jego celu. Aby dobrze dobrać zakres, trzeba zrozumieć, do czego rozwiązanie będzie klientowi potrzebne.

Pomocne jest myślenie w kategoriach zadania, które klient lub jego odbiorca próbuje wykonać. Użytkownik nie potrzebuje formularza dla samego formularza. Chce szybko uzyskać wycenę. Firma nie potrzebuje dashboardu tylko dlatego, że wygląda profesjonalnie. Chce wcześniej zauważać spadki sprzedaży i podejmować trafniejsze decyzje.

• Dlaczego ten projekt jest potrzebny właśnie teraz?
• Jaki problem ma zostać rozwiązany?
• Kto najbardziej odczuwa ten problem?
• Jak użytkownicy radzą sobie z nim obecnie?
• Co powinno stać się łatwiejsze, szybsze lub tańsze?
• Jakiej decyzji albo działania ma pomagać rozwiązanie?
• Co będzie możliwe po realizacji, czego nie da się zrobić dzisiaj?
• Jakie są konsekwencje pozostawienia obecnej sytuacji bez zmian?

Zdefiniuj rezultat, a nie tylko materiały do dostarczenia

Rezultat projektu powinien obejmować zarówno to, co wykonawca dostarczy, jak i zmianę, której oczekuje klient. Materiałem może być nowa strona. Oczekiwanym rezultatem jest łatwiejsze znalezienie informacji i wzrost liczby wartościowych zapytań. Materiałem może być automatyzacja. Rezultatem jest skrócenie procesu z dwóch godzin do kilkunastu minut.

Nie każdy rezultat można zagwarantować. Freelancer projektujący sklep nie ma pełnej kontroli nad liczbą sprzedaży, ponieważ wpływają na nią również oferta, ruch, ceny i działania marketingowe. Nadal jednak można zdefiniować wskaźniki, na które projekt ma oddziaływać, oraz warunki pozwalające ocenić jego jakość.

• Po czym klient pozna, że projekt się udał?
• Jakie zachowanie użytkowników powinno się zmienić?
• Który proces powinien trwać krócej?
• Jakie błędy powinny występować rzadziej?
• Jakie informacje powinny stać się łatwiej dostępne?
• Jaki minimalny rezultat uzasadnia realizację projektu?
• Kiedy i w jaki sposób efekt będzie oceniany?

Pytaj o konkretne sytuacje z przeszłości

Pytania o przyszłość często prowadzą do deklaracji i życzeń. Klient może powiedzieć, że system powinien być „intuicyjny”, „nowoczesny”, „skalowalny” i „prosty”. Każdy rozumie te słowa inaczej. Znacznie bardziej użyteczne są pytania o konkretne zdarzenia.

• Kiedy ostatnio pojawił się ten problem?
• Co dokładnie wtedy się wydarzyło?
• Kto próbował go rozwiązać?
• Ile czasu to zajęło?
• Jakie narzędzia były używane?
• Co było najbardziej frustrujące?
• Jak zakończyła się ta sytuacja?
• Czy podobny problem zdarza się regularnie?

Konkretny przykład pozwala zobaczyć kontekst, kolejność działań, uczestników i ograniczenia. Często ujawnia również różnicę między tym, co firma uważa za swój oficjalny proces, a tym, jak praca wygląda w praktyce.

Nie pytaj wyłącznie, czego klient chce

Bezpośrednie pytanie o oczekiwania jest potrzebne, ale nie może być jedyną metodą. Ludzie pomijają czynności, które wydają im się oczywiste, nie pamiętają wszystkich wyjątków albo proponują rozwiązania na podstawie ograniczonej wiedzy.

W zależności od rodzaju projektu warto uzupełnić rozmowę analizą istniejących materiałów, danych, formularzy, procedur, wiadomości od klientów, nagrań rozmów, statystyk strony lub używanych narzędzi. Przy projektowaniu procesów pomocna może być także obserwacja rzeczywistej pracy użytkowników.

Klient może powiedzieć, że jego pracownik wykonuje zadanie w prosty sposób. Dopiero obserwacja ujawni, że pomiędzy etapami korzysta z prywatnego arkusza, kopiuje dane z wiadomości i ręcznie sprawdza kilka wyjątków. Te działania mogą mieć kluczowe znaczenie dla projektu, choć nie pojawiły się w pierwotnym opisie.

Jak zadawać pytania, aby otrzymywać użyteczne odpowiedzi?

Zadawaj jedno pytanie naraz

Pytanie zawierające kilka wątków zwykle prowadzi do odpowiedzi tylko na jeden z nich. Zamiast pytać jednocześnie o odbiorców, cel, budżet, funkcje i termin, rozdziel rozmowę na krótsze części. Dzięki temu łatwiej zauważysz niejasności i zadasz pytanie uzupełniające.

Unikaj branżowego języka

Klient może przytaknąć, mimo że nie rozumie pytania o architekturę informacji, webhooki, persony, lejek, key visual czy środowisko stagingowe. Używaj języka opisującego działania i rezultaty. Terminologię techniczną można wprowadzić później, gdy będzie rzeczywiście potrzebna.

Proś o przykłady

Gdy klient mówi, że projekt powinien wyglądać profesjonalnie, zapytaj, jakie konkretne materiały uważa za profesjonalne i co dokładnie mu się w nich podoba. Gdy oczekuje łatwej obsługi, poproś o opis zadania, które użytkownik powinien wykonać bez pomocy.

Dopytuj o przyczynę

Nie chodzi o mechaniczne powtarzanie pytania „dlaczego?” po każdej odpowiedzi. Warto jednak zrozumieć motyw stojący za wymaganiem. Jeżeli klient chce logowanie przez media społecznościowe, zapytaj, jaki problem ma to rozwiązać. Być może użytkownicy zapominają haseł, rejestracja trwa zbyt długo albo firma chce pozyskać konkretny rodzaj danych.

Podsumowuj własnymi słowami

Po ważniejszej części rozmowy przedstaw własne rozumienie sytuacji i poproś o potwierdzenie. Nie powtarzaj jedynie słów klienta. Spróbuj uporządkować zależności między problemem, odbiorcami, celem i proponowanym zakresem.

Rozumiem, że największym problemem nie jest sama liczba wiadomości, lecz to, że trafiają do różnych osób i nie wiadomo, które zapytania zostały już obsłużone. Priorytetem jest więc wspólne miejsce do zarządzania zgłoszeniami, a automatyczne odpowiedzi są na razie dodatkiem. Czy dobrze to podsumowuję?

Przykładowe podsumowanie

Ustal, kto naprawdę korzysta z rozwiązania

Osoba kupująca usługę nie zawsze jest jej użytkownikiem. Właściciel zamawia system dla pracowników, dział marketingu stronę dla klientów, a menedżer raport dla zarządu. Każda z tych grup może mieć inne cele, ograniczenia i poziom wiedzy.

Jeżeli użytkownicy nie uczestniczą w ustalaniu potrzeb, projekt może odpowiadać oczekiwaniom osoby decyzyjnej, ale utrudniać codzienną pracę. Nie zawsze trzeba prowadzić duże badania. Czasami wystarczy krótka rozmowa z kilkoma osobami wykonującymi dany proces.

• Kto będzie najczęściej korzystał z rozwiązania?
• Kto podejmuje decyzję o zakupie?
• Kto zatwierdzi rezultat?
• Kto dostarczy materiały i wiedzę?
• Czyje obowiązki zmienią się po wdrożeniu?
• Kto będzie utrzymywał rozwiązanie po zakończeniu projektu?
• Czy potrzeby poszczególnych grup są ze sobą zgodne?

Zamień ogólne określenia w kryteria

Słowa takie jak „nowoczesny”, „prosty”, „premium”, „szybki”, „elastyczny” czy „intuicyjny” nie są jeszcze wymaganiami. Są kierunkiem, który trzeba doprecyzować.

Jeżeli strona ma być szybka, ustal, czy chodzi o techniczny czas ładowania, łatwe znajdowanie informacji, krótki proces zakupowy czy sprawne zarządzanie treścią. Jeżeli system ma być prosty, określ, jakie zadania użytkownik ma wykonywać i jakie błędy obecnie popełnia.

• Co konkretnie oznacza to określenie w tym projekcie?
• Jaki przykład spełnia to oczekiwanie?
• Jaki przykład zdecydowanie go nie spełnia?
• Kto będzie oceniał ten element?
• Po czym obiektywnie poznamy, że wymaganie zostało spełnione?

Pomóż klientowi ustalić priorytety

Gdy rozmowa przebiega dobrze, lista potrzeb zwykle rośnie. To nie jest jeszcze problem. Problem pojawia się wtedy, gdy wszystkie elementy zostają uznane za obowiązkowe, mimo ograniczonego budżetu i terminu.

Priorytety można ustalać, pytając o wpływ rezygnacji z danego elementu. Jeśli projekt bez konkretnej funkcji nadal rozwiązuje najważniejszy problem, prawdopodobnie nie jest ona niezbędna w pierwszej wersji.

• Co bezwzględnie musi znaleźć się w pierwszej wersji?
• Bez czego rozwiązanie nie będzie spełniało podstawowego celu?
• Które elementy przynoszą największą wartość?
• Co można wykonać ręcznie na początku?
• Co można przenieść do kolejnego etapu?
• Które wymagania wynikają z prawa, bezpieczeństwa lub umów?
• Z czego klient zrezygnowałby jako pierwszego przy mniejszym budżecie?

Dobrym sposobem jest podział na elementy konieczne, ważne, opcjonalne i pozostawione na przyszłość. Samo przypisanie etykiet nie wystarczy — każda decyzja powinna wynikać z celu projektu i dostępnych ograniczeń.

Pokaż rozwiązanie na przykładzie, zanim zbudujesz całość

Niektórych potrzeb nie da się doprecyzować samą rozmową. Klient może dopiero po zobaczeniu przykładu zauważyć, czego brakuje, co jest zbędne albo jak powinien wyglądać przepływ informacji.

W zależności od projektu pomocne mogą być szkice, makiety, moodboardy, przykładowe treści, prototypy, próbki, mapy procesu lub niewielkie wersje demonstracyjne. Ich celem nie jest bezpłatne wykonywanie części projektu, lecz szybkie sprawdzenie ważnych założeń przed kosztowną realizacją.

Prototyp powinien odpowiadać na konkretne pytanie. Może sprawdzać, czy użytkownik rozumie układ formularza, czy system da się połączyć z istniejącymi danymi albo czy proponowany styl pasuje do pozycjonowania marki. Nie trzeba projektować całego rozwiązania, aby zweryfikować najważniejsze ryzyko.

Kiedy discovery powinno być płatne?

Krótka kwalifikacja przed ofertą jest zwykle elementem sprzedaży. Możesz bezpłatnie zadać kilka pytań, ocenić dopasowanie i ustalić podstawowy zakres. Granica zostaje przekroczona, gdy klient potrzebuje realnej pracy analitycznej: audytu, konsultacji z wieloma osobami, analizy danych, warsztatów, mapowania procesu lub przygotowania szczegółowej koncepcji.

Taki etap ma samodzielną wartość. Po jego zakończeniu klient powinien lepiej rozumieć problem, priorytety, ryzyka i możliwe rozwiązania — nawet jeśli realizację zleci komuś innemu. Dlatego discovery może być osobną usługą, a nie bezpłatnym dodatkiem do wyceny.

• Projekt jest złożony i obejmuje wiele procesów.
• Wymagania kilku interesariuszy są sprzeczne.
• Nie wiadomo, które rozwiązanie jest wykonalne.
• Trzeba przeanalizować istniejący system lub dokumentację.
• Dokładna wycena wymaga przygotowania koncepcji.
• Projekt będzie kosztowny, a błędne założenia mogą wygenerować duże straty.
• Klient oczekuje warsztatu, audytu, badań lub szczegółowej rekomendacji.

Co może powstać w ramach płatnego discovery?

• Opis problemu i celu projektu.
• Mapa obecnego procesu.
• Lista interesariuszy i użytkowników.
• Uporządkowane wymagania.
• Priorytety pierwszego etapu.
• Założenia i ograniczenia.
• Lista ryzyk oraz niewiadomych.
• Rekomendowany wariant rozwiązania.
• Wstępna architektura lub makieta.
• Plan realizacji i dokładniejsza wycena.

Nie przygotowuj stałej ceny, gdy zakres nadal jest nieznany

Jednym z najbardziej ryzykownych błędów jest podanie wiążącej ceny tylko dlatego, że klient jej oczekuje. Jeżeli nie wiadomo, co dokładnie ma zostać wykonane, każda konkretna kwota jest oparta na ukrytych założeniach.

Wykonawca może założyć prostą wersję, a klient rozbudowaną. Różnica wychodzi na jaw dopiero podczas realizacji. Pojawiają się dopłaty, konflikty i przekonanie klienta, że freelancer próbuje zmienić wcześniejsze warunki.

Przy niejasnym zakresie można podać orientacyjny przedział, wycenić etap discovery albo rozliczać pierwszą część godzinowo. Cena projektowa ma sens dopiero wtedy, gdy strony rozumieją, jaki rezultat, zakres i poziom odpowiedzialności obejmuje.

Na tym etapie mogę podać jedynie przedział 15 000–30 000 zł netto, ponieważ nie znamy jeszcze liczby integracji i zasad przepływu danych. Proponuję rozpocząć od płatnego warsztatu i analizy. Po tym etapie otrzymają Państwo rekomendowany zakres, plan oraz dokładną wycenę realizacji.

Przykładowa odpowiedź

Dokumentuj założenia, a nie tylko ustalenia

W projektach z dużą niepewnością ważne jest zapisanie nie tylko tego, co strony uzgodniły, ale również na jakich założeniach opiera się zakres. Jeśli cena zakłada dostarczenie przez klienta gotowych treści, dostęp do określonego systemu albo udział jednej osoby decyzyjnej, powinno być to wyraźnie wskazane.

Założenie może później okazać się nieprawdziwe. Nie oznacza to automatycznie, że ktoś popełnił błąd. Ważne, aby strony mogły ocenić wpływ nowej informacji na zakres, cenę i harmonogram.

• Co uznajemy obecnie za prawdę?
• Które informacje zostały potwierdzone?
• Których danych nadal brakuje?
• Jakie decyzje muszą zostać podjęte później?
• Co może istotnie zmienić zakres?
• Kto odpowiada za sprawdzenie poszczególnych założeń?

Jak zakończyć discovery konkretnym podsumowaniem?

Rozmowa nie powinna kończyć się luźnym poczuciem, że obie strony mniej więcej rozumieją projekt. Warto przygotować krótkie podsumowanie i poprosić klienta o potwierdzenie.

1. Opisz obecną sytuację.
2. Nazwij najważniejszy problem.
3. Wskaż użytkowników i interesariuszy.
4. Określ główny cel projektu.
5. Zdefiniuj oczekiwany rezultat.
6. Wymień zakres pierwszego etapu.
7. Zapisz elementy poza zakresem.
8. Przedstaw najważniejsze założenia i ryzyka.
9. Wskaż potrzebne materiały i decyzje klienta.
10. Określ następny krok.

Podsumowanie nie musi być długą specyfikacją. Powinno jednak pozwalać klientowi zauważyć, czy wykonawca prawidłowo zrozumiał jego sytuację. Jeżeli już na tym etapie pojawiają się różnice, znacznie taniej wyjaśnić je przed rozpoczęciem realizacji.

Czego nie robić, gdy klient nie zna swoich potrzeb?

Nie zgaduj za klienta

Możesz formułować hipotezy i rekomendacje, ale powinny być jasno oznaczone. Jeżeli samodzielnie założysz, czego klient potrzebuje, a następnie zbudujesz na tym całą ofertę, ryzykujesz przygotowanie rozwiązania dla problemu, który nie istnieje.

Nie zamieniaj rozmowy w przesłuchanie

Długa lista pytań zadanych bez kontekstu może przytłoczyć klienta. Wyjaśnij, dlaczego dana informacja jest potrzebna, reaguj na odpowiedzi i pomijaj pytania, które nie mają znaczenia dla konkretnego projektu.

Nie podsuwaj odpowiedzi zbyt wcześnie

Pytanie „Czy potrzebujecie aplikacji z panelem administratora i automatycznymi powiadomieniami?” kieruje klienta w stronę konkretnego rozwiązania. Najpierw lepiej zapytać, kto zarządza informacjami, jak robi to obecnie i kiedy musi kontaktować się z użytkownikami.

Nie traktuj inspiracji jako specyfikacji

Klient może pokazać stronę konkurencji lub przykładowy projekt i powiedzieć, że chce coś podobnego. Trzeba ustalić, które elementy są dla niego ważne i dlaczego. Inspiracja może dotyczyć stylu, struktury, funkcji albo ogólnego wrażenia, ale rzadko opisuje pełne wymagania.

Nie obiecuj rezultatu, którego nie da się jeszcze ocenić

Jeżeli nie rozumiesz problemu, nie możesz odpowiedzialnie zagwarantować, że proponowane rozwiązanie przyniesie oczekiwany efekt. Możesz zobowiązać się do przeprowadzenia analizy, przygotowania rekomendacji lub wykonania konkretnego zakresu, ale nie udawaj pewności tam, gdzie nadal istnieją istotne niewiadome.

Kiedy lepiej odmówić współpracy?

Niejasne potrzeby same w sobie nie są czerwoną flagą. Problemem jest brak gotowości do wspólnego ich odkrycia. Jeżeli klient nie zna zakresu, ale odpowiada na pytania, udostępnia materiały i akceptuje etap analityczny, projekt może być bardzo dobrą współpracą.

Ryzyko rośnie, gdy klient jednocześnie nie potrafi określić potrzeb, odmawia udziału w discovery, oczekuje natychmiastowej stałej ceny i chce pełnej gwarancji rezultatu. W takim układzie wykonawca przejmuje odpowiedzialność za decyzje, do których nie otrzymał wystarczających informacji.

• Klient nie chce odpowiadać na podstawowe pytania.
• Nie udostępnia materiałów potrzebnych do analizy.
• Nie wiadomo, kto podejmuje decyzje.
• Każdy interesariusz oczekuje czegoś innego, ale nikt nie chce ustalić priorytetów.
• Klient wymaga stałej ceny bez określenia zakresu.
• Oczekuje bezpłatnego przygotowania kompletnej strategii lub koncepcji.
• Nie akceptuje żadnych ograniczeń liczby zmian.
• Chce, aby wykonawca zagwarantował wynik zależny od wielu czynników zewnętrznych.

Przykład: klient chce „nowoczesną stronę”

Klient zgłasza się z prośbą o przygotowanie nowoczesnej strony firmowej. Nie wie, ile potrzebuje podstron, jakie funkcje powinny się na niej znaleźć ani co dokładnie oznacza dla niego nowoczesność.

Zamiast od razu pytać o preferowany styl, freelancer ustala, dlaczego firma rozważa zmianę. Okazuje się, że obecna strona powstała osiem lat temu, źle działa na telefonach i prezentuje nieaktualną ofertę. Większość klientów trafia z poleceń, ale po wejściu na stronę kontaktuje się głównie w sprawie najtańszych usług. Firma chce pozyskiwać większe kontrakty B2B.

Dalsza rozmowa pokazuje, że najważniejsze nie jest samo unowocześnienie wyglądu. Strona ma wyjaśniać ofertę dla większych firm, prezentować realizacje, odpowiadać na typowe obawy i kierować potencjalnych klientów do odpowiedniego formularza. Firma nie potrzebuje natomiast bloga, sklepu ani rozbudowanego panelu klienta.

Niejasne hasło zostało zamienione w konkretny cel, grupę odbiorców, zakres i sposób oceny projektu. Dopiero w tym momencie można odpowiedzialnie rozmawiać o strukturze, terminie i cenie.

Przykład: klient chce aplikację do zarządzania firmą

Pierwotne zapytanie brzmi bardzo szeroko: firma chce aplikację, w której pracownicy będą zarządzać klientami, zadaniami, dokumentami i raportami. Próba wyceny całego systemu na tym etapie byłaby zgadywaniem.

Podczas discovery okazuje się, że największym problemem nie jest brak jednego systemu, lecz ręczne przekazywanie danych o nowych zamówieniach między działem sprzedaży a realizacją. Błędy w tym miejscu powodują opóźnienia i reklamacje.

Zamiast rozpoczynać od rozbudowanej aplikacji, pierwszym etapem może być uporządkowanie formularza zamówienia, centralna lista realizacji i automatyczne przypisanie osoby odpowiedzialnej. Pozostałe funkcje zostają zapisane jako możliwe etapy rozwoju, ale nie zwiększają kosztu pierwszej wersji.

Jak wykorzystać brief przy niejasnych potrzebach?

Brief nie powinien wymagać od klienta wiedzy specjalistycznej ani gotowej listy rozwiązań. Jeżeli formularz zaczyna się od pytań o technologię, formaty, funkcje i szczegółową strukturę, osoba na wczesnym etapie może go porzucić albo udzielić przypadkowych odpowiedzi.

Lepszy brief prowadzi klienta od informacji, które zna, do tych wymagających wspólnego doprecyzowania. Najpierw pyta o firmę, odbiorców, obecną sytuację i problem. Następnie o cel, priorytety, ograniczenia, materiały, termin oraz budżet. Pytania dotyczące rozwiązania pojawiają się dopiero później.

Warto umożliwić klientowi wybór odpowiedzi „nie wiem” lub „potrzebuję rekomendacji”. Brak pewności jest ważną informacją. Dzięki niej freelancer wie, że dany obszar wymaga rozmowy, analizy lub przedstawienia wariantów.

Przykładowa kolejność pytań w briefie

1. Czym zajmuje się firma lub projekt?
2. Kto będzie korzystał z rezultatu?
3. Jak obecnie rozwiązujecie ten problem?
4. Co nie działa w obecnym rozwiązaniu?
5. Dlaczego chcecie zająć się tym właśnie teraz?
6. Jaki rezultat będzie dla Was sukcesem?
7. Które elementy są najważniejsze?
8. Jakie materiały i zasoby są już dostępne?
9. Jaki jest oczekiwany termin?
10. Jaki budżet lub przedział budżetu jest przewidziany?
11. Kto będzie uczestniczył w podejmowaniu decyzji?
12. W których obszarach oczekujecie rekomendacji wykonawcy?

Jak Briefstreak pomaga uporządkować niejasne zapytania?

W Briefstreak można przygotować osobny brief dla konkretnej usługi i prowadzić klienta przez pytania w logicznej kolejności. Dzięki odpowiedziom jedno- i wielokrotnego wyboru, polom tekstowym, załącznikom, pytaniom o termin oraz logice warunkowej formularz może dopasowywać się do sytuacji klienta.

Osoba, która dopiero szuka rozwiązania, nie musi odpowiadać na te same szczegółowe pytania co klient z gotową specyfikacją. Może najpierw opisać problem i oczekiwany efekt. Na podstawie tych odpowiedzi freelancer decyduje, czy może przygotować ofertę, potrzebuje dodatkowej rozmowy, czy powinien zaproponować płatne discovery.

Uporządkowany brief nie zastępuje myślenia ani rozmowy. Ogranicza jednak chaotyczną wymianę wiadomości, ujawnia brakujące informacje i pomaga obu stronom zobaczyć, które decyzje zostały już podjęte, a które nadal wymagają pracy.

Proces krok po kroku

1. Nie wymagaj od klienta gotowej specyfikacji.
2. Ustal, dlaczego projekt jest potrzebny właśnie teraz.
3. Poproś o opis obecnej sytuacji i konkretnego przykładu problemu.
4. Oddziel potrzebę od rozwiązania zaproponowanego przez klienta.
5. Zidentyfikuj użytkowników, osobę decyzyjną i pozostałych interesariuszy.
6. Określ oczekiwany rezultat oraz sposób jego oceny.
7. Przeanalizuj istniejące materiały, dane i procesy.
8. Zamień ogólne określenia w konkretne kryteria.
9. Ustal priorytety oraz minimalny sensowny zakres.
10. Zapisz niewiadome, założenia i ryzyka.
11. W razie potrzeby zaproponuj płatne discovery lub prototyp.
12. Dopiero po doprecyzowaniu zakresu przygotuj wiążącą wycenę.
13. Prześlij klientowi podsumowanie i uzyskaj jego potwierdzenie.
14. Traktuj późniejsze nowe informacje jako zmianę założeń, którą trzeba świadomie ocenić.

Podsumowanie

Klient, który nie potrafi dokładnie określić swoich potrzeb, nie musi być trudnym ani źle przygotowanym klientem. Często znajduje się po prostu na etapie, na którym rozumie problem lepiej niż możliwe rozwiązania. Właśnie wtedy najbardziej potrzebuje specjalisty, który pomoże mu uporządkować sytuację.

Nie należy jednak wypełniać wszystkich luk własnymi domysłami. Skuteczne discovery jest wspólnym procesem: klient dostarcza wiedzę o swojej firmie i użytkownikach, a wykonawca pomaga zamienić tę wiedzę w cele, priorytety, wymagania i realistyczny zakres.

Najlepiej zaczynać od obecnej sytuacji, konkretnych problemów i oczekiwanej zmiany. Dopiero później warto rozmawiać o funkcjach, wyglądzie, technologii i materiałach do dostarczenia. Dzięki temu rozwiązanie wynika z potrzeby, a nie z pierwszego pomysłu, który pojawił się podczas rozmowy.

Jeżeli ustalenie potrzeb wymaga audytu, warsztatów, analizy danych lub opracowania koncepcji, powinno stać się osobnym, płatnym etapem. Freelancer nie musi bezpłatnie rozwiązywać złożonego problemu tylko po to, aby móc podać cenę.

Celem nie jest usunięcie każdej niewiadomej przed startem. W wielu projektach będzie to niemożliwe. Chodzi o rozpoznanie najważniejszych założeń, świadome ograniczenie ryzyka i ustalenie procesu, dzięki któremu kolejne decyzje nie będą podejmowane przypadkowo.