Znajdowanie prawdziwej potrzeby klienta

Znalezienie i zrozumienie prawdziwej potrzeby klienta jest jednym z podstawowych elementów procesu tworzenia udanych produktów. Z artykułu dowiesz się jakie mogą być powody, dla których zespoły nie docierają do potrzeb kleintów. Przeczytasz też, dlaczego warto do tego dążyć oraz jak to zrobić w praktyce.

O zgłębianiu prawdziwej potrzeby klienta pisaliśmy już w artykule o tym, jak przeprowadzać porządnie Refinement Backlogu Produktu. Poniższy artykuł pogłębia i poszerza ten wątek.

Przykłady z życia, kiedy zespoły nie zgłębiają prawdziwej potrzeby klienta

Przykład pierwszy: ubezpieczenie komunikacyjne

Wyobraź sobie zespół, który rozwija system do zarządzania ubezpieczeń komunikacyjnych. Zespół miał dodać do systemu flagę. Otrzymał konkretne informacje dotyczące tego w jakiej usłudze, w jakim polu, o jakiej nazwie, należy dodać jaką flagę i jakie wartości ma ta flaga przyjmować.

Zespół długo dyskutował o szczegółach rozwiązania tego zadania, nie wiedząc za bardzo jaki był kontekst i powód jego wdrożenia. W tym konkretnym przypadku ktoś w końcu zapytał, po co w zasadzie mają ustawiać tę flagę przy tym ubezpieczeniu komunikacyjnym. Okazało się, że firma chce zaoferować bardzo korzystne rozwiązanie, unikalne na rynku, które będzie oznaczało, że te ubezpieczenia będą miały atrakcyjny pakiet, w którym kierowcy będą mieli zarówno autocasco jak i assistance. Stąd pojawiła się potrzeba odzwierciedlenia tego w systemie, że jest możliwość skorzystania z jakiegoś ciekawego, odrębnego ubezpieczenia.

Natomiast istniał dramatyczny rozdźwięk między „ustawcie flagę w bazie”, a tym, że „chcemy zrobić unikalne ubezpieczenie i potrzebujemy je mieć w jakiś sposób widoczne w systemie”. Dopiero gdy zespół dowiedział się, po co ma zrealizować to zadanie, tak naprawdę zaczęła się sensowna i głęboka rozmowa o tym, jak do niego podejść i je zrealizować. 

Przykład drugi: wyszukiwarka w systemie

Do zespołu, w którym pracował Jacek, przyszedł Product Owner. Zaczął opowieść, z której wynikało, że w konkretnym miejscu systemu potrzebuje wyszukiwarkę. Chciał uzyskać możliwość wyszukiwania parametrów, przypiętych do produktów, sprzedawanych na platformie e-commerce, którą rozwijał. Rozpoczęła się długa rozmowa o tej wyszukiwarce: jak często odświeżać rezultaty wyszukiwania, jak często ją indeksować, czy ma tam być możliwe zaawansowane wyszukiwanie.

Dopiero po pewnym czasie zespół zaczął dociekać, po co Product Ownerowi tak naprawdę jest potrzebna wyszukiwarka. Od słowa do słowa okazało się, że tych elementów, które chciał wyszukiwać, wcale nie było tak dużo. Kiedy zespół zrozumiał, z jakim problemem przyszedł Product Owner, to zaproponował zupełnie inne rozwiązanie (paginację), które można było zaimplementować w pół dnia, zamiast budować skomplikowaną wyszukiwarkę.

Oba przykłady pokazują, że należy zadawać pytania, trzeba próbować zrozumieć potrzeby, bo zwykle prowadzi do zespoły do lepszych rozwiązań, nierzadko tańszych i bardziej dopasowanych do potrzeb klientów lub użytkowników. 

Potencjalne powody dlaczego zespoły nie szukają prawdziwej potrzeby klienta

Bazując na naszym doświadczeniu, przygotowaliśmy 6 najczęstszych powodów pomijania etapu zrozumienia prawdziwej potrzeby klienta:

1. “Nikt nie powiedział, że możemy pytać” – W zespole brak jest świadomości, że mogą zadawać pytania i pogłębiać swoje zrozumienie tematu. Działają automatycznie, dostają informacje, co mają zrobić i to robią.
   
2. “Nie wolno nam” – Zespół jest ustawiony w pozycji, w której próba zadawania pogłębiających pytań – nawet otwartych, nawet bardzo grzecznie wypowiedzianych – jest niewskazana. Jeśli nawet nie jest to powiedziane wprost, to reakcje na te pytania powodują, że zespołowi się odechciewa ponownie pytać.
   
3. “Mamy dużo funkcji do zbudowania, nie ma czasu” – Presja czasu i ilość pracy oczekującej na wykonanie jest tak duża, że najsensowniejszym rozwiązaniem wydaje się po prostu to robić, a nie zadawać pytania, które zajmą dodatkowy czas.
   
4. “My tu nie jesteśmy od myślenia” – Zespół ma poczucie, że jest od robienia rzeczy, a od myślenia jest ktoś inny. Ten ktoś ma obraz całości, ktoś to wymyślił, no i pewnie ma rację. Zespół nie czuje się kompetentny, żeby to kwestionować. Doprowadza to do spłycenia roli, np. programistów do roli klepaczy kodu.
   
5. “Nie wiemy jak to zrobić” – W zespole brakuje kompetencji na poziomie zadawania pytań, facylitacji rozmowy czy wizualizacji pracy do wykonania, ale też analizy konkretnych zagadnień i syntezy zdobytych informacji.
   
6. “Nie mamy na to ochoty” – Nikt tak nie mówi otwarcie, jednak zespół jest zdemotywowany, brak jest zaangażowania. Jest poczucie, że nie mają na nic wpływu, więc nie chcą zadawać pytań i wnikać głębiej w zagadnienie, po prostu robią swoje.

Dlaczego warto dążyć do zidentyfikowania prawdziwej potrzeby klienta?

Istnieją 4 główne korzyści płynące ze znalezienia i zrozumienia potrzeb klienta.

1. Oszczędność czasu

Przed chwilą pisaliśmy, że zespoły nie wnikają w prawdziwe potrzeby, bo są tak zajęci, że nie mają na to czasu, a teraz mówimy o czymś zupełnie przeciwnym. Dlaczego?

Paradoks polega na tym, że porządne zagłębienie się w prawdziwą potrzebę jest z dużym prawdopodobieństwem oszczędnością czasu w dalszych etapach rozwoju produktu czy projektu. Zespół może uchwycić właściwą potrzebę na wczesnym etapie rozwoju i rozwiązać ten problem w najwłaściwszy sposób, najkrótszą możliwą ścieżką.

Jest to nawiązanie do zasad stojących za Manifestem Zwinnego Wytwarzania Oprogramowania a konkretnie poniższej zasady:

„Prostota – sztuka maksymalizacji ilości pracy, która nie zostanie wykonana – jest niezbędna.”

I owszem, trzeba będzie poświęcić trochę czasu na to, żeby zadać trochę pytań i pogłębić temat, ale najpewniej unikniemy bezsensownej pracy i wielu rund poprawek.

Innymi słowy, zaoszczędzimy czas, inwestując go na odpowiednio wczesnym etapie w dobre przemyślenie tego, co jest do zrobienia.

2. Kreatywne pomysły

Produktem ubocznym dążenia do zrozumienia prawdziwej potrzeby klienta są pomysły, które rodzą się w tym procesie.

Dzięki temu nie ograniczamy się do jednego, właściwego rozwiązania, które powstało w głowie jedej, wybranej osoby. Zapraszamy zespół do poszukania palety rozwiązań. Włączamy w to całą grupę osób, co pozwala sięgnąć do różnych perspektyw.

Z doświadczenia wiemy, że przeanalizowanie tematu przez zespół wytwórczy, potrafi wywrócić nawet te najlepiej przemyślane pomysły.

3. Lepsze rozwiązania technologicznie

Dzięki połączeniu swobody w kreowaniu pomysłów i wiedzy o możliwościach technologicznych, zespół może stworzyć lepsze rozwiązanie, także pod kątem jego rozwoju w przyszłości.

Osoby posiadające wiedzę techniczną są w stanie zwrócić uwagę na rzeczy, które w ogóle nie przyszły by przyszły do głowy osobie zlecającej zadanie do wykonania. 

4. Wyższe zaangażowanie w zespole

Ostatni, ale nie mniej ważny argument, to możliwość uzyskania wyższego zaangażowania w zespole.

Schodząc na poziom dyskusji o prawdziwych potrzebach w zespole wytwarza się poczucie współodpowiedzialności za produkt. Wynika to z faktu, że staje się wtedy już nie tylko podwykonawcą czyjegoś pomysłu, ale ma szansę realnie wpłynąć na kształt produktu.

Współodpowiedzialność zwykle powoduje, że ludziom chce się działać. Zależy im, żeby produkt był jak najlepszy i chcą, żeby użytkownicy mieli maksymalnie udane doświadczenie z jego używania.

Jak poprawić identyfikację prawdziwej potrzeby klienta?

Mamy dla Ciebie też kilka wskazówek jak można usprawnić identyfikowanie faktycznych potrzeb klienta.

1. Pomijaj pośredników

Dotrzyj bezpośrednio do klienta, nawet jeśli wydaje Ci się to niemożliwe. W naszej działalności często napotykamy postawę obronną zespołów, które nie wiedzą jak to zrobić, z kim mieliby rozmawiać i czy ktokolwiek chciałby to zrobić.

Mamy świadomość, że czasem może być to trudne. Stąd pierwszym, bezpiecznym krokiem może być nie kompletne wyeliminowanie wszystkich pośredników, a początkowe wyeliminowanie choćby jednego pośredniczącego ogniwa.

Przykładowo, zamiast rozmawiać z Product Ownerem, który w naszym imieniu rozmawia z interesariuszem, można porozmawiać z nim bezpośrednio. Taki bezpośredni kontakt pozwala zwykle poznać szerszy kontekst omawianego zagadnienia.

Innym pomysłem może być porozmawianie z kimś z call center lub osobami, które mają bezpośredni kontakt  z klientem, który korzysta z naszego systemu lub rozwiązania.

2. Zadawaj właściwe pytania

Chodzi o zadawanie pytań, które mocno zgłębiają kontekst i potrzebę klienta. Poniżej kilka przykładowych:

• Co zrobisz, jak dostaniesz ten ficzer?
• Co cię boli, gdy korzystasz z mojego rozwiązania?
• Co chcesz uzyskać dzięki mojemu produktowi?

Unikaj pytań wskazujących rozwiązania typu: Czego konkretnie się spodziewasz? Gdzie chcesz coś zmienić?

Staraj się zrozumieć kontekst użytkownika i tego, jak korzysta z naszego produktu. Pamiętaj też, aby skupić się na słuchaniu tego, co mówi rozmówca i powstrzymuj się przed podpowiadaniem i sugerowaniem konkretnych rozwiązań.

Warto poprosić kogoś bardziej doświadczonego w przeprowadzaniu tego typu wywiadów o krótkie przeszkolenie, czy podzielenie się jakimiś wskazówkami.

3. Wchodź w buty klienta

Jeżeli pierwsza nasza porada mówiąca o bezpośrednim docieraniu do klienta docelowego jest niemożliwa do realizacji, to warto chociaż starać się zrozumieć, jak myśli nasz klient.

Wszelkiego rodzaju empatyzowanie z użytkownikiem i postawienie się w jego sytuacji jest sensownym krokiem w kierunku zrozumieniu jego potrzeb. Pomocne w tym może być stworzenie person, przygotowanie w rzetelny sposób User story lub Mapy Empatii.

Dobrą praktyką jest też wykorzystanie koncepcji Jobs to be done,  czyli porozmawianie o tym, co tak naprawdę klient chce osiągnąć, korzystając z naszego rozwiązania.

Takie ćwiczenia można przeprowadzić w formie warsztatów z analitykiem i UX designerem, a można też po prostu w ramach własnego zespołu przedyskutować temat.

4. Wnikaj w kontekst pracy

Wyobraź sobie sytuację w której zespół otrzymuje bardzo konktetnie opisane rozwiązanie docelowe. Praca Product Ownera skupia się na tym, żeby jasno sformułować, co jest do zrobienia oraz jakie są kryteria akceptacji. Zespół ma dużo informacji na temat tego, co zrobić, ale nie ma informacji, dlaczego ma to zrobić.

W ten sposób, najpewniej nieświadomie, Product Owner odciął zespół od możliwości zgłębienia kontekstu pracy, co może mieć negatywny wpływ na zaangażowanie i poczucia, że robimy coś sensownego i wartościowego. 

Zagłębienie się w kontekst pracy przede wszystkim buduje zaangażowanie zespołu.

Po drugie, pobudza zespół do zadania sobie dodatkowych pytań: Czemu ma to służyć? Jaki problem ma to rozwiązać? Jakie ułatwienia ma to zapewnić? Jak sobie radzi użytkownik w tej chwili, gdy nie ma tego ficzera? Jak zmieni się jego zachowanie, gdy otrzyma ten ficzer? Co mu to uprości?

5. Nie bądź przesadnie przygotowany

Jest to porada studząca nieco wcześniej przytoczone wskazówki. Kierujemy ją przede wszystkim do Product Ownerów.

Warto przyhamować pokusę przygotowania wszystkich informacji z dużym poziomem szczegółowości. Teoretycznie może to skrócić rozmowy, jednak należy pamiętać, że przygotowanie zostało wykonane indywidualnie przez PO, bez zaangażowania mądrości zespołu. Gdyby na wcześniejszym etapie porozmawiać z zespołem, to jest duża szansa, że udałoby się wypracować coś innego, coś o większej wartości i być może łatwiejsze w realizacji.

Zachęcamy do podchodzenia do doskonalenia Backlogu Produktu w sposób iteracyjny. Na pierwszy refinement PO mógłby przyjść wyłącznie z problemem, który został zidentyfikowany. Zidentyfikowane brak w wiedzy mogą zostać uzupełnione do czasu kolejnego refinementu, gdzie kolejny raz podejdziemy do rozmowy, tym razem mając więcej wiedzy. Proces potwarzamy do momentu, gdy wszystko w kontekście konkretnego zadania jest już dla wszystkich jasne.

Kiedy nasze porady mogą okazać się nietrafione?

Warto na koniec wspomnieć, że powyższe porady i wskazówki nie zawsze będą miały zastosowanie.

Jesteśmy w stanie wyobrazić sobie sytuację, gdy będą one po prostu stratą czasu, bo do realizacji będzie jakieś bardzo podstawowe i trywialne rozwiązanie, które dla wszysrtkich jest oczywiste i szkoda czasu na długie dyskusje.

Miej jednak z tyłu głowy, że nawet rzeczy, które wydają się dość proste, mogą zasługiwać na zastanowienie się i przegadanie ich z innymi osobami. Zachęcamy do samodzielnej oceny, gdzie leży dolna granica, przy której nie ma sensu zbytnio zgłębiać zagadnienia.  

Dodatkowe materiały

• Porządny Refinement
• Facylitacja spotkań

Transkrypcja podcastu „Znajdowanie prawdziwej potrzeby klienta”

Kuba: Ostatnio ponownie spotkałem przypadek zespołu, który bardzo szybko przechodził do bardzo szczegółowej dyskusji o rozwiązaniu, zamiast wniknąć w to, jaka jest faktyczna potrzeba klienta w danym przypadku. Ten zespół był bardzo fajnym, zgranym zespołem. Robił dużo rzeczy całkiem dobrze, ale moim zdaniem nie było to optymalne, że momentalnie wskakiwali w rozwiązanie, zamiast zastanowić się, jak podejść do tego problemu w ogóle lepiej. I ponieważ często trafiamy na takie sytuacje, postanowiliśmy poświęcić temu ten odcinek. 

Jacek: Ten temat, który będziemy dzisiaj omawiać, bardzo mocno ze mną rezonuje. Można powiedzieć, że tak się wychowałem, ponieważ pierwszy Zespół Scrumowy, w którym pracowałem jako Scrum Master, starał się właśnie w ten sposób podchodzić do zrozumienia prawdziwych potrzeb klienta. Życzyłbym sobie, czy naprawdę fajnie bym się czuł, gdybym wiedział, że więcej zespołów w ten sposób pracuje. Tak naprawdę to dogłębne zrozumienie, po co coś robimy, no po prostu otwiera nam całą paletę korzyści, o których dzisiaj w trakcie odcinka opowiemy. 

Kuba: To zgłębienie prawdziwej potrzeby klienta, to jest coś, co wspomnieliśmy jako jedna z recept na dobry Refinement Backlogu Produktu. Był to odcinek #009 podcastu. Natomiast w tamtym odcinku, wspomnieliśmy o tym w zasadzie raptem w paru zdaniach. Dzisiaj czujemy, że to zasługuje na głębsze potraktowanie i tak naprawdę pełne omówienie, więc w pewnym sensie rozszerzamy wątek, który był w odcinku #009. Jeśli jeszcze go nie słuchałeś lub nie słuchałaś, to oczywiście polecamy poszukanie odcinka na przykład pod adresem porzadnyagile.pl/9

Jacek: Plan na dzisiejszy odcinek będzie wyglądał następująco. Na początku podamy parę przykładów sytuacji, o której będziemy rozmawiać w odcinku. Następnie powiemy o potencjalnych powodach, dlaczego zespoły nie szukają prawdziwej potrzeby klienta. Następnie powiemy, dlaczego warto dążyć do zidentyfikowania prawdziwych potrzeb. No i na koniec powiemy, jak można poprawić identyfikację prawdziwej potrzeby klienta. 

Kuba: Zaczniemy od przykładów, tak jak Jacek wspomniał. Przykłady są po to, żeby zobrazować trochę też, o co nam chodzi. Bo wiemy, że są zespoły, które jak tego nie robią, to w ogóle mogą nie wiedzieć, o co nam chodzi. Ja mam taki przykład trochę wcześniejszy niż ten, który mnie zainspirował do tej tematyki. Przykład zespołu, który rozwijał system do zarządzania ubezpieczeń. Konkretnie ubezpieczeń komunikacyjnych. No i byłem obserwatorem rozmowy o tym, że od zespołu oczekiwało się, że do systemu dodać należy flagę. I część z Was może sobie dosyć łatwo to wyobrazić. Część może nie miała przyjemności pracy w tym stylu. No, ale ten zespół miał podyktowane w jakiej usłudze, w jakim polu, o jakiej nazwie, należy dodać jaką flagę i ta flaga ma koniecznie przyjmować wartość zero lub dwa. I zespół w zasadzie długo i cierpliwie dyskutował o szczególikach rozwiązania tej flagi, nie wiedząc za bardzo jaki był kontekst. Na szczęście, akurat w tym konkretnym przypadku, trochę dłuższą drogą okrężną, ale w końcu ktoś zadał pytanie _ Ale w zasadzie to, po co mamy ustawiać tą flagę przy tym ubezpieczeniu komunikacyjnym? I nagle się okazało, że tam jest cała fajna, ważna historia o tym, że firma chce zaoferować jakieś bardzo korzystne rozwiązanie, unikalne na rynku, które będzie oznaczało, że te ubezpieczenia będą miały jakiś fajny pakiet, gdzie kierowcy będą mieli i autocasco i assistance. No i po prostu trzeba odzwierciedlić w systemie, że jest możliwość skorzystania z jakiegoś fajnego odrębnego ubezpieczenia. Natomiast rozdźwięk był dramatyczny między tym, że ustaw flagę w bazie, a tym chcemy zrobić bardzo unikalne ubezpieczenie. I w związku z tym chcemy je mieć widoczne w systemie, w wydrukach, w raportach, w jakichś tam ofertach. Zupełnie inna rozmowa. No i co ważne, dopiero jak już zespół wiedział po co, to tak naprawdę zaczęła się sensowna rozmowa o tym, że może nie tak to zróbmy, tylko trochę inaczej. Od razu przewidźmy pewne inne warianty, bo tak naprawdę nie sprowadza się to tylko i wyłącznie do jakiegoś przełączniczka w jednym miejscu, jak to pierwotnie zostało temu zespołowi zlecone. W tym konkretnym przypadku, między innymi przez analityka systemowego. 

Jacek: Ja najbardziej pamiętam taką historię, kiedy pierwszy raz się zderzyłem z tą sytuacją, gdzie próba poszukania potrzeby wygenerowała zaskakujące rozwiązanie. Mianowicie do zespołu, w którym pracowałem przyszedł Product Owner i zaczął opowiadać, że w jakimś tam miejscu w systemie, w takiej części administracyjnej, w produkcie takim typowo e-commerce’owym, on bardzo by potrzebował wyszukiwarkę, bo chce móc wyszukiwać jakieś tam parametry opisujące jakieś konkretne produkty. No i długa rozmowa o tej wyszukiwarce. Trochę już się zaczęła dyskusja, tak naprawdę, jak tam jak często ją odświeżać, jak często indeksować, czy tam jakieś zaawansowane wyszukiwania mają mieć możliwość. No i na szczęście rozmowa trochę zeszła na tory – Dobra, a w sumie to, po co ci ta wyszukiwarka? I tak od słowa do słowa okazało się, że tych elementów, które chciał wyszukiwać, wcale nie było tak dużo. W sensie kilkadziesiąt, jeśli mnie pamięć nie myli. No i w tym momencie zespół, kiedy zrozumiał, jaka jest potrzeba tego Product Ownera, no to zaproponował zupełnie alternatywne rozwiązanie. Rozwiązanie to była po prostu paginacja strony. Paginacja oczywiście dostępna była z pudełka, więc można było ją zaimplementować w pół dnia, zamiast budować wyszukiwarkę, która oczywiście byłaby trochę trudniejsza. Tak więc to był taki moment w mojej karierze, kiedy zrozumiałem, że te pytania trzeba zadawać, trzeba próbować zrozumieć, bo zwykle prowadzi to co najmniej do ciekawych dyskusji, a może też prowadzić do lepszych rozwiązań. Tańszych rozwiązań, bardziej dopasowanych rozwiązań. 

Kuba: Natomiast lata pracy z zespołami pokazują, że to nie jest takie proste. Czyli, jak my jesteśmy już przekonani do tego, że trzeba szukać prawdziwą potrzebę,  zgłębiać ją, zadawać sobie te wszystkie pytania, o których tutaj mówimy. No to, jak już jesteśmy za tą rzeką, no to już jest dla nas oczywiste. Natomiast, gdy pracujemy z zespołami. No tutaj uruchamia nam się ten minimalny pokład empatii. Wiemy i rozumiemy, i spotykamy zespoły, które mają swoje powody, że nie szukają prawdziwej potrzeby klienta. No i co w takiej sytuacji Jacek słyszymy?

Jacek: Taką bardzo częstą odpowiedzią jest – Nikt nam nie powiedział, że możemy pytać. Czyli zespół zgłasza coś takiego, że tak naprawdę nie był świadomy, że mogą pracować na potrzebę. Że to po prostu jest automatyczne, że ktoś przychodzi i mówi co mamy zrobić. No i po prostu robimy bez tej świadomości, że tak naprawdę można pracować inaczej. 

Kuba: Druga odpowiedź, która nam się zdarza to, że – Nam nie wolno. Czyli zespół jest sprowadzony, czy to w całej organizacji, czy ten konkretny jeden zespół, jest postrzegany jako ktoś, kto nie może zakwestionować tego, że ktoś przychodzi na przykład z gotowym rozwiązaniem, albo z jakimś konkretnym opisem tego co ma być zrobione. No i zespół jest tutaj ustawiony w takiej pozycji, że nawet próba zadawania takich pytań – nawet otwartych, nawet bardzo grzecznie zapytanych, tak jakby sformułowanych – jest niewskazana, jest zabroniona. Czy, nawet jeśli nie jest to powiedziane wprost, to reakcje powodują, że jednak nam się odechciewa i czujemy, że to nie jest ta sytuacja? To może być sytuacja wewnętrzna, że na przykład IT nie jest traktowana jako partner do dyskusji i do kreowania rozwiązań. To może być też sytuacja w tej tutaj interakcji zewnętrznej. Czyli jesteśmy na przykład software housem, który dostarcza rozwiązania dla klienta. No, ale tak, a nie inaczej mamy kontrakt ustawiony, że mamy zrobić to, co klient zamówił i dyskutować, nie wnikać. Nie wolno nam tutaj o tym rozmawiać, czy o to pytać. 

Jacek: Kolejna rzecz którą, słyszymy to – Mamy za dużo do zrobienia, nie ma na to czasu. Czyli takie poczucie, że jest tyle pracy oczekującej na wykonanie. I taka jest presja, że najsensowniejszym rozwiązaniem wydaje się po prostu to robić. Trochę wpadać w taki antywzorzec fabryki ficzerów. No bo to zawsze na wyjściu będzie jednak jakieś ficzer, czyli powiedzmy jakiś namacalny efekt. No i teraz rozgrzebywanie, dlaczego i po co, może rodzić w zespole poczucie, że to nie jest właściwy moment na taką rozmowę. Jest za późno i tak już jesteśmy spóźnieni. 

Kuba: Idąc dalej, coraz gorsze historie będziemy przytaczać. Jest taka historia – My tu nie jesteśmy od myślenia. Trochę podobnie do tych dwóch poprzednich cytatów, tylko tutaj bardziej taka koncepcja, że jest ktoś w firmie od myślenia. I my twórcy, my tutaj na przykład programiści, czy w ogóle osoby realizujące jakieś przedsięwzięcie, projekt, no to my jesteśmy tutaj od zrobienia. Tak nam powiedzieli, że mamy to zrobić. Ktoś ma obraz całości, ktoś to wymyślił, no i pewnie ma rację. My nie jesteśmy od tego, żeby to kwestionować. No i niestety doprowadza to do takiego jeszcze kolejnego antywzorca, takiego spłycenie roli. Na przykład roli programistów do koderów, do klepaczy kodu. Po prostu osoby, które mają zaimplementować to, co zostało zlecone. Mają to dobrze opisane, mają to zdecydowane i po prostu mają się skupić na tym, żeby efektywnie powstawał kod. 

Jacek: Przedostatnia rzecz, którą mamy, z którym się spotykamy to komentarz w stylu – Nie wiem jak to zrobić. Czyli po prostu taka sytuacja, w której brakuje kompetencji takich poziomu zadawania pytań, facylitacji rozmowy czy spotkania pracy w wizualny sposób, ale też analizy konkretnych zagadnień. A następnie też po takim dogłębnym rozgrzebaniu, też jakiejś takiej syntezy i powrotu jednak do czegoś namacalnego. Nie są to domyślne kompetencje, które są w każdym zespole. No i po prostu, jeżeli ktoś nie miał szczęścia pracować w takim zespole, który ma kompetencje dochodzenia do prawdziwych potrzeb, no to po prostu najnormalniej w świecie ktoś może nie wiedzieć w ogóle, jak się za to zabrać. 

Kuba: I ostatni cytat, który możemy tutaj usłyszeć. Niestety chyba najsmutniejszy. Nie mam na to ochoty. Ludzie tak nie mówią, ale mają na myśli. Mam to w nosie. Nie jestem zaangażowany. Jestem zdemotywowany. Nie mam na nic wpływu. Nie będę zadawał tych pytań. Nie jestem szanowany. No i cała taka sfera właśnie braku zaangażowania czy braku motywacji, która powoduje, że po prostu nie chce się pojedynczym osobom, a może nawet nie chce się całemu zespołowi wchodzić, wnikać, wnieść coś od siebie, zadawać pytania, przemyśleć. Cała ta sfera, o której tutaj w ogóle mówimy. 

Jacek: No dobrze to powiedzieliśmy sobie, co najczęściej jest powodem. To powiedzmy sobie w skrócie, dlaczego mimo wszystko warto drążyć ten temat i dążyć do  zidentyfikowania prawdziwych potrzeb?

Kuba: Pierwszy powód, który przychodzi do głowy to oszczędność czasu. I to jest pewien paradoks, w porównaniu do tego cytatu z poprzedniej części tego odcinka. Czyli jesteśmy tacy zajęci, że nie mamy czasu wnikać w potrzebę. Natomiast paradoks polega na tym, że dobre wniknięcie w prawdziwą potrzebę jest z dużym prawdopodobieństwem oszczędnością czasu w dalszych etapach. Czyli wnikniemy głęboko w prawdziwą potrzebę. Czyli prawdopodobnie złapiemy tę właściwą potrzebę na wczesnym etapie rozwoju. Rozwiążemy teraz to, co jest do zrobienia w najwłaściwszy sposób, najkrótszą możliwą ścieżką, na jaką jesteśmy w stanie wpaść na takim etapie główkowania. No i coś, co nawiązuje do zasad stojących za Manifestem Zwinnego Wytwarzania Oprogramowania. Będziemy maksymalizować pracę niewykonaną. Czyli oszczędzimy sobie kilku iteracji, być może dotniemy rozwiązania o te jakieś aspekty, które są naprawdę najistotniejsze. I owszem, poświęcimy trochę czasu na to, żeby zadawać sobie trochę pytań, trochę pownikać. O tym jeszcze będziemy mówić, co można zrobić. No, ale dzięki temu nie będziemy robili pracy bezsensownej i nie będziemy robili kilku okrążeń poprawiania. Zaoszczędzimy czas, inwestując go na odpowiednio wczesnym etapie w dobre przemyślenie tego, co jest do zrobienia. 

Jacek: Drugim powodem, dla którego warto dążyć do identyfikowania prawdziwych potrzeb klienta, jest to, że liczymy na kreatywne pomysły. Czyli nie ograniczamy się tylko do tego gotowego rozwiązania, jednego rozwiązania, które zostało stworzone w czyjejś głowie. Tylko jednak zapraszamy zespół do poszukania palety rozwiązań. I rozmawiamy tutaj z całą grupą osób, które mają najczęściej różne perspektywy. Często też znają produkt, co powoduje, że potencjalnie to rozwiązanie będzie po prostu lepsze. Oczywiście zakładając wariant, że ten pomysł, który został przeniesiony do zespołu, nie został wcześniej w jakiś sposób przemyślany. Niemniej jednak to dotknięcie zespołu deweloperskiego, na bazie moich doświadczeń, często potrafi wywrócić nawet te pierwotne przemyślane pomysły.

Kuba: Dobre zgłębianie prawdziwej potrzeby klienta może prowadzić też do lepszych rozwiązań technologicznych. To jest dosyć podobna kwestia do tego, co Jacek przed chwilą powiedziałeś. Ale mimo wszystko chcę to jakoś tutaj wyróżnić. Bo chodzi o to też, że jeśli wiem, co jest prawdziwą potrzebą, to zwłaszcza jeśli jestem tutaj inżynierem, osobą dobrze rozumiejącą możliwości technologiczne, być może jakieś nowinki, jestem w stanie na potrzeby klienta zaaplikować również tutaj swoją wiedzę i również być może przewidzieć pewne rozwiązania też tak przyszłościowo. Rzeczy, które być może nie przyszły do głowy zlecającemu. Klient sam być może nie będzie nawet umiał je zamówić, a ja tutaj mając, powiedzmy swoją technologię, będę w stanie to lepiej rozwiązać. Lepiej niż zostałoby kiedykolwiek, jakkolwiek zlecone. 

Jacek: Ostatnim argumentem, dlaczego warto, to możliwość uzyskania wyższego zaangażowania w zespole. I tutaj co najmniej kilka wątków się pojawia. Przede wszystkim takie poczucie współodpowiedzialności i współtworzenia produktu. Czyli, nie jestem tylko tym takim dostawcą, podwykonawcą czyjegoś pomysłu, ale mam szansę w jakikolwiek sposób się zidentyfikować z produktem. Pamiętam, współpracowałem z zespołem, który tworzył produkt mobilny i fajnie było popatrzeć na to, jak ten zespół cytuje jakieś recenzje, które gdzieś na platformie mobilnej ta aplikacja dostawała. I tak bardzo emocjonalnie reagowali. Że jak?! Nie wie, że tam, gdzie gdzieś można kliknąć, ten użytkownik w sensie. Oczywiście trochę było w tym śmiechu, trochę prawdy. Natomiast było widać po prostu, że temu zespołowi zależy. Że oni chcą, żeby ten produkt był dobry i chcą, żeby użytkownicy po prostu mieli fajne doświadczenie. Więc na pewno ta współodpowiedzialność jest istotna. To zaangażowanie prowadzi do tego, że ludzie się angażują. Ludziom się chce. A to jest jedno z takich najczęstszych pytań, które dostaję od managementu firm, z którymi pracuję, jak budować zaangażowanie. Tak więc to jest taka dosyć prosta odpowiedź. Pozwólmy ludziom współtworzyć produkt. Dajmy im poczucie jakiejś tam autonomii. To może być i autonomia na poziomie technologicznym, oczywiście w pewnym ustalonym zakresie, ale także autonomia w zakresie produktowym. Czyli po prostu możliwość wpływania na to, jak coś będzie funkcjonować. Jak będziemy rozwiązywać konkretny problem, czy potrzeby użytkownika?

Kuba: No dobra to już ustaliliśmy, dlaczego mogą być zespoły, które nie zgłębiają potrzeby klienta. Mamy też wymienione zalety takiego dobrego podejścia do potrzeb klienta. No to ustalmy kilka naszych rekomendacji. Jak można poprawić identyfikację prawdziwej potrzeby klienta?

Jacek: No zdecydowanie rekomendujemy pomijać pośredników. Czyli, co do zasady, taka najogólniejsza porada by brzmiała – Dotrzyj do klienta. I bardzo często, kiedy proponuje takie podejście, żeby poddać je pod dyskusję, to najczęściej spotykam się z taką reakcją obronną. Na zasadzie to niemożliwe. Jak mielibyśmy to zrobić? Kto w ogóle miałby chcieć z nami rozmawiać? I tak dalej. Czyli najczęściej zaczyna się jakaś tam wyliczanka powodów, dla których to jest niemożliwe i w pewnym sensie to rozumiem. No bo, jeżeli ten klient jest traktowany, jako taki byt obcy, który tylko gdzieś tam te pretensje swoje w jakimś call center, czy w customer care zostawia, no to aż trudno sobie momentami wyobrazić, że nagle to miałaby być osoba czy osoby, z którymi zaczynamy rozmawiać. Natomiast uważam, że to jest absolutnie sensowna ścieżka, której można nie traktować dosłownie. Na takiej zasadzie, że jeżeli jesteś absolutnie przestraszony, przestraszona samą myślą, że można byłoby dotrzeć do klienta, czy do użytkownika, no to spójrzmy sobie na ten łańcuch pośredników i może chociaż go skróćmy o jedno oczko. Czyli powiedzmy, jeżeli zawsze przynosi do zespołu tematy Product Owner z jakichś tam obszarów biznesowych firmy, no to fajnym pierwszym krokiem może być to, że ściągniemy sobie takiego biznesowca, interesariusza, osobę o jakiejś tam wiedzy domenowej do zespołu, czy na Refinement, czy na planowanie. I to już jest coś, co powoduje, że jednak jesteśmy w stanie zadać pytania. Usłyszeć trochę szerszy kontekst. To nie jest odfiltrowane. Ta rozmowa ma szanse się potoczyć dokładnie tak, jak czujemy, że powinniśmy jako zespół z tą osobą porozmawiać. Tak więc zdecydowanie, docieranie do klienta, lub jako taki etap pośredni, chociaż likwidowanie pojedynczych ogniw w tym łańcuchu, no to zdecydowanie jest coś, co warto spróbować. 

Kuba: I w tym kontekście mi się serce kroi, jak słyszę argumenty za tym, żeby nie docierać do użytkownika, czy klienta w realiach rozwiązań, które są takie wewnątrz firmowe. Tutaj, chociażby myślę o jakimś call center, jakimś CRMie czy CMSie, rozwiązań, których tak naprawdę to wewnątrz jednej organizacji, albo w ramach jednej grupy są ci, do których powinniśmy ostatecznie dotrzeć. To jest moim zdaniem szczególny przypadek, w którym naprawdę nie kupuję argumentu, że tu analityk, Product Owner, jakiś kierownik z biznesu. To są właściwe osoby, z którymi można rozmawiać, bo tak naprawdę dosłownie, pewnie z odrobiną oczywiście organizacji, jakiejś tam logistyki, ale jesteśmy w stanie dotrzeć na przykład do pracowników call center, którzy korzystają z naszego systemu. Porozmawiać z ludźmi, którzy autentycznie obsługują pewien proces, na którym my na przykład budujemy jakieś narzędzia. Ale tutaj taka mikro anegdota, też nawet w realiach, gdy jesteśmy klientem zewnętrznym. Też moim zdaniem to się da zrobić, tylko być może nikt u nas tego do tej pory nie robił, albo wydaje nam się, że jest to trudne. Całkiem niedawno odebrałem telefon z nieznanego mi numeru. Myślałem, że fotowoltaika. A się okazuje, że się przedstawia. Miły człowiek po drugiej stronie i zaczyna tłumaczyć, że rozwija aplikację do faktur, z której akurat korzystamy w naszej firmie. No i krótka rozmowa, bardzo uprzejma. O tym, że mają pomysł na pewne nowe rozwiązania i czy mogą ze mną porozmawiać na temat tego, jak korzystam z tej aplikacji i co sądzę o tym, czy co mnie boli. I czy to, co planują, by to rozwiązało. Już nie wchodząc w szczegóły, jak to się skończyło. Tak naprawdę, to w gruncie rzeczy była dosyć krótka rozmowa. Jeśli tylko ja miałem czas, to nie było znowu takie trudne. Wierzę w to, że w tym przypadku akurat osoby, które rozwijają ten system, po prostu dostały najlepszą możliwą informację bezpośrednio, a nie się do myślały albo bazowały na jakiejś wizji jakiegoś pośrednika z tamtej organizacji. 

Kuba: Druga porada, którą mamy tutaj w temacie tego, co można zrobić, żeby lepiej identyfikować potrzeby klienta, to porada o treści – Zadawaj właściwe pytania. Mamy tu na myśli przede wszystkim zadawanie pytań, ale też zadawanie pytań, które tutaj mocno zgłębiają kontekst, potrzebę klienta. To, po co stosuje to rozwiązanie. Przykłady takich pytań. To nie są uniwersalne pytania, wymienimy kilka. Na przykład to może być takie pytanie – Co zrobisz jak dostaniesz ten ficzer? Te pytania, które już wymieniłem z poprzedniego przykładu. Co cię boli, gdy korzystasz z mojego rozwiązania? Co chcesz zrobić? Co chcesz uzyskać dzięki mojemu produktowi? To mogą być takie pytania, które nie są wprost. Powiedz mi, jakie ma być rozwiązanie. To nie są pytania – Czego chcesz? Gdzie chcesz coś zmienić? Tylko bardziej staramy się zrozumieć otoczenie, kontekst. Słuchamy też tego, co klient mówi, w tym konkretnym kontekście. Przez przynajmniej chwilę powstrzymujemy się od razu z wyskakiwaniem, sugerowaniem przykładowej wyszukiwarki czy flagi w bazie danych, jak z naszych przykładów. Tylko najpierw próbujemy zrozumieć, gdzie ten klient jest. Co chce zrobić? Tego typu pytaniami dążymy. Próbujemy zrozumieć, gdzie i co możemy zrobić. 

Jacek: I wcale nie jest tak, że te kompetencje są dostępne w każdym zespole. Tak jak Kuba powiedział, te pytania nie są jakieś super trudne. Myślę, że do tego dodałbym jeszcze taki komentarz, że warto rozróżniać pytania otwarte od pytań zamkniętych. Wiedzieć, kiedy zadać takie, a kiedy zadać inne. Natomiast może jest tak, że ktoś w organizacji ma już takie kompetencje, bo na przykład wcześniej tego rodzaju pytania zadawał w jakichś kontekstach pracy z klientami. No i po prostu może pomóc w naszym zespole, albo dołączyć do zespołu nawet na jakiś, czas czy na te konkretne momenty, kiedy te pytania mogły być zadane, albo wesprzeć osoby, które będą zadawać takie pytania jakąś wiedzą. Może też na przykład jakieś krótkie warsztaty, czy jakieś krótkie szkolenie przeprowadzić. Tak więc nawet jak słyszysz to dzisiaj i myślisz sobie – Skąd miałbym, miałabym wiedzieć, co to są za pytania. No to pragnę uspokoić, że to naprawdę nie jest jakaś taka tajemna wiedza i przy odrobinie zaangażowania można do tej wiedzy dotrzeć. 

Jacek: Trzecia porada brzmi – Wchodź w buty klienta. Jeżeli pierwsza nasza porada, czyli to docieranie do klienta docelowego jest utrudnione z jakichś powodów, no to warto, chociaż starać się zrozumieć, jak myśli nasz klient. Czyli mamy tutaj na myśli wszelkiego rodzaju takie empatyzowanie. Gdybym był użytkownikiem, to czy chciałbym, żeby ten formularz tak działał? Albo, czy ten proces, gdybym miał go codziennie przeklikiwać, to czy jest intuicyjny? Tak więc zarówno ćwiczenie myślowe, jak i nawet konkretne techniki. Czyli przykładowo stworzenie sobie jakiejś persony. Próba trochę głębszego zrozumienia, kto jest naszym klientem, kto jest naszym użytkownikiem. Czy na przykład, po prostu przygotowywanie w rzetelny sposób User Story, czyli historii użytkownika? Gdzie jednak chwilkę się zastanowimy, kto jest użytkownikiem. Co tak naprawdę chciałby uzyskać, w jaki sposób?

Kuba: I to jest akurat ta sfera, w której są konkretne techniki. Jacek wymienił personę czy User Story. Ja do kompletu dorzucę Mapy Empatii. Czy na przykład taka koncepcja „Jobs to be done”, czyli taka rozmowa o tym, co tak naprawdę klient chce osiągnąć? Wyabstrahowana perspektywa konkretnego systemu. Ja chce coś kupić. Ja  chce coś zainwestować. A tak naprawdę dopiero potem jest to, że dostaje appkę do zakupów w internecie, albo appkę do inwestowania na giełdzie. I tak naprawdę to jest nieskończony katalog konkretnych praktyk, konkretnych technik. Zastosowanie jakiejś, albo kilku, moim zdaniem i tak będzie lepsze niż rozmowa w powietrzu, albo natychmiastowe wskakiwanie w gotowce, w jakieś rozwiązania, które pierwsze rozwiązanie, które komuś przyszło do głowy. Tutaj czasami ta perspektywa twórców nie będzie wystarczająco szeroka. No i być może trzeba się wprowadzić trochę w takie właśnie ćwiczeniowe formy, czy te warsztatowe formy i zasymulować, albo wyobrazić sobie tego klienta. W wielu zespołach, zwłaszcza takich wytwarzających oprogramowanie, które mają różnorodne kompetencje. Fajnie jeśli jest osoba, która patrzy bardziej na tę perspektywę. Może to jest jakiś projektant UX. Może to jest analityk, który umie poprowadzić tego typu warsztaty. Ale nawet w zespole, który takich osób nie ma, no to to są techniki, które nie są jakąś tam tajemną wiedzą. W gruncie rzeczy one są dosyć proste. Bardziej chodzi o to, żeby w ogóle dopuścić myśl o tym, że nasi klienci mogą nie rozumieć naszego systemu. Nasi klienci mogą być zmęczeni, zirytowani, albo obsługiwać naszą aplikację zgrabiałymi palcami, bo są z zawodu karierami i nie mają aż tyle czasu i takiej swobody postępowania, jak my mamy w naszym cieplutkim biurze albo w naszym przytulnym home office. 

Kuba: Czwarta rada to – Wnikaj w kontekst pracy. Tutaj mamy na myśli taką sytuację, w której do zespołu przychodzi jakieś całkiem dobrze dookreślone rozwiązanie. I na Product Owner skupia się na tym, żeby sformułować, co jest do zrobienia. Jakie są kryteria akceptacji. Może jakieś scenariusze. Jest dużo, dużo informacji na temat tego, jak coś zrobić, ale nie ma informacji dlaczego. Nie ma informacji, kim jest klient. Dlaczego to jest ważne dla klienta? I cała taka otoczka, która powoduje, że lepiej rozumiem, po co to mam zrobić. I to jest to na przykład to, co wspomniałem w tym przypadku ubezpieczeń, że w zasadzie tamten zespół dosyć precyzyjnie dostał informację, co mają zrobić. Tylko jakoś tego nie czuli. No bo nie czuli zupełnie, po co to jest biznesowo potrzebne. I też całkowicie w tym przypadku Product Owner odciął od tej sfery możliwego zaangażowania. Że kurcze, robimy coś wartościowego, robimy coś sensownego. To to jest po coś. I widzimy, i czujemy z tego dumę, albo potencjalną dumę, która nas czeka, gdy to zrobimy. Więc to wniknięcie w ten kontekst pracy, po pierwsze buduje to zaangażowanie, o którym mówiliśmy. Ale tutaj, jeśli jesteśmy w kontekście odcinka o zgłębianiu potrzeb klienta, no to ten kontekst, po co to robimy? Czemu ma to służyć? Jaki problem rozwiązać? Jakie ułatwienia zapewnić? To jest wszystko coś, co pozwoli nam w ogóle zacząć myśleć o tej perspektywie, że to jest po coś i być może dać okazję do tego, żeby zadać jakieś kolejne pytania. Zastanowić się, gdzie to wszystko może zmierzać. Czy nawet takie pytania, które może też nadają się do tej części o zadawaniu właściwych pytań? A jak sobie radzi użytkownik w tej chwili, gdy nie ma tego ficzera?. Albo, jak już mu udamy ten ficzer, to jak się zmieni jego zachowanie? Co mu się skróci? Co mu się uprości? Albo, co jeszcze będzie robił, gdy już skończy generowanie jakiegoś formularza albo eksport jakiegoś pliku?

Jacek: Tutaj te pytania mogą z różnym natężeniem pojawiać. Jeżeli to nie jest domyślna praca Product Ownera, że zaczyna od, dlaczego i od potrzeby, no to tych pytań może być więcej. Natomiast wielokrotnie spotykam Product Ownerów, którzy po prostu już domyślnie w ten sposób funkcjonują. Czyli po prostu zaczynają od wytłumaczenia kontekstu i jakby nie ma innego sposobu opowiedzenia. No, chyba że mówimy o czymś absolutnie jakimś takim niewymagającym myślenia drobiazgu. No to czasem po prostu jest jakiś większy konkret. Tak więc oczekiwanie od Product Ownera po prostu, że będzie w ten sposób pracował spowoduje, że tych pytań najprawdopodobniej będzie mniej. Bo to po prostu stanie się domyślny sposób naszej pracy i po prostu w ten sposób będziemy funkcjonować. 

Jacek: I ostatnia porada, którą mamy brzmi – Nie bądź zbyt przygotowany. To jest taka porada, trochę powiedzmy sobie studząca te wszystkie rzeczy, które powiedzieliśmy przed chwilą. Mianowicie ktoś może mieć pokusę, żeby wszystkie te rzeczy przygotować, rozpisać w bardzo dużym detalu. Przygotować już wspaniałe makiety. Często intencje stojące za takim przygotowaniem są bardzo fajne. Ale nadal tutaj mówimy o tym, że to jednak w czyjejś głowie się ta synteza dokonała. I może to jest tak, jak rozmawialiśmy krótkofalowo, interesująco, bo skróci rozmowy. Natomiast paradoksalnie może się okazać, że wcale nie. Że gdybyśmy przyszli do zespołu na wcześniejszym etapie trochę, to udałoby się wypracować coś innego. Może coś tańszego w wykonaniu, o takiej samej, bądź większej wartości. Ja jestem ogólnie dużym fanem podchodzenia do Refinementów, czyli do doskonalenia Backlogu Produktu, w taki sposób iteracyjny. Czyli normalne dla mnie jest, że Product Owner przychodzi i mówi – Słuchajcie jest taki i taki problem, coś takiego zidentyfikowaliśmy, albo z jakichś ankiet płynie nam feedback, że coś. Po pierwszej rundzie to zespół może po prostu pozadawać trochę pytań, i tyle. Na zasadzie dobra to Product Owner sprawdzi coś tam, UX sprawdzi coś, analityk coś. Deweloperzy też tam zajrzą w kod. No i się spotkamy za dwa dni, za trzy dni, za pięć dni. I już jesteśmy mądrzejsi. Już sobie możemy troszeczkę eksplorować. Dobra jakby to można było rozwiązać? Dwie, trzy, cztery iteracje, zależy od tematu, od tego jak nam idzie. I generalnie możemy mieć bardzo fajnie przygotowane rozwiązanie. A takim fajnym efektem ubocznym jest to, że jeśli zespół uczestniczy w tym, no to bardzo dobrze rozumie, czemu to rozwiązanie, czemu odrzuciliśmy inne. No i to jest wiedza, która przydaje się w przyszłości. No bo jednak podejmowanie decyzji opiera się też częściowo na tym, co już się wydarzyło. No i mamy to doświadczenie. Nie możemy powiedzieć, że jesteśmy obdarci z tego kontekstu. 

Kuba: I nawet gdyby się trafił taki niewysublimowany przypadek, że w zasadzie ten Product Owner na przykład przyniósłby już całkowicie rozpisane User Story, kryteria akceptacji i tu zespół nic by nie wymyślił innego, niż sam Product Owner wymyślił. To i tak moim zdaniem jest wartość w tym wszystkim, co Jacek opowiadasz, że dochodzimy do tego razem, dajemy sobie szansę. Czy na przykład odcinamy te takie negatywne możliwe zjawiska, że my tu jesteśmy od wykonania, my tu jesteśmy odcięci, my mamy zrobić dokładnie to, co nam zlecone? Więc częścią pracy zespołu takiego twórczego jest również to główkowanie razem. Nawet jeśli to dawkowanie razem i tak doprowadzi w niektórych przypadkach do tego samego rozwiązania, na które wpadłby na przykład doświadczony Product Owner, który bardzo dobrze zna produkt i klienta. Więc nawet jeśli to przygotowanie byłoby często trafne, to i tak też podpisuję się pod poradą – Nie bądź zbyt przygotowany. Zostaw trochę miejsca na to, żeby zespół razem z tobą mógł ten Backlog Produktu budować i tak naprawdę pewne rzeczy odkrywać razem, i się uczyć razem. A nie koniecznie mieć wszystko gotowe, podane na tacy, no i z pełnym odarciem niestety z tych różnych korzystnych zjawisk, o których wspominaliśmy.

Kuba: ale dla równowagi mamy takie małe zastrzeżenie. Na koniec à propos tych wszystkich porad, że jesteśmy w stanie sobie wyobrazić sytuacje, w których trochę szkoda zachodu i wkładania wysiłku, o którym tu mówimy. Zastosowania konkretnych technik, czy organizowania jakichś spotkań warsztatowych. Gdzieś jest pewnie dolna granica rzeczy, które są absolutnie standardowe. Absolutnie trywialne, takie bardzo podstawowe, tanie w realizacji. I może się zdarzyć, że jakiś prosty ficzer, który zajmuje tam godzinę, dwie roboty, być może nie ma co o nim dyskutować godzinę i dwie warsztatowo. No bo po prostu wyciągamy zbyt duże środki na zbyt łatwy problem. Więc na pewno jest gdzieś granica dolna rozsądku, by nie zgłębiać wielkiej potrzeby do rzeczy, które wydają się dość trywialne. Aczkolwiek sami mamy poczucie, że nawet rzeczy, które wydają się dosyć proste, mogą zasługiwać na zastanowienie się. Niestety każdy zespół musi sobie sam ocenić, gdzie jest ta granica i co to jest coś, co jest trywialne i niewymagające zgłębiania potrzeby klienta. 

Jacek: No i chyba jeszcze jeden komentarz do tego, co mówisz. To to, że to nazwijmy to szeroko, pogłębianie zrozumienia i generowanie rozwiązań, to można zrobić bardzo efektywnie i bardzo nieefektywnie. Więc tu na pewno w ciemno odsyłam do odcinka, w którym rozmawialiśmy między innymi o facylitacji spotkań. No, żeby po prostu, jeżeli już się zagłębiamy, inwestujemy czas, no to żeby to po prostu było efektywne. Nie ma nic gorszego niż poczucie, że spaliśmy godzinę i w sumie nie wiemy, gdzie jesteśmy. Nic nie zapisaliśmy, nic z tego nie wyszło. Nie wiemy, jakie są plusy minusy. Na pewno takie działanie spowoduje, że szybko usłyszymy – Wy tu chyba za dużo myślicie. No bo to będzie tak z boku widoczne, myślę bardziej w tę stronę. No i po prostu płyniemy do brzegu. Jednak ktoś tam będzie wam z boku przygotowywał, a Wy róbcie. Tak więc idąc tą ścieżką, którą tutaj polecamy, to równocześnie trzeba dbać o to, żeby to po prostu miało sens, żeby to przynosiło wartość, żeby to było po prostu zrobione w porządny, efektywny sposób. 

Kuba: Szybko sprawdziłem. Odcinek, o którym Jacek mówi to odcinek #049. Można znaleźć notatkę do tego odcinka pod adresem porzadnyagile.pl/49, gdzie poruszamy te wszystkie techniki, jak sprawić, żeby spotkania były efektywne. 

Jacek: Podsumowując. Jak można poprawić identyfikację prawdziwej potrzeby klienta? Pomijaj pośredników. Zadawaj właściwe pytania. 

Kuba: Wchodź w buty klienta. Wnikaj w kontekst pracy. Nie bądź zbyt przygotowany. 

Kuba: Ponownie zareklamuję swój warsztat Przypadki Scrumowe. W momencie, gdy nagrywamy ten odcinek, zostało dosłownie ostatnich kilka miejsc do dyspozycji. Więc jeśli zastanawiasz się, wahasz się, myślałeś lub myślałeś o tym, żeby się zapisać, ale się nie udało, no to przypominam o tym, że zapisy cały czas jeszcze trwają. Warsztaty odbędą się 16-17 maja. Na szczęście stacjonarnie w takim trybie, który uwielbiam, w Warszawie. A więcej informacji o samym warsztacie i zapisy na stronie 202procent.pl/przypadki-scrumowe

Jacek: Natomiast notatki do tego odcinka, docelowo artykuł, transkrypcję naszej rozmowy, a także zapis wideo, znajdziesz na stronie porzadnyagile.pl/85. 

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek. 

Jacek: Dzięki Kuba. 

Kuba: I do usłyszenia. Wkrótce.