Transformacja produktowa – droga od inżynierii do inżynierii produktu

Niektóre rzeczy dostrzec można dopiero z dystansu. I tak ja, po trzech latach pracy w Spartez dostrzegam swój udział w ważnym procesie transformacji. Wraz z niezastąpioną grupą liderów, zespół świetnych inżynierów pracujących w Spartez przekształciliśmy w zespół inżynierów produktu. Jaka to różnica? Ogromna! Opowiem wam o kilku mitach, które musieliśmy obalić i o tym jak wyglądała nasza droga do stania się organizacją produktową.

Mity

“To projekt technologiczny, nie potrzebujemy Product Managera”

Każda inwestycja w produkt wymaga decyzji PMa. To Product Manager jest odpowiedzialny za strategię i priorytetyzację inwestycji w produkt. Nie zrozumcie mnie jednak źle, PM nie podejmuje decyzji technologicznych – na tym najlepiej znają się inżynierowie. Jednak decyzje dotyczące tego gdzie i ile inwestować w produkt są domeną PMa. Przepisujemy kod? Oczywiście! Tylko jaką wartość będzie z tego miał użytkownik? Szybsza, bardziej wydajna aplikacja. Świetnie! Krótszy czas dostarczenia nowych funkcjonalności. Tak, jak najbardziej. Każda z tych decyzji to rozmowa o priorytetach, a przy tej rozmowie obecność Product Managera jest niezbędna.

“Dobry Product Manager produktu technologicznego musi być z wykształcenia inżynierem”

Z wykształcenia jestem psychologiem i filologiem angielskim, jednak od ponad 15 lat pracuję z inżynierami oprogramowania i bez trudności udaje nam się znaleźć wspólny język. Znam też doskonałych PMów, którzy z wykształcenia są fizykami czy specjalistami marketingu. Jako Product Managerowie odpowiedzialni jesteśmy za zdefiniowanie klienta docelowego, rynku oraz tego jakie problemy użytkownika będziemy adresować. Odpowiedzialność za decyzje dotyczące konkretnych rozwiązań technologicznych pozostawiam w rękach inżynierów. To proces ciągłego dialogu, wspólnie ustalamy co jest ważne, ile jesteśmy w stanie zainwestować i jaką wartość uzyskamy z danej inwestycji.

Oczywiście są obszary, w których wiedza techniczna może okazać się bardzo pomocna. Z mojego doświadczenia jednak w relacji Product Manager/Inżynier ważniejsze jest jasne zdefiniowanie obszarów odpowiedzialności w ramach każdej z tych ról. Przekraczanie ich przez każdą ze stron może mieć bardzo negatywne skutki. I tak PM może sugerować pewne rozwiązania technologiczne, podobnie jak inżynierowie powinni mieć swój udział w dyskusji o strategii produktowej. Ostateczna decyzja w każdej z tych dziedzin leży w rękach osób reprezentujących poszczególne role, a ich współpraca powinna opierać się na wzajemnym zaufaniu.

“Inżynierowie nie muszą rozmawiać z klientami, to rola Product Managera”

Obalenie tego mitu jest według mnie najważniejsze, jeśli chcemy zbudować organizację produktową. Do obowiązków Product Managera należy określenie segmentu odbiorców docelowych produktu, zdefiniowanie strategii, priorytetyzowanie obszarów, w które zespół/organizacja powinna inwestować, by zmaksymalizować wartość produktów. Nie oznacza to jednak, że Product Manager ma monopol na rozmowę z użytkownikami. Wręcz przeciwnie.

W procesie tworzenia oprogramowania to inżynierowie odgrywają kluczową rolę. Bez nich nie byłoby produktu. Product Managerowie mogą być autorami najpiękniejszej wizji i najskuteczniejszej strategii, w ramach której projektanci zaprojektują przyjazną użytkownikowi aplikację, ale tylko i wyłącznie zdolni inżynierowie są w stanie zrealizować ową wizję i dostarczyć produkt do rąk użytkownika. Właśnie dlatego tak ważne jest by inżynierowie rozumieli dla kogo budują i dlaczego rozwiązują właśnie ten konkretny problem. Rozmowa z użytkownikami nie tylko otwiera im oczy na to, jak produkt jest używany, ale przede wszystkim pozwala dostrzec szeroką paletę różnych rozwiązań problemu, nad którym właśnie się pochylają. Rozmowa z użytkownikami pozwala też zbudować z nimi relację opartą na empatii. Bezcenne!

Droga

Jeśli rozpoznajesz, że w Twojej organizacji pokutuje którykolwiek z opisanych przeze mnie mitów – zmień to! Od czego zacząć proces transformacji? Oczywiście każda organizacja jest pod wieloma względami wyjątkowa, ale postaram się podać Wam kilka uniwersalnych rad.

1. W centrum postaw użytkownika

Przeprowadź w organizacji krótki test. Zapytaj kilku inżynierów, czy wiedzą dla kogo budują oprogramowanie, kto z niego korzysta i w jakim celu. Jakie są największe problemy, z którymi zmagają się użytkownicy. Jeśli nie uzyskasz odpowiedzi na te pytania – trzeba interweniować. Zaplanuj wywiady lub sesje usability z użytkownikami. Jeżeli spotkania z użytkownikami już się w twojej organizacji odbywają się, jednak uczestniczą w nich tylko liderzy, projektanci i Product Managerowie, koniecznie zaproś na nie inżynierów. Z doświadczenia wiem, że inżynierowie czasem czują się skrępowani takimi spotkaniami. W końcu najbezpieczniej jest w zaciszu własnego kodu. Zapewnij ich, że sesja z użytkownikiem będzie dla nich wartościowym doświadczeniem . Nie muszą zadawać pytań. Wystarczy, że wysłuchają historii użytkowników, zapoznają się z rzeczywistymi zastosowaniami aplikacji, czy zobaczą, na jakie trudności napotykają użytkownicy korzystając z produktu.

W Spartez inżynierowie towarzyszą Product Managerom i projektantom podczas każdej rozmowy z klientem, prowadzą też rozmowy z użytkownikami produktów Atlassiana w czasie dorocznego Atlassian Summit. Rozumieją jaką wartość zyskuje ich praca, kiedy w centrum wszystkiego co robią postawią użytkownika i zbudują w sobie empatię do odbiorców napisanego przez nich kodu.

2. Zbuduj w organizacji “muskuł produktowy”

Chociaż od wczesnych lat mojej kariery odpowiedzialna byłam za kreowanie przyszłości produktu, nie od razu nazwałam się Product Managerem. Na naszym rynku to ciągle stosunkowo nowa rola, nie wszyscy do końca rozumieją za co odpowiedzialny jest Product Manager. Jakimi cechami powinna wyróżniać się osoba pełniąca w organizacji tę rolę? Czym Product Manager różni się od Product Ownera, czy Project Managera?

O roli Product Managera opowiadam szerzej w innym swoim artykule; dziś chciałam skupić się na tym, jak ważnym etapem na drodze transformacji w kierunku organizacji produktowej, jest zbudowanie silnego zespołu Product Managerów i projektantów.

Moim osobistym sukcesem jest to, że dziś, kiedy powstaje w Spartez nowy zespół, to liderzy zespołu inżynieryjnego zwracają się do nas z prośbą o zatrudnienie do zespołu Product Managera i projektanta, poświęcając na to inżynieryjne “etaty”. Nie zawsze tak było.

Product Managerowie, a także projektanci, pracują bardzo blisko z zespołami inżynieryjnymi i wspólnie z nimi podejmują decyzje dotyczące kolejnych strategicznie ważnych inwestycji.

Dla jasności, nie chodzi tu o zatrudnienie jednego Product Managera, który zajmie się pięcioma czy dziesięcioma strategicznymi obszarami. W taki sposób nie można pracować efektywnie. Product Managerowie muszą mieć szansę spędzić z inżynierami czas, zrozumieć sposób w jaki pracują. Dlatego w dynamicznie rozwijającej się organizacji ważne jest zbudowanie zespołu Product Managerów i przydzielenie im strategicznie ważnych obszarów, nad którymi pracują wspólnie z zespołami inżynieryjnymi. Z mojego doświadczenia Product Manager może zająć się jednym obszarem, Senior Product Manager – dwoma. To jednak również zależy od rozległości i znaczenia danego obszaru w szerszej strategii organizacji. Jednym i niezmiennym elementem jest bliska współpraca z inżynierami. Jeśli Product Manager nie ma na to czasu, to jasny sygnał, że ma w swoim portfolio zbyt wiele wątków.

3. Bądź “lean” i “agile”

Jaka jest najkrótsza definicja tego czym zajmuje się Produkt Manager? Esencją tej roli jest podejmowanie decyzji i komunikowanie ich. Brzmi banalnie, prawda? Jednak diabeł, jak zwykle, tkwi w szczegółach. Organizacja produktowa, aby odnieść sukces powinna w odniesieniu do obydwu tych elementów stosować dwie zasady: lean i agile. Choć nie jestem ekspertem ani od lean managementu, ani od technik agile, w swojej praktyce staram się jednak stosować połączenie obydwu filozofii.

Metodologia Lean, najczęściej kojarzy się z ciągłym doskonaleniem procesu poprzez minimalizację strat. Lean to jednak dużo więcej. Metodologia ta skupia się na nieustannym definiowaniu i tworzeniu wartości dla klienta oraz wspieraniu zespołu w tym, by potrafił samodzielnie rozwiązywać postawione przez nich problemy.

Ten ostatni element jest dla mnie szczególnie ważny. Zespoły produktowe, które zarządzane są za pomocą celów (managing by objectives), skoncentrowane na rozwiązywaniu problemów klientów i dostarczaniu wartości, samodzielnie podejmują decyzje i komunikują je swoim interesariuszom – tylko takie zespoły mogą być prawdziwie zwinne (agile).

Tak właśnie pracujemy w Spartezie. Zespoły wyposażone są w niezbędne kompetencje; w zespole pracuje product manager, inżynierowie, projektanci, analitycy danych, inżynierowie jakości. Dzięki temu mogą skutecznie przejąć odpowiedzialność za wybrany, ważny strategicznie obszar. W ramach tego obszaru zespoły mogą dzięki wsparciu product managera podejmować decyzje i w sposób iteracyjny, zwinny dostarczać wartość dla klienta.

Dlaczego warto?

Obalenie mitów i przejście kolejnych etapów transformacji wymaga zaangażowania wielu osób w organizacji. Nie zrobią tego sami tylko Product Managerowie czy projektanci, i z całą pewnością zbudowanie skutecznej organizacji produktowej nie jest możliwe bez wsparcia inżynierów. Nie mam jednak wątpliwości, że wysiłek zainwestowany w przeprowadzenie w organizacji takiej zmiany się opłaca.

W Spartezie obaliliśmy mity i przeszliśmy drogę, dzięki której zbudowaliśmy organizację skupioną na kliencie, sprawnie podejmującą decyzje produktowe i skutecznie komunikującą je zarówno wewnątrz, jak i na zewnątrz organizacji. Ale przede wszystkim w sposób ciągły dostarczamy klientom wartość i w oparciu o informację zwrotną korygujemy nasze priorytety. Na początku procesu transformacji nowa wersja Jiry Software Server i Data Center trafiała w ręce naszych klientów mniej więcej co 4-6 miesięcy, teraz klienci dostają nową Jirę co równe 6 tygodni. To działa!