Za sve product nindže: 3 metode prioritizacije backloga

Saveti 8. mar. 2022

Svaki Product Manager ili Product Owner zna da je izgradnja uspešnog digitalnog proizvoda poput izgradnje kuće, sa samo jednom malom razlikom: kuću u jednom trenutku zapravo završiš – proizvod... Pa i ne baš.

I tu nastaje tvoja najgora noćna mora.

Beskonačni nizovi zadataka, bugova i user storyja unutar Product Backloga u kombinaciji sa svakodnevnim pitanjima kada će feature biti pušten.

Srećom, postoje metode koje će ti pomoći da odrediš prioritet taskova unutar svog Product Backloga. U ovom blog postu ćemo pokriti naše 3 najdraže metode:

  1. Impact effort matrix
  2. Stack ranking
  3. MoSCoW metoda

O čemu se radi?

Svaki Product Manager ili Product Owner nastoji najpre da isporuči feature koje donose najveću vrednost za potrošača. Ironično, ono što obično donosi najveću vrednost, zahteva najviše vremena za istraživanje od strane tima kako bi se smanjili potencijalni rizici povezani s isporukom tog featura.

Zato, u početku, isporuka ovakvih funcionalnosti oduzima više vremena jer je naše znanje minimalno. Ali zamisli, što da postoji hitan bug fix ili ono malo unapređenje proizvoda koje stalno provlačiš kroz svaki sprint ili pak tehnička nadogradnja koja će omogućiti dev timu brži razvoj u budućnosti?

Šta ćeš prvo da uradiš?

Postoji trade-off između kratkoročnog i dugoročnog razmišljanja, za koji Product Manager mora da pronađe kompromis. Da li zadatke brzo puštati iz backloga, ali uz donošenje manje ili nikakve vrednosti za potrošača ili se fokusirati na dugi rok i isporučiti najvažniji feature za potrošača, ali nakon uložene značajne količine vremena.

Reklo bi se da nije tako lako doneti tu odluku.

Ali, to nije sve.

Ako dilemi dodamo ultimativno pitanje: treba li tim da razvija prave feature ili da razvija feature ispravno ili pak da se odluči za treću opciju - da ih razvija brzo?

E, tada već malo poludiš. 😊

Idealan slučaj bi bio da možeš da postigneš sve tri opcije, ali to nije uvek moguće.

Ponekad ćeš biti u poziciji da razviješ prave funkcionalnosti s pravom tehnologijom ili arhitekturom sistema, ali će ti trebati dosta vremena i propustićeš tržišnu priliku za lansiranje ovog featura. Konkurent može biti ispred tebe, a potrošač gubi ekskluzivnost.

Sa druge strane, možeš biti u poziciji da vrlo brzo razviješ prave stvari, ali preskakanje koraka te može dugoročno koštati značajnog technical debta, napora za refaktorisanje koda ili čak može značiti promenu tehnologije koju koristiš.

Treća opcija, kada stvari možeš razviti ispravno na prilično brz način, čini se kao sjajna opcija, ali šta ako napraviš nešto što potrošaču nikada nije trebalo, niti donosi vrednost. E, onda si tek u problemu.

Gledajući iz daleka, očigledno je da moraš da balansiraš između tri opcije, ali što je još važnije potrebno je da balansiraš između Scrum uloga – a evo i zašto.

Obično će se Product Manager ili Product Owner zauzeti za stvari koje donose najveću vrednost potrošaču, dok će razvojni tim nastojati da stvari budu izgrađene na pravi način, a zatim će tvoji stakeholderi sužavati rokove i požurivati da stvari što pre krenu u razvoj.

Vreme je važno jer znači novac, ciljeve (milestonove) i go-live datume, itd. Štaviše, brzim razvojem pre ćeš dobiti povratne informacije o razvijenim featurima i brže ćeš učiti. Ovo je prednost koja će se umnožiti sa sprintovima i samim time će skratiti tvoj feedback loop.

Ali na kraju, što ako "najglasniji" stakeholder traži jednu funkcionalnost, dok ostali traže drugu? Čini se da smo skloni utišati najglasnije ljude u prostoriji tako što ćemo ih prve poslušati, ali evo važne lekcije koju trebaš da naučiš iz Stakeholder Managementa: u redu je reći ne.

Iako je ovo samo deo mogućih situacija koje ti se događaju na dnevnoj bazi, to nije kraj sveta jer, srećom, postoje metode koje su dokazano efikasne pri određivanju prioriteta taskova unutar Product Backloga. Ovo su naše preporučene tehnike:

#1 Impact effort matrix

Ova metoda za prioritizaciju taskova koristi dve ose:

  1. Nivo truda neophodnog da se postigne task
  2. Nivo značaja određenog taska za produkt

Dok smo još bili svi zajedno u kancelarijama, najlakše je bilo iscrtati koordinatni sistem na tabli i zalepiti post-it papiriće sa taskovima na nju.

Sada, kada smo remote postoje razni templejti u tkz. “whiteboard” alatima, kao što su edraw, miro i SketchBubble.

Kako određuješ kom kvadrantu pripada koji task?

Quick wins su taskovi na koje treba da se fokusiraš i odradiš ih što pre. Oni su fundamentalni i najefikasniji u poređenju sa uloženim vremenom.

Major projects su taskovi koji će dati neku vrednost projektu, ali su dosta kompleksni. Ovde treba jako paziti koji taskovi se biraju za dalje izvršavanje i uzimati samo one koji vredni truda uloženog u njih.

Fill in Jobs nisu toliko bitni, svakodnevni taskovi. Ne treba da se brineš oko njih. Samo ih ubacuj između bitnijih taskova kada imaš vremena.

Thankless Tasks su taskovi koji zahtevaju previše vremena i resursa koje je bolje potrošiti na nešto drugo. Njih je najbolje da kompletno izbegavaš ili ako baš ne možeš da izbegneš delegiraj nekome ko ima više vremena.

Sad kad znaš šta se očekuje u kom kvadrantu, ostaje ti samo da dobro procenite svoje taskove, vreme koje je potrebno da uložte, kao i značaj koji oni donose za ceo projekat.

Ovo je dobar način da uključiš i članove drugih timova da daju svoje mišljenje o tome koji su prioriteti za produkt, kako biste doneli najbolju zajedničku odluku.

#2 Stack ranking

Ovo je jedna od najčešće korištenih metoda – postavljanje taskova po listi prioriteta.

Najbitniji taskovi su na vrhu liste.
Najmanje bitni taskovi se nalaze pri dnu liste.

Koja je prednost ove metode?

Tera vas da zajedno odlučite koji je taj, jedan, najbitniji task. A i, iskreno, najlakša je za primenu.

Šta to znači za vas kao tim?

To znači da ćete uvek raditi na taskovima koji donose najviše vrednosti za razvoj vašeg produkta.

Koje su mane ove metode?

Često se značaj taskova određuje na osnovu intiuicije, uz nešto malo analitičkih podataka – nije baš najobjektivnija metoda.

High impact u kombinaciji sa Stack Rankingom

Neki Product Manageri ili Product Owneri odluče se za kombinaciju gore spomenutih tehnika.

Nakon što doneseš odluku koji će taskovi završiti u kojem kvadrantu na temelju High impact matrice, tada možeš koristiti Stack ranking kako bi poređao zadatke unutar kvadranta.

Tako dobijaš backlog proizvoda s uređenim popisom taskova, koji odgovara poslovnim očekivanjima.

#3 MoSCoW metoda

MoSCoW metoda je slična metodi koju smo naveli iznad, sa jednom izmenom – kategorije značaja.

Nazi MoSCoW metode je nastao po nazivu kategorija po kojima prioritizujemo taskove:

Must have (Mora da se uradi)

Ove taskove je neophodno uraditi u zadatom vremenskom periodu kako bismo postigli uspet. Ako makar jedan od ovih taskova nije urađen i dostavljen na vreme, smatramo da je projekat bio neuspešan.

Should have (Trebalo bi da se uradi)

Bitno je da se urade, ali neće uticati na delivery projekta.

Could have (Moglo bi se uraditi)

Bilo bi dobro da se urade ovi taskovi, ali nije neophodno. Ukoliko su svi taskovi iz bitnijih kategorija urađeni, ovi taskovi dolaze na red.

Won’t have (Neće se uraditi)
Ne postižemo da ih uradimo u ovom ciklusu. Bilo bi dobro da ih imamo, ali nisu od velike važnosti.

Koji problemi mogu da nastanu sa MoSCoW metodom?

Jako je lako staviti puno taskova u Must have kategoriju i prioritizovati nove feature, dok se, na primer, refaktorisanje koda često stavlja u "Could have" i "Won’t have" kategorije.

Važnost prioritizacije backloga

Nakon što je tvoj backlog prioritizovan, imaš jasan put za fokus tvog tima.

Ali, nemoj zaboraviti, backlog refinement je iterativni proces i kada ga jednom rešiš, to ne znači da se posao tu završava.

Uvek bi trebalo da pročistiš i reorganizuješ taskove u svom backlog pazeći da su ispoštovani principi određivanja prioriteta koje si prethodno usvojio.

Tagovi

Tvoja prijava je uspešno sačuvana!
Odlično! Da bi imao pristup kompletnom sadržaju bloga potrebno je da završiš proces plaćanja.
Tvoja prijava je uspešna!
Tvoj nalog je aktiviran, sada imaš pristup kompletnom sadržaju bloga.