To jest 277. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o karierze Product Ownera. 

Wszystko, co potrzebujesz, notatka, linki, transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/277. 

Partnerem dzisiejszego odcinka jest Sigma Software, która to może być idealnym miejscem dla Ciebie, jeśli szukasz kolejnego kroku w swojej karierze w IT. To firma z ponad 22-letnim doświadczeniem i zespołem liczącym ponad 2 tys. ekspertów na całym świecie. Realizuje nowoczesne projekty dla globalnych marek, takich jak AstraZeneca, Viaplay, Volvo czy Scania. 

Co wyróżnia Sigma Software? Ekscytujące projekty z obszaru fintech, motoryzacji, AI i chmury, elastyczne środowisko pracy, opcja zdalna, hybrydowa, jak i w nowoczesnych biurach w Polsce. Płaska struktura organizacyjna, liczą się pomysły i doświadczenia, możliwość rozwoju w międzynarodowym zespole. Jeśli szukasz firmy, która ceni innowacje, wiedzę i równowagę między pracą a życiem prywatnym, odwiedź ich stronę i sprawdź dostępne oferty pracy. Link znajdziesz w opisie tego odcinka. 

Nazywam się Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi z branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz, lub podzielenie się tym odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć! 

Osoba, którą goszczę dzisiaj w podcaście to ekspertka z ponad 8-letnim doświadczeniem w dziedzinie analizy biznesowej i Product Ownership’u. W Szkole Product Ownera prowadzi kursy i dzieli się swoją wiedzą. Moim i Waszym gościem jest Natalia Cholewa. 

Cześć, Natalia, bardzo miło mi gościć Cię w podcaście. 

 

Cześć, Krzysiek, bardzo mi miło być gościem. 

 

Cieszę się bardzo. Dzisiaj będziemy rozmawiać o karierze Product Ownera, jak ją rozpocząć, co jest potrzebne do awansu i na czym polega rola Product Ops. Ale zanim na te wszystkie pytania odpowiemy, to chciałbym Cię, Natalia, zapytać, czy słuchasz podcastów? Być może jakieś ciekawe audycje będziesz w stanie zarekomendować? 

 

Oczywiście, że słucham podcastów. To jest coś, co mi towarzyszy w takich zadaniach, które nie zajmują głowy, jak sprzątanie, składanie prania. Każdy, kto prowadzi swój dom, wie, ile takich zadań jest. Mam takie branżowe bardziej i mam takie mniej branżowe. 

Tak że z branżowych uwielbiam słuchać podcastu Techstorie. To jest taki podcast, który mówi o technologiach, ale w takim ujęciu biznesowo-społecznym, więc bardzo lubię tego słuchać. Lubię też podcast Technologicznie od Jarka Kuźniara i czasami Bartka Pucka. Bardzo dużo fajnych przemyśleń. Z takich niebranżowych, bym powiedziała, to jestem fanem podcastu Dział Zagraniczny, który mówi o takich randomowych różnych tematach, bardzo ciekawych, więc można się dużo dowiedzieć. I ponieważ jestem mega fanem Formuły 1, to moim ulubionym podcastem jest Budnik i Pokrzywiński z takim polotem prześmiewczym, więc to jest taki mega odprężający. 

 

To mocne rekomendacje jak najbardziej i można się pod tym wszystkim podpisać. 

Dobrze, Natalia, myślę, że powinniśmy sobie na początku odpowiedzieć na pytanie, czym właściwie zajmuje się Product Owner, żeby dalej wchodzić w głąb i meandry tej roli, więc gdybyś mogła tak definicyjnie i ze swojego doświadczenia powiedzieć, co właściwie na co dzień robi Product Owner, to byłoby świetne rozpoczęcie naszej rozmowy. 

 

Definicyjnie rzeczywistość, zwłaszcza w polskim IT, to są dwie różne rzeczy, bo definicyjnie Product Owner to jest właściciel produktu. Przez właściciela produktu, tak bardzo książkowo, to rozumiemy, że on decyduje w zasadzie o całości produktu, ma jakiś budżet, jakieś zasoby itd. To się nie wydarza najczęściej, bo bądźmy szczerzy, w związku z tym to jest taka rola wspierająca i łącząca świat biznesu ze światem IT, czyli współpracujemy z biznesem i z zespołem developerskim, żeby przetłumaczyć jeden język na drugi, czyli język potrzeb biznesowych na język developerski i w drugą stronę, tak najkrócej jak się da. 

 

Wiesz, często mam wrażenie, że jest ta rola mylona albo łączona, albo wręcz w jednej osobie się gromadzi z rolą Project Managera. Często mówi się PM, myśli się o Product Ownerze i odwrotnie, a więc gdybyśmy na początku mogli sobie rozwijać właśnie te wątpliwości i powiedzieć, czy właściwie PO różni się od PM, to byłoby świetnie. 

 

Tak, to jest bardzo częsty problem, mylenia tych ról. Bardzo niesprawiedliwie dla jednej i dla drugiej strony, bo ja mam ogromny szacunek do Project Managerów, którzy siedzą w kontraktach, w budżetach, w tabelkach, w zasobach. To jest wszystko to, czym ja bym się nie chciała zajmować na co dzień, dlatego że moją pasją i moim obszarem zainteresowania jest produkt i dostarczenie wartości, która zaspokoi potrzebę biznesową bądź użytkownika, różnie możemy na to patrzeć.

Czyli my jako Product Ownerzy, analitycy, biznesowi, Product Managerowie, bo to też wymiennie się stosuje w polskim IT, my jesteśmy skupieni na produkcie. Project Manager, jak sama nazwa wskazuje, jest skupiony na projekcie, więc znacznie szerszy obszar. On się już nie wgryza w wymagania produktowe, ale właśnie zapewnia to wszystko, co pozwala nam dostarczać te projekty. 

Czyli zarządza zasobami, trakuje ile spaliliśmy godzin, ile zużyliśmy budżetu, nadzoruje umowy z klientami. Tak że wszystko to, co pozwala nam realnie funkcjonować w projektach. 

 

Czy wobec tego ta rola Product Ownera jest pewnym takim, wiesz, elementem składowym roli Project Managera, czy też jest tutaj, te rzeczy są rozłączne, jakbyś to mogła zdefiniować? 

 

To zależy od firmy, dlatego że tak, ja jestem nauczona do pracy z Project Managerami i my się nie zazębiamy, jeżeli chodzi o nasze kompetencje. To oczywiście wynika też z tego, że jasno sobie rozdzielamy te kompetencje i mamy do siebie zaufanie, w związku z tym to może tak funkcjonować. Wielu Product Ownerów robi pracę Project Managera i wielu Project Managerów robi pracę Product Ownera. Widzę to w swoich kursach. Niejednokrotnie nawet do szkoły Product Ownera przychodzą Project Managerowie, bo po prostu zajmują się tym obszarem, bo firma nie wyspecjalizowała sobie obszaru obok. I często jest tak, że Product Owner zadaje mi pytania na kursach, które są zupełnie poza zakresem wymagań i produktu i tak to często wygląda z jednej i z drugiej strony.

Tak że ja lubię rozłączność tych ról, dlatego że nikt z nas nie jest dobry we wszystkim i ja nie lubię siedzieć w tabelkach, umowach i liczbach, takich niezwiązanych z produktem, więc ja sobie bardzo cenię Project Managerów w swoich projektach.

 

Powiedziałaś, jak to powinno w teorii wyglądać i że w rzeczywistości bardzo trudno jest uzyskać właśnie ten ideał. Wspomniałaś tutaj o rynku polskim. Czy masz jakieś rozeznanie, że powiedzmy na rynkach zagranicznych, Europa Zachodnia, Stany to wygląda inaczej, czy też życie idzie tutaj swoim torem i gdzieś odchodzimy od definicji, powiedzmy?

 

Polska tak ma swoje za uszami, że tak powiem, bo u nas po prostu ta konwencja nazewnictwa chyba wynika z tego, że my w większości jednak pracujemy w software house’ach. W związku z tym ciężko zdefiniować rolę Product Ownera jako właściciela produktu, bo nie pracujemy po prostu dla firm produktowych często.

Jeżeli chodzi o Stany, to tam jest zupełnie inne to podejście. Tam większość firm to są firmy produktowe. Jeżeli potrzebują wsparcia, to korzystają ze wsparcia firm software house’owych i pojawia się ten sam problem. Natomiast tam jest dużo większe zrozumienie dla tych ról i dla rozgraniczenia.

W Europie bywa różnie, ale to właśnie skupiamy się na tym, czy pracujemy w firmie produktowej, czy nie. Bo moje doświadczenia z pracą z rynkami włoskimi, angielskimi, szwajcarskimi czy niemieckimi, jest takie, że oni to bardzo rozumieją, to rozgraniczenie.

 

Jak wobec tego zacząć z tą rolą? Od czego tutaj byś radziła czerpanie wiedzy, czy może jakieś ciekawe źródła tej wiedzy mogłabyś polecić?

 

To zależy, ulubiona odpowiedź wszystkich konsultantów, ale to zależy od tego, czy już w jakiś sposób jesteśmy w IT, w sensie jesteśmy testerem, pracujemy na supportcie, jesteśmy Project Managerem, chcemy się specjalizować. Ta ścieżka wtedy jest trochę inna, bo wtedy najlepiej byłoby się zorientować po prostu u nas wewnętrznie w firmie, czy taka rola istnieje i co trzeba zrobić, żeby taką rolę objąć.

Jeżeli jesteśmy zupełnie spoza IT, jest ta ścieżka w tej chwili troszkę trudniejsza, mało jest ofert dla juniorów, więc warto nie zamykać się tylko na te ogłoszenia Product Ownera czy analityka biznesowego, tylko właśnie też testera i customer support, bo łatwiej się dostać po prostu do tych miejsc i tak długofalowo zaplanować sobie tę karierę.

Ale bez względu jakby na rolę, przede wszystkim musimy nabyć wiedzy, no bo kompetencje to jest wiedza, umiejętności i postawy, tak? Więc najpierw zdobądźmy wiedzę, z tej wiedzy będą się budować umiejętności, czyli jak przykładowo wiemy, czym są wymagania, skąd one się biorą, jakie są rodzaje wymagań, w jaki sposób możemy je zapisywać itd., to tylko wtedy możemy budować już umiejętności budowania dokumentacji. I dopiero jak mamy te dwie rzeczy, to możemy sobie jakieś postawy wypracować.

Ja bardzo lubię w ogóle pracować w polskim IT i jak rozmawiam ze znajomymi, którzy nie pracują w IT, to zawsze mam takie, że żyjemy w bańce. U nas Ownership jest dużo większy niż w jakiejkolwiek innej branży. U nas taka płaska struktura, nawet jak masz wielką strukturę w firmie, to i tak możesz pogadać z każdym normalnie. Nikt tam cię nie zarzuci jakimiś pretensjami, że porozmawiaj sobie z szefem oddziału, unikając swoich liderów po drodze. My jesteśmy otwarci na taką komunikację, my jesteśmy też otwarci na feedback.

Ja tutaj zawsze zazdroszczę programistom. Dlatego, że oni mają code review. To jest takie, że my czegoś takiego nie mamy i zawsze im tego zazdroszczę, ale my jesteśmy przygotowani, my jesteśmy wyuczeni w tej kulturze feedbackowej, że nie oceniamy osoby, tylko oceniamy pomysły, pracę, pomagamy sobie itd. Więc to też jest bardzo ważne, żeby taką postawę sobie wyrobić, jeżeli do tej pory nie pracowaliśmy w takim środowisku.

 

No tak, zgodnie z tym podejściem Scrumowym, Product Owner jest częścią zespołu, prawda? Więc siłą rzeczy musi się wpasować w te zasady, albo te zasady są wspólne dla wszystkich członków tego zespołu, który na koniec dnia ma coś dowieść. Chciałem Cię zapytać o taką jedną rzecz, jeden wątek, który tutaj wspomniałaś, że trudniej jest osobom spoza IT właśnie wskoczyć w tą rolę Product Ownera w zespołach związanych z IT, bo brakuje, powiedzmy, na ten moment ofert dla juniorów.

Czy tutaj w przypadku Product Ownera też jest taka klasyczna gradacja na juniora, mida, powiedzmy regulara, seniora, bo jakiś czas temu zastanawiałem się z kimś, że w przypadku tych ról takich wokoło technicznych właśnie chociażby w takim wydaniu Scrumowym, rzadko widzi się np. ogłoszenia na junior Scrum Mastera, prawda? Raczej ktoś poszukuje Scrum Mastera. Zastanawiam się, czy w przypadku Product Ownera jest podobnie, czy tutaj jednak mamy te szczeble kariery takie klasyczne?

 

Mamy, mamy, dosyć klasyczne i jakbym miała to tak podzielić, to junior to jest taki requirement engineer. Czyli skupiamy się na wymaganiach, napisaniu kryteriów akceptacji i I cała ta ścieżka polega na tym, że coraz bardziej stajesz się partnerem dla biznesu.

I tak jak junior nie chce się wychylać w takim sensie, że nie będzie traktowany jako partner ze względu na swoją wiedzę biznesową jeszcze i właśnie brak tej wiedzy i doświadczenia, to jak ja przychodzę na spotkanie z obojętnie jaką wielką firmą, ja nie mam problemu z powiedzeniem: nie, tego tak nie zrobimy.

Bo liczby mówią to i to, w sensie to nie jest sama umiejętność powiedzenia nie i wypchajcie się i tego nie zrobimy, tylko chodzi o to, że stajemy się takim partnerem, bo znamy branżę, wiemy jak biznes funkcjonuje, wiemy, skąd biorą się pieniądze, znamy swój produkt, znamy swoich użytkowników, potrafimy to przebadać i potrafimy doradzić biznesowi, że tak, to jest dobra inicjatywa, w którą wkładamy pieniądze, albo nie, to nie jest najlepsza inicjatywa. 

Rozumiemy, skąd taka potrzeba przychodzi, natomiast uważamy, że lepiej można wykorzystać te pieniądze w inny sposób, przez pieniądze oczywiście rozumiejąc też po prostu czas developerów, bo nie zapominajmy, że nie zawsze będziemy mieli jakiś budżet określony, z którym przyjdzie klient, tylko np. mamy zespół na tzw. time and material, więc po prostu pracują stale, ale to są ostatecznie też pieniądze.

Im szybciej zrozumiemy, bo to jest też często, się spotykam z tym, że nie wszystko się robi dla pieniędzy. No kurde nie, w biznesie wszystko się robi dla pieniędzy. Im szybciej to zrozumiemy, że biznes jest po to, żeby generować pieniądze, te pieniądze opłacają nasze wynagrodzenie, tym będzie dla nas lepiej.

Więc nawet jak jakaś firma robi non-profit, to nie robi go z dobrego serducha, bo firma nie ma serducha, tylko coś za tym się kryje. Tak że im szybciej to zrozumiemy, zrozumiemy, jak funkcjonuje biznes, skąd się biorą te pieniądze, skąd się biorą koszty, no to właśnie przy tej ścieżce od juniora do leada, to w zasadzie to jest największe wyzwanie: poznać ten biznes i być takim partnerem, i umiejętnie się komunikować też z tym poziomem tak zwanym C-level, czyli tych wszystkich prezesów.

 

Tak, i tutaj co prawda to będzie off topic, ale myślę nawiązując do tego co powiedziałaś, nam Polakom brakuje takiego zrozumienia, że zarabianie to nie jest nic złego, że firmy istnieją po to, żeby zarabiać i to jest właśnie motor gospodarki. Jeszcze pewnie troszkę musi wody w Wiśle upłynąć, zanim faktycznie to zaakceptujemy i będzie to dla nas po prostu normalne, nie ma w tym nic złego, tak jak tutaj też powiedziałaś.

Wiedza, umiejętności i postawy, to jest to, co zaznaczyłaś. Jakieś źródła wiedzy mogłabyś wskazać? Może nawet niekoniecznie precyzyjnie adresy, tylko chodzi mi o raczej, z jakich tutaj kanałów możemy tę wiedzę czerpać, właśnie myśląc o zostaniu Product Ownerem.

 

Tak, żyjemy w takich pięknych czasach, że wiedza jest dostępna w zasadzie wszędzie. Warto jednak zweryfikować źródło tej wiedzy. Na samym początku warto opierać się na dobrych standardach, na dobrych sprawdzonych źródłach. Mamy całe zasoby związane ze Scrumem, mamy całe zasoby związane z analizą biznesową, jest organizacja IIBA, która się tym dzieli też, nieskromnie wspomnę tu mojego bloga, ale też innych osób działających na rynku IT, które do tych standardów się stosują.

Dlaczego o tym wspominam, że to jest takie ważne? Bo ja nie jestem fanem certyfikatów. Generalnie nie uważam, że certyfikat to jest potwierdzenie jakichkolwiek umiejętności, to jest potwierdzenie wiedzy. Natomiast żeby coś móc zakwestionować i żeby móc coś zmienić, musimy wiedzieć bardzo dobrze, skąd to się bierze i jakie są podstawy.

Więc przykładowo, jeżeli wiemy, że jakiś proces jest z oka w firmie, to nic nie osiągniemy, krytykując go na początku  i próbując go zmienić. Więc ja zawsze mówię, że najpierw wymasteruj ten proces, jaki jest, taki jaki on jest. Udowodnij, że jesteś w stanie za nim podążać, bo jak to udowodnisz, to wtedy łatwiej będzie Ci wprowadzać zmiany i komuś coś zasugerować, bo on widzi, że Ty współpracujesz, a nie jesteś na nie na dzień dobry.

W związku z tym tak samo jest z tą wiedzą. Najpierw zacznijmy od standardów, a później w miarę swojego doświadczenia zweryfikujmy, czy to jest zgodne z tym, jak my pracujemy, do naszych projektów, ale to znowu mówię, żeby coś zakwestionować, to trzeba wiedzieć, co kwestionujemy w ogóle.

 

No tak, ta podstawa, te fundamenty, one zawsze zostają, one są niezmienne, nawet jeśli ta nadbudówka, czy też liczne narzędzia, które wykorzystujemy, się zmieniają, no to cały czas podstawy są niezmienne. Chciałbym Cię zapytać, co obecnie jest takiego hot na rynku, jeśli chodzi o kompetencje, czego pracodawcy szukają, poszukując kogoś właśnie do roli Product Ownera, na co tutaj trzeba się nastawić, albo w jakie kompetencje wyposażyć?

 

Na tę chwilę to AI. Jest to rewolucja, która nas dotyka. Zobaczymy, jak ta rewolucja przebiegnie, bo na tę chwilę moim zdaniem nie jesteśmy w stanie nic powiedzieć. Niemniej jednak zrozumienie, jak działa sztuczna inteligencja, jak można ją włączać w produkty i umiejętność wykorzystywania jej na co dzień, to jest jedna z rzeczy, która się pojawia już coraz częściej w ogłoszeniach.

Jak obserwuję, kiedy zaczynałam w zeszłym roku z kursem AI Product Owner, to tych Ogłoszeń było tam raptem parę. Jak chciałam stworzyć, popatrzcie, tutaj już potrzebują takich kompetencji, to było tego dosłownie parę na stronach naszych branżowych z ogłoszeniami o pracę. Teraz w co drugim ogłoszeniu są już te wymagania, więc myślę, że to jest coś, z czym trzeba się oswoić.

A poza tym, oprócz takiej klasycznej wiedzy o wymaganiach, o potrzebach, o tym jak działa Scrum, to nieszczęsne narzędzia jeszcze zostają. Czyli umiejętność Jiry i Confluense’a, bo to jest taki standard, jeżeli chodzi o zarządzanie wymaganiami.

Mówię nieszczęsne nie dlatego, że nie lubię, bo ja akurat jestem fanem Jiry i Confluense’a spośród tego, co mamy do wyboru. Bo to jest trochę jak z demokracją, nie jest idealna, ale nic lepszego jeszcze człowiek nie wymyślił, więc tutaj z tą Jirą i Confluencem trzeba się dobrze zapoznać, bo to nie chodzi o to, żeby znać narzędzia dla znania narzędzia, to chodzi o to, żeby te narzędzia nam pomagały, a nie przeszkadzały, więc to są takie rzeczy, na których na pewno trzeba się skupić teraz.

Mówię nieszczęsne nie dlatego, że nie lubię, bo ja akurat jestem fanem Jiry i Confluense’a spośród tego, co mamy do wyboru. Bo to jest trochę jak z demokracją, nie jest idealna, ale nic lepszego jeszcze człowiek nie wymyślił, więc tutaj z tą Jirą i Confluencem trzeba się dobrze zapoznać, bo to nie chodzi o to, żeby znać narzędzia dla znania narzędzia, to chodzi o to, żeby te narzędzia nam pomagały, a nie przeszkadzały, więc to są takie rzeczy, na których na pewno trzeba się skupić teraz.

 

Myślę sobie, że to są takie narzędzia, które jesteśmy w stanie opanować albo przynajmniej zaznajomić się, pracując nawet w innych rolach. Nie wymagamy tutaj dostępu, który jest, powiedzmy, tylko jak już jesteś w tej korporacji, bo inaczej nie jesteś w stanie się tego dostać. Jesteś w stanie poćwiczyć z AI, jesteś w stanie przejść jakieś kursy, jesteś w stanie nawet z Jirą i Confluencem się pobawić, jakoś te swoje kompetencje poszlifować.

 

Tak, bo Jira i Confluence zasadniczo są bezpłatne w takich małych organizacjach, więc można sobie samemu stworzyć, poklikać. Oni mają też bardzo dużą bazę wiedzy, więc jeżeli ktoś nie chce inwestować swoich pieniędzy w jakiś konkretny kurs na ten temat, które też są dostępne na rynku, to sama baza Confluense’a, w sensie Atlassiana, jako samouczki też jest wystarczająco duża, żeby się o to oprzeć.

 

A jak wygląda, powiedzmy, taki background zawodowy osób, które wskakują właśnie w rolę Product Ownera? Czym najczęściej z Twoich obserwacji te osoby zajmowały się wcześniej? Jakie może mają wykształcenie? Czy jest coś, co łączy tą grupę, czy tutaj jest rozstrzał bardzo szeroki i duży?

 

Jedyne co łączy tę grupę, to jest niesamowita determinacja do tego, żeby zostać Product Ownerem bądź analitykiem biznesowym, bo background naprawdę jest mega, mega różny i nawet nie mogę powiedzieć, że z jakiejś branży częściej przychodzą ludzie, czy nie, dlatego, że ja już jakby „przerobiłam” kursantów z backgroundem logistycznym, nawet kiedyś pracowałam z osobą, która była kontrolerem lotów, księgowe, sprzedaż, pośrednictwo farmaceutyczne, budownictwo, przeróżne branże, naprawdę, bo też to doświadczenie wcześniejsze może być mega, mega atutem na początek pracy.

Dlatego że szybciej, jeżeli mamy projekt w bardzo wąskiej, specjalistycznej branży, czyli np. nie e-commerce, nie robimy sklepu jakiegoś, czy coś w tym stylu, tylko np. właśnie tworzymy oprogramowanie dla lotnictwa, to jak my przechodzimy jako były kontroler lotów, no to jakby znajomość branży jest już na takim poziomie, że zanim ktoś nawet z kompetencjami Product Ownerskimi dojdzie do tego poziomu, no to tamten już wszystko załatwi, nie? Bo umiejętność pisania kryteriów akceptacji można dużo szybciej zdobyć niż wiedzę domenową z zakresu jakiejś bardzo wąskiej branży.

 

To może być akurat na plus te nasze wcześniejsze doświadczenia, prawda? Ta znajomość tej domeny właśnie może być naszym atutem. Warto to wykorzystać nawet w rozmowie kwalifikacyjnej.

 

Tak, zdecydowanie. I ja zawsze mówię, że w CV, żeby wpisywać te domeny, które znamy. Jeżeli pracowaliśmy w księgowości, w HR-ach, nawet w McDonaldzie, to znajomość systemów sprzedaży, to wszystko jest istotne. Bardziej właśnie niż role techniczne, to znajomość tych domen biznesowych jest mega ważna, więc to jest coś, co właśnie mówię, juniorom jest teraz trudno, spoza branży, ale to może być taki mega asset przy rekrutacji, że ktoś już zna tą branżę, więc przynajmniej tego nie będzie musiał się uczyć.

 

A czy jeśli chodzi o rodzaj firm, wiesz, myślę o takim klasycznym podziale software house’y, startupy, slash, firmy produktowe i korporacje, to czy ta praca codzienna Product Ownera wygląda inaczej, czy może nawet, wiesz, więcej któryś z tych gatunków, rodzajów firm zatrudnia właśnie osób na to stanowisko? Jak to wygląda?

 

Tutaj nie ma jasnego podziału, dlatego że są duże korporacje, które nie mają w ogóle analityków biznesowych i nie rozumieją, po co oni mieliby być, i to wtedy robią Project Managerowie. Są takie organizacje, do których, w sensie ja tak zaczęłam, dostałam się do firmy, która już wtedy miała 100 analityków. I to był super start, dlatego że było biuro analizy biznesowej, były standardy, były templatki, dostałam mentora, to jest super wyjście.

Więc jeżeli szukamy firmy i mamy komfort wybierania firmy, to nie ma znaczenia, czy to jest duża firma, czy to jest mała firma, znaczenie ma, czy będziecie mieli od kogo się uczyć. Bo ja widziałam wiele osób, w sensie to zawsze są inteligentni, fajni ludzie, którzy tracą mnóstwo czasu na tworzeniu standardów, procesów, które już ktoś kiedyś stworzył i mógłby ich nauczyć. Ale jeżeli nie masz się od kogo uczyć, to sam musisz to wypracować, więc jeżeli mamy komfort wyboru, to ja zawsze pójdę w stronę tego, że mam się od kogo uczyć.

Tak wybierałam każdą kolejną moją rolę, jak zmieniałam pracę, to zawsze było dla mnie istotne, czy ja będę miała jak się rozwijać i od kogo się uczyć. Do pewnego momentu, bo do pewnego momentu uczymy się sami, a później uczymy się przez uczenie innych, więc w pewnym momencie w mojej karierze już poszłam bardziej w lead Product Ownera, czyli oprócz robienia projektów, to zarządzanie zespołem Product Ownerskim i tworzenie razem z nimi tych standardów, bo to wtedy człowiek też się bardzo dużo uczy.

Ja w ogóle uwielbiam pracować z juniorami, bez względu na to, czy to Product Owner, czy to programista, czy tester. To jest zawsze tak świeża perspektywa i tak wybijająca z butów doświadczone osoby. Uwielbiam tą perspektywę, bardzo dużo się uczę od takich osób zawsze.

 

Powiedziałaś tutaj sporo o starcie, jakie kompetencje są potrzebne, czym się kierować przy wyborze firmy. Kiedy już mamy tę pracę, już spędziliśmy trochę czasu, to przychodzi być może jakiś apetyt na awans. W związku z tym chcę Cię zapytać, co wyróżnia takiego dobrego Product Ownera i jak właśnie na ten awans sobie zasłużyć, co zrobić, żeby awansować?

 

Moim zdaniem, żeby awansować, to w każdej roli musisz rozwiązywać więcej problemów, niż generujesz, tak ogólnie rzecz biorąc. I to jest coś, nie wiem czemu, często niezrozumiałe. W sensie chodzi mi o to, że jeżeli masz z czymś problem, to po pierwsze idź z propozycją rozwiązania. Nawet jak ona nie zostanie przyjęta, to pokazujesz, że jesteś nastawiony na rozwiązanie tego problemu. Bo to nie chodzi o to, żeby siedzieć jak mysz pod miotłą i się nie odzywać jak nic nie działa, tylko chodzi o to, żeby być częścią rozwiązania tego problemu.

To tyczy się wszystkich ról, ale jeżeli chodzi o Product Ownera, to właśnie chodzi o ten fokus na biznes, że jeżeli przychodzi klient i mówi: my potrzebujemy takiego czegoś, że tu będzie przycisk, a tu będzie coś tam, a tu będzie coś tam, to my dojdźmy do tego, po co to jest zrobione, po co my to chcemy zrobić, dlaczego to jest ważne i jaką potrzebę my chcemy zaspokoić, bo bardzo często właśnie na początku jesteśmy tacy jakby przestraszeni, że przecież klient wie, czego chce.

To jest bzdura. Klient nie wie, czego chce. Klient co najwyżej wie, czego potrzebuje, jak go dobrze zapytamy, ale bardzo często nie wie, czego chce i to jest coś, czego się uczymy z czasem.

Więc ta umiejętność nieprzyjmowania od razu wszystkiego, co klient nam mówi jako pewnik, tylko walidacja, weryfikacja, zaproponowanie alternatywnego rozwiązania, zrozumienie takich pain pointów biznesowych.

Są takie sytuacje, kiedy klient przychodzi i mówi, że coś szybko trzeba zrobić, że mają problem i coś szybko trzeba rozwiązać. I tutaj mamy dwie ścieżki. Możemy skupić się na tym problemie i znaleźć razem z zespołem, bo nigdy się nie jest samemu. Jak powiedziałeś, Product Owner jest częścią zespołu, więc angażując zespół, znajdujemy jak najprostsze, jak najszybsze rozwiązanie tego problemu, choćby na już, a pełne rozwiązanie dostarczymy później, informujemy w jakich etapach itd. Albo możemy powiedzieć, że to zajmie z miesiąc. I tutaj macie road mapę, my to wszystko zrobimy, ale to za miesiąc. Szybciej się nie da. 99% przypadków da się szybciej rozwiązać. 

Czasem w nieładny sposób, nie ukrywajmy, że to później boli wszystkich. Natomiast chodzi o to, że jeżeli my zrozumiemy, że to jest naprawdę duży problem biznesowy i to zaadresujemy, to od razu zyskujemy też w oczach biznesu.

A drugą rzeczą jest to, że ja zawsze powtarzam, że klient nie musi nas lubić, my nie chodzimy z nim na piwo, my mu się nie zwierzamy z problemów, ale klient musi nam ufać. Więc jeżeli powiemy, że coś zrobimy, to zrobimy to. I to jest takie dla mnie zero-jedynkowe, tutaj nie ma odstępstw od tego.

Oczywiście pomijam sytuacje losowe, bo takie się zdarzają, ale chodzi mi o to, że jeżeli mimochodem na spotkaniu rzuciliśmy, dobra ja się tym zajmę, no to się, kurde, tym zajmijmy. To, że to nie zostało spisane przez kogoś, to nas nie zwalnia z tego ownership’u. I to jest taka rzecz, którą wiem, że wyróżnia mnie i osoby z moich zespołów, że nawet jak się nie znosimy z klientem, bo też miałam taką sytuację, gdzie bardzo źle mi się pracowało z klientem, bardzo… No tak szowinistycznie podchodził do pracy i tak generalnie bardzo nie lubiłam z nim pracować, to on i tak wiedział, że jak coś ustaliliśmy, jak coś się miało zrobić, to się zrobiło i jak odchodziłam z projektu, to był autentycznie zawiedziony, więc to, że nie było chemii między nami, że się nie lubiliśmy, nie miało żadnego znaczenia, ale po prostu były dowożone rezultaty.

Są takie sytuacje, kiedy klient przychodzi i mówi, że coś szybko trzeba zrobić, że mają problem i coś szybko trzeba rozwiązać. I tutaj mamy dwie ścieżki. Możemy skupić się na tym problemie i znaleźć razem z zespołem, bo nigdy się nie jest samemu. Jak powiedziałeś, Product Owner jest częścią zespołu, więc angażując zespół, znajdujemy jak najprostsze, jak najszybsze rozwiązanie tego problemu, choćby na już, a pełne rozwiązanie dostarczymy później, informujemy w jakich etapach itd. Albo możemy powiedzieć, że to zajmie z miesiąc. I tutaj macie road mapę, my to wszystko zrobimy, ale to za miesiąc. Szybciej się nie da. 99% przypadków da się szybciej rozwiązać. 

 

Profesjonalizm to jest to, co musi nas wyróżniać i odpowiedzialność za pracę. To wyciągnąłem z tego, co przed chwilą opowiedziałaś, jako najważniejsze elementy.

Dobrze, czy jest coś takiego jak standardowy dzień pracy Product Ownera? Jednym słowem mówiąc, czym tak naprawdę zajmuje się Product Owner? Jakie obowiązki? Może jakieś przykłady, gdybyś mogła podać, to byłoby świetnie.

 

Więc nie, nie ma standardowego dnia, ale ja po prostu zbiorę nasze zadania, które robimy powiedzmy w ciągu sprintu, bo to różnie sobie ludzie układają pracę, ale mniej więcej wygląda to tak, że to wszystko co teraz powiem dzieje się równocześnie.

Ale tak, na pewnym etapie przychodzą do nas potrzeby, które trzeba zaspokoić. Źródła są przeróżne. Jeżeli jesteśmy na poziomie juniorskim, to prawdopodobnie ktoś nam wręcza już zwalidowane potrzeby, że to po prostu trzeba zaadresować. Im dalej w las, im wyżej jesteśmy, to sami też generujemy takie potrzeby, badając produkt, badając zachowanie użytkowników, sami wymyślając.

Następnie przechodzi taki proces dospecyfikowania, możemy to nazywać refinementem, ale generalnie chodzi o to, żeby doprecyzować, jakby zaadresować tę potrzebę poprzez wymaganie. Czyli jakieś znaleźć rozwiązanie, które zaspokoi tę potrzebę i wtedy piszemy niektórzy user stories, niektórzy inny rodzaj specyfikacji z kryteriami akceptacji i zaczynają się dyskusje.

W sensie to nie jest tak, że my bierzemy, piszemy i teraz zespół developerski to dostaje i róbta co chceta, tylko włączamy wszystkich w ten proces. Czyli rozmawiamy z biznesem, rozmawiamy z zespołem developerskim, każda perspektywa jest ważna. Tym bardziej że zespół developerski to są najczęściej ludzie, którzy są mega doświadczeni i napisali już niejeden system i niejeden problem rozwiązali, więc oni mają też fajne insighty i ja lubię z nimi gadać i właśnie korzystać z ich podpowiedzi.

I jak mamy sobie przygotowaną taką specyfikację już przegadaną z zespołem, z klientem, to następuje proces priorytetyzacji, czyli jak ważne to jest, kiedy chcemy to zrobić. Więc tutaj jest taki cały proces walczenia z tym workiem, który się nazywa backlog produktu, żeby ustalić kiedy coś można zrobić.

W międzyczasie odpowiadamy na wszelkie niejasności, pytania zespołu developerskiego i klienta, które się pojawiły w międzyczasie, bo już wiemy na podstawie danych, że nie ma sensu spędzać więcej czasu na doprecyzowaniu idealnym specyfikacji przed startem projektowania, bo to po prostu kosztuje więcej niż zrobienie tego w trakcie doprecyzowania. W związku z tym zostawiamy sobie taką furtkę, że zawsze mogą się pojawić pytania i jeszcze coś tam możemy doprecyzować. I to jest stały proces. To w jednym czasie developujemy rzeczy, które wcześniej ustaliliśmy, a równocześnie doprecyzowujemy wymagania na następne sprinty czy na następny okres.

W międzyczasie jako Product Ownerzy wspieramy sprzedaż, wspieramy marketing, wspieramy customer support, wspieramy samych klientów, w sensie end userów, czyli użytkowników naszego produktu, w zależności od tego, w jakiej konfiguracji jesteśmy ustawieni, więc to jest dosyć wielowątkowa praca, co nie jest łatwe zasadniczo.

I dobrze by było gdzieś w którymś momencie jeszcze znaleźć czas na to, żeby usprawniać swoją pracę i budować procesy, ale to jest znowu domena osób raczej bardziej doświadczonych, które już wiedzą, że zbudowanie procesu i poświęcenie na to czasu wcześniej zaoszczędzi nam go znacznie później.

I zawsze jak opowiadam o moim dniu, w sensie jak to wygląda u mnie, to często spotykam się z takim nie wyśmianiem, tylko z takim komentarzem, że o kurde, Ty to masz wszystko w checklistach, bo ja mam wszystko w checklistach.

Ja jak siadam rano, to mam checklistę ranną, co ja mam zrobić i po prostu krok po kroku lecę. Jak siadam do specyfikacji, to mam checklistę specyfikacji i po prostu krok po kroku sprawdzam, czy wszystko tam jest, co powinno być. Jak mam slot na pisanie maili, to ja wiem, jakie maile mam napisać, na jakie mam odpisać, jakich danych potrzebuję itd.

Więc ja lubię te swoje checklisty i budowanie ich, takie procesy, kiedy, co, jak i ustawianie przypomnień, bo strasznie dużo rzeczy trzymamy w głowie, jakby im więcej otwartych pętli, czyli niezamkniętych zadań, tym gorzej nam się myśli, a Product Owner ma mnóstwo zadań otwartych, dlatego że większość jego pracy zależy od innych osób. Więc ja lubię sobie zrzucać to do checklist i do zadań, żeby po prostu uwolnić mózg do myślenia.

 

No tak, pewnie nie bez powodu w lotnictwie funkcjonują checklisty, bardzo dobrze się sprawdzają, wszystko jest na nich oparte, więc żeby nie pilnować, nie trzymać tego wszystkiego w głowie, to lepiej to zwrócić na papier albo inny laptop.

Wspomniałaś tutaj, że lubisz rozmawiać z developerami. Tutaj myślę, że chodziło Ci o takie rozumienie, jak to przedstawia Scrum Guide, czyli wszystkie osoby techniczne, powiedzmy, zaangażowane w dany projekt czy produkt. W związku z tym pewnie wymagany jest jakiś tam poziom znajomości tej wiedzy technicznej po to, żeby móc się dogadać z tym zespołem, albo żeby przynajmniej rozumieć jakiego typu problemy zgłasza, jakie obiekcje ma, jakie wnioski wnosi itd.

Czy to jest też jakiś rodzaj wymagania co do Product Ownera, żeby właśnie ten poziom wiedzy technicznej jakiś tam był, a jeśli tak to jaki?

 

Nie, to najczęściej nie jest wymaganie. To jest wymaganie i nie jest. W sensie nikt tego nie napisze w ogłoszeniu o pracę, ale tak zdecydowanie łatwiej rozmawia się z zespołem developerskim, jak rozumiemy technologię. Ja po tych ośmiu latach potrafię przeczytać  kawałek kodu, głównie frontendowego. Nikt się ze mną nie dzieli backendowym kodem, ale to nie jest też tak, że ja wiem wszystko.

Technologia się bardzo zmienia, bardzo ewoluuje i I ja nad tym nie nadążam, bo to nie jest moja praca. Więc jak ja czegoś nie wiem, to po prostu proszę, żeby mi wytłumaczono i jeszcze nie spotkałam się z developerem, który nie chciałby się podzielić swoją wiedzą i mi wytłumaczyć, o co chodzi.

Więc trzeba mieć taką otwartość na to, żeby zapytać, poprosić o pomoc, bo mówię, ja do dzisiaj się pytam, bo cały czas wchodzą nowe rzeczy i właśnie ostatnio ktoś tam rzucił, że teraz ważne będą landing zony i ja takie, kurde, co to w ogóle jest? I trzeba było znowu zgooglować, znowu się zapoznać, znowu kogoś podpytać itd., I to jest normalne i ja zawsze mówię: nie fiksujmy się na tym my jako Product Ownerzy, bo naszym zadaniem nie jest podążać za technologią tak, wiesz, na co dzień, bo to jest praca programistów, to oni są specjalistami w tej dziedzinie, więc jak ja czegoś nie rozumiem, to zawsze po prostu pytam i to z czasem ta wiedza się buduje.

Dobrze na początek wiedzieć, czym jest backend, czym jest frontend, czym to się różni, że są biblioteki, że jest API i jak działa mniej więcej API, żeby to zrozumieć, a cała reszta przyjdzie później.

Bo też są bardzo różne projekty i bardzo różnie ta technologia jest wykorzystywana, bo inaczej będzie wyglądał projekt, który jest totalnie customowy, i tam zupełnie inaczej ta technologia będzie funkcjonować, a zupełnie inaczej wygląda projekt, który jest zbudowany, nie wiem, w power appsach na przykład Microsoftu, gdzie mamy dużo komponentów po prostu out of the box i tylko je jakoś tam kolorujemy. W dużym uproszczeniu oczywiście, ale wiesz o co chodzi, prawda?

W sensie takim, że nie możemy się fiksować na technologii na jakimś konkretnym zakresie, dlatego że możemy być w przeróżnych projektach. I mówię, za każdym razem jak się idzie do nowego projektu, to najważniejsza jest taka postawa na zasadzie: no dobra, nie wiem, to się dowiem. Jakby nauczyłam się już tabliczki mnożenia, później całek, no to teraz landing zony i lećmy z tym.

 

Wiesz, to się bardzo dobrze wpasowuje to, co powiedziałaś o znajomości tych podstaw, tych fundamentów. Czyli trzeba znać mniej więcej właśnie te zupełne podstawy, czym jest backend, frontend, API itd., i DevOps pewnie, a resztę można się dowiedzieć albo w trakcie, albo właśnie podpytać zespołu i nie ma w tym nic złego. Nie powinniśmy się krępować przed zadawaniem tego typu pytań.

 

Nie, wszystkie moje największe wtopy w życiu projektowym to było dlatego, że się nie zapytałam. Wiesz, ja przechodziłam do IT jakby spoza branży, w związku z tym dla mnie ten język na początek to było, ja się bałam przyznać, że ja tego nie wiem. Jak mi Project Manager rzucił, że mam cisnąć klienta o credentiale, to próbowałam to zgooglować. No kurde, powiem Ci, że nie jest łatwo zgooglować słówko credentiale i o co chodzi. I ja naprawdę pół dnia próbowałam to zrobić, zamiast się przyznać, że ale o co ci tak naprawdę chodzi.

Więc tak, wszystkie moje wtopy wynikały z tego, że gdzieś tam się nie zapytałam, albo się wstydziłam zapytać, albo bałam się przyznać, że czegoś nie wiem, dosyć szybko mi przeszło.

 

Rozumiem. Gdy pytałem Cię o kompetencje, co tam jest poszukiwane teraz na rynku, to wspomniałaś o AI. I właśnie jak Ty z punktu widzenia Product Ownera na tę technologię, te rozwiązania, na tę dziedzinę patrzysz? Czy to jest zagrożenie dla Product Ownera? Narzędzie? Może tylko jakaś ciekawostka?

 

Nie widzę zagrożenia, bo taki mem nawet chodził chyba designerski, że jestem bezpieczny o swoją pracę, bo klient musiałby opisać dokładnie, czego potrzebuje. Więc nie, ja się nie boję, ale w takim sensie ta rola się zmieni, zdecydowanie się zmieni, dlatego że AI mocno upraszcza pracę. I ja wykorzystuję AI na co dzień, faktycznie. To jest tak, że nawet już sobie stworzyłam tego swojego GPT-sa takiego, który mi pomaga pisać specyfikacje, który pomaga mi wyłapać jakieś rzeczy, o które mogą zapytać developerzy na refinemencie czy testerzy, więc jestem jeszcze bardziej przygotowana.

Idzie to po prostu szybciej, natomiast jakby core naszej pracy się nie zmienia, bo mam rozwiązywać problemy i to wymaga takiego myślenia nieszablonowego, bo czasami to jest zero-jedynkowe i klient naprawdę wie, czego potrzebuje i przychodzi z konkretami, ale czasami jest tak, że właśnie rzuca jakieś hasło w eter i my musimy wymyślić, a w tym projekcie ktoś robił to, a w tym tamto i może tak, a może z tej strony, a czasami jakby bierze się zupełnie jakieś coś nowego.

Natomiast bądźmy szczerzy, my raczkujemy jeszcze w tym AI, w sensie my jako ludzkość, więc to na razie są narzędzia, które przyspieszają naszą pracę taką, jaką znamy, natomiast myślę, że to się bardzo zmieni. W sensie, że nasza praca, nasze życie się bardzo zmieni. To tak jak przy rewolucji dotcomów. Ostatnio właśnie gadałam z Tomkiem Wykowskim z ProCognity na ten temat i on właśnie uświadomił mi, że tak jak powstał Google na przykład, jako pochodna tej rewolucji dotcomów, czyli firma, która funkcjonuje zupełnie inaczej, niż wcześniej firmy funkcjonowały, to możemy się spodziewać, że takie firmy, których jeszcze nie jesteśmy w sobie w stanie wyobrazić, takie AI native powstaną.

Więc myślę, że jesteśmy na początku. Myślę, że to jest bardzo ważne, żeby mieć rękę na pulsie. W takim sensie, że już teraz wdrażamy rozwiązania sztucznej inteligencji w produkty. Dobrze wiedzieć w jaki sposób można to zrobić, nie tylko chatboty. Więc bardzo dobrze wiedzieć, z czym to jeść. I nie mówię na poziomie technologicznym, tak, bo to nikt nie wymaga od nas, żeby teraz nauczyć się, nie wiem, Pythona albo pisać nie wiadomo czego, tylko chodzi o to, żeby wiedzieć już, gdzie my jesteśmy, co my już możemy zrobić, jakie serwisy są gotowe, produkcyjne, do wykorzystania nawet w korporacjach.

I nauczyć się wykorzystywać to na co dzień, dlatego że mówię, to na razie przyspiesza naszą pracę, taką, jaką mamy i niestety będzie tak, że to będzie wymagane za chwilę. Na razie to jest 50% ofert, ale za chwilę będzie tak, że no ale jak nie potrafisz zrobić prezentacji w pół godziny zamiast w cały dzień? No przecież, wiesz, są narzędzia i faktycznie akurat prezentację można już zrobić bardzo dobrą z wykorzystaniem AI zarówno merytorycznie, jak i wizualnie, co jest dla mnie najważniejsze, bo ja z merytoryką nigdy nie miałam problemu, ale PowerPoint nie jest moim najlepszym przyjacielem.

Więc ja na to patrzę raczej jak na taką ogromną szansę do wykorzystania teraz. Nie sądzę, żeby to było zagrożenie, tak samo jak nie sądzę, że to jest zagrożenie dla developerów, raczej szansa do wykorzystania.

Nie widzę zagrożenia, bo taki mem nawet chodził chyba designerski, że jestem bezpieczny o swoją pracę, bo klient musiałby opisać dokładnie, czego potrzebuje. Więc nie, ja się nie boję, ale w takim sensie ta rola się zmieni, zdecydowanie się zmieni, dlatego że AI mocno upraszcza pracę. I ja wykorzystuję AI na co dzień, faktycznie. To jest tak, że nawet już sobie stworzyłam tego swojego GPT-sa takiego, który mi pomaga pisać specyfikacje, który pomaga mi wyłapać jakieś rzeczy, o które mogą zapytać developerzy na refinemencie czy testerzy, więc jestem jeszcze bardziej przygotowana.

 

Tak naprawdę to ci będą mieli przewagę, którzy będą te narzędzia już znali. Zanim rynek zacznie tego twardo, mocno wymagać, my możemy uciec do przodu i po prostu zacząć się z tym zaznajamiać jak najwcześniej.

AI to jest oczywiście pewna nowinka, z którą powinniśmy być w miarę na bieżąco. Inny taki termin, który się ostatnio pojawił i który prosiłbym, żebyś rozwinęła, to jest Product Ops. Jak to się łączy z pracą Product Ownera?

 

To jest już taki level bardzo zaawansowany. To jest tak, tak sama jak powstała rola Product Ownera czy analityka biznesowego, bo ktoś po prostu robił tę część analityczną lepiej albo miał większy fan z tego, bo kiedyś tą pracę wykonywali programiści, powiedzmy sobie szczerze, że to do dzisiaj wielu programistów robi tę robotę, ale znaleźli się ludzie, którzy woleli wykonywać tę pracę niż pisać kod i się tak wyspecjalizowaliśmy, no to teraz cała ta branża jakby też się zaczyna specjalizować.

I Product Ops to jest budowanie procesów wokół rozwoju produktu. Mega ciekawe rzeczy. To jest w ogóle taka rzecz, która mnie teraz bardzo interesuje, właśnie Product Ops, dlatego że budowanie dużych produktów wymaga zbudowania procesów wokół tego, co my wiemy. Bo najgorzej to iść w ciemno i opierać decyzję o jakiś nasze gut feeling. A mamy dane, mamy bardzo dużo tych danych, możemy je zbierać, możemy je analizować, ale nie każdy ma na to przestrzeń czasową, kompetencyjną na to, żeby budować takie procesy.

Więc łatwiej jest rozdzielić budowanie procesów, zbierania tych danych, analizowania i budowania tych procesów produktowych, od tej pracy takiej, ja bym to nazwała grant work, czyli takiej u podstaw pracy z zespołem developerskim, bo tu mamy właśnie kompletnie dwa różne poziomy.

I moim zdaniem ta praca z zespołem developerskim jest i będzie jedną z ważniejszych ról, natomiast żeby ułatwić tę pracę i kierować się w tę dobrą stronę na podstawie danych, które mamy, no to powstaje właśnie Product Ops, który tę część jakby tak zaopiekowuje. Czyli nie skupiamy się już na pracy z zespołem developerskim, na pisaniu specyfikacji, tylko skupiamy się na budowaniu procesów wokół rozwijania produktu. Dla niektórych nudna, ale mnie fascynuje niesamowicie w tej chwili.

 

Dla mnie jest fascynujące to, że takie role, które kiedyś wydawały się bardzo spójne, bardzo zamknięte, dla mnie Product Owner zawsze był tego typu rolą, okazuje się, rozmawiając tutaj z Tobą te 40 minut, że zaczynają się wykształcać pewne specjalizacje, pewne odnogi, które z pewnością pójdą gdzieś tam w swoim kierunku, i za jakiś czas, a może już teraz będziemy widzieć osoby pracujące właśnie w tych jeszcze węższych specjalizacjach, wewnątrz specjalizacji, które wykształciły się jakiś czas temu. Więc to jest fascynujące, jak ta cała branża IT się tutaj nam rozwija.

 

Ale to jest właśnie ta charakterystyka, o której mówiłam wcześniej, że my mamy tę umiejętność wglądu, rewizji, feedbacku, więc ktoś powiedział: ej, ja nie jestem w tym dobry, ale tu jest osoba, która to robi dobrze, i tak w paru firmach się zbudowało, wiesz, i zaczyna się z tego specjalizacja robić.

Bo lepiej wyciągnąć jedną osobę do tworzenia procesów, która jest w tym dobra i lubi to robić, po to, żeby ta czwórka pozostałych, załóżmy, mogła robić to, co ona lubi, korzystając z pracy tej osoby, niż żeby każdy się gdzieś tam plątał pomiędzy jednym a drugim, nie? To po prostu tak jest. No mamy frontendowców, backendowców i wiemy, że oni po prostu jak… Są też oczywiście, wiesz, fullstackowie, którzy potrafią wszystko, ale chodzi mi o to, że jest grupa ludzi, która po prostu bardziej czuje ten frontend albo bardziej czuje ten backend i to jest taka naturalna ewolucja, na którą my ogólnie rzecz biorąc jako IT sobie dajemy przyzwolenie powiedzmy, nie?

 

Świetnie, że pokazałaś te różne możliwości, te różne odcienie i blaski pracy właśnie Product Ownera w branży IT. Natalia, bardzo Ci dziękuję za rozmowę, za ten poświęcony czas.

 

Bardzo Ci dziękuję.

 

Powiedz jeszcze, proszę, na koniec, gdzie cię można znaleźć w internecie, gdzie możemy słuchaczy odesłać?

 

Zapraszam na stronę nataliacholewa.pl albo szkolaproductownera.pl, ale tak na co dzień to najbliższy jest mi Instagram. Nie LinkedIn, nie nic innego, tylko jestem na co dzień na Instagramie, tak że jeżeli to jest również Wasza platforma, to zapraszam.

 

Świetnie, oczywiście te wszystkie linki znajdą się w notatce do odcinka. Natalia, jeszcze raz dzięki, do usłyszenia i cześć!

 

Cześć!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@porozmawiajmyoit.pl lub przez social media.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o karierze Product Ownera.

Do usłyszenia w następnym odcinku.

Cześć!