Software house, jako firma sprzedająca usługi pojedynczych programistów lub całych zespołów na rzecz innych firm, nie rozwija własnych produktów. Faktycznym właścicielem produktu jest tutaj klient. W idealnej sytuacji firma klienta desygnuje osobę pełniącą rolę Product Ownera. Ma ona wówczas odpowiednie umocowanie, by decydować  o wymaganiach produktowych, priorytetach, budżecie. PO będący przedstawicielem klienta tworzy strategię rozwoju produktu i dba o jego rynkowy sukces. Jednocześnie osoba taka powinna być na co dzień dostępna dla zespołu i móc na bieżąco z nim współpracować. Po co więc w ogóle zatrudniać Product Ownera w firmie, która nie posiada swoich produktów?

Z mojego doświadczenia wynika, że kompetentny, decyzyjny, a jednocześnie dostępny dla zespołu reprezentant klienta, to sytuacja dość rzadka w firmach korzystających z usług software house’ów.

Często zupełnie brakuje osoby pełniącej tę rolę. W dużych, „skostniałych korporacjach” decyzyjność produktowa jest rozproszona po wielu działach i nie ma jednej osoby, która ostatecznie mogłaby zadecydować, jak ma wyglądać produkt. Niejednokrotnie zdarza się współpracować z firmami działającymi w podejściu kaskadowym – można tam znaleźć kierowników projektów, analityków systemowych, ale brakuje jasno określonego właścicielstwa. Zdarza się – zwłaszcza w przypadku niewielkich startupów – że jest właściciel, ma całkiem dobrze określoną wizję i wymagania, ale jednocześnie musi zajmować się niemal wszystkim i ostatnie, na co ma czas, to codzienna współpraca ze zdalnym zespołem.

Nie bez znaczenia pozostaje też kwestia metodologicznych kompetencji osób działających jako PO po stronie klienta. Trudno oczekiwać, że zawsze będą to osoby zaznajomione z frameworkiem scruma i wywodzącymi się z niego techniki. Sprawia to, że dobrze utrzymany Product Backlog, solidnie napisane historyjki użytkownika czy jasno zaplanowane releasy pozostają pobożnymi życzeniami.

W takich i podobnych sytuacjach, zaangażowanie kompetentnego Product Ownera po stronie zespołu SH pomaga rozwiązać wiele z wymienionych problemów. Osoba taka z jednej strony wspomaga współpracę z klientem, z drugiej dba o to, by zespół dobrze rozumiał nie tylko poszczególne wymagania, ale i szerszy kontekst biznesowy produktu. W rezultacie jakość pracy zespołu jak i dostarczanego przezeń oprogramowania istotnie wzrasta.

Ograniczenia roli Product Ownera w Software Housie

Bycie Product Ownerem w software housie wiąże się zazwyczaj z licznymi ograniczeniami. Są one konsekwencją braku własnego produktu i obecnością klienta, który, nawet jeśli formalnie nie zatrudnia PO po swojej stronie, w rzeczywistości ma rozstrzygające zdanie w większości spraw związanych z rozwojem produktu.

Ostatnio Agnieszka opisała ograniczenia roli Product Ownera w korporacji. Porównując te dwie sytuacje, odkryłyśmy, że w software house’ach jest bardzo podobnie. Tak jak w korporacji PO zazwyczaj nie ma wpływu na wizję produktu i decyzje budżetowe. Może mieć ograniczony udział w tworzeniu roadmapy, pracy z interesariuszami i użytkownikiem produktu. I – tak samo jak w korporacjach – jednym z niewielu obszarów wpływu, pozostaje dla niego zespół programistyczny.

Dlatego jednym z głównych wyzwań, przed jakimi stoi Product Owner w software housie, jest “poszerzanie obszaru wpływu”. Tylko dzięki temu można przybliżyć zespół do rzeczywistości biznesowej i zrozumienia oczekiwań klienta, interesariuszy oraz użytkowników produktu.

W mojej historii opowiem o tym, jak udało mi się ten obszar wpływu poszerzyć pracując w jednym z Software House’ów i co z tego wyniknęło.

Przygoda PO w software housie

Zespół

Przed około dwoma laty dołączyłam do zespołu 18 deweloperów pracujących nad złożonym produktem bankowym. Zostałam zatrudniona w zespole jako Product Owner, jednak trudno było tam znaleźć jakikolwiek produkt. Zespół przede wszystkim usiłował poradzić sobie z pozornie nieskończoną i dość przypadkową listą “bugów”. Każde wymaganie trafiające do zespołu było określane tym mianem, choć często nie były to faktyczne defekty. Owe bugi trafiały do zespołu w sposób ciągły i większość z nich określana była jako bardzo pilne. Nic dziwnego, że pomimo starań  zespołu, zastałam trzy jednocześnie “otwarte” sprinty. Po prostu zanim dobrze udało się skupić na zakresie zaplanowanym do pierwszego z nich, wjeżdżały nowe, zmienione wymagania.

Ogólny chaos odnośnie wymagań i spora liczba członków zespołu sprawiała, że utrudniona była synchronizacja pracy i skupienie się na wspólnym celu. Każdy pracował nad swoim wycinkiem, nie orientując się, co robią jego koledzy. Na daily scrumach można było zazwyczaj usłyszeć, powtarzane 18 razy “wczoraj pracowałem nad bugami, dziś będę pracował nad bugami, nic mnie nie blokuje”.

W tej niewesołej sytuacji ogromnym wsparciem był dla mnie Scrum Master (bardzo dobry!), który zajął się kulejącymi procesami i komunikacją w zespole, a ja mogłam się skupić na uporządkowaniu produktu.

Produkt

Zaczęłam od nauczenia się naszego produktu, przeanalizowania wszystkich możliwych ścieżek, wariantów i procesów, zapoznania się z dostępnymi funkcjonalnościami. Interesowało mnie nie tylko działanie systemu, ale i powody biznesowe leżące u podstaw takich, a nie innych rozwiązań. Następnie zaczęłam rozmawiać z klientem o dalszych planach rozwijania produktu. Także tu poszukiwałam odpowiedzi na pytanie “Dlaczego?”: “Dlaczego chcemy dodać funkcjonalność A?”, “Z jakiego powodu jest dla nas ważne rozwijanie kolejnego procesu?”. Zdobytą w ten sposób wiedzę dzieliłam z zespołem. To pomogło nam zmienić perspektywę –  przeszliśmy od przypadkowej kolekcji bugów do całego produktu i jego szerszego kontekstu.

Interesariusze

Ważną częścią mojej pracy był kontakt z interesariuszami. Należało zacząć od przetarcia ścieżek do nich. Na początku tylko jedna osoba komunikowała się z zespołem – przekazywała wszystkie wymagania spływające z różnych części firmy klienta i wyjaśniała ewentualne niejasności. Naturalnie często stawała się “wąskim gardłem”. Stopniowo udało się nawiązać relację z innymi osobami, przedstawicielami różnych tajemniczych departamentów ginących w mroku korporacji. Ukoronowaniem tych starań było zaproszenie naszych bezpośrednich interesariuszy na Sprint Review (coś, co wcześniej nigdy nie miało miejsca). Oczywiście spotkanie to przyniosło obu stronom wiele cennej wiedzy. Zespołowi pozwoliło między innymi zaoszczędzić czas dzięki rezygnacji z niektórych wymagań, które dla naszego klienta okazały się całkowicie drugorzędne.

Użytkownicy produktu

Innym kamieniem milowym było nawiązanie bezpośredniego dialogu z naszymi użytkownikami końcowymi. Rozwijany przez nas system używany był w salonach samochodowych do sporządzania wniosków kredytowych i leasingowych. Odwiedziliśmy jeden z takich salonów i dokonaliśmy tam sporo interesujących odkryć. Dowiedzieliśmy się na przykład, że w największych salonach to nie sprzedawca przygotowywał wnioski kredytowe, ale pracująca w salonie osoba reprezentująca bank. W naszym systemie było wiele ról, jednak żadna z nich nie była przeznaczona dla takich osób. W związku z tym logowali się oni na konta sprzedawców, korzystając z ich danych, i w ich imieniu przygotowywali wnioski. Około 70% całej sprzedaży obsługiwane było w ten, nie całkiem legalny, sposób.

Inne odkrycie wiązało się z zabezpieczeniami dostępu. W celu stworzenia jak najbezpieczniejszego systemu wprowadzono bardzo skomplikowane identyfikatory i hasła do logowania. W rezultacie żaden normalny człowiek nie był w stanie ich zapamiętać. Użytkownicy znaleźli proste rozwiązanie: wszystkie identyfikatory i hasła zapisane były na wizytówkach i schludnie poukładane w wizytownikach leżały na biurkach. Dzięki takim spotkaniom zaczęłam zauważać wiele aspektów produktu, których nie byłam wcześniej świadoma. Dzięki ich znajomości, mogłam zacząć proponować naszemu klientowi nowe rozwiązania, lepiej trafiające w potrzeby końcowego użytkownika.

Warsztat

Równie ważnym, choć może nie tak ekscytującym, wymiarem mojej pracy był solidny warsztat product ownerski. Dzięki systematycznej pracy z product backlogiem osiągnęliśmy wreszcie stan, w którym zespół miał przygotowane i spriorytytezowane historyjki i mógł planować kolejne sprinty i wdrożenia. Dzięki jasnym kryteriom akceptacji nikt już nie musiał zgadywać, o co chodziło naszemu klientowi. Udało się także zatrzymać nieustanny napływ ‘bugów’ i istotnie poprawić jakość dostarczanego produktu. Początkowa proporcja: 80% czasu pracy nad bugami a tylko 20% nad nowymi funkcjonalnościami, została zupełnie odwrócona.

Co udało się osiągnąć

Efekty mojej pracy w zespole zaczęły być widoczne dość szybko. Zaczęliśmy dostarczać oprogramowanie lepszej jakości – sporym wydarzeniem był dzień, w którym liczba bugów spadła do 0 (startowaliśmy od > 100). Dzięki bezpośredniej komunikacji z interesariuszami nasz produkt lepiej spełniał oczekiwania klienta. Poprawiło się też morale zespołu, na co znaczący wpływ miała świadomość dla kogo i po co tworzymy nasz produkt. W pewnym momencie wielki 18-osobowy zespół podzielił się na 3 mniejsze. Nie tylko usprawniło to naszą pracę, ale także zainicjowało proces budowania tożsamości zespołowej i identyfikacji z produktem w ramach nowych podzespołów.

Dla mnie osobiście najcenniejszym efektem opisanej współpracy było zaufanie, jakie udało mi się zdobyć zarówno od strony klienta, jak i zespołu. Zbudowanie go nie byłoby możliwe bez zdobytej wiedzy o produkcie, dobrego rozumienia potrzeb klienta oraz solidnego warsztatu. Zdobyte zaufanie stało się podstawą do budowania mojego autorytetu jako Product Ownera. Bez tych dwóch czynników -zaufania i autorytetu- nie jest możliwe skuteczne pełnienie roli PO, niezależnie od tego, w jakiego typu organizacji się pracuje.

Klucz do sukcesu?

Agnieszka w swoim wcześniejszym artykule opowiedziała historię swojej pracy w korporacji. Nasze historie, pomimo innych okoliczności, różnych produktów, odmiennej struktury organizacyjnej, są podobne. Zaczęłyśmy zastanawiać się, czy są jakieś wspólne cechy charakteru zwiększające prawdopodobieństwo odniesienia sukcesu w pracy Product Ownera.

Tak, zdecydowanie są takie cechy! Na swój użytek zdefiniowałyśmy je jako: bezczelność, naiwność i upierdliwość.

Być bezczelnym znaczy, że jesteś odważny i proaktywny. Masz czelność kwestionować zastany stan rzeczy i poszukiwać wciąż lepszych rozwiązań. W swoich działaniach kierujesz się przede wszystkim potrzebami użytkownika, co często może wymagać przeciwstawiania się osobom znacznie wyżej od Ciebie postawionym.

W byciu naiwnym chodzi o przyjęcie postawy dziecka. Dziecko z natury jest ciekawskie i nie boi się ograniczeń. Bycie naiwnym to umiejętność rozpalenia w sobie pasji do, z pozoru, tak nudnych tematów jak prawne ograniczenia płatności czy proces oceny zdolności kredytowej. Kiedy jesteś jak dziecko, potrafisz bez większego wysiłku wciągnąć innych w Twoją twórczą aktywność i w ten sposób utrzymywać zaangażowanie swoich współpracowników i interesariuszy.

Ale o co chodzi z tą upierdliwością? Nie brzmi to jak zbyt miła cecha… Dla nas przede wszystkim oznacza ona bycie zdeterminowanym i wchodzenie (a czasem wpychanie się) tam, gdzie cię nie proszą. Niekiedy nawet wielokrotnie. Upierdliwość to także uparte i niestrudzone odkrywanie faktów – o klientach, użytkownikach, rynku, produkcie – które nie zawsze są nam podane na tacy.

Bezczelność, naiwność, upierdliwość – są bardzo istotne, ale nie zdadzą się na wiele, jeśli nie będą wsparte umiejętnością budowania relacji. Musisz lubić ludzi, z którymi pracujesz i oni muszą to czuć. Wśród wielu istotnych dla PO relacji – z interesariuszami, zespołem, przełożonymi – kluczowa jest relacja ze Scrum Masterem. Ale to już temat na kolejną, długą opowieść.