Proxy Product Owner po stronie dostawcy? Plusy i minusy rozwiązania.

Zespoły Deweloperskie pracujące w software house’ach często doświadczają niełatwej współpracy ze zdalnym Product Ownerem, pracującym po stronie zagranicznego klienta. Problemy to najczęściej kiepska dostępność Product Ownera dla zespołu, brak kompetencji produktowych, fizyczna odległość od zespołu oraz bariery językowe. Rozwiązaniem może być wprowadzenie roli proxy Product Ownera po stronie dostawcy. Koncepcja ta — jak łatwo się domyślić — ma swoje plusy i minusy.

 

W czym jest problem?

Spędziłem kilka lat pracując z software housea’mi — zarówno jako osoba zatrudniona wewnątrz organizacji, jak i konsultant zewnętrzny. Moje doświadczenia w tym obszarze jest następujące: w firmach dostarczających rozwiązania dla klientów zewnętrznych, sensowny Product Owner po stronie klienta to rzadkość. Typowe problemy, z którymi można się spotkać w takiej konfiguracji, to:

  • Brak dostępności czasowej Product Ownera – często zdarza się, że osoba ta nie ma czasu, żeby wywiązać się z obowiązków w tej roli. Wynika to najcześciej z innych, aktualnie posiadanych obowiązków w swojej firmie. Często spotykam się z przypadkiem, gdy osoby takie dostają dodatkowe obowiązki (“będziesz Product Ownerem dla naszego dostawcy”), przy jednoczesnym pozostawieniu aktualnych obowiązków na niezmienionym poziomie.
  • Praca w różnych strefach czasowych – o ile współpraca z Polski z klientami z krajów europejskich nie jest problematyczna (zwykle 1h przesunięcia czasowego), o tyle krótkie okno czasowe z USA, Meksykiem czy Australią komplikuje temat. W takich przypadkach Produkt Owner po stronie klienta zwykle jest dostępny dosłownie na jedną lub dwie godziny, zakładając, że na po obu stronach praca odbywa się w typowych biurowych godzinach (np. od 9 do 17).
  • Brak kompetencji produktowych – musiałbym się solidnie zastanowić, czy spotkałem się z Produkt Ownerem po stronie klienta, którego zdecydowałbym się zatrudnić. Może akurat tak trafiałem, może moje oczekiwania w stosunku do tej roli są wysokie, może za mało widziałem. Nie mniej jednak moje doświadczenie jest takie, że często osoby wybrane, aby pełnić tę rolę, nie są do tej roli odpowiednio przygotowane. Powoduje to, że Zespoły Deweloperskie otrzymują ułamek tego, czego mogłyby się spodziewać od osoby w roli Product Ownera.
  • Różne zrozumienie, czym jest zwinne wytwarzanie produktów – ile firm, tyle sposobów interpretacji tego, czym jest sensownie wykorzystanie podejścia zwinnego do wytwarzania produktów cyfrowych. Bywa, że wcześniejsze doświadczenia osób w roli Product Ownera po stronie klienta bywają bliższe podejściu water-scrum-fall, aniżeli sensownie rozumianej zwinności. Może to rodzić konflikty oraz nieporozumienia we współpracy z zespołami, które mają apetyt na prawdziwie zwinną współpracę oraz partnerstwo.
  • Bariera językowa oraz różnice kulturowe – skuteczna komunikacja w języku ojczystym jest niebanalnym zadaniem. Sytuacja komplikuje się dodatkowo, gdy odbywa się w innym języku. Istotne niuanse mogą zostać niewyłapane, akcent może utrudniać zrozumienie, a konkretne wyrazy zostać zrozumiane w niewłaściwy sposób. Nawet najlepszy Deweloper traci swoje “moce”, jeśli poziom umiejętności obcych języków nie jest na wysokim poziomie. Do tego dochodzą różnice kulturowe, które mogą dawać błędny obraz tego, jakie emocje oraz myśli faktycznie występują po stronie klienta.
  • Trudność w zbudowaniu relacji – trwałe relacje międzyludzkie buduje się łatwiej, gdy możemy współpracować fizycznie w jednej lokalizacji, mając umożliwiony kontakt twarzą w twarz. Pracując zdalnie, problem ten można do pewnego stopnia łagodzić: od prostych sposobów jak włączanie kamery w trakcie wideokonferencji, do organizowania regularnych, fizycznych wizyt w biurze u dostawcy lub klienta. Niemniej, nic nie zastąpi przypadkowych okazji do budowania więzi społecznych, takich jak rozmowy przy ekspresie do kawy czy nieplanowanych spotkań na korytarzu, podczas których można spontanicznie zamienić kilka zdań.

Wstawiamy Proxy Product Ownera po stronie dostawcy

Z powyższymi problemami można pracować na wiele różnych sposobów. Dzisiaj skupię się na jednym, sprawdzonym przeze mnie wielokrotnie rozwiązaniu, polegającym na umieszczeniu proxy Product Ownera po stronie software house’u, przy jednoczesnym przesunięciu Product Ownera dostarczonego przez klienta w rolę interesariusza.

Co do zasady, w firmach budujących własne produkty, instytucję proxy Product Ownera uważam za antywzorzec. Jednocześnie w realiach pracy z klientem zewnętrzny może się okazać, że pomimo sporej listy wad, posiadanie tej roli może przynieść wartość zarówno dla klienta, jak i dostawcy.

Poniżej wypisałem plusy oraz minusy, które zabrałem na bazie własnych doświadczeń i obserwacji.

Plusy posiadania proxy Product Ownera

Istnieje kilka namacalnych plusów, które mogą wynikać z posiadania proxy Product Ownera po stronie dostawcy:

  • Usprawnienie komunikacji w Zespole Scrumowym – proxy Product Owner pracujący po stronie dostawcy najczęściej siedzi fizycznie z zespołem w tym samym pokoju. Pozwala mu to natychmiast reagować i odpowiadać na pytania biznesowe, które pojawiają się w zespole.
  • Ciągła dostępność kontekstu biznesowego dla zespołu – będąc blisko zespołu, proxy Product Owner ma możliwość, aby w ciągły sposób dzielić się z nim wizją produktu, planami rozwojowymi oraz kontekstem biznesowym. Może to zrobić w dowolnym momencie, kiedy uzna wraz z Zespołem Deweloperskim, że jest to konieczne.
  • Usunięcie problemu stref czasowych – proxy Product Owner jest dostępny dla zespołu w godzinach ich pracy, dzięki czemu marnotrawstwo — związane z koniecznością oczekiwania na uzyskanie odpowiedzi — zmniejsza się lub jest całkowicie eliminowane.
  • Możliwość budowania relacji osobistych – w sytuacji, w której proxy Product Owner jest dostępny w tej samej lokalizacji co Zespół Deweloperski, okazje do budowania relacji pojawiają się na niemal każdym kroku (rozmowa przy biurku, przy automacie z kawą, na korytarzu, podczas spotkań społeczności skupionych wokół konkretnych tematów, przy okazji innych spotkań w firmie itp.)
  • Pozytywny wpływ na motywację zespołu – z moich obserwacji wynika, że sensowny proxy Product Owner, pracujący na miejscu z zespołem, może mieć dobry wpływ na morale zespołu. Wynika to zwykle z niechęci zespołów do pracy z kimś, kto jest permanentnie niedostępny lub nie przygotowany merytorycznie do pełnienia tej roli.
  • Szansa na wzmocnienie postrzegania software house’u jako partnera w oczach klienta – sensownie wykonywana praca proxy Product Owner może przekonać klienta, że jako software house jesteśmy w stanie dostarczyć znacznie więcej niż tylko linijki kodu. Może być to argument, który przesunie software house z pozycji “dostawca” na pozycję “partner”.

Minusy oraz wyzwania posiadania proxy Product Ownera

Jak łatwo się domyślić, nie jest to rozwiązanie pozbawione wad. Istnieje szereg negatywnych aspektów oraz trudności, na które warto zwrócić uwagę, zanim zdecydujemy się na powołanie roli proxy Product Ownera.

  • Ograniczone możliwości decyzyjne – na koniec dnia, proxy Product Owner to nadal tylko proxy, który najprawdopodobniej nigdy nie zyska pełnej decyzyjności w temacie zarządzania produktem klienta. Decyzyjność może zwiększać się wraz z upływem czasu i osiągać poziom pozwalający skutecznie pracować z Zespołem Deweloperskim, niemniej warto być świadomym potencjalnych ograniczeń.
  • Ryzyko wydłużenia ścieżki komunikacyjnej – w założeniu proxy Product Owner ma być lekarstwem na słabą komunikację produktową pomiędzy klientem a software house’em. Należy jednak wziąć pod uwagę ryzyko, że niewłaściwe wejście w tę rolę (np. słabe zarządzanie interesariuszami, brak świadomych wysiłków w celu zwiększania decyzyjności, zbudowanie niedostatecznie głębokiego zaufania z klientem) może paradoksalnie skutkować wydłużeniem, a nie skróceniem ścieżek komunikacyjnych pomiędzy użytkownikami końcowymi produktu a Zespołem Deweloperskim.
  • Długi czas wdrożenia – na bazie moich obserwacji, efektywne wejście w rolę proxy Product Ownera może trwać wiele miesięcy. Odnalezienie się realiach klienta, zrozumienie rynku, poznanie konkurencji, właściwe rozpoznanie interesariuszy, zbudowanie zaufania czy zdobycie wiedzy domenowej to obszary, do zgłębienia których nie ma prostej drogi na skróty.
  • Trudność w rekrutacji osoby na to stanowisko – miałem okazję uczestniczyć w kilkudziesięciu rozmowach rekrutacyjnych na stanowisko proxy Product Ownera, budując zespół o kompetencjach produktowych w jednym z polskich software house’ów. Pisząc o trudności z perspektywy rekrutacji, przychodzą mi do głowy trzy główne aspekty. Po pierwsze, na rynku jest skończona liczba doświadczonych Product Ownerów i co więcej, zwykle mogą oni przebierać w ofertach pracy. Po drugie, nie każdy Product Owner będzie zainteresowany wejściem w rolę proxy w software house’ie, ze względu na potencjalne ograniczenia decyzyjności związane z pełnieniem tej roli. Po trzecie, nie zawsze na etapie rekrutacji jest jasne, z jakim klientem (kraj, branża, produkt, wewnętrzna kultura organizacyjna firmy) będzie współpracował rekrutowany kandydat, co dla części z nich może oznaczać wysoki poziom niepewności, nie będący do zaakceptowania.
  • Konieczność podróżowania do klienta – o ile proxy Product Ownerowi łatwo jest zbudować relację z osobami z zespołu, które są z nim w jednej lokalizacji, o tyle wyzwaniem może być zrobienie tego samego z otoczeniem klienta. Interesariusze mogą być ulokowani w różnych częściach świata, co może oznaczać konieczność częstych i niejednokrotnie męczących podróży, aby mieć okazję do poznania ich osobiście.
  • Trudność w przekonaniu klienta do roli proxy Product Ownera – dla klientów software house’u, którzy po prostu szukają deweloperów, propozycja konfiguracji osobowej z dodatkowym proxy Product Ownerem może okazać się czymś nowym, co będzie wymagało dodatkowego wysiłku komunikacyjnego ze strony dostawcy. Jednocześnie nie ma gwarancji, że podjęte wysiłki dadzą oczekiwane rezultaty.
  • Brak zgody klienta na rolę proxy Product Ownera – klienci mogą nie zgodzić się na pomysł, by przekazać rolę odpowiedzialną za produkt osobie, która nie jest zatrudniona w ich własnej firmie. Zwykle wynika to wprost ze strategii firmy, która preferuje budować kompetencje produktowe po swojej stronie, zamiast korzystać z usług partnerów zewnętrznych.

Podsumowanie

Wstawienie proxy Product Owner po stronie dostawcy to jedno z możliwych rozwiązań w sytuacji, gdy doświadczamy problemów we współpracy ze zdalnym Product Ownerem po stronie klienta. Rozwiązanie to należy rozważyć na wielu płaszczyznach, będąc świadomym zarówno jego zalet, jak i wad.

Jakie macie doświadczenia z rolą proxy Product Ownera? Sprawdzała się w Waszym software house’ie, powodowała więcej problemów niż zysku, a może nigdy nie spróbowaliście? Zapraszam do dyskusji w komentarzach.

Chcesz dowiedzieć się więcej o tym, jak zwinne wytwarzać produkty z klientem zewnętrznym w Scrumie? Zobacz moje 2-dniowe warsztaty “Scrum dla software houseów”, które przygotowałem na bazie moich doświadczeń w pracy z klientami z USA, UK, Irlandii, Niemiec oraz Polski. Więcej informacji znajdziesz na stronie http://www.scrumdlasoftwarehouseow.pl/

Źródło zdjęcia: https://www.flickr.com/photos/mikecogh/5676155632/

Komentarze do wpisu: “Proxy Product Owner po stronie dostawcy? Plusy i minusy rozwiązania.


Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x