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:

„Caring” approach:

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.

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