Kilka pytań dot. dobrej współpracy UXa i Product Ownera – pytania z Agile Silesia #12

Wczoraj na Agile Silesia #12 miałem wielką przyjemność opowiedzieć o moich doświadczeniach ze współpracy z Product Ownerami, z którymi pracowałem przez ostatnie 7 lat. Była to polska wersja wykładu, który już wcześniej prowadziłem na Agile by Example 2015 i Product Development Days 2015. Zainteresowanych odsyłam do slajdów i nagrania z ABE15.

Podczas wykładu, który planowo miał trwać około 20 minut, a razem z dyskusją przeciągnął się do godziny, padło wiele bardzo dobrych pytań. Bardzo Wam za nie dziękuję. Trzy z nich postanowiłem dodatkowo omówić na blogu.

„Common” approach:

Zrzut ekranu 2016-02-03 o 23.28.19

„Caring” approach:

Zrzut ekranu 2016-02-04 o 08.47.31

1.Czy to aby nie Scurm Master, albo Agile Coach powinni wyjaśnić głównym zainteresowanym jaki jest zakres odpowiedzialności Product Ownera i UX Designera, a potem przypilnować, by osoby w tych rolach robiły to co do nich należy? Czy wtedy, zaprezentowany przez Ciebie model dalej ma sens? Dodatkowo, czy model nie jest oparty tylko na Twoich doświadczeniach, przez co może nie sprawdzić się w innym kontekście? 

Bardzo dziękuję za te pytania. Wszystko, o czym opowiedziałem na wykładzie to moje osobiste doświadczenia. Nie lubię nie swoich case’ów, a przez ostatnich 7 lat udało mi się zebrać ich na tyle dużo, że mogę długo o nich opowiadać. To, co jest bardzo celne w tym pytaniu, to fakt, że specyfika firmy, w której pracowałem i relacje biznesowe z klientami, w jakich uczestniczyłem, nie są podręcznikowe, ale mocno życiowe. Wykład odnosił się do specyficznego kontekstu mojej pracy, dlatego z pewnością część problemów, o których opowiadałem w innym kontekście mogłoby być rozwiązanych przez dobrego Scrum Mastera, czy Agile Coacha.

W innym kontekście, taki Scrum Master mógłby spokojnie pomóc określić zakres odpowiedzialności i przypilnować, by każdy w zespole robił to w czym jest najlepszy i sprawnie tworzył wartość dla produktu. Wtedy zaprezentowane przeze mnie wskazówki nie musiałyby być aż tak istotne, ponieważ niedopowiedzenia czy ryzyko konfliktu na linii UX Designer – PO byłyby minimalizowane przez podejmowane przez Scrum Mastera działania.

Jednak w złożonych relacjach biznesowych, w których uczestniczyłem, gdzie zespół był rozproszony nawet po kilku krajach, sam klient (PO) był na stałe np. w Wielkiej Brytanii i dodatkowo projekty nie były robione w czystym Scrumie, wtedy, by praca szła do przodu, należało się skupić na zbudowaniu dobrej relacji, a nie na twardym trzymaniu się swojej roli.

Z moich doświadczeń w takich projektach, UX Designer często wchodził w rolę proxy PO (sic!). Podchodząc do ustawienia współpracy w taki sposób, jaki zaprezentowałem podczas wykładu, UXowiec zaczynał odgrywać kluczową rolę w projekcie.

Rzeczywistość, którą poznałem często uciekała podręcznikom i dobrym praktykom, które z powodzeniem działają w wielu przypadkach, za to wymagała dużej pokory i wielu długich tygodni, a nawet miesięcy budowania opartej na zaufaniu relacji z Product Ownerem.

2.Czy model, który pokazujesz, odnosi się też do innych ról w projekcie, np. developerów albo testerów?

Tak. To jest bardzo prosty i zdroworozsądkowy model, który można zastosować do wielu ról projektowych. Ba, można na nim oprzeć bardzo wiele innych sytuacji, gdzie współpracują / współegzystują ze sobą ludzie. Pewnie jakby się dobrze zagłębić w literaturę, albo przeszukać internet, to można by znaleźć podobny model, tylko pewnie dotyczący innego kontekstu. To co jest w nim najważniejsze, to wskazanie, że pokrywające się kompetencje, wcale nie muszą prowadzić do konfliktu. Natomiast, mogą, a nawet powinny prowadzić do synergii.

3.Skąd mamy dowiedzieć się o rzeczach, o których istnieniu nie wiemy, a które mogą być istotne dla sukcesu produktu?

Podczas wykładu zaznaczyłem, że w ramach współpracy należy mocno skupić się na tym, by jak najszybciej identyfikować niewidoczne zagadnienia, które mogą okazać się bardzo istotne dla sukcesu produktu.

Na początku każdego projektu większość rzeczy, które określamy jako istotne, to tak naprawdę nasze założenia. Rzeczy, których jesteśmy naprawdę pewni jest bardzo niewiele. Dodatkowo, na samym początku wymagania są najczęściej wysokopoziomowe i dosyć trudno jest stwierdzić, czy są one w ogóle poprawne. Zwinne metodyki odgrywają dużą rolę w ograniczaniu niepewności związanej z poprawnością wymagań, ponieważ umożliwiają ich dosyć szybką weryfikację. Dodatkowo, badania i prototypy wykonywane przez UX Designerów pomagają tę niepewność jeszcze szybciej i jeszcze taniej zmniejszać.

Jak się dowiadywać o rzeczach, o których nie wiemy? Jak to powiedział Steve Blank: „In a startup no facts exist inside the building, only opinions.”  Dlatego polecam, by tak często jak to możliwe, rozmawiać z użytkownikami, budować prototypy,  testować je z udziałem użytkowników, a następnie wyciągać z tych testów wnioski. Dzięki temu będziemy szybciej podejmować właściwe decyzje biznesowe. Dobrze prowadzony proces projektowy i świadome wsłuchiwanie się w to, co mówią do nas użytkownicy, pozwala nam poznać ich potrzeby. Rozumiejąc te potrzeby możemy budować produkty, które mają szansę odnieść rynkowy sukces.

12654507_1011335485603655_1989787995538281329_n

Bardzo dziękuję za wszystkie pytania. Było mi na prawdę miło uczestniczyć w 12-tej edycji Agile Silesia. Do zobaczenia!

Spotyka się Projektant z Klientem – część 3: Świadomość braku pewności.

Część pierwsza: Tak niewiele wiem.
Część druga: Wydaje mi się że…

Projektant

Rozmowa trwa już od ładnych kilku godzin. Odbierasz Klienta jako bardzo wartościową i pełna pasji osobę. Coraz lepiej zaczynasz też rozumieć jego potrzeby. Widzisz również, że Klient bardzo często mówi o rozwiązaniach, nie skupiając się na istocie problemu. Oczywiście, rozwiązania dla części wyzwań wydają się dosyć trywialne, jednak widzisz też problemy, których rozwiązanie będzie wymagało więcej czasu i uwagi, a Klient stawia sprawy twardo. Zależy mu na szybkich efektach. Wiesz, że nie tylko o szybkość wprowadzania zmian chodzi, ale przede wszystkim o ich skuteczność.

Dobrze zdajesz sobie sprawę z tego, że:

  • poruszacie się w świecie założeń i niezweryfikowanych hipotez, mimo, że klient uważa wszystko co mówi za pewnik,
  • działacie w warunkach skrajnej niepewności, mimo, że klient mówi, że zna biznes i ludzi,
  • świat, na okres tej współpracy, nie zatrzyma się w miejscu, i nie zaczeka na wdrożenie rozwiązania – w trakcie współpracy jeszcze wszystko może się zmienić,
  • albo ty i Klient będziecie blisko współpracować, albo cała ta zabawa nie będzie miała sensu.

Wiesz, że możesz poprowadzić tę współpracę dwiema drogami:

  1. Zaczniecie budować iluzję zrozumienia problemów. Skupisz się na formułowanych przez Klienta wymaganiach i zaprojektujesz dla niego to czego chce.
  2. Zaczniecie pracować nad tym, by dokładnie zrozumieć problemy, z którymi mierzy się Klient i zaprojektujesz dla niego to czego naprawdę potrzebuje.

Proponujesz podejście drugie, ponieważ wiesz, że to jest jedyna słuszna droga. Szanujesz Klienta, jego wiedzę i doświadczenie. Z pokorą patrzysz na swoje obecne doświadczenia, jednak to czego jesteś bardziej niż pewny, to fakt, że tak wczesnym etapie pracy, niczego nie można być pewnym. Mimo, że wiele rzeczy może wydawać się oczywistych, to jednak z pełną świadomością proponujesz Klientowi uczciwe podejście, oparte na współpracy i zaufaniu. Nie starasz się sprzedać mu marzeń, nie chcesz projektować rozwiązań, które będą ‚jakoś’ działać i dawać ‚jakąś’ wartość. Chcesz rozwiązać problemy Klienta. Jeżeli współpraca dojdzie do skutku, będziesz miał sporo pracy, by udowodnić wartość proponowanego podejścia i zbudować zaufanie.

Klient

Czujesz lekkie zdziwienie i zagubienie. Liczyłeś na to, że Projektant będzie od razu wiedzieć co zmienić, że zaprojektuje to o co go poprosisz. On natomiast otwarcie ci mówi, że nie wie jakie rozwiązanie jest najlepsze. Mało tego, przekonuje cię do tego, żeby zupełnie nie mówić w tej chwili o rozwiązaniach. Twierdzi, że ciężko jest określić, czy to gdzie chcesz iść, jest tym samym miejscem, gdzie naprawdę chcesz być. Dziwi cię to, że Projektant, zamiast zgodzić się na to, o co go prosisz (w końcu mu płacisz), zaczyna twierdzić, że to co uważasz za problem i to co proponujesz, by ten problem rozwiązać, to tylko założenia i hipotezy, które dopiero trzeba zweryfikować. Że trzeba zrozumieć cele i potrzeby wszystkich interesariuszy. Zastanawiasz się, kogo on ma na myśli? Twoich pracowników, może klientów? Może ich wszystkich na raz? Mówi ci, że trzeba do tego podejść ‚zwinnie’ i że w ramach jego pracy będzie chciał prowadzić dużo małych eksperymentów, które pozwolą weryfikować, czy przyjęty kierunek jest słuszny, czy trzeba go zmodyfikować. Że niby to „zwinne” i „szczupłe” podejście oparte na szybkiej weryfikacji założeń da lepsze rezultaty. Na końcu mówi ci jeszcze, że nie sprzedajesz produktów, tylko doświadczenia. Przecież sam najlepiej wiesz, co sprzedajesz.

Mimo, że spodziewałeś się czegoś zupełnie innego, to czujesz lekki dreszczyk emocji i sporą ciekawość. Ten cały Projektant, mimo że mówi o czymś innym, niż to co chciałeś usłyszeć, to w sumie mówi z sensem. Nawet zaczyna cię bawić fakt, że założyłeś przed spotkaniem jego efekt, a to co słyszysz jest zupełnie czymś innym niż zakładałeś. To tylko potwierdza słowa, które przed chwilą powiedział do ciebie Projektant, że nie można z góry nic zakładać i przewidywać wyników podejmowanych działań, jednak można tak zweryfikować pomysły, które chcemy wdrożyć w życie, zwiększając w ten sposób szanse, że ich wdrożenie da zamierzone efekty.

Czujesz, że może ten cały „UXowiec” ma rację i zanim zrobisz kosztowną rewolucję w swojej firmie, warto zweryfikować te wszystkie pomysły i zobaczyć co tak na prawdę jest ważne i wartościowe, a co tylko wydaje się takim być. Decydujesz się zagrać na jego zasadach, bo zaczynasz czuć, że gość wie co mówi i od początku jest z tobą szczery, mimo że z pewnością jest świadomy tego, że postawienie spraw w ten sposób teoretycznie mogło go kosztować utratę kontraktu.

Zaczynacie współpracę…

Epilog

Tę krótką, trzy częściową historyjkę napisałem na podstawie swoich doświadczeń ze współpracy z klientami, z którymi miałem przyjemność pracować przez ostatnie kilka lat. Oczywiście nie od razu wiedziałem o rzeczach, o których piszę w tym tekście. Gdy 5 lat temu zaczynałem swoją przygodę z User Experience to mimo wielkich chęci i dobrych intencji w stosunku do klienta, projektu, zespołu z którym pracowałem, popełniałem błędy. Często skupiałem się mocniej na rozwiązaniu jakie wymyśliłem niż na problemie i osobach, których problem dotyczył. Skutki takiego podejścia szybko wychodziły. Najlepiej były widoczne w projektach software’owych, gdzie jako projektant UX zajmowałem się głównie pisaniem specyfikacji produktu dla klienta i developerów oraz projektowaniem interfejsu aplikacji. Niezweryfikowane wcześniej hipotezy w końcu weryfikowała rzeczywistość, co często okazywało się niezwykle kosztowne.

Dojście do opisanych w tekście przemyśleń, ich zrozumienie i praktyczne zastosowanie we współpracy zajęło mi sporo czasu. Nie od nauczycieli akademickich, współpracowników czy autorów książek, tylko od klientów, z którymi miałem okazję współpracować, dostałem te najbardziej wartościowe lekcje, które pozwoliły mi się rozwinąć w roli projektanta. Z pewnością jeszcze sporo lekcji przede mną i chwil, w których będę musiał zdążyć na 9 rano na spotkanie, by rozpocząć nową, ciekawą współpracę.

Spotyka się Projektant z Klientem – część 2: Wydaje mi się że…

Część pierwsza: Tak niewiele wiem.

Klient

Spotkanie ma rozpocząć się o 9 rano w twoim biurze. Sekretarka powiedziała ci, że Projektant przyszedł wcześniej i że czeka już na ciebie w sali konferencyjnej. Plus dla niego. Nie lubisz jak ludzie spóźniają się na spotkania. Punktualność i terminowość przede wszystkim. To właśnie dzięki trzymaniu się wyznaczonych terminów udało ci się przez ostatnie 7 lat z małej, jednoosobowej firmy zbudować dobrze działające, stuosobowe przedsiębiorstwo.

Niby wszystko jest dobrze. Biznes kwitnie, klienci są zadowoleni, pracownicy też nie narzekają, jednak od dłuższego czasu czujesz, że nie wszystko działa jak należy. Niestety, sam do końca nie wiesz, gdzie leży problem. Z jednej strony znasz ten biznes jak mało kto. Z drugiej jednak strony czujesz, że nie jesteś w tym miejscu, w którym chcesz być. Coś ci w tym wszystkim nie gra. Może procesy wewnętrzne w firmie nie działają tak jak należy? Masz poczucie, że tracisz nad nimi kontrolę. Dwóch klientów, o których myślałeś, że zostaną z tobą na zawsze, przeszło ostatnio do konkurencji, która powoli zaczęła cię doganiać. Ba, w przypadku kilku produktów, już zdążyła cię przegonić. Mimo, że sytuacja wciąż wydaje ci się stabilna i do opanowania, chcesz coś zmienić.

Od kilku osób słyszałeś o korzyściach wynikających z pracy z projektantem. Twój dobry znajomy dzięki takiej współpracy wyprowadził swoją spółkę ze sporych kłopotów. Do tej pory nawet nie zakładałeś, że ktoś z zewnątrz może ci się przydać, przecież sam najlepiej wiesz czego chcą twoi klienci i w jaki sposób poukładać pracę w firmie. Ostatnio jednak doszedłeś do wniosku, że warto spróbować. Może jak ktoś spojrzy na to wszystko szerzej, z zewnątrz, to zauważy rzeczy, których ty, będąc tutaj w środku, nie jesteś w stanie dostrzec.

Nie masz pojęcia jak ci projektanci pracują. Do tej pory projektant kojarzył ci się albo z architektem, albo z grafikiem. Nigdy z osobą, której głównym zadaniem jest rozwiązywanie problemów. W ogóle ten cały design, to coś czego jeszcze nie do końca rozumiesz, ale czujesz, że to ma wartość i że to bardziej zasada działania, niż wygląd. Przeczytałeś w sieci, że projektanci obserwują jak działa firma, rozmawiają z pracownikami, klientami, proponują różne usprawnienia wewnątrz organizacji, potrafią projektować produkty i usługi, a nawet czasami proponują zmianę modelu biznesowego, mimo, że nie znają się na danym biznesie. Podobno jakoś na ludziach się bardziej skupiają, na ich potrzebach, celach. Mają swoje techniki, żółte karteczki, narzędzia. Bawi cię, jak również trochę irytuje, że ostatnio nic nie może się już normalnie nazywać: UXowcy, Service Designerzy. Jakby nie było polskich nazw? Z resztą, i tak uważasz, że najważniejsze, żeby ten cały UXowiec był skuteczny, a niech nazywa się tak jak chce.

Za chwilę masz wejść do sali konferencyjnej. Agenda poszła wcześniej mailem. Jeszcze raz układasz sobie w głowie, to o czym chcesz opowiedzieć podczas pierwszego spotkania. Wydaje ci się że wiesz dużo, jednak to, czym tak na tę chwilę dysponujesz, to:

1. Wiedza o biznesie – wiedza domenowa.

Klient zna biznes i trudno, żeby projektant rozumiał zasady i procesy działania danego biznesu lepiej od swojego klienta. Niestety, często zdarza się, że klient nie ma wiedzy na temat swoich klientów (odbiorców / użytkowników swoich produktów i usług). Wiele z jego decyzji biznesowych wynika z ogólnej znajomości rynku i konkurencji, rutyny, intuicji, podążania za trendami, a dużo rzadziej z dobrej wiedzy i zrozumienia potrzeb swoich odbiorców. Podobnie jest z decyzjami i działaniami dotyczącymi zarządzania samą firmą i ustawianiem procesów wewnątrz organizacji – czasem więcej w tym magii i założeń, niż faktycznych danych. A organizacja pracy wewnątrz jest dla firmy równie istotna co wartość usług / produktów proponowanych na zewnątrz.

2. Przemyślenia na temat obecnej sytuacji i problemów.

Owe przemyślenia, to tak naprawdę refleksja klienta na temat aktualnie doświadczanego stanu. Klient odczuwa brak komfortu wynikający z danego stanu rzeczy: np.:

  • pracownicy narzekają na istniejący system IT, który ma usprawniać ich pracę,
  • klienci odchodzą,
  • konkurencja ma bardziej atrakcyjną ofertę,
  • firma szybko urosła i jest w niej teraz spory bałagan, który przynosi spore straty,
  • klient chciałby zwiększyć zyski firmy, bo obecne są niewystarczające etc.

Czasem, wszystko wydaje się być OK, oprócz tego, że klient czuje że chce być ze swoją firmą w innym miejscu, więc np. szuka nowych możliwości biznesowych, albo wdraża jakiś nowy produkt do swojej oferty etc.

Jeżeli klient uważnie słucha, co mówią do niego ludzie (pracownicy, użytkownicy), tym lepsza jego wiedza o tym co w jego biznesie jest tak na prawdę ważne. Jeżeli wszyscy powtarzają że dany element biznesu nie działa jak należy, to nie potrzeba wielkich badań i rozkmin, żeby zauważyć, że coś w tym miejscu jest nie tak i trzeba się pochylić nad tematem.

Dobrze jest też wziąć poprawkę na to, że czasami coś co klient określa jako źródło problemu, może być tylko i wyłącznie jego subiektywnym, niczym nie podpartym założeniem. Nie, opinia trzech najbliższych współpracowników, nie sprawi, że przyczyna problemu będzie lepiej zdefiniowana. To dalej będzie subiektywna opinia, którą trzeba będzie zweryfikować, poprzez zderzenie jej z rzeczywistością, która najczęściej jest bardzo poplątana i zależna od wielu czynników. Refleksje klienta i jego współpracowników, to bardzo cenne insighty, które stanowią dużą wartość w procesie projektowym, jednak to jeszcze nie wszystko. Rolą projektanta jest zebrać możliwie dużo istotnych informacji, które w najpełniejszy sposób opiszą kontekst i pozwolą określić wyzwanie projektowe. Nie mówię oczywiście o tym, że należy przepalać czas na analizę rzeczy nie istotnych, tylko o tym, że należy skupić się na naturze (przyczynach) wyzwań i problemów klienta, zanim weźmiemy się za ich rozwiązywanie.

Bardzo istotne jest też, by opierać się na sprawdzonych danych, których klient często nie ma i które trzeba dopiero zebrać. O technikach zbierania danych napiszę w przyszłości osobny post.

Podsumowując, niezależnie skąd pojawił się u klienta bodziec do poszukiwania zmiany, na samym początku stan obecny definiowany jest przez subiektywne doświadczenia / przemyślenia klienta oraz dane (które są, lub które trzeba zdobyć). Stan obecny to nasz punkt wyjścia.

3. Wstępna wizja tego, gdzie chcesz się znaleźć.

Zmiana, którą chce wdrożyć klient to przejście ze stanu A, w którym obecnie znajduje się do stanu B, w którym chce się znaleźć. Stan B to jednak tylko wyobrażenie klienta na temat przyszłego doświadczenia. Całe wyzwanie przed którym stajemy jako projektanci, to zrozumienie:

  • czym dokładnie jest stan A (jak działa, kto w nim funkcjonuje, jakie są jego mocne i słabe strony, etc.)
  • czym ma być stan B (co ma się zmienić w stosunku do stanu A, a co ma pozostać niezmienione, jakie mają być korzyści wynikające ze znalezienia się w stanie B etc.)

To, co trzeba wziąć mocno pod uwagę i na co trzeba wyraźnie uczulić klienta, to fakt, że nie zawsze, to co początkowo wydaje mu się stanem pożądanym, faktycznie jest tym gdzie klient chce się znaleźć. Sprawa jest o tyle złożona, że nie jest łatwo określić czy miejsce B jest fajne / niefajne, dopóki się tam nie znajdziemy i tego nie stwierdzimy. UX design ma sporo technik, które pozwalają lepiej doprecyzowywać miejsce B. O tym w kolejnych postach.

Kolejna ważna rzecz: Zmiana, o której myśli klient, często niesie za sobą sporo wyzwań.

Czasami klient od samego początku myśli rozwiązaniem np. chce wdrożyć aplikację mobilną dla swoich klientów, dzięki czemu (zakłada że) zredukuje ilość papierkowej roboty u siebie w firmie, jednak w tym samym czasie zapomina, że największą wartością dla jego klientów jest osobisty kontakt z jego pracownikami.

Często zmiana może wiązać się z niechęcią pracowników / klientów, którzy już przyzwyczaili się do pewnych zasad i wdrożenie zmiany może powodować u nich poczucie zagrożenia (np. teraz program będzie za mnie pracować i nie będę potrzebny w firmie, stracę przez to pracę) czy też konieczność zmiany przyzwyczajeń (np. już nie mogę zadzwonić tak jak zawsze, tylko mam wypełnić jakiś formularz na stronie).

Projektowanie i wdrażanie zmiany wymaga dużo uwagi, cierpliwości, testów i skupienia na wszystkich interesariuszach. No i przede wszystkim skupienia na efekcie jaki zmiana ma wnieść, a nie na zmianie samej w sobie.

W biznesie, tak jak w życiu, wszystko się zmienia i na to nie poradzimy. Jednak wdrażanie przemyślanych zmian jest olbrzymią wartością, która pozwala na osiągnie zdecydowanie lepszych efektów, niż wdrażanie przypadkowych zmian, albo czekanie aż „świat zdecyduje za nas”. Świadomie podejmowanie decyzji dobrze rozumiejąc ich konsekwencje to najlepsza droga. Nigdy nie znamy wszystkich konsekwencji, ale brak decyzji, to też decyzja, obciążona często jeszcze większym ryzykiem.

Jako projektanci pomagamy naszym klientom przejść ze stanu A do stanu B (jednak czasami sporo pracy musimy włożyć w określenie stanów A i B i znalezienie dobrej drogi z A do B).

Wchodzisz do sali konferencyjnej, gdzie czeka na ciebie Projektant. Rozpoczynacie rozmowę, która po chwili przeradza się w długa i bardzo interesującą dyskusję, która do góry nogami wywraca twój początkowy plan…

Część trzecia: Świadomość braku pewności.

Spotyka się Projektant z Klientem – część 1: Tak niewiele wiem.

Projektant

Spotkanie ma rozpocząć się o 9 rano w siedzibie Klienta. Na miejscu jesteś 20 minut wcześniej. Zależy ci na jak najlepszym pierwszym wrażeniu, więc nie chcesz rozpocząć budowania relacji z Klientem od spóźnienia. Do prądu podłączasz laptop, wyjmujesz notatnik i rozglądasz się po sali konferencyjnej, w której ma odbyć się wasza pierwsza długa rozmowa. Zaproponowano Ci kawę i  herbatę. Wybrałeś Earl Grey, bo przed wyjściem z domu potraktowałeś się sporą ilością kofeiny. Kofeiny, której i tak za dużo przyjmujesz. Zresztą lekarz mówił ci o tym już kilka razy.

Z Klientem znacie się tylko z czterech, krótkich maili i jednej rozmowy telefonicznej. Research na Linkedinie nie wiele ci pomógł. Dodatkowo, nikt z twoich znajomych wcześniej z nim nie pracował, więc nie wiesz czego możesz spodziewać się po tej współpracy i kim w ogóle jest ten człowiek. W rozmowie telefonicznej wydawał ci się miły, a zarazem bardzo pewny siebie. Czujesz, że Klient dobrze wie, co chce osiągnąć. Pijesz łyk Earl Grey’a. Gorące. Spotkanie ma się za chwilę rozpocząć. Wiesz, że będziesz musiał tak pokierować spotkaniem, by jak najlepiej określić i zrozumieć wyzwanie projektowe, z którym przyjdzie ci się zmierzyć. Póki co wiesz bardzo niewiele. Pracujesz w tym zawodzie od kilku ładnych lat, miałeś takich spotkań dziesiątki w swojej karierze, jednak mimo to czujesz lekką niepewność. Wszystko co w tej chwili masz, to:

1. Niezbyt duże pojęcie o domenie biznesowej Klienta.

Najczęściej jest tak, że na początku współpracy albo bardzo słabo znamy i rozumiemy dany biznes, albo w ogóle nie mamy o nim pojęcia. Czasami zdarza się, że znamy domenę dosyć dobrze, bo robiliśmy już w niej kilka projektów, wtedy mniej czasu poświęcamy na naukę słownictwa używanego przez klienta, lepiej rozumiemy wybrane zasady i procesy etc. Gdy słabo znamy biznes, musimy poświęcić dużo uwagi na początku, by jak najlepiej zrozumieć zasady jego działania. Gdy biznes znaliśmy już wcześniej, to wtedy możemy odnosić się do naszego doświadczenia i dobrych praktyk, jakie wynieśliśmy z wcześniejszych projektów. Czasami szukamy analogii z tym co już robiliśmy wcześniej, co w niektórych przypadkach może wyprowadzić nas w pole. Jednak nie ma się co łudzić, znajomość domeny to nasza, często przeceniana, przewaga, która trochę usprawnia pracę na samym początku współpracy. Dobry projektant poradzi sobie nawet w bardzo specyficznej domenie, jeżeli odpowiednio podejdzie do zadania.

2. Wstępnie zarysowany problem / wyzwanie, z którym będziesz się mierzyć.

Niezależnie czy opis trafił do nas w formie krótkiego maila czy stu stronicowej dokumentacji z długą listą wymagań, to i tak na samym początku z tego wszystkiego wiemy i rozumiemy bardzo niewiele, więcej domyślamy się. Większość dokumentacji, z którymi miałem do czynienia, były przygotowane albo przez klienta, lub kogoś z jego pracowników, albo przez zewnętrzną firmę konsultingową. Niestety, w większości znanych mi przypadków, są to opracowania, które w sposób bardzo ogólny traktują o problemie, a mocno skupiają się na wymaganiach związanych z tym jak problem rozwiązać. Nie neguję wartości takich opracowań, jest to często dobra baza na start. Niestety, zdarza się, że opisane rozwiązanie, wcale nie rozwiąże problemu, który ma klient. Dużo bardziej preferuję krótki brief projektowy, albo nawet maila, które stanowią podstawę do dalszej rozmowy, niż ciężką i kosztowną dokumentację, do której klient już  przywiązał się emocjonalnie, która niestety czasami jest zupełnie do niczego.

3. Wcześniejsze doświadczenia w pracy nad prawdopodobnie podobnymi problemami.

Nie chodzi tym razem o domenę biznesową, ale o problem, który może występować w wielu domenach, np. usprawnianie procesu sprzedaży. Znów, na zasadzie analogii możemy zakładać, że będziemy docelowo projektować podobne rozwiązanie. Tak jak w przypadku znajomości domeny, znowu możemy sami siebie wpuszczać w maliny, gdy naiwnie wyjdziemy z założenia, że jeżeli coś zadziało w jednym miejscu, to pewnie zadziała też w drugim. Każdy projekt jest unikalny, mimo, że wiele rzeczy może wydawać się bardzo podobnych.

4. Wiedza na temat badań i projektowania, znajomość dziesiątek narzędzi z obszarów UX i Service Design i wiedza (często intuicja) na temat tego, z którego narzędzia skorzystać w danej chwili.

To właśnie wiedza i doświadczenie z tych obszarów jest kluczowa we współpracy. Nie wiedza domenowa, ale to w jaki sposób podchodzimy do problemu, jak realizujemy proces projektowy, czy umiemy w odpowiednim momencie skorzystać z odpowiednich narzędzi i czy potrafimy wyłapywać problemy istotne i pomijać rzeczy, które nie mają w danej chwili większego znaczenia. Nie ma przecież jednej zasady, że w tym i w tym momencie mamy zrobić persony, a service blueprint ma być zaraz po nich. Współpraca zawsze jest dynamiczna i narzędzia z których korzystamy są drugorzędne, ponieważ na pierwszym miejscu musimy wiedzieć w jakim celu chcemy skorzystać z danego narzędzia. Często jeden cel można osiągnąć na wiele różnych sposobów i trzymanie się na siłę niektórych narzędzi, to po prostu strata czasu i energii.

5. Otwarty umysł.

Przychodzimy słuchać i obserwować, a nie zagadać klienta na śmierć i pokazać jacy jesteśmy fajni i ile to już projektów zrobiliśmy. Warto przed spotkaniem schować swojego ego do kieszeni, a najlepiej zostawić je w domu. Na spotkanie nie idziemy sprzedawać, tylko idziemy pracować – etap sprzedaży jest już za nami, bo siedzimy właśnie na spotkaniu. Ostatnio przeczytałem bardzo fajny cytat Stephen’a R. Covey: „Most people do not listen with the intent to understand; they listen with the intent to reply.” Zgadzam się z nim w 100%. Projektant ma słuchać, by zrozumieć.

6. Szczera chęć pomocy Klientowi.

Jeżeli nie ma w tobie szczerej chęci pomocy i nie palisz się do tego, żeby poprawić mały kawałek świata, poprzez rozwiązanie problemu twojego klienta, to zastanów się, czy na pewno chcesz być projektantem. Jeżeli czujesz, że klient zajmuje się domeną, z którą ty nie chcesz mieć nic wspólnego np. prowadzi przetwórnie mięsa, podczas gdy ty jesteś wegetarianinem, to po prostu nie podejmuj tej współpracy. Zgodnie z twoim rozumieniem świata, jest to coś niewłaściwego, do czego nie chcesz się przykładać i to jest OK. Jednak jeżeli już decydujesz się na coś, to wejdź w temat na 120%.

7. Zaufanie do samego siebie i chęć podejmowania ryzyka.

Nie mówię tutaj o wierze w siebie, tylko o świadomości swojego doświadczenia oraz akceptacji ryzyka związanego z tym, że stajesz przed nowym wyzwaniem. Jeżeli ufasz swoim możliwościom i jednocześnie chcesz wejść w kolejny projekt, wychodząc poza swoją strefę komfortu, to wiedz, że szykuje się współpraca, w której będziesz miał okazję pokazać i rozwinąć swoje kompetencje. Oczywiście pod warunkiem, że dogadacie się z klientem, który z pewnością nie zaufa ci od początku na 100% i będzie czekał, aż wykażesz swoją wartość.

Robisz kolejny łyk herbaty. Do sali konferencyjnej wchodzi Klient…

Część druga: Wydaje mi się że…