A co, gdy klient się myli?

Ostatnio dużo dyskutujemy o wartości i o tym, w jaki sposób najlepiej pomóc naszemu klientowi. Co jednak zrobić w sytuacji, w której trafiło do nas wymaganie, które nie tylko zawiera błędne założenia, ale wręcz wiemy, że jego realizacja zaszkodzi naszemu odbiorcy? Co zrobić, gdy klient się myli?

 

Opowieść niewigilijna

Każdy zna tę historię, opowiedzianą w taki czy w inny sposób. Wyobraźmy sobie konsultanta, który doradza osobom na wysokim szczeblu w wielkiej korporacji. Na podstawie jego analiz zarząd zawsze podejmuje decyzje, przeważnie dobre. Nasz konsultant jest więc poważany i uznawany za pożytecznego, a do jego rąk trafiają coraz trudniejsze sprawy.

Pewnego dnia, po kolejnej prezentacji na stronę bierze go sam prezes, który mówi “Wykonujesz dla nas świetną robotę, ale zauważyłem, że za każdym razem pokazujesz nam do wyboru dwie bardzo podobne opcje. Zwykle jedna z nich jest w jakimś zauważalnym stopniu lepsza. Rozumiem, co robisz, ale chciałbym, żebyś następnym razem przygotował po prostu jedną, najlepszą propozycję.”

Konsultant nie potrafi odmówić prezesowi. Zresztą, dlaczego miałby? Kolejna sprawa, kolejne analizy i kolejna prezentacja. Konsultant przychodzi z optymalnym rozwiązaniem, przedstawia je przed zarządem, który oczywiście zgadza się na wszystko.

Jakiś czas później konsultant zostaje wezwany na rozmowę do prezesa, podczas której zostaje zwolniony. Zdziwieni? Jeszcze dziwniejsze jest wyjaśnienie prezesa:

“Nie chodzi o to, że źle wykonałeś swoją pracę, ale że nie czuję się jakbym to ja podejmował decyzję. Wyglądało to tak, jakbyś mi mówił co mam robić, a to moja firma.”

 

Nieracjonalne zachowanie to norma

Czy nasz konsultant z opowieści powinien zignorować prośbę prezesa i nadal przedstawiać mu dwie propozycje? Czy w takiej sytuacji nadal miałby tę pracę? I czy w ogóle jest to normalne otoczenie? Ktoś przecież może powiedzieć, że prezes zachował się zupełnie nieracjonalnie. W takiej sytuacji praca w takim miejscu nie ma w ogóle sensu!

Tak mogą jednak powiedzieć tylko niedoświadczone osoby. Wykonując pracę na rzecz innych osób nie sprzedajemy tylko produktu, ale też i siebie, a przede wszystkim – emocje. Jeżeli podczas korzystania z naszego rozwiązania wszyscy wpadną w euforię, to nikt nie będzie zwracał uwagi na braki w funkcjach, które i tak były zbędne. Jeżeli jednak zagramy komuś na nosie ignorując wymagania, albo damy komuś poczuć, że decydujemy za niego, to urażona duma przykryje wymierne korzyści.

Nieracjonalne? Wystarczy sięgnąć po genialne “Thinking, Fast and Slow” Daniela Kahnemana czy “Predictably Irrational” Dana Ariely, żeby przekonać się, że z racjonalnością rodzaj ludzki nie ma za wiele wspólnego. Na nasze decyzje wpływają nasze przekonania, lęki, emocje, błędy poznawcze i wiele innych czynników. Rzadko kiedy podejmujemy optymalne decyzje, za to świetnie potrafimy wytłumaczyć sobie i innym dlaczego wybrane przez nas rozwiązanie jest najlepsze.

Nawet jeśli nie jest.

Product Owner, czyli mistrz perswazji

Tak jak często mówimy, że Scrum Master powinien być psychologiem, tak tym bardziej Product Owner powinien być mistrzem perswazji. Bo to Product Owner najczęściej komunikuje się z interesariuszami na wysokim poziomie. Jeżeli ktokolwiek ma kogoś przekonać, że dana funkcjonalność to strata czasu i pieniędzy, to będzie to właśnie PO.

Zgodnie jednak z przytoczoną opowieścią, wspomnianymi książkami i praktyką życiową, Product Owner nie może po prostu powiedzieć “to wymaganie jest bez sensu, lepiej zrób tak”. Takie postawienie sprawy w każdym wywoła odruch obronny i automatyczną obronę naszej decyzji. Nawet tej błędnej.

Product Owner musi tak pokierować rozmową z interesariuszami, żeby to od nich wyszła potrzeba zmiany wymagań i dostosowania ich do realiów. Co prawda my jesteśmy ekspertami i zwykle mamy większe doświadczenie niż zamawiający, ale nie możemy się szarogęsić i pokazywać tego na każdym kroku. Musi się to zadziać w subtelny sposób. Jeżeli w tym momencie komuś przypomniał się film “Incepcja”, to świetnie, bo właśnie o to nam chodzi.

Nie da się ukryć, że nieocenioną pomocą dla PO jest dostarczone MVP, którego odbiorcy mogą zacząć używać (a nie testować!). Gdy na własnej skórze przekonają się, że “to nie o to chodzi”, łatwiej będzie im podjąć decyzję o konieczności zmiany. Ale nawet i bez tego, zadając konkretne pytania, wspólnie analizując sposób działania organizacji, procesy i przypadki użycia możemy spowodować, że druga strona zacznie zastanawiać się “czy to na pewno będzie dla nas przydatne”.

Jak najbardziej podpowiadajmy różne rozwiązania, pokazujmy jak one będą wyglądały oraz jakie są ich plusy i minusy. Powstrzymujmy się jednak od oceniania pomysłów lub podejmowania decyzji za drugą stronę. Nakierujmy, ale nie popychajmy. Pamiętajmy, że celem zwinności jest “zadowolenie klienta”, a nie “zmuszenie go, żeby się cieszył”.

Uparty klient

Czasami zdarza się też, że trafimy na kogoś naprawdę upartego, do kogo nie trafią żadne argumenty. Uprze się, i koniec. “Moje pieniądze, moje decyzje, ma być po mojemu.”

To tak zwany “trudny klient”, bardzo często występujący pod pseudonimem “zamówienie publiczne”. Szczególnie bowiem przy przetargach często trafiamy w pułapkę zamrożonych wymagań. Zamiast utrzymywać zmienny backlog, mamy stałą i niezmienną listę rzeczy do zrobienia, zdefiniowaną na początku projektu. Czasami nawet miesiące albo – o zgrozo – lata wcześniej.

Zawsze będę stał na stanowisku, że nie należy robić rzeczy bezużytecznych. Jeżeli realizujemy bezsensowne wymaganie, to już samo zapisanie go w postaci User Story “jako (…) chcę (…) aby spełnić kryteria określone w przetargu” pozwoli Zespołom Deweloperskim na odpowiednie potraktowanie takiego zapisu. Mamy nadzieję, że dla takich wymagań zrobią MVP, czyli funkcjonalność “tylko działającą”, bo i tak wiemy, że jej jedyne użycie nastąpi podczas odbioru projektu. Nie spędzajmy nad nią nie wiadomo ile czasu. Zamiast ją dopracowywać, zróbmy te bardziej przydatne rzeczy. Klient na pewno się ucieszy, gdy dostanie “więcej”.

Nawet jeśli jesteśmy pewni, że dana opcja nigdy nie zostanie włączona, to nie możemy sami zadecydować o jej pominięciu. To nie my zamawiamy produkt, ani nie my za niego płacimy. Możemy przekonać osoby decyzyjne, że warto iść w zaproponowaną przez nas stronę, ale jak zwykle w takich sytuacjach najlepiej sprawdzi się pokazanie dwóch (lub więcej) dróg, wśród których jedna będzie w oczywisty sposób lepsza. Pozwólmy klientowi dokonać zmiany wymagań. Niech czuje, że to jest jego decyzja i że to on znalazł lepsze rozwiązanie problemu.

Jeżeli naprawdę zależy nam na “zadowoleniu klienta”, możemy nawet udać lekki opór przed zmianą wymagań tak, aby “wygrana” drugiej strony była jeszcze większa. Ale to już oczywiście sztuczki, na które przy zdrowej współpracy nie ma miejsca.

Wierzę, że w większości przypadków nasz klient, który stanie przed wyborem “stracić w imię zasad” bądź “zyskać przyznając się do pomyłki” nie będzie miał żadnych wątpliwości. Takich klientów życzę sobie i Wam.

Tomasz Dzierżek

17 lat doświadczenia w IT, 9 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: