Współpraca Product Ownera, z zespołem scrumowym

Jestem zwolenniczką bliskiej współpracy produktowców z zespołem programistycznym – chodzi mi przede wszystkim o to, żeby angażować zespół również w prace projektowe, a nie przekazywać mu tylko zadań związanych z zaimplementowaniem konkretnej funkcji.

Dlaczego? Według mnie zwiększa to zadowolenie z pracy programistów, dodaje motywację do pracy i także (wbrew pozorom) zwiększa ich efektywność! Daje także dobre efekty biznesowe. Projekty konsultowane przez programistów zawsze uwzględniają możliwości i ograniczenia technologiczne, co obniża ryzyko zainwestowania w prace, które na dłuższą metę, nie mają sensu.

Poniżej znajdziesz moje ulubione metody angażowania zespołu do rozwoju produktu, rozwiązywania problemów naszych klientów i realizacji wyzwań biznesowych.

Dostępność dla zespołu

Zacznę od tego, że aby zbudować relację z zespołem, zaangażować go do realizacji celów, musisz być dla niego dostępny. Na co dzień, gdy zespół ma pytanie co do zakresu zadania powinien sprawnie odpowiadać i transferować do zespołu jak najwięcej wiedzy – również tej biznesowej – związanej ze strategią firmy, roadmapą, feedbackiem od klientów. Product Owner powinien dbać także o regularność wszystkich spotkań, przede wszystkich tych, które sam organizuje – nie może zawodzić. Na spotkanie planistyczne czy refinement, zawsze powinien przychodzić przygotowany.

Samoorganizacja zespołu

To, że Product Owner powinien pracować blisko zespołu, nie oznacza wcale, że powinien podejmować wszystkie możliwe decyzje, które są do podjęcia w trakcie sprintów oraz uczestniczyć we wszystkich możliwych spotkaniach, również tych dotyczących rozwiązań technologicznych. Pytaj członków zespołu o ich zdanie, ich rekomendacje na rozwiązanie danego zagadnienia. Daj im swobodę do eksperymentowania, a także do podejmowania decyzji.

Badania User Experience

Aby przekazać do zespołu kontekst prac, warto rozważyć zaangażowanie zespołu w badania użyteczności.

Z moich doświadczeń wynika, że bardzo dobrze sprawdza się zapraszanie programisty do udziału w zdalnym wywiadzie z klientem (w roli obserwatora, słuchacza). Jeżeli robimy rundę badań w organizacji, na koniec sporządzamy raport, czy też podsumowanie tego czego się dowiedzieliśmy. Takimi informacjami warto dzielić się zarówno z zespołem programistycznym, jak i interesariuszami.

Kolejną możliwością jest wspólne oglądanie filmików, na których jest nagrane jak klient korzysta z produktu. W SentiOne korzystamy z narzędzia Hotjar, które nagrywa sesje użytkowników naszego produktu i daje nam funkcje do ich przeglądania oraz analizy. Efektem takiej sesji z programistami są konkretne pomysły na optymalizacje produktu. Podczas oglądania nagrywek, dyskutujemy o nich, zapisujemy problemy. Optymalizacje, które są zgodne z naszymi obecnymi celami, czy problemami użytkowników, przenosimy do Backlogu Produktu i priorytetyzujemy względem innych oczekujących zadań.

Jeżeli prowadzicie testy A/B, analizujcie wspólnie wyniki i podejmujcie decyzje co warto optymalizować dalej.

Metryki produktowe

Jeżeli masz dostęp do danych, korzystasz z narzędzia analitycznego, lub raz na jakiś czas kluczowe metryki produktowe dostarcza Ci analityk, czy zespół finansowy – podziel się również tą informacją z zespołem. Cały zespół powinien czuć, że to co robi, ma wpływ na to jak funkcjonuje biznes, a także na to jak klient korzysta z produktu.

Warto rozważyć wyświetlenie kluczowych metryk (np. liczba konwersji, czy płatności w danym miesiącu, zalogowanych użytkowników) na telewizorach w biurze).

Rola lidera funkcji, czyli “Feature Leada”

Nierzadko zdarza się, że Product Owner jest zapracowany. Przyczyną tego może być dużo zadań związanych z biznesowymi aspektami produktu, czy też odpowiedzialność za więcej niż jeden produkt jednocześnie. W takiej sytuacji warto zaangażować członków zespołu, aby odciążali w pewnych aspektach produktowca i brali odpowiedzialność za sukces projektu, czy nową funkcję wdrażaną do systemu. Product Owner w dalszym ciągu, musi konsultować ten projekt, ale przekazuje swoje zaufanie i decyzyjność do członka zespołu, który “mocniej niż zwykle” angażuje się w projektowanie UX dla danej zmiany, analizę technologiczną lub pomaga w tworzeniu kart do Product Backlogu.

Tutaj chciałabym pozdrowić Wojciecha Urbańskiego, który podzielił się tą techniką po przejściu do SentiOne z firmy Spartez (btw. Spartez rozwija Jirę w Gdańsku). Od 2 lat efektywnie korzystam z niej w SentiOne, mam duże zaufanie do zespołu i sprawnie idzie nam dzięki temu rozwijanie kilku produktów jednocześnie.

Roadmapa produktu

Tworząc Roadmapę, należy również konsultować się z całym zespołem. Zawsze przed rozpoczęciem kwartału, który planujemy, siadam z zespołem i rozmawiamy wspólnie o tym, jak widzimy dalszy rozwój produktu, na którym razem pracujemy – gdzie widzimy potencjał oraz jakie potrzeby klientów wspólnie dostrzegamy. Na koniec zastanawiamy się, gdzie mamy największy dług technologiczny i czy jest coś co regularnie wpływa na efektywność naszej pracy. Większe prace nad optymalizacją kodu również mogą być planowane w ramach Roadmapy. Alternatywnie można ustalić też jakaś procentową część każdego sprintu, która przeznaczana jest np. na zwiększenie pokrycia kodu testami automatycznymi, czy redukcją długu technologicznego.

Konsultowanie planów i dzielenie się kontekstem biznesowym z zespołem popłaca. Wyrównana wiedza sprawia, że Product Owner nie musi być centrum każdej decyzji.

Podsumowanie

Na koniec chciałabym dodać, że zespół pracujący zwinnie, blisko z Product Ownerem, to sytuacja idealna.

Może zdarzyć się jednak sytuacja, że zespół w którym rozpoczniesz pracę będzie zamknięty na zmiany – raczej skupia się na programowaniu historyjek, które są rozpisane przez produktowca. Warto jednak zawsze nad tym podejściem pracować – mały kroczkami wymyślać (np. podczas retrospektyw) nowe możliwości dla zespołu, aby polepszać współpracę i zwiększać jego zaangażowanie. W efekcie końcowym zauważymy duże zmiany w jakości wytwarzanego oprogramowania.