Nie-techniczność Product Ownera nie jest problemem. Ich brak wizji produktu już tak. Oto 5 wskazówek dla początkujących Product Ownerów.
Piękno pracy w branży IT polega na tym, że podejmujesz nowe wyzwania praktycznie każdego dnia. Jednak objęcie roli Product Ownera w procesie rozwoju produktu cyfrowego było dla mnie dość onieśmielające, jako osoby pracującej w komunikacji przez większość mojej kariery.
Jestem szefem marketingu bez prawdziwego technicznego zaplecza. Zawsze więc zastanawiało mnie—czy naprawdę istnieje taka wielka różnica między technicznym a nietechnicznym Product Ownerem? Czerpiąc z moich ostatnich doświadczeń i kilku dyskusji, które miałem z programistami w naszym zespole, postanowiłem zebrać kilka wskazówek dla osób, które mogą znaleźć się w podobnej sytuacji.
5 wskazówek dla nowych i nietechnicznych Właścicieli Produktu
Przewaga techniczna nie musi być niesprawiedliwa
Nie ma sensu udawać, że nie ma różnicy między Product Ownerem z tłem technicznym a tym bez.
Techniczni Product Owners mają przewagę, jeśli chodzi o komunikację z zespołem deweloperskim lub bycie pośrednikiem między zespołem wewnętrznym a zewnętrznym dostawcą usług. Rozumieją techniczne niuanse i potrafią zaproponować rozwiązania oraz stworzyć historie użytkowników. Ustalanie kryteriów akceptacji jest dla nich naturalnym procesem.
Programiści, z którymi omawiałem tę kwestię, mówią, że chociaż dostrzegają różnicę między pracą z technicznymi a nietechnicznymi Product Owners, nie jest to automatycznie problem.
To, co jest kluczowe w roli Product Ownera, to:
- Maję jasną wizję produktu.
- Są zdecydowani i skoncentrowani.
- Maję motywację.
Miej jasną wizję swojego produktu
Mieć jasną wizję produktu to klucz do znacznie płynniejszego procesu rozwoju. Zrozumienie potrzeb użytkowników i klientów, posiadanie konkretnych celów na uwadze - to wszystko sprawia, że podejmowanie właściwych decyzji dotyczących projektowania i rozwoju jest nieskończono łatwiejsze. Niezwykle trudno jest stworzyć historie użytkowników i priorytetyzować funkcje, nie wiedząc dokładnie, co chcemy osiągnąć.
Musisz mieć cel na uwadze przez cały proces. Jaki jest cel tego komponentu? Jaka jest korzyść dla użytkownika? Jeśli nie jesteś pewien, jak tam dotrzeć - to w porządku, dlatego zatrudniłeś wykwalifikowany zespół. Ale jeśli nie znasz celu stojącego za funkcją, możesz mieć problem. To ty jesteś odpowiedzialny za cele biznesowe swojego rozwiązania.
Zawsze dobrze jest zacząć od swojego starego „DLACZEGO?” i „CO?”. To sprawi, że proces rozwoju skupi się na „JAK?”. A aby je ustalić, będziesz miał wsparcie całego zespołu deweloperskiego. Razem będziecie w stanie znaleźć najlepsze działające rozwiązanie.
Aby wyjaśnić wizję, możesz zacząć od Warsztatu Projektowania Produktu, który pomoże ci zorganizować cały proces rozwoju. Może to również pomóc uniknąć pułapki planowania zbyt wielu zadań naraz lub priorytetyzowania zbyt wielu funkcji na początkowe wydanie.
Nie bój się podejmować decyzji
Jeśli chcesz, aby praca przebiegała sprawnie, pamiętaj, że musisz być osobą, która podejmuje ostateczną decyzję. Nie zostawiaj tego programistom, aby decydowali, kiedy funkcjonalność jest gotowa. To ty wiesz, jakie potrzeby ma spełniać produkt. Programiści to zazwyczaj grupa mądrych ludzi — co często oznacza, że mają tendencję do komplikowania spraw. Chcą, aby funkcjonalność obejmowała wszystkie możliwe scenariusze użycia. Twoją rolą jest to uprościć, ponieważ nie chcesz skończyć z zbyt skomplikowaną funkcjonalnością.
Pracując z agencją deweloperską, warto również zrozumieć, że nie zamawiasz gotowego produktu cyfrowego — to nie jest sklep. Zamawiasz pracę od wykwalifikowanego zespołu, który zrobi wszystko, co w jego mocy, aby stworzyć produkt, który wymyśliłeś. Ale to nie jest tak, że jest gotowy. Musi zostać opracowany. I tylko właściciel produktu ma niezbędną wiedzę na temat tego, jak produkt będzie obsługiwany (strategia wprowadzenia na rynek, plany dalszego rozwoju, zespół odpowiedzialny za produkt wewnętrznie, użytkownicy itp.). Dlatego PO musi być osobą podejmującą ostateczne decyzje.
„Wprowadź tutaj motywujący cytat”
Właściciel produktu musi być zmotywowany, aby znaleźć najbardziej optymalne rozwiązania, a Ty możesz być tą osobą, nawet jeśli nie masz technicznego wykształcenia. Ale tylko wtedy, gdy znasz swoich użytkowników i naprawdę wierzysz w wartość, jaką Twój produkt może dodać do ich życia.
Ważne jest, aby być obecnym, nie zostawiaj zespołu deweloperskiego samego, ponieważ pozostawia to wiele miejsca na spekulacje co do tego, co miało być dostarczone. Nie chcesz, aby zespół stracił kontekst biznesowy swojej pracy. To Twoja rola, aby określić, co ma być dostarczone i opisać kryteria akceptacji. W przeciwnym razie możesz nie otrzymać tego, czego oczekiwałeś. Weźmy zadanie takie jak „panel logowania”: czy chcesz, aby użytkownik mógł logować się za pomocą profili w mediach społecznościowych? Których? A może powinno to być tylko przez e-mail? Rozumiesz, o co chodzi.
Zadawaj pytania
Byłem zaskoczony, jak wiele można się nauczyć, po prostu słuchając dyskusji zespołu technicznego. Ale nauczyłem się jeszcze więcej, zadając bezpośrednie pytania. „Czy to możliwe…?”, „Jaka jest różnica między…?” — myślę, że zadałem to pytanie setki razy podczas procesu rozwoju i nie żałuję tego. Czy to było irytujące? Może. Czy było to konieczne i pomocne na koniec dnia? Zdecydowanie. W końcu to był jedyny sposób, aby zapewnić nasze wzajemne zrozumienie i również świetne narzędzie do budowania zaufania. Zespół wiedział, że jeśli czegoś nie rozumiem, zapytam o to, zamiast kiwać głową i udawać, że wszystko jest jasne (co mogłoby generować problemy w dalszym etapie procesu).
Bycie Product Ownerem - podsumowanie
Bycie Product Ownerem to odpowiedzialna praca, ale bardzo satysfakcjonująca. Moja ostatnia rada brzmi: przyjdź przygotowany, znaj swoją wizję i nie stresuj się. Z odpowiednim zespołem u boku czeka cię wspaniała przygoda. A na końcu świetny produkt roboczy.
Sprawdź także
