O błędach, które popełniłam jako początkujący Product Owner

Kilka lat temu miałam okazję tworzyć start-up, w ramach dużej spółki. Początkowo w chaosie, bez zastosowania żadnej metody pracy. Na kilkanaście tygodni przed wdrożeniem produkcyjnym szef zespołu developerskiego zachęcał nasz zespół koncepcyjny do zastosowania techniki MoSCoW. Zróbcie listę rzeczy, które muszą wejść na proda – „Must have”, które powinny wejść – „Should have” i resztę „Could have”, „Won’t have”. Wszystkiego nie damy rady zrobić. Zupełnie nie rozumieliśmy, czego od nas oczekuje. Wszystko w naszym długim backlogu było „Must have”!

Po negocjacjach udało nam się dojść do porozumienia i spriorytetyzować listę tematów. Kiedy zaczęliśmy pracować Scrumem, było już tylko lepiej. Regularny rytm i przewidywalne tempo pracy, częste spotkania z developerami, cykliczne planowanie, usprawnienia sposobu pracy. No może poza tym, że zarówno jako specjalista ds rozwoju, jak i późniejszy Product Owner zespołu scrumowego, popełniłam podobne błędy. Zmieniły się narzędzia, poprawiła komunikacja i atmosfera w zespole, ale błędy pozostały. Dla wielu z Was będą oczywiste. Wciąż jednak spotykam się z nimi u innych początkujących Product Ownerów, dlatego zdecydowałam się o nich napisać.

Oto zatem moja osobista lista błędów, które przeszkadzają w byciu naprawdę dobrym Product Ownerem. Czytajcie i nie popełniajcie:



Rozwiązania dla wszystkich, czyli dla nikogo

Podchodząc do tematu nowego serwisu, miałam ambicję zrobić COŚ wielkiego, COŚ, z czego będą korzystać rzesze internautów. Byłam przekonana, że mamy dobrze zdefiniowaną grupę docelową, a właściwie kilka grup, skoro zasięg miał być duży. Każda z potencjalnie innymi potrzebami i oczekiwaniami, co sprawiło, że niemożliwe było precyzyjne określenie potrzeb i oczekiwań użytkownika końcowego rozwiązań.

Efekt – „ficzeriada”, misz-masz funkcjonalności spowodowany próbami stworzenia CZEGOŚ wyjątkowego dla wszystkich, każdej z grup z osobna. Brak dobrze zdefiniowanej grupy docelowej (jak to dziś interpretuję), spowodował też trudności z planowaniem strategii i akcji marketingowych (do kogo je kierować?). Podsumowując, nie polecam takiego podejścia.

Zakochanie we własnych pomysłach

Jak już coś wymyśliłam, skonsultowałam ze znajomymi z branży (serio, tak wiarygodnie?;)), a na podstawie feedbacku od nich dopracowałam, to musiało być dobre. Na tyle dobre, żeby bronić pomysłów w zaparte, nawet jeśli zakładały zmianę przyzwyczajeń użytkownika. Zamiast tego, można było skupić się na efektywnym i wiarygodnym zweryfikowaniu zamiarów przed wdrożeniem ich w życie. O tym, jak sprawdzić, czy nasze pomysły faktycznie mają szansę zainteresować potencjalnych użytkowników, pisałam po warsztatach UX, w których uczestniczyłam w ramach Poznań Startup Weekend 2014. Tych, którzy chcieliby dowiedzieć się więcej, odsyłam do tego materiału.

Big bang dla użytkownika

Wyobraźcie sobie, że ktoś pokazuje Wam swój nowy serwis, prosi Was o feedback, ale zanim rzucicie na niego okiem, dodaje z dumą: „Wiesz, budowaliśmy go iteracyjnie i przyrostowo. Fajnie, nie?” „Yyyy, i co z tego?” chciałoby się odpowiedzieć. Z perspektywy użytkownika naprawdę nie ma znaczenia, jak wyglądał sposób pracy nad serwisem, z którego korzysta, albo z jakichś powodów korzystać nie chce. Dla niego liczą się efekty tej pracy.

Dialog podobny do tego przytoczonego przeze mnie, mógłby odbyć się pomiędzy mną, a pierwszymi użytkownikami serwisu. Nasze wdrożenie było big bangiem mimo, że strona powstawała w sensownych krokach. Rozbudowywaliśmy ją jednak do tzw. szuflady, a przed użytkownikami odkryliśmy dopiero wersję maximum. Pokazaliśmy im rozbudowany serwis z dużą ilością opcji, funkcjonalności, materiałami merytorycznymi… Część z nich okazała się zbędna, więc niepotrzebnie straciliśmy na nie czas.

Jak mogłam to zrobić inaczej? Wypracować wspólnie z zespołem wersję MVP naszego serwisu (ang. Minimum Viable Product), którą można wcześnie zweryfikować z rynkiem – pokazać użytkownikom i na podstawie feedbacku od nich i akcji podejmowanych w serwisie, dalej przyrostowo rozbudowywać. Częste wdrożenia i śledzenie zachowań użytkowników pozwoliłyby dużo szybciej wyłapać chybione pomysły i zwiększyłyby szanse na realizację tematów wnoszących wartość dla tych użytkowników.

Zbyt szczegółowo rozpisany backlog

Początkujący Product Ownerzy zazwyczaj albo zaniedbują Product Backlog, albo zbyt pieczołowicie go rozpisują. Ja należałam do tych drugich. Skrupulatnie rozpisane historyjki i sprinty zaplanowane z dużym wyprzedzeniem w praktyce oznaczały niewielkie zaangażowanie zespołu w prace koncepcyjne i planowanie bez brania pod uwagę feedbacku użytkownika końcowego. Nie za bardzo agile.

Zdecydowanie większą wartość przyniosłoby skoncentrowanie sił i moich, i zespołu na częstych wdrożeniach oraz weryfikacji, na ile pomysły faktycznie przypadają do gustu naszym użytkownikom i czy wpływają na poszerzanie zasięgu serwisu.

Bezużyteczne KPI’s (ang. key performance indicators)

Jako Product Owner dysponowałam kluczowymi wskaźnikami efektywności dla produktu (ang. KPI). Moim celem mogło być na przykład wypracowanie X więcej nowych unikalnych użytkowników w określonym czasie, albo X użytkowników, którzy podejmują określone akcje w serwisie. Problem polegał na tym, że KPIs było za dużo i za często się zmieniały np. z liczby użytkowników na finansowe w przeciągu 3 miesięcy. W tak krótkim czasie trudno było wprowadzić zmiany i sprawdzić, czy spowodowały oczekiwane efekty. Dodatkowo, moje cele nie były zbieżne z zespołowymi. Jak się pewnie domyślacie, w efekcie KPI’s nie były realnym punktem odniesienia ani dla mnie, ani dla zespołu. A szkoda. Zamiast ciągnąć kilka srok za ogon i to w różne strony, można było skupić się na tej najważniejszej. Całym zespołem.

Nieliczenie kosztów

W mojej pracy mocno skupiłam się na ulepszaniu, rozwijaniu produktu. Nie myślałam o realnych kosztach związanych z realizacją pomysłów, o nich myślał mój przełożony. Ja byłam jedynie osobą od badania rynku, kreatywnych rozwiązań, planowania i współpracy z zespołem. Błąd. Dzisiaj bardzo przekonuje mnie podejście, w którym Product Owner odpowiada również za budżet, albo przynajmniej ma go mocno na uwadze. Dzięki temu podejmuje bardziej przemyślane decyzje, intuicyjnie szuka sposobów jak najszybszego uzyskania feedbacku od użytkownika. A wreszcie, planuje prace w taki sposób, aby jego produkt przyrastał iteracyjnie, a nie był jedynie rozwijany w iteracjach. Różnicę pomiędzy tymi dwoma podejściami w ciekawy sposób opisał na swoim blogu Jacek Wieczorek w poście o znamiennym tytule: To Twój ostatni Sprint. Co robisz?

Pisząc o kosztach, mam na myśli koszt zespołu per sprint, miesiąc, release lub po prostu czas spędzony na przygotowaniu konkretnych rozwiązań. Warto dodać do tego również koszty związane z niezbędną infrastrukturą, jak choćby serwery, czy sieć, o których rzadko się pamięta, a to również wydatek. Ważne, żeby jako Product Owner w pełni świadomie dysponować czasem zespołu, a pracę nad rozwijaniem produktu traktować jak swój własny biznes.

Nieliczenie kosztów błędów i poprawek

Ten temat wydaje mi się na tyle istotny, że postanowiłam poświęcić mu oddzielny akapit. Być może gdzieś na świecie powstają produkty i usługi, w których nie pojawiają się błędy. Ja takich nie widziałam. Z perspektywy Product Ownera istotne jest, aby mieć świadomość skali tego zjawiska i zarządzać produktem całościowo – od rozwoju poprzez utrzymanie i błędy. Gdybyście zapytali mnie te kilka lat temu, czy zarządzam błędami, odpowiedziałabym, że tak. Uzgodniliśmy  z zespołem, co definiujemy jako “bug”, wiedziałam, z jaką ilością błędów mamy do czynienia, znałam ich wagę (wpływ albo potencjalny wpływ tych niepoprawionych na satysfakcję korzystania z serwisu w przyszłości) i czasochłonność. Wreszcie decydowałam, na które z nich poświęcamy czas. Ile go jednak realnie było? Jaki % swojego czasu zespół spędził (stracił!) na naprawianiu błędów i poprawkach? Tego już nie wiedziałam. A szkoda, bo właśnie taka wiedza dałaby mi całościowy obraz tego, na co wydajemy pieniądze i jak to się przekłada na dostarczanie wartości naszym użytkownikom.

Tyle ode mnie. Co jeszcze byście dodali do takiej listy błędów Product Ownerów?

 —

Źródło zdjęcia: https://stocksnap.io/photo/SCDVW6SSE2

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