Treba biti samo jedan Product Owner (Tim)
- Detalji
- Klikova: 10185
Scrum vodič kaže da je "Product Owner jedna osoba, a ne komisija". Moje razumijevanje ovog pravila je da su autori Scrum-a željeli osigurati takvo projektno okruženje gdje razvojni tim ima jedan izvor znanja o problemu koji treba da riješi. Ne bi trebalo da imamo komisiju (komitet, projektni tim) u ulozi Product Owner-a jer bi to onda moglo voditi do konflikata interesa i razlika u mišljenjima članova tog tima. Vjerovatno bi takvoj komisiji bilo potrebno više vremena da postigne koncenzus, a ako su razlike u mišljenju velike, mogli bi početi praviti kompromise u donošenju odluka vezanih za softverski proizvod, a pravljenje kompromisa oko karakteristika (features) softvera nije način da se postigne optimalna vrijednost krajnjeg proizvoda (što je po Scrum-u osnovni zadatak Product Owner-a). Moguće je da bi različiti članovi te komisije počeli nezavisno pristupati programerima sa svojim zahtjevima, što bi vodilo u novi krug nerazumijevanja i gubitaka vremena i napora razvojnog tima. Zvuči jako razumljivo da je potrebno imati samo jednog lidera proizvoda.
Dakle, potreban nam je jedan Product Owner. On ili ona je vizionar i lider u razvoju softverskog proizvoda. To znači da ta osoba zna gdje se taj proizvod „uklapa“ u program odnosno portfolio i kako će njegovo puštanje u rad doprinijeti postizanju strateških ciljeva organizacije. Iz projektne perspektive, ova osoba je sposobna jasno definisati korisničke zahtjeve tokom cijelog perioda razvoja softvera. On ili ona otkriva potrebne feature-e proizvoda, rafinira korisničke zahtjeve (dodaje detalje smanjujući nepoznanice) i konstantno poboljšava sadržaj Product Backlog-a. On ili ona je dostupna razvojnom timu, pruža blagovremene i jasne odgovore na pitanja koje postavlja razvojni tim i općenito je posvećena kontinuiranom pružanju dovoljne količine kvalitetnih opisa očekivanih karakteristika proizvoda kako bi napor razvojnog tima bio optimiziran – da ono što razvojni tim napravi bude zaista ono što klijentu treba i ono što će biti sadržaj krajnjeg proizvoda. Radeći poslove upravljanja Product Backlog-om, Product Owner-a optimizira vrijednost krajnjeg proizvoda.
To nije sve. Product Owner nije kao kapetan Jack Sparrow, koji navigira svoj brod govoreći svima šta treba da rade. Voditi razvojni proces nije moguće bez svakodnevnog temeljitog testiranja funkcionalnosti isporučenih inkremenata proizvoda. Ako se razvojnom timu osigura dovoljna količina jasno definisanih korisničkih zahtjeva, tim će vjerovatno ponuditi dovoljno razvijenih funkcionalnosti da Product Owner svakog dana većinu svog vremena provede radeći funkcionalno testiranje inkremenata, testirajući “happy path” scenario i moguće izuzetke u radnom procesu, otkrivajući pri tome mogućnosti za poboljšanja postojećih i razvoj novih funkcionalnosti, i pružajući povratne informacije razvojnom timu o tome. Na kraju, Product Owner je jedan, a razvojni tim, po Scrum-u, čini tri do devet ljudi.
Jasno je da Product Owner treba pomoć u obavljanju svih gore spomenutih poslova. Sa druge strane, ja radim u upravi i, kao i u mnogim drugim nesoftverskim organizacijama, IT menadžer odnosno inženjer se doživljava ne samo kao osoba koja treba voditi IT projekat, već kao i osoba odgovorna za uspjeh razvijenog proizvoda. Jasno je da IT osoba nije nužno ekspert za poslovnu oblast za koju se razvija IT rješenje. Čak i ako ta IT osoba podržava poslovne operacije dugi niz godina, to i dalje ne znači da će biti u stanju pružiti odgovor na svako postavljeno pitanje i biti vizionar i lider u poslovnim aspektima svrhe i cilja koji se želi postići razvojem tog proizvoda. Autori iz oblasti agilnog upravljanja projektima kažu da se Product Owner bavi poslom informiranog odlučivanja, što znači da je on ili ona u kontinuiranoj komunikaciji sa razvojnim timom, poslovnim ljudima i korisnicima, nastojeći da prepozna stvarne potrebe poslovnih ljudi i korisnika i razumije šta razvojni tim može i predlaže; kako bi mogao donijeti poslovno vrijedne odluke.
Ovo zvuči OK, razvoj softverskog proizvoda JESTE izraženo kolaborativan posao, ali ako odgovornost za uspjeh projekta nije jasno pridružena i poslovnim ljudima i internim korisnicima sa kojima ovakav Product Owner komunicira, kako će oni shvatiti svoju ulogu u projektu? Vrlo vjerovatno samo kao osobe koje treba konzultirati sa vremena na vrijeme i kada se pojave problemi ili nedoumice. Moguće da poslovni ljudi i korisnici neće biti motivirani niti vidjeti svrhu svog prisustvovanja sastancima planiranja i evaluacije inkremenata proizvoda (IT sistem je posao IT stručnjaka, zar ne?), posebice kroz duži vremenski period. Product Owner zato vjerovatno neće moći pružiti sve odgovore razvojnom timu na tim sastancima, i moraće kontinuirano ići od svojih internih korisnika do programera i nazad, razjašnjavajući stvari i tek onda donoseći odluke. Na kraju, takav Product Owner jednostavno neće moći isporučiti kontinuirani tok za razvojni tim korisnih opisa i detalja proizvoda koji se razvija, a nedostatak informacija od strane Product Owner-a je „tihi ubica“ efikasnosti agilnog razvojnog procesa.
Moja praksa uspostave Product Owner Tima
U svojim projektima, sa dosta uspjeha, prakticiram uspostavu tima koji ja nazivam Product Owner Tim. Ovaj tim formira se kao kolektivni organ nadležan za donošenje projektnih odluka i upravljanje vrijednošću proizvoda sa strane klijentske organizacije i sastoji se od:
- Vođe Product Owner Tima
- Poslovnog predstavnika
- Predstavnika korisnika
- Predstavnika razvojnog tima
Ukratko, vođa Product Owner Tima je "prvi među jednakima" u ovom timu i obavlja ulogu Product Owner-a, odgovorne (u smislu engleske riječi accountable) osobe za uspjeh proizvoda. Ova osoba je glavni motivator i komunikator na projektu i vodi razvoj proizvoda. Međutim, dužnosti i odgovornosti (u smislu engleske riječi responsible) Product Owner-a dijele svi članovi ovog tima. Tako svaki član tima postavljen u Product Owner Tim razumije da je on ili ona dužan i odgovoran (responsible) da:
- Pruži znanje i informacije koje će doprinijeti optimizaciji vrijednosti softverskog proizvoda.
- Učestvuje na svim sesijama planiranja i evaluacije inkremenata proizvoda, te eventualnim drugim ad-hoc sastancima.
- Doprinosi rafiniranju Product Backlog-a i definisanju kriterija prihvatljivosti pojedinačnih funkcionalnosti proizvoda.
- Testira funkcionalnosti razvijene u iterativno-inkrementalnom razvoju i pruža svoj feedback.
Većinu svojih aktivnosti Product Owner Tim obavlja u formatu sastanaka licem-u-lice. Product Owner Tim sastavljen je tako da posjeduje svo potrebno znanje i ima mandat za donošenje odluka vezanih za problem koji razvojni tim rješava, tako da se pojašnjenja i odluke u većini slučajeva mogu donijeti na samom sastanku. Da bi poslovni ljudi i korisnici shvatili širi kontekst svog angažmana, vođa ovog tima kontinuirano objašnjava članovima tima agilni proces razvoja softvera, uloge i odgovornosti svih učesnika u razvoju softverskog rješenja, i generalno vodi taj tim. Tako je vođa Product Owner Tima za razvojni tim Product Owner a za svoj tim radi kao Scrum Master.
Do sada sam uočio sljedeće prednosti ovog pristupa:
- Odluke, pojašnjenja i drugi doprinosi sadržaju Product Backlog-a se rade na Scrum sastancima, rijetko nakon njih, i to većinom ako je priroda pitanja takva da se ono mora eskalirati ka upravi klijentske organizacije.
- Razvojni tim cijeni priliku da razgovara sa stvarnim korisnicima softverskog rješenja. Kroz direktnu dnevnu komunikaciju u prilici su ponuditi i diskutirati bolja odnosno optimalnija rješenja za korisnike.
- Rad sa Scrum timom pomaže poslovnim ljudima i korisnicima da razumiju i prihvate vrijednosti i principe agilnog razvoja softvera, što doprinosi optimalnom razvojnom procesu i kasnijem procesu održavanja softverskog rješenja. U jednom projektu u kojem sam učestvovao, interni korisnici sistema su preuzeli vlasništvo nad proizvodom (product ownership) tako da su danas oni samostalni agenti servis deska, oni identificiraju otvorena pitanja i šanse za poboljšanja sistema, i, uz malo moje pomoći, iste komuniciraju sa programerima, procjenjuju očekivanu poslovnu vrijednost u odnosu na cijenu razvoja, odobravaju posao programerima na osnovu svojih procjena i prioriteta te rade funkcionalno testiranje razvijenih funkcionalnosti i donose release odluke.
- Svaki razvoj novog softverskog proizvoda je inicijativa promjene, a promjena se puno lakše uvodi ako su oni koje promjena pogađa (poslovni ljudi i korisnici) uključeni u sami dizajn promjene.
Šta vi mislite?
Šta ovdje nedostaje ili je pogrešno ili dobro? Ako ste vi u ulozi menadžera IT projekata u nesoftverskoj organizaciji, kako vi prakticirate agilni odnosno Scrum razvoj sa ugovorenim vanjskim razvojnim timom i kako vi angažirate svoje poslovne korisnike u razvojnom procesu? Ako želite, podijelite svoja razmišljanja i komentare u pripadajućem LinkedIn blog post-u ili ovdje.
Napomena: Silueta ljudi na slici je iz Visual AGILExicon-a. Ovaj tekst je dostupan i na engleskom jeziku.
