Zespół musi mieć spokój pracy. O roli Product Ownera w zespole.

Czwarty już odcinek podcastu „Rozmowy na classpathie”, gdzie poprzez rozmowy ze specjalistami Tobiasz Kowalski stara się przybliżyć świat IT tym, którzy dopiero do niego wkraczają.

Jego kolejnym gościem była Magda Draniewicz, doświadczony Product Owner, pracujący obecnie w IDEMIA. Rozmowa z Magdą dotyczyła pracy PO, a w szczególności tego:

• czego Product Owner powinien wymagać od zespołu?
• czego zespół powinien wymagać od Product Owner’a?
• czy Product Owner jest zawsze potrzebny?
• czy Product Owner powinien mieć doświadczenie techniczne?
• czym różni się produkt od projektu oraz Product Owner od Project Managera?

Tobiasz: Product Owner a Project Manager – gdzie są granice? Mówiliśmy, że obydwoje stoją na moście. Który czym powinien się zajmować?

Magda: Mocno jest to związane (…) z tym, jak działa firma, co jest dostarczane. U nas akurat mamy produkt, który się rozwija w dłuższym czasookresie (…). Natomiast są też projekty, które albo mają za zadanie dostarczyć ten standardowy produkt dla konkretnego klienta, albo też dołożyć coś do tego produktu. Ale są też jeszcze projekty, które są zamówieniem zupełnie nowego produktu, stworzonego zupełnie od podstaw. Dlatego Project Manager z Product Owner’em powinni żyć w symbiozie, tylko każdy ma trochę inny zakres działań. Project Manager musi się skupić na tym, żeby w określonym czasie coś dla klienta zostało dostarczone. Musi się komunikować z PO, dlatego, że niejako projekt może wchodzić – nie chcę tego nazwać „ w konflikt”, ale musi się gdzieś osadzić na tej roadmapie. A czasem zdarza się tak, że nie był przewidziany, prawda? Mamy środek roku, nagle przychodzi projekt, są jakieś dodatkowe wymagania i trzeba to jakoś na tej roadmapie umieścić, bo to też będzie angażowało zespół.

PO z PM też często pojawiają się na tych samych spotkaniach z klientem, gdzie omawiane są wymagania. PO jest czasami dopraszany, ponieważ standardowo PO nie jest częścią Project Teamu – może nią być, może nie być. Zależy to też od tego, czy w projekcie jest do dostarczenia coś specyficznego dla tego klienta. Wtedy istnienie PO w projekcie przez cały jego okres trwania jest istotne. Natomiast jeśli projekt ma za zadanie dostarczenie tylko tego standardowego produktu, którym się PO zajmuje, to wtedy niekoniecznie. Bo tam wszystko jest jasne. Ewentualnie, jeżeli jest potrzebne szkolenie dla klienta, to wtedy też tym PO się zajmuje. Prezentuje, szkoli klienta z tego, jak produktu używać, robi jakieś demo. Zdarza się jednak, że tych projektów, które się dzieją w danym czasie jest sporo i wtedy niewyobrażalnym by było, aby PO angażował się w rozmowę z klientem na każdym etapie. I tym zajmuje się PM – on rozmawia z klientem. Jeżeli rozmowy z klientem schodzą na taki etap, że potrzebna jest pełna i bardzo szczegółowa funkcjonalna wiedza o produkcie, to wtedy angażuje PO.  I na tym ta symbioza też polega. Ja chronię zespół, a PM też mnie poniekąd chroni, bo zarządza tą komunikacją bezpośrednio z klientem. Bo ja muszę dbać o rozwój produktu i nie jestem w stanie kontaktować się z każdym klientem, jeśli jest powiedzmy 20 projektów, które w danym czasie się toczą.

Ale dodatkowo PM dla PO dostarcza też informację zwrotną od klienta. Z czego klient jest zadowolony, z czego jest niezadowolony. Nawet jeżeli klient w projekcie za coś nie chce zapłacić, to czasem przekazuje bardzo ważną informację zwrotną że czegoś by jednak brakowało – fajnie gdyby to „coś” gdzieś w roadmapie się pojawiło. I dzięki temu też PO czerpie inspirację z tamtej strony. Bo to nie jest tak, że PO siedzi i wymyśla ten produkt. To jest praca zespołowa. To jest też opieranie się na inspiracjach od klientów, jak oni tego używają, co im się sprawdza, co im się nie sprawdza. Na tej podstawie jest też budowana roadmapa na kolejne lata. Wiemy, gdzie jest jakaś potencjalna przestrzeń do usprawnień, ale wiemy to właśnie od użytkowników. Obraz PO czy zespołu jest mało obiektywny, bo my jesteśmy w środku. Dlatego ta informacja stamtąd jest istotna i dostarcza ją też poniekąd PM.

Tobiasz: My akurat w naszej firmie, w naszym dziale, pracujemy w oparciu o pewne specyfikacje (np.GSMA). Często się obracamy wokół nich. I mam takie luźne pytanie do Ciebie, o Twoje odczucia – co jest lepsze, czy praca w oparciu o globalną specyfikację, czy praca nad zupełnie autorskim produktem? Jakie są plusy i minusy jednego i drugiego.

Magda: Ja nie mam preferencji. Pracowałam i w standardach, i nie w standardach. Nie mogę powiedzieć, że jedno jest lepsze od drugiego. Zresztą, jedno drugiego nie wyklucza.  My się obracamy w standardzie (GSMA) i nie możemy być niezgodni ze standardem, natomiast to nie znaczy, że na podstawie standardu nie możemy budować jakichś specyficznych, dodatkowych, naszych tylko funkcjonalności. To jest clue – jak wyciągnąć z takiego, czasem bezdusznego, standardu takie smaczki, o których konkurencja nie pomyśli. Aby na bazie tego standardu zbudować coś, co będzie wyróżniało się na rynku. I to jest moim zdaniem bardzo ciekawe. To jest tak samo ciekawe, jak budowanie czegoś od początku. Dzięki temu, że musisz się wpisywać w standard, możesz oferować ten produkt tak szerokiej audiencji – on będzie wszędzie pasował, bo fundamenty są te same. Ale całe wyzwanie jest w tym, żeby się na tyle wyróżnić interpretacją i patrzeniem szerzej na ten standard, żeby pomóc klientowi rozwiązać jakiś problem, albo pozwolić mu zarabiać na tym produkcie więcej (…).