Co własciciel produktu robi w projektach?

Jak wygląda udział produkt ownera w realizacji projektów? Co takiego trzeba robić, by sprawnie tworzyć i rozwijać produkty cyfrowe? To kolejny wpis o tym zawodzie. Będzie więcej, bo temat jest dość gorący – świadczy o tym choćby ilość dyskusji na serwisie Quora od jakiegoś czasu.

W Google produkt ownerzy zdobywają szlify w dwuletnim programie Associate Product Manager, który przez 10 lat tworzyła i rozwijała Marissa Mayer – dziś szefowa Yahoo! Łatwo znajdziecie strony, na których firma poszukuje kandydatów do tej pracy. Jedna z trzech kluczowych odpowiedzialności tych ludzi to praca w zespołach rozwojowych nad wdrożeniami.

Nie znający tematu mogą mieć problem z rozróżnieniem właściciela produktu od project managera. Choć różne to nazwy, ciągle komuś się to miesza. Może lepiej używać określenia właściciel (owner) a nie manager. Przynajmniej skróty są różne – PO i PM. Google wcale się tym nie przejmuje, ale to nie znaczy, że jego model zadziała wszędzie. Zdarzają się ownerzy, którzy świetnie sobie radzą z zadaniami pma. Jednak PM zawsze powinien być adwokatem projektu – dbać o to, by został zakończony z powodzeniem, w budżecie i o czasie. Te dwa ostatnie elementy PO chętnie będzie poświęcał.

Gdy produkt owner nad czymś pracuje, zdarza się ktoś mówi o nim, że „prowadzi projekt” nawet wtedy, gdy projekt wcale się nie toczy. Tu jest kluczowa różnica – to pm projekty prowadzi i jest aktywny wyłącznie w czasie ich trwania. PO jest przy produkcie zawsze. PM sprawia, by każdy wykonał swoją pracę w zaplanowanym czasie. PO musi się zapewić, by były to właściwe rzeczy.

Jak to robi? Przede wszystkim zna wizję oraz strategię produktu. Wie, dokąd produkt zmierza i jaką drogą najlepiej tam dojść. Potrafi to przekazać ludziom, z którymi współpracuje. Musi zmotywować zespół projektowy w dążeniu do celu i sprawić, by jego członkowie rozumieli po co projekty są realizowane i co jest w nich ważne. Można działać bez tego, ale ludzie o wiele lepiej pracują, gdy wiedzą jaki jest cel.

Wizja to bardzo szerokie spojrzenie na produkt. Ona daje ramy działania. To co w danym momencie ważne – to priorytety. Produkt owner wie, co i w jakiej kolejności chce osiągnąć. Potrafi wybrać zmiany, które przyniosą mu największe korzyści (finansowe, rynkowe) w stosunku do poniesionych kosztów. Rezygnuje przy tym z 99 proc. pomysłów na rozwój, które się pojawiają. To typowe, że pomysłów zawsze jest więcej. Produkt owner zna je i wie dlaczego je odrzucił.

Między innymi dzięki takiemu podejściu PO dostarcza kolejne wersje produktu na rynek. Dopiero wdrażając sprawdza czy jego idee i teorie wypracowane np. z projektantami trafiają do użytkowników. Im częściej to robi, tym szybciej się uczy i mniej marnuje wysiłku. Realizując szuka prostych rozwiązań dla złożonych problemów. Rozwój produktów cyfrowych to nie służba w armii, nie trzeba myć sal gimnastycznych za pomocą sznurówek. Nie ilość wysiłku ma znaczenie, tylko efekt – dla użytkowników i dla biznesu. Efektywność i spryt to konieczność.

Inspiracje: wpis na blogu Michael Karnjanaprakorna, materiały o programie APM Google, wypowiedzi PO na Quora, lata praktyki i prac terenowych.

Nowy zawód: właściciel produktu

Oto nowy zawód: właściciel produktu cyfrowego. Coraz częściej w firmach potrzebne są osoby, które rozumiejąc rynek i użytkowników sprawnie poruszają się na styku biznesu i technologii. Ich głównym zadaniem jest podejmowanie decyzji związanych z rozwojem.

Właściciel musi wiedzieć co najbardziej dolega produktowi i czego brakuje jego użytkownikom. Powinien ich i produkt znać na wylot. Rozumieć każdy aspekt jego działania, rozumieć jak funkcjonuje obsługująca go technologia, ale też jakie procesy są z nim związane – co i jak robią pracujący przy nim ludzie. Musi też wiedzieć z czym produkt najmocniej odstaje od konkurencji (co nie znaczy, że tę konkurencję ma gonić).

W branży cyfrowej nie ma produktów skończonych. Zawsze są jakieś rzeczy do poprawienia lub zbudowania. Dynamicznie zmienia się oferta konkurencji i technologia. Inspiracji do rozwoju nie brakuje. Niestety realizacja większości dostępnych pomysłów nic zmienia, a za każdym razem zajmuje czas i kosztuje. Rozwój wymaga wyborów: nawet jeśli idzie szybko, to cokolwiek robimy, nie robimy w tym czasie czegoś innego. By osiągać efekt można robić dużo, licząc, że czasem się trafi, albo niewiele, starając się dobrze wybierać.

Praca właściciela produktu to ciągłe podejmowanie decyzji o rozwoju i współpraca z ludźmi w projektach, w których te decyzje są realizowane. To komplikuje się wraz z wielkością organizacji. Złożone, popularne produkty obsługuje często kilka grup osób. Może to być nawet kilkudziesięciu ludzi z kilkoma szefami w strukturze. Zajmują się jego sprzedażą, tworzą zapełniające go treści, komunikują się z użytkownikami. Z drugiej strony, do każdego projektu rozwojowego trzeba zwykle zaangażowac kilku ludzi: programistów, webmastera, projektanta i grafika. Gdyby zebrać wszystkich szefów i ludzi niezbędnych w realizacji, czasem trudno znaleźć dla nich salę. Poza kłopotami logistycznymi, udział tych wszystkich ludzi może powodować paraliż decyzyjny.

Jak z tego wybrnąć? Rozwiązanie to właśnie „product owner” reprezentujący wszystkich zajmujących się produktem. Musi on ich dobrze znać, słuchać i rozumieć. Pracuje z nimi nad wizją i strategią rozwoju. Jej świadomośc pozwala mu ocenić, co jest ważne, które zmiany ją wspierają, a które nie. Jako jedyny przedstawiciel biznesu jest kluczowym członkiem zespołu projektowego.

Idealnie gdy właścicielem jest to sam szef biznesu związanego z produktem. Gdy jednak biznes jest duży – ktoś bezpośrednio raportujący do niego. Produkt owner musi być stale dostępny dla zespołu projektowego. Musi mieć przy tym wiedzę niezbędną do pracy z technologią nad produktami dla ludzi. Musi rozumieć jak użytkownicy korzystają oni z cyfrowej komunikacji (z internetu, komputerów, smartfonów itp.). Nie może nie potrafić dogadać się z programistami. To kluczowa rzecz – dogadać to znaczy umieć zyskać szacunek, potrafić uzyskać kluczowe informacje i wspólnie znaleźć optymalne drogi realizacji celów. Umieć zadawać dobre pytania i prowadzić dialog. Nie korpo-dialog oparty na władzy i hierarchii, ale normalną otwartą rozmowę.

Jak ustalić priorytety?

Zespoły nie są w stanie skutecznie zajmować się wieloma sprawami jednocześnie. Skupienie pomaga, dlatego warto minimalizować ilość “pracy w toku”. To, czym się zajmujemy powinno wynikać z większego planu i założonej w nim kolejności działań – z przyjętych priorytetów.

Plany produktowe to najczęściej pogoń za ficzerami, które ma konkurencja. Można rozwój produktu prowadzić ad hoc, ale dobrze się to nie kończy. Gdy po roku prowadzonych w taki sposób prac spojrzy się wstecz, widać, że nic istotnego się nie wydarzyło. Co więc jest potrzebne by dobrze ustalać priorytety?

Lista spraw. Priorytetyzowanie to określanie ważności rzeczy względem siebie. Dowolne dwie możemy porównać i stwierdzić, którą zająć się wcześniej lub która jest ważniejsza (to nie to samo). By zacząć potrzebna jest jakakolwiek lista.

Co priorytetyzować? Jeśli kogoś poprosicie o listę priorytetów rozwojowych dla jego produktu, pokaże spis funkcjonalności, które chce wdrożyć. Tymczasem powinny to być problemy jakie chce rozwiązać. Zawsze łatwiej stwierdzić, że chcemy wdrożyć niebieski przycisk niż zdefiniować jaką potrzebę ma zaspokoić.

Elementy listy. Priorytetyzowane rzeczy powiny być mieć podobny ciężar gatunkowy i być w podobny sposób opisane. Nie należy zestawiać postulatów naprawy drobnych uciążliwości z potrzebami systemowych zmian. Czasem warto je zebrać w dwie – trzy grupy, w zależności od tego, czego dotyczą i kogo będą angażować.

Ile spraw? Liczba musi przekraczać nasze możliwości realizacyjne. Jeśli jest ich nieco za dużo, mamy konkurencję. Jeśli lista będzie przekraczała niezbyt magiczną liczbę 20, będzie demotywująca. Komfort związany z bardzo krótką listą jest zły – oznacza brak wyboru.

Kolejność. Jak układać taką listę? Prywatną można nawet alfabetycznie. Czasem będzie to bardziej korzystne niż gdyby wynikało tylko z subiektywnej atrakcyjności. Indywidualne prefencje w biznesie są mało praktyczne.

Jak więc sortować? Warto dla wszystkich pozycji użyć miar, co pozwoli uzyskać kolejnośc, w której mamy najlepszy stosunek oczekiwanych korzyści do szacowanych kosztów. Równocześnie należy zapewnić żeby ważne i trudne rzeczy nie były odkładane w nieskończoność – czasem może być konieczne podzielenie ich na więcej drobnych tematów.

Aktualizacja. Lista powinna być regularnie weryfikowana. To co dziś wydaje się ważne, za miesiąc może już takie nie być. Najbardziej atrakcyjne wydają nam się rzeczy, które właśnie do listy dołożyliśmy – im najlepiej dać chwilę czasu, żeby dojrzały, zamiast z dnia na dzień zmieniać harmonogramy.

Tyle teoria. By ją uzupełnić warto zobaczyć proste drzewo decyzyjne dla użyteczności oraz przeczytać o priorytetach na tynerblain.com a także na Svpg.com.

Para idzie w kod

Ciekawe statystyki prac nad nowym serwisem PKO BP podało na Facebooku K2. Cytuję za UXlabs:

  • 1.100 h pracy działów Strategii, Design i UX
  • 1.500 h poświęconych na analizę
  • 11.000 h pracy działu IT
  • 700 h poświęconych testom jakości
  • 700 h pracy content edytorów
  • 2.800 h pracy działu Client Service

Jak widać największa część to praca nad kodem i wdrożeniami (dział IT). Jest potraktowana jak monolit, ale w przeciętnym projekcie czas programowanie + przystawki oscyluje w okolicach 75 proc. całości. Dane podane są w kolejności prac. Niektórzy drugą część – analizę, w której określa się jak zaprogramować to co zostało zaprojektowane – wliczają w część IT. Podobnie z testami jakości. Stąd to 75 proc. a nie 61 jak w tym zestawieniu.

Tak jest w w zdecydowanej większości projektów np. u nas, w Gazeta.pl. Podobnie wygląda w dowolnym projekcie rozwojowym, z którego statystykami się spotkałem. Ktoś mógłby powiedzieć „w bankach jest inaczej”, powyższe dane jednak pokazują, że w zasadzie jest tak samo. Dowolna rzecz, która trwa miesiąc lub więcej, w której powstają nowe rozwiązania, składa się przede wszystkim z programownia albo oczekiwania na efekty pracy programistów.

Prace IT pozostają największym kosztem w tego typu projektach. Najwięcej można zyskać dobrze nimi zarządzając i monitorując postępy w tej części – np. dzieląc całość na mniejsze kawałki, które można wdrażać niezleżnie. I na milion jeszcze innych sposób – ale nie o tym tu.

Równocześnie – i to strasznie ważne – wartość z projektu powstaje na początku. W pierwszych składowych projektowane są rozwiązania i tu zapadają decyzje jak czas programistów zostanie „wydany”. To pokazuje jak istotne jest podejmowanie decyzji i projektowanie (które w dużym stopniu jest podejmowaniem decyzji).