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