Wielu z czytelników bloga zainteresowanych jest dynamiczną naturą współpracy pomiędzy product ownerem a projektantem UX. W tym wpisie spróbuję wyjaśnić, jak w moim pojęciu odbywać się powinna taka współpraca — a także dlaczego najczęściej wyobrażamy sobie to zupełnie inaczej, niż powinniśmy.
Czy jestem product ownerem?
Po warsztatach w Poznaniu, na których mówiłem o trudnościach związanych z adaptacją metolodogii UX w dużych organizacjach kilkoro z gości napisało do mnie emaile, w rozwiniętej dyskusji sugerując, że jestem chyba product ownerem. Doszli do takiego wniosku, gdyż mówiłem o tym w jaki sposób projektant UX może wpływać na proces, doprowadzając do stworzenia czegoś, co działa dobrze i zadowala tak użytkownika, jak i klienta. Proponowałem traktować ten proces jako produkt tworzony zgodnie z zasadami UX — a więc rozmyślnie, przy zainwestowaniu czasu w badania na temat zespołu, założeń produkcyjnych i tak, aby nikogo nie pomijać. W swoich listach moi koledzy i koleżanki pisali, iż zobaczyli we mnie product ownera, bo ich rola nie pozwala im najczęściej na wywieranie takiego rodzaju wpływu na kolegów, który doprowadziłby projekt do szczęśliwego i użytecznego końca.
Czy jestem zatem product ownerem?
Czy jest nim projektant UX? Ciocia Niusia? Czekoladowy Zajączek? Ty?
Zastanówmy się.
Twoje magiczne moce
Jeżeli jesteś projektantem UX, powinieneś móc komunikować się ze swoim zespołem i dostarczać dowodów na potwierdzanie swoich tez. Twoje wybory i decyzje na temat funkcjonalności powinny być podparte doświadczeniem praktycznym i wiedzą wyniesioną z testów. Twoje rekomendacje powinny być brane pod uwagę, a twój szef i cały zespół powinien zwracać głowę w twoją stronę, kiedy nadchodzą wątpliwości co do przydatności projektowanych rozwiązań.
To oczywiście sytuacja idealna. Wszyscy wiemy, jak bywa naprawdę. Szefostwo ma swoje własne pomysły, klient ma jeszcze inne, a produkt końcowy nijak nie przypomina tego, co w pocie czoła zaprojektowaliśmy. Polityka i preferencje biorą górę. Często tym, który decyduje o nieszczęśliwym obrocie sprawy jest właśnie product owner. To odpowiedzialna pozycja, ale stresująca i wystawiona na ciągłe napięcia. Łatwo im ulec. Wtedy powinieneś na scenę wjechać ty, ze swoją gadką i wiaderkiem materiału dowodowego.
Zaufanie
W tym miejscu często natrafisz na mur. Nikt nie będzie chciał cię słuchać, bo product owner ma ostatnie zdanie. Jednakże w dobrze funkcjonujących organizacjach decyzje podejmowane przez tą osobę nie powinny być formułowane tylko na podstawie własnych preferencji czy nacisków. Warto o tym pamiętać i działać tak, żeby móc dorzucić swoje przysłowiowe trzy grosze.
Prawdą jest, że mam szczęście pracować w otoczeniu, w którym moim zadaniem jest koordynowanie pracy nad częścią projektu, owocem której jest interfejs lub jakaś inna fizyczna manifestacja usługi. Zgodnie z tym, o czym często pieję, wszyscy w zespole projektowym odpowiedzialni są za UX. Nie da się odseparować pracy programisty od tego, co tworzy projektant interfejsów czy architekt informacji. Nie da się również tego zbudować w izolacji bez pomocy project managera i badacza użyteczności. To znaczy da się, ale jaki to ma sens? Równie dobrze można zacząć znów klepać HTML w tabelkach. Product owner ma finalne słowo w sytuacjach, które wymagają eskalacji lub też wtedy, kiedy następuje konieczność nie planowanej wcześniej rozbudowy funkcjonalności. Poza tymi momentami powinien być najczęściej zdystansowany i ufać swojemu zespołowi. To jest powód, dla którego sam na przykład drużynie programista/grafik przekazuję tylko szkice, a nie makiety. Wierzę im na tyle, że wiem, iż dostarczą mi dobry materiał.
Product owner kontra reszta zespołu
Czy zatem projektant UX jest product ownerem? Kto właściwie nim jest? Otóż z mojego doświadczenia wynika, że o ile jest to rola namacalna — to znaczy, jest nim na przykład Stefan — o tyle jest ona zupełnie rozproszona. Stefan może mieć ostatnie słowo, ale odpowiedzialność za dostarczenie produktu, który działa jak trzeba spoczywa na całym zespole. Tak samo, jak każdy jego pracownik jest projektantem UX, tak samo jest też product ownerem. Przyzwyczajenie się do tej myśli zasadniczo ułatwia sprawę i pozwala projektantowi UX (i innym) zobaczyć swoją rolę w kontekście całości. Wtedy trudniej o zjazdy i pomyłki. Wszakże zależy nam na tym, aby dobrze wykonać swoją pracę, a zatem w sytuacjach, w których potrzebna nam będzie pomoc kolegów zwrócimy się do nich — i vice versa. Kiedy biegamy pomiędzy biurkami i maczamy palce we wszystkim, od interfejsu poprzez specyfikacje techniczne, a potem słuchamy o budżecie na spotkaniu z klientem, w istocie wydawać się może, iż jesteśmy product ownerem. Zupełnie słusznie, bo każdy z nas nim być powinien.
Można by napisać, iż „tak to masz ty, Wojtku” a „w Polsce to jest inaczej”. Tylko, że produkty, które tworzysz też są efektem pracy zespołu. Nie ważne, czy w Kathmandu czy w Edynburgu. Różnica polega tylko na świadomości albo jej braku. Metody są te same. Mów zatem o tym i nie bój się powoływać na odpowiedzialność grupy za to, co wychodzi przez drzwi. Pomagaj zamiast piętnować i wytykać błędy palcem (jeżeli będziesz kultywował takie zachowania, doświadczysz ich sam). Poddawaj w wątpliwość nieracjonalne decyzje. Może nie wywrzesz efektu, ale zostaniesz zapamiętany. Refleksja przychodzi o każdego.
Utopia?
W twojej firmie nie ma na to szans? Produkty wypychane są bez zastanowienia, przy zerowym poszanowaniu dla twojej pracy? Bardzo możliwe. Powodów może być kilka; od słabej świadomości i kiepskiej kultury pracy począwszy po twoje niezdecydowanie i brak umiejętności czy strach przed walnięciem pięścią w stół skończywszy. Jednakże zanim zamkniesz zakładkę z tym tekstem myśląc, że piszę o jakichś cudach na kiju zastanów się nad odpowiedzią na jedno pytanie: kiedy przyjdzie do rozliczenia figur finansowych po wypuszczeniu projektu „do ludzi”, a od użytkowników końcowych zaczną docierać do agencji w której pracujesz wyrazy niezadowolenia, kto dostanie za to po uszach?
Cały zespół.
Kto jest zatem product ownerem, nawet jeśli nie zdaje sobie z tego sprawy?
Jeden komentarz
Zamknąłem funkcję komentowania.