Nie ma w tym nic zaskakującego – branża kojarzy nam się bezpośrednio z technologią i rozwojem oprogramowania.
W Softie – szkole IT prowadzącej kursy od podstaw, którą współtworzę nierzadko zdarzały się rozmowy z potencjalnymi kursantami, podczas których padały pytania „Który kurs możemy polecić?”, czy „W jakiej roli najłatwiej można obecnie znaleźć pracę?”. Dopiero w dalszym przebiegu rozmowy po odpowiedzi „To zależy” wielokrotnie dochodziliśmy do punktu, w którym zakres wiedzy na temat różnorodności ról i stanowisk w branży był bardzo niewielki.
Role w projektach IT
Zacznijmy jednak od początku – czy deweloper i programista to to samo? Tak, ale nie do końca. Programista, czyli osoba implementująca rozwiązanie jest jedynie członkiem zespołu deweloperskiego – co więcej zakres technologii i języków programowania, w których można się specjalizować jest bardzo szeroki, a więc wybór jednej ścieżki na początku kariery wydaje się bardzo trudny. W skład zespołu wchodzą jednak wszystkie osoby pracujące nad rozwiązaniem. Może to być tester (manualny lub automatyzujący), projektant (UX, UI), analityk biznesowy, DevOps, czy architekt. Lista ta oczywiście może być jeszcze szersza, w zależności od indywidualnych potrzeb każdego zespołu. Zdarza się też, że wybrane role są łączone.
Mając na uwadze fakt, że w zakres obowiązków zespołu deweloperskiego wchodzi przede wszystkim wdrażanie funkcjonalności możemy sobie wyobrazić, że zespół potrzebuje osoby odpowiedzialnej za przygotowywanie wymagań funkcjonalnych, czyli krótko mówiąc „zadań” dla zespołu. Tą osobą jest Product Owner – pośrednik między zespołem, a interesariuszami (klientami, użytkownikami, działem marketingu, sprzedaży, supportu itd.). Jego rolą jest regularne dostarczanie zespołowi potrzeb lub problemów użytkowników, które należy rozwiązać, zwykle w postaci nowych funkcjonalności systemu.
Poza przygotowywaniem wymagań Product Owner odpowiada za priorytetyzację, a więc określanie, które zmiany funkcjonalne przyniosą najbardziej pozytywne zmiany w aplikacji, np. wzrost sprzedaży, wydłużenie czasu przebywania użytkownika w aplikacji lub częstotliwość jego powracania, co w efekcie przekłada się na decyzje, nad którymi wymaganiami należy pracować w pierwszej kolejności.
Product Owner, a technologia
Praca Product Ownera to przede wszystkim przeprowadzanie badań i ciągły kontakt z interesariuszami. Podczas swojej pracy Product Owner stara dowiedzieć się co sprawi, że produkt będzie rósł w dobrym dla organizacji i użytkowników kierunku, a następnie przygotowane wymagania omawia z zespołem i przygotowuje plan pracy na kolejne iteracje. Scrum Guide, podręcznik i podstawowe źródło wiedzy na temat Scruma, bardzo konkretnie rozdziela rolę Product Ownera od zespołu deweloperskiego. Wskazuje, że Product Owner odpowiada za to „CO” powinno być implementowane, natomiast zespół deweloperski „JAK”. Oznacza to, że Product Owner bardzo często jest odizolowany od warstwy technologicznej aplikacji i nie ingeruje w takie szczegóły, jak sposób czy metoda implementacji, a interesuje go wyłącznie efekt końcowy – rozwiązanie problemów użytkowników systemu.
Rola Product Ownera jest niezależna i do poprawnego wykonywania obowiązków nie jest wymagana znajomość technologii i języków programowania. Często jednak w miarę doświadczenia i zrozumienia procesów rozwoju oprogramowania ta wiedza może okazywać się przydatna, by efektywniej zarządzać produktem.
Umiejętności miękkie
Praca Product Ownera jest pracą organizacyjną, analityczną i pełną kontaktów ze współpracownikami, klientami czy użytkownikami. To co najważniejsze z punktu widzenia pracy, jako Product Owner, to zbiór umiejętności miękkich. Wśród nich możemy wyróżnić:
- Komunikatywność – zarządzanie produktem wiąże się z ciągłym kontaktem, prowadzeniem spotkań, wywiadów czy prezentacji,
- Umiejętność negocjacji, priorytetyzacji i podejmowania decyzji – kiedy zakres wymagań rośnie, a wiele z nich ma wysoki priorytet dla różnych interesariuszy Product Owner musi samodzielnie zdecydować o kolejności wdrażanych rozwiązań,
- Planowania – na barkach Product Ownera leży nie tylko badanie potrzeb, ale też odpowiednie przygotowywanie wymagań dla zespołu deweloperskiego. Product Owner musi więc zarządzać wymaganiami tak, by zespół mógł pracować w trybie ciągłym, regularnie dostarczając kolejne, wartościowe dla użytkowników rozwiązania,
- Kontroli – Product Owner nie zarządza zespołem, a produktem – dąży do maksymalizacji jego wartości. W zakres jego pracy wchodzi więc regularna weryfikacja efektów pracy zespołu, testów (poprawności działania całej aplikacji), czy analityki (badania zachowania użytkowników w aplikacji).
Jak zostać Product Ownerem
Product Owner jest nazywany „encyklopedią produktu”. Jest osobą, która na temat produktu i branży, w której występuje wie praktycznie wszystko i jest w stanie odpowiedzieć na każde pytanie. Proces poznawania nowego produktu czy wchodzenia w nieznaną jeszcze branżę może okazać się długi, w szczególności, gdy nie pracowaliśmy wcześniej na stanowisku produktowym. Firmy, z uwagi na bardzo dobrą znajomość potrzeb użytkowników, często stawiają na osoby związane wcześniej z produktem, np. na osoby z działu marketingu czy obsługi klienta. Zdarza się, że na Product Ownera przebranżawiają się programiści pracujący wcześniej w tym samym projekcie i po czasie zmieniają stanowisko. Również podczas rekrutacji warto przygotować się merytorycznie pod kątem branży lub – jeśli produkt jest ogólnodostępnym narzędziem – z jego plusów i minusów, czy nawet konkurencji.
Nie jest to jednak wyłączna ścieżka – poza znajomością branży bardzo ważną rolę pełnią umiejętności organizacyjne, a więc sama predyspozycja do tej roli. Jeśli kandydat na to stanowisko ma wcześniej doświadczenie w prowadzeniu projektów w innych branżach (lub nawet w przypadku braku doświadczenia komercyjnego np. w projektach studenckich projektach non-profit) istnieje duża szansa na sprawne odnalezienie się w nowych realiach.
Na początku kariery warto rozważyć pracę na stanowisku juniorskim czy nawet stażowym. Nauka zakresu obowiązków pod okiem bardziej doświadczonych osób będzie bardzo pozytywnie wpływała na szybki rozwój umiejętności w prowadzeniu produktu. Przed poszukiwaniem pierwszej pracy warto również rozważyć naukę wiedzy teoretycznej na temat metodologii i frameworków, takich jak Scrum, Kanban, AgilePM, czy PRINCE2, a zdobyte certyfikaty przedstawić podczas rekrutacji, jako potwierdzenie wiedzy.
