Product Owner – Moj (budući) posao – Predrag Spasojević

Pogledajte kako izgleda posao Product Owner-a, čiji opis posla, za serijal Moj (budući) posao, pruža product owner Predrag Spasojević.

Transkripcija

Ćao ja sam Predrag Spasojević, radim kao product owner. Potrudiću se da vam približim posao product owner-a, odnosno da detaljno objasnim šta radi IT product owner u sklopu agile project management-a kao i druge pozicije / delove ovakvog menadžmenta kao što je scrum master, user story i alate koje jedan product owner koristi u svakodnevnom poslu.

Čime se bavi Product Owner?

Product owner je neko ko je zadužen i kompletno odgovoran za neki proizvod i njegov razvoj. To može da uključuje definisanu viziju proizvoda i neke road mape, odnosno neki timeline po kojem proizvod treba da se razvija.

Pa na kraju do nekih funkcionalnosti i feature-a koje je potrebno razviti kako bi se zapravo dostavila vrednost krajnjim korisnicima, ili u B segmentu poslovnim korisnicima i kompanijama.

I na kraju, zadužen je za sam uspeh ili neuspeh proizvoda, odnosno za ROI (return on investment iliti povraćaj investicije), za to što se razvija.

Šta može biti proizvod koji razvija Product Owner?

Sama uloga product owner-a se pominje u agilnom razvoju, a agilni razvoj se najčešće usmerava na neki IT projekat, odnosno na softverske projekte. Ali tu nisu granice, zato što definitivno pr. owner može biti angažovan za fizičke proizvode, odnosno druge industrije i grane.

Tako da posao product owner-a ne mora da se odnosi samo na IT kada se ta pozicija može nazvati i IT product owner, a stoga i sam proizvod može biti IT proizvod ili usluga. Tada je diskutabilno da li se koristi termin product owner ili topic owner.

Kako izgleda radni dan product owner-a?

Najviše vremena se posvećuje komunikacijij sa stejkholderima, odnosno ideja je da se neki status proizvoda koji se razvija komunicira pravovremeno i transparentno svima koji imaju interese od tog proizvoda (bilo da su uključeni u razvoj istog, ili su savetodavno tu).

Često product owner nije jedina odgovorna osoba za proizvod koji se razvija, već mu je potrebna i neka druga partija odakle product owner dobija inpute i dodatne detaljnije informacije za to što razvija.

Te druge partije mogu biti:

• marketing tim (neki članovi marketing tima mogu biti: direktor marketinga, marketing executive, PR i marketing menadžer, account manager)
• tim za razvoj
• UX dizajner
• UI dizajner i slično.

Konkretno ideja je da se neki zahtev napiše kroz formu koja se zove user story, koja može da se pretoči developeru, a koji će na to da ima pogled iz korisničke perspektive i znajući na osnovu nekih kriterijuma prihvatanja / odobrenja (acceptance criteria) šta je to što treba da razvija.

Ali to se nikad ne dešava u realnosti, tako da product 0wner komunicira sa development timom svakodnevno.

Product owner treba da objasni developeru šta je to što on tačno želi, odnosno za šta smatra da može da dostavi najveću vrednost korisniku i kako to treba da izgleda na kraju, što se nikada ne može kako treba opisati kvalitativno unutar samog opisa u user story.

Šta je user story?

Jedna interesantna paralela u odnosu na tradicionalni način razvoja projekata, koji se zove Waterfall (voterfol), jeste što se u agilnom razvoju koristi user story (korisnička priča).

User story, iliti „kartice“ koje razvijamo / pratimo stavljaju korisnika u centar zbivanja, zato što se dosad puno proizvoda razvijalo, kako digitalnih tako i fizičkih, iz perspektive samog menadžera koji smatra da proizvod treba da se razvija onako kako on misli da treba da se razvija.

Pošto se ovde korisnik stavlja u centar zbivanja svaki user story treba da započne sa rečenicom:

„Kao ___ (određena vrsta korisnika), ja bih želeo da uradim nešto, odnosno da napravim neku radnju kako bih postigao željeni rezultat.“ To je standardna forma agile development-a u okviru kog product owner teži da sa timom razvije proizvod.

Na engleskom: „As a user I would like to ___, so that i can benefit from it.“

To je u principu jedan naslov user storija, svaki user story treba da ima prioritet. Prioritet može biti:

• nizak,
• srednji,
• visoki.

Neki veoma pouplarni prioriteti user story-a na osnovu kojih se razvija proizvod su trivial, critical, medium…

Posle prioriteta, user story treba da ima opis. Taj opis treba da sadrži neki acceptance criteria.

Acceptance criteria govori šta je to što je potrebno uraditi, tj. šta i kako developer treba da razvije kako bi taj user story bio razvijen na pravi način.

Još jedan novi termin koji može biti konfuzan zove se definition of done, koji je u direktno vezi sa acceptance criteria terminom, a definition of done govori kada je neki „feature“ / „funkcionalnost“ proizvoda razvijen.

Neki feature koji je zapravo opisan u tom user storiju. Tako da, ukoliko za primer uzmemo „dugme na veb šopu“, definition of done može biti: ukoliko to dugme ima tačno određene dimenzije prema nekom starom gajdu, ima tačno određenu boju i kolor kod i slično.

Kako se pišu kartice?

Ono što se konkretno veoma često dešava u praksi jeste da product owner nema mogućnost da sam napiše user story, odnosno da napiše sam kostur celog proizvoda i sve funkcionalnosti koje je potrebno razviti.

Na primer, ukoliko product owner dolazi sa biznis strane, fokusira se na front-end odnosno na funkcionalnu stranu koja je vidljiva okom korisnika i koja ima direktan kontakt sa korisnikom.

Dok se back-end strana i funkcionalnosti (tehničkiji user story) piše zajedno sa razvojnim timom. Takođe, dešava se i da sam veb developer, nakon što dobije user story orijentisan na funkcinalnost / korisničku stranu, sam može napisati određene pod taskove tj. pod zadatke za konkretan user story, jer mora pristupiti problemu tehničkije, programerski i slično.

Koje alate koristi product owner u svakodnevnom poslu agile project management-a?

Ja sam veliki ljubitelj stikera, post it nalepnica, tako da i na svom stolu imam tablu koja ima kolone:

• to do,
• doing i
• done.

Na njima pišem svoje dnevne zadatke. Ukoliko je moguće, najlepše je dokumentovati user storije na samom stikeru, i zatim na velikom zidu, gde može da se okupi ceo tim, preko dana pomerati stikere, kako bi se uvela fizička interakcija tima i praćenje procesa razvoja. To je mnogo lepše nego raditi kroz neki softver koji je crno na belo i koji ti ne dozvoljava da ustaneš sa stolice, da se prošetaš i udahneš vazduh.

Ali nažalost, u realnosti nije moguće uvek raditi sa stikerima na zidu, razvojni timovi često nisu na istoj lokaciji, ne sede u istoj prostoriji sa product owner-om.

Nekad je lakše zapravo sve te projekte dokumentovati i pokazati rezultat i ostalim stejkholderima koji su često i van organizacije, a da bi se to uradilo najlakše je koristi program Jira.

Trenutno ja u većini koristim Điru, za user story. Đira je sama po sebi izuzetno kompleksna, i često mnogima više i odmogne nego što pomogne, a ljudi su veoma kivni da se naviknu da je koriste i savladaju sve njene prednosti.

Jira ima jako veliki broj opcija i mogućnosti, koje zaista nisu potrebne za čak 80% populacije koja se bavi razvojem, pa zbog toga pominjem i drugi agile alat, koji je interesantan i koristan za agile scrum menadžment, jeste Trello.

Trello se više koristi za marketing i biznis timove, ali mislim da može da ispuni i zahteve većine razvojnih timova.

Ali što se tiče nekog enterprajz iliti korporativnog okruženja, Đira je tu postala standard. Najpre zbog svojih integracija, plug-inova i ekstenzija gde je moguće omogućiti ostale radnje koje su sastavni deo razvoja softvera.

Na šta ti odlazi najviše vremena u tom procesu?

Dobar deo slučajeva product owner ne razmišlja samo koji je to neki budući feature koji treba da razvija, već razmišlja o samom use case-u za tu tehnologiju koju poseduje iliti za proizvod koji razvija. Razmišlja o nekom drugom načinu ili biznis modelu, nekoj drugoj grupi korisnika kojoj može da plasira rešenje.

Ideja je izvući, za uložen trud i novac tj. investiciju, za razvoj use case-a. Use case možemo da posmatramo kao čitav set feature-a, kao nešto potpuno novo što proizvod može da ponudi, ili to može da bude potpuno novi proizvod.

Ideja je da product owner pokuša da validira novi use case, odnosno da proceni da li ta neka investicija koja pokreće novi use case ima smisla i može li takav smer razvoja da povrati uloženo kroz željeni period posmatranja.

Tako da u idealnom scenariju, super je ako product owner može da bude u mogućnosti da sam razvije neki mockup. Koji može da bude papirni wireframe, ili čak neki digitalni prototip, i da uspeva da ga plasira krajnjem korisniku za koga razvija taj proizvod, feature, user case, šta god… i da ga potom validira.

Odnosno da dobije fidbek, da promeni taj prototip, kroz nekoliko iteracija pre nego što na kraju sve to servira development timu i potroši 6 meseci da razvije ideju.

Da li product owner radi sam ili u timu?

Još jedna svakodnevna situacija jeste da product owner komunicira sa nekom eksternom agencijom iliti sa eksternim developerima koji razvijaju taj proizvod.

Ne postoji uvek formalno tim i ne postoji mogućnost da se product owner sretne sa tim developerima i priča na dnevnoj bazi.

U svakom slučaju, direktna interakcija treba da postoji sa skram masterom, ili sa edžajl masterom ako se radi o nekom drugom agilnom frejmvorku, a nakon toga postoji sa članovima razvojnog tima, zato što u većini slučajeva product owner treba nešto da objasni nekom developeru, a ne da ide ping pong sa skram masterom.

Iako je skram master tu da bude neki servant lider, odnosno neko ko će često i da brani tim odproduct owner-a kad je on navalentan – hoće da ubaci novi fičr u iteraciju, hoće da repriotizira i sl.

Deo samog tima poželjno je da bude i QA lik, odnosno neko ko se bavi samim testiranjem kvaliteta proizvoda, a često i deo samog tima neko ko se bavi UX-om i UI-om.

Naravno, u nekim slučajevima imamo nekog ko je zadužen za devOps ili neko ko se zove application manager ko radi deployment…

Ono što je stvarno lepa odlika te pozicije jeste što za razliku od edžajl mastera kao sastavnog dela tima i razvojnog tima, product owner često može i da putuje. Pogotovo u zemlje gde se lansira taj proizvod ili aplikacija, kako bi bolje upoznao okruženje i korisnike kojima želi da servira proizvod.

Product owner putuje na destinaciju kako bi ili upoznao lokalni tim, ukoliko je veća organizacija koja će zapravo da pomogne pri puštanju proizvoda, ili kako bi testirao sa kranjim korisnicima prozivod i dobio prvi fidbek.

Što se tiče same komunikacije sa članovima tima, moj lični alat koji volim i duže koristim jeste Slack. Ima zapravo sjajne integracije sa drugim alatima koji se koriste, na primer pomenutom Đirom, gde možemo da imamo pregled šta se novo dešava i koji se novi user storiji prave.

Zatim imamo Jenkins, gde možemo da vidimo stanje bilda. Naravno, postoje čet botovi koji mogu i artifišl inteledžence neki agenti koji mogu da olakšaju komunikaciju sa krajnjim korisnicima.

Još jedna super stvar kod Slack-a, jeste što postoje javne grupe i kanali. Koji su upravo vezani za neki product menadžment ili za UX, gde možete da u nekoj beta fazi proizvoda podelite svoj proizvod sa gikovima koji su zagriženi za agile project management i da dobijete fidbek pre nego što ga lansirate, a naravno možete i da saznate ostale aktuelne stvari, otkrijete nove aplikacije, startape i slično.

Kako se postaje product owner?

U principu teško je generalizovati koji je to profil product owner-a, odnosno sa kog fakulteta može da dođe.

Zato što u zavisnosti od proizvoda, može da dođe sa biznis, menadžment strane, može da dođe i iz IT-a.

Ukoliko imamo neki finansijski sistem, koji product owner razvija potrebno je da poznaje finansije veoma detaljno.

Ja sam konkretno imao sreće da spojim FON – menadžment, i IT deo kasnije, što mi je dosta pomoglo, jer mi je upravo trebala ta neka spona između biznisa i IT-a.

Što se tiče samog iskustva,product owner može imati više i manje iskustva, ali ukoliko otvorite oglase najviše se viđa da je potrebno 3+ godine iskustva, tako da u principu nije uvek lako početi.

Prilično je nemoguće završiti samo fakultet i postati product owner, ali ono što može svakako da pomogne, što je meni pomoglo, jeste ukoliko probamo da razvijemo sami neki proizvod, da napravimo neki startap i da sami osetimo šta znači napraviti neki prototip, validirati sa korisnicima, lansirati, dobiti fidbek i tako dalje.

To može pomoći da prebrodimo taj nedostak iskustva, kako bismo došli u neku kompaniju ili firmu manje veličine i postali product owner. Drugi način jeste ako pomažemo nekom product owner-u kao pripravnik ili asistent u razvoju samog proizvoda i naravno učimo sa strane.

Ako se radi o samom IT proizvodu, odnosno nekom softveru, iz moje perspektive je bolje ako sam product owner ima neku softversku pozadinu, odnosno može i da priča rečima developera i da piše sam user story i da objašnjava fičure.

Ali to može da bude mač sa dve oštrice, jer je potrebno i da razume samog korisnika, da razume kako funkcioniše tržište, ekonomija.

Teško je reći kako započeti, jer stvarno ne postoji praksa za product owner-a, tako da prvi savet bi bio pokrenuti nešto svoje, jer tu zapravo imamo priliku da se igramo product owner-a po prvi put.

Čest slučaj jeste da product owner zapravo dođe iz nekog biznis development okruženja ili čak iz sejlsa, jer ima direktan kontak sa korisnicima.

Zna šta korisnici ili kupci žele, i onda to može da pretoči u zahtev koji se dalje razvija. Takođe može biti slučaj da sam developer koji je pokazao liderske osobine, da razume način razmišljanja korisnika.

Još bitnije ako pogledamo Silicijumsku dolinu, London ili Berlin i ostale Meke startapa, većina ljudi koji su ih gradili imaju upravo neku IT pozadinu, jer su bili u mogućnosti da sami i sa partnerom razviju taj proizvod, a da postepeno u samom razvoju steknu osećaj za šta je to što korisnik želi i na koji način može da razvije i plasira to korisniku i da dostavi vrednost. Naravno i zauzvrat ostvari neki profit.

Pomenuo bih za kraj, svoja omiljena dva izvora:

1. Product hunt – platforma gde dnevno vidimo veliki broj novih aplikacija, novih proizvoda, novih feature-a… Gde možete zapravo da osetite šta je trenutno aktuelno, prema tim glasovima korisnika možemo da osetimo šta je to što radi na tržištu. šta je potrebeno, što stvarno rešava problem, a nije naredni bulšit.
2. Mind the product – Blog / konferencija / cela zajednica.

Pogledajte / pročitajte korisne informacije i opise poslova drugih srodnih zanimanja:

• Vice President of Client Success – Moj (budući) posao – Nenad Trailov
• PR i marketing menadžer – Moj (budući) posao – Zoran Burić
• Group Account Director – Moj (budući) Posao – Nataša Bojanić
• Marketing Executive – Moj (budući) posao – Jelena Đoković
• Direktor marketinga – Moj (budući) posao – Darko Mandić
• Account manager – Moj (budući) posao – Tijana Pantelić
• Direktor finansija i opštih poslova – Moj (budući) posao – Tijana Jovanović