13 kwietnia 2022Odcinki

Znajdowanie prawdziwej potrzeby klienta

Chcielibyśmy, żeby w swojej pracy wszystkie zespoły podchodziły do zrozumienia potrzeb klienta. Często tak nie jest i możemy wymienić Ci kilka powodów, choćby taki, że po prostu odgórnie nie mogą, albo nie mają ochoty. Dowiesz się, dlaczego warto dążyć do zidentyfikowania prawdziwych potrzeb. Skorzystaj z naszych kilku rad, żeby poprawić identyfikację prawdziwej potrzeby klienta.

Porządny Agile · #085 – Znajdowanie prawdziwej potrzeby klienta

Znalezienie i zrozumienie prawdziwej potrzeby klienta jest jednym z podstawowych elementów procesu tworzenia skutecznego produktu. Dlaczego jest to tak ważne i jak poprawić identyfikację potrzeb klienta?

Wiele zespołów niestety, zamiast wniknąć głębiej w potrzeby klienta, przechodzi od razu do szukania rozwiązania. Co jest powodem takiego podejścia? Jak je zmienić w zespole, aby potrzeby klienta były równie istotne, jak nasze doświadczenie i przekonanie o najlepszym w danym przypadku rozwiązaniu?

O zgłębianiu prawdziwej potrzeby klienta rozmawialiśmy już w odcinku #009 naszego podcastu, w którym podawaliśmy ją jako jedną z recept na dobry Refinement Backlogu Produktu. Dziś omówimy szerzej ten wątek, a do przesłuchania wspomnianego odcinka serdecznie Cię zachęcamy.

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

Jednym z przykładów sytuacji, o której mówimy w tym odcinku, jest zespół, który rozwijał system do zarządzania ubezpieczeń komunikacyjnych. Zespół miał dodać do systemu flagę. Otrzymał on 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 przyjmować ta flaga. Zespół długo dyskutował o szczegółach rozwiązania tego zadania, nie wiedząc za bardzo jaki był kontekst i powód jej 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ć jakieś bardzo korzystne rozwiązanie, unikalne na rynku, które będzie oznaczało, że te ubezpieczenia będą miały jakiś atrakcyjny pakiet, w którym kierowcy będą mieli i autocasco i assistance. Stąd pojawiła się potrzeba odzwierciedlenia w systemie, że jest możliwość skorzystania z jakiegoś ciekawego odrębnego ubezpieczenia. Natomiast rozdźwięk był dramatyczny między tym, że ustaw flagę w bazie, a tym, że chcemy zrobić bardzo unikalne ubezpieczenie i dlatego chcemy je mieć widoczne w systemie, w wydrukach, w raportach, w jakichś tam ofertach. Dopiero jak zespół wiedział, po co ma zrealizować to zadanie, to tak naprawdę zaczęła się sensowna rozmowa o tym, jak do niego podejść i je zrealizować.

Druga sytuacja, w której spotkaliśmy się z takim podejściem, to gdy do zespołu, w którym pracował Jacek, przyszedł Product Owner. Zaczął on opowiadać, że w jakimś tam miejscu w systemie, w takiej i takiej części administracyjnej, muszą wdrożyć wyszukiwarkę. Chciał on mieć sposobność wyszukiwać konkretne parametry opisujące jakieś konkretne produkty. Rozpoczęła się długa rozmowa o tej wyszukiwarce, jak często ją odświeżać, jak często indeksować, czy ma tam być możliwe zaawansowane wyszukiwanie. Dopiero po pewnym czasie zainteresowano się, po co mu tak naprawdę ta 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ł, jaka jest potrzeba Product Ownera, to zaproponował zupełnie alternatywne rozwiązanie, które można było zaimplementować w pół dnia, zamiast budować wyszukiwarkę, która byłaby trochę trudniejsza i bardziej czasochłonna.

To pokazuje, że trzeba zadawać pytania, trzeba próbować zrozumieć potrzeby, bo często może nas zaprowadzić do lepszych rozwiązań, nierzadko tańszych i bardziej dopasowanych do potrzeb.

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

Bazując na naszym doświadczeniu możemy wymienić 6 najczęstszych powodów pomijania etapu zrozumienia prawdziwej potrzeby klienta:

“Nikt nie powiedział, że możemy pytać” – W zespole brak jest świadomości, że mogą pracować, opierając się o jakąś konkretną potrzebę. Działają automatycznie, dostają informacje, co mają zrobić i to robią.
“Nie wolno nam” – Zespół jest tutaj ustawiony w takiej pozycji, w której próba zadawania takich 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ć. Może to być sytuacja w ramach własnej organizacji, gdzie dział IT nie jest traktowany jako partner do dyskusji i do kreowania rozwiązań. Może to być też sytuacja w interakcji zewnętrznej, np. jako software house, który dostarcza rozwiązania dla klienta, a kontrakt jest ustawiony tak, że mamy zrobić to, co klient zamówił i dyskutować, nie wnikać.
“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.
“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 koderów, do klepaczy kodu.
“Nie wiemy jak to zrobić” – W zespole brakuje kompetencji na poziomie zadawania pytań, facylitacji rozmowy czy wizualizacji pracy, ale też analizy konkretnych zagadnień i syntezy.
“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?

Z naszego punktu widzenia mamy 4 główne korzyści płynące ze znalezienia i zrozumienia potrzeb klienta.

Oszczędność czasu
Przed chwilą wspomnieliśmy, że zespoły nie wnikają w 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 dobre wniknięcie w prawdziwą potrzebę jest z dużym prawdopodobieństwem oszczędnością czasu w dalszych etapach. Czyli zespół może złapać tę właściwą potrzebę na wczesnym etapie rozwoju i rozwiązać aktualny problem w najwłaściwszy sposób i najkrótszą możliwą ścieżką.

Mamy tutaj nawiązanie do zasad stojących za Manifestem Zwinnego Wytwarzania Oprogramowania. Maksymalizacja pracy niewykonanej. I owszem, trzeba będzie poświęcić trochę czasu na to, żeby zadawać trochę pytań i pogłębić temat, ale unikniemy bezsensownej pracy i kilku rund poprawek.
Innymi słowy, zaoszczędzimy czas, inwestując go na odpowiednio wczesnym etapie w dobre przemyślenie tego, co jest do zrobienia.
Kreatywne pomysły
Dzięki temu nie ograniczamy się do jednego rozwiązania, które powstało w jednej głowie. Zapraszamy zespół do poszukania palety rozwiązań. 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. Z doświadczenia wiemy, że przeanalizowanie tematu przez zespół deweloperski, potrafi wywrócić nawet te pierwotne przemyślane pomysły.

Lepsze rozwiązania technologicznie
Dzięki swobodzie 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. Jest on w stanie zobaczyć rzeczy, które być może nie by przyszły do głowy zlecającemu zadanie.

Wyższe zaangażowanie w zespole
Ostatni, ale nie mniej ważny argument, to możliwość uzyskania wyższego zaangażowania w zespole.
Przede wszystkim w zespole wytwarza się poczucie współodpowiedzialności za produkt. Zespół nie jest już tylko podwykonawcą jakiegoś pomysłu, ale ma szansę zidentyfikować się z produktem. Ta współodpowiedzialność powoduje, że ludziom się po prostu chce działać. Zależy im, żeby ten produkt był dobry i chcą, żeby użytkownicy mieli fajne 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 niestety często napotykamy taką postawę obronną, gdzie zespół nie wie jak to zrobić, z kim miałby rozmawiać i czy ktokolwiek chciałby to zrobić.

Mamy świadomość, że czasem może być to trudne, jednak warto, chociaż zmniejszyć łańcuch pośredników pomiędzy klientem a zespołem developerskim.

Przykładowo, zamiast rozmawiać z Product Ownerem, można porozmawiać z interesariuszem, kimś z biznesu. To już pozwoli poznać szerszy kontekst. Dobrze byłoby też porozmawiać z kimś z Call center lub osobami, które mają bezpośredni kontakt z klientem i autentycznie korzystają z naszego systemu lub obsługują proces, na bazie którego my buduje jakieś narzędzia.

2. Zadawaj właściwe pytania
Mamy tu na myśli zadawanie pytań, które mocno zgłębiają kontekst i potrzebę klienta. Nie są to uniwersalne pytania, ale wymienimy 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?

Nie mogą to być jednak pytania typu: Czego chcesz? Gdzie chcesz coś zmienić? Starajmy się zrozumieć kontekst użytkownika. Pamiętajmy też, aby słuchać, co mówi rozmówca i powstrzymujmy 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, czyli to docieranie do klienta docelowego jest niemożliwa do realizacji, to warto, chociaż starać się zrozumieć, jak myśli nasz klient.

Chodzi tu o wszelkiego rodzaju empatyzowanie z użytkownikiem i postawienie się w jego sytuacji. Można stworzyć jakieś persony, 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ąć?

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

Chodzi tu przede wszystkim o to, żeby w ogóle dopuścić myśl o tym, że użytkownicy mogą nie rozumieć naszego systemu.

4. Wnikaj w kontekst pracy
Mamy tutaj na myśli sytuację, w której zespół otrzymuje całkiem dobrze opisane rozwiązanie. Product Owner skupia się na tym, żeby sformułować, co jest do zrobienia, jakie są kryteria akceptacji, dostarcza jakieś scenariusze. Zespół ma dużo informacji na temat tego, jak coś zrobić, ale nie ma informacji, po co ma to zrobić. Nie wie, kim jest klient, dlaczego to jest ważne dla klienta.

Product Owner odciął zespół od tej sfery możliwego zaangażowania i poczucia, że robimy coś sensownego i wartościowego.

Zatem to wniknięcie w ten kontekst pracy, po pierwsze buduje zaangażowanie, o którym mówiliśmy. Po drugie, pobudza to 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 się uprości?

5. Nie bądź zbyt przygotowany
Jest to porada trochę studząca wcześniej przytoczone wskazówki. Najbardziej kierujemy ją do Product Ownerów. Chodzi o to, aby przyhamować pokusę przygotowania wszystkich informacji z dużym poziomem szczegółowości. Teoretycznie może to skrócić rozmowy, jednak pamiętajmy, że to jednak przygotowała tylko jedna osoba. Natomiast, gdyby na wcześniejszym etapie porozmawiać z zespołem, to jest duża szansa, że udałoby się wypracować coś innego, może coś tańszego, może coś o większej wartości.

Zachęcamy do podchodzenia do Refinementów, czyli do doskonalenia Backlogu Produktu, w sposób iteracyjny. Czyli tutaj Product Owner przychodzi do zespołu i przedstawia jaki problem został zidentyfikowany. W szukanie rozwiązania zaangażuje się też UX designer, analityk i deweloperzy. Zespół lepiej rozumie wypracowane rozwiązanie, jest też bardziej zaangażowany w jego wdrożenie, a zdobyta wiedza często przydaje się też w przyszłości.

Na koniec naszych rozważań dotyczących poznawania prawdziwych potrzeb klienta musimy powiedzieć, ż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 przykładowo mamy do realizacji jakieś bardzo podstawowe i trywialne rozwiązanie, które zajmie jedną lub dwie godziny i szkoda czasu na długie dyskusje czy warsztaty. 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. Tu już musicie sami ocenić, gdzie leży ta dolna granica, przy której nie ma sensu zbytnio zgłębiać zagadnienia.

Przy okazji, zachęcamy Cię do przesłuchania odcinka o facylitacji spotkań (odcinek #049), gdyż pogłębianie zrozumienia i generowanie rozwiązań, można zrobić bardzo efektywnie i bardzo nieefektywnie. Nie ma nic gorszego niż poczucie, że straciliśmy godzinę na spotkanie, a w sumie nie wiemy, gdzie jesteśmy. We wspomnianym odcinku omawiamy różne techniki pozwalające uniknąć takiej sytuacji i pomagające w przeprowadzaniu efektywnych spotkań.

Podziel się w komentarzu Twoimi przemyśleniami na temat znajdowania prawdziwych potrzeb klienta. Być może znasz jeszcze jakieś wskazówki ułatwiające identyfikację potrzeb klienta?

Dodatkowe materiały

Porządny Refinement
Facylitacja spotkań

TRANSKRYPCJA

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.