“Mislim da bi ovo moglo biti korisno” je uvodna rečenica u romanu “Kako je propala Roadmapa”, po kome je kasnije snimljen dokumentarac, a najzad i igrana serija (znate one priče izSilicon Valley – ko je gledao, nek javi kakva je).

Dovoljno je product krvi proteklo kroz naše vene, da možemo da priznamo da nam je povremeno roadmap samo spisak nasumičnih taskova za koje se “čini da bi mogli biti korisni”.
(Poziva se u pomoć mitsko biće Data i ono, kako beše, User Research.)
Ono, bacaš feature-e u backlog kao konfete na paradi, i nadaš se da će neki od njih zapravo pogoditi metu. Ako imaš bar malo sreće i pameti da si metu prvobitno postavio. [blink:blink]
Kao kroz maglu, kao da je poznato? 🙂

Takvi su počeci, dok kroz bolnu praksu ne naučiš da roadmap nije samo TO-DO lista za naš dev tim. Saznaš to na teži način – nakon što napravite “revolucionarnu funkcionalnost” koju je koristio… pa, niko. Baš niko.

Zašto roadmap nije samo spisak zadataka?

Utorak, 10:00. Meeting room 3.

“Dakle, šta stavljamo u roadmap za sledeći kvartal?” pita menadžer.

Hm, šta misliš da se dešava dalje? Da li je odgovor:

a) “Možemo dodati onu novu notifikaciju, i unaprediti UI, i redizajnirati dashboard, i dodati export opciju…”
b) “Hajde da prvo razumemo koji problemi najviše muče naše korisnike, i fokusiramo se na njih.”

Priznaj, svi smo mi ponekad bili “a” tim – ja prva.�

A šta sve ovo znači u praksi?
Kako roadmap može da izgleda kada nije dobro napravljen i kako treba da izgleda kada je smislen? Evo nekoliko primera:

Kako NE treba:

• Roadmap se sastoji od nasumičnog niza funkcionalnosti bez jasne logike.
• Svaka stavka je napisana kao „Implementirati novu notifikaciju” ili „Dodati filter pretrage”.
• Nema prioritizacije, sve je „važno”.

Kako TREBA:

• Roadmap je organizovan oko korisničkih problema.
• Stavke su definisane u kontekstu uticaja na korisnika, npr. „Smanjiti vreme pretrage za 30% dodavanjem AI filtera”.
• Jasno su postavljeni prioriteti na osnovu uticaja i poslovne vrednosti.

Primer:
Umesto „Dodati AI pretragu proizvoda”,
bolje je
„Korisnici troše previše vremena tražeći proizvode – smanjiti vreme pretrage za 30%”.

Česta greška u planiranju proizvoda je tretiranje roadmap-a kao liste funkcionalnosti. Ovo kažem iz ličnog iskustva – jednom sam provela ceo sprint implementirajući “ključnu funkcionalnost” za koju se ispostavilo da rešava nepostojeći problem.
Bila sam ponosna, tim je bio ponosan, stakeholderi oduševljeni… samo korisnici nisu primećivali razliku. Ups!

Međutim, pravi roadmap:

• Fokusira se na korisničke probleme, a ne na taskove.
• Povezuje poslovne ciljeve sa potrebama korisnika.
• Prilagodljiv je promenama kroz iteracije.

Ako tvoj roadmap izgleda kao lista taskova za tim, vreme je za promenu pristupa.
Ne brini, evo ti recept kako.

�Pogledaj i: Kako izbeći beskorisne sprint ciljeve – jer roadmap mora biti smislen kako bi sprintovi imali jasne ciljeve.

Kako kreirati roadmap koji ima smisla?

1. Definiši ključne korisničke probleme

Iskreno za početak.
Ne možeš kreirati dobar roadmap sedući sam/a u kancelariji, sipajući petu kafu i razmišljajući: “Šta bi bilo kul da napravimo?“
To sam probala više puta, veruj mi na reč da ne funkcioniše.�

Umesto da se fokusiraš na „Šta ćemo praviti?”, pitaj se „Koji problem rešavamo?”.
Korisnički problemi su osnova roadmap-a! Tačka.

Primer: Umesto „Dodati AI pretragu proizvoda“, bolje je „Korisnici troše previše vremena tražeći proizvode – smanjiti vreme pretrage za 30%“.

Metoda: Koristi korisničke intervjue i analitiku da potvrdiš probleme. Razgovor sa stvarnim korisnicima često je bio najbitniji deo mog posla, iako u početku nisam cenila koliko je to važno.

2. Postavi prioritete koristeći odgovarajuću metodu

Ne možeš sve raditi odjednom – ključno je odrediti šta donosi najveću vrednost.
Imala sam prilike da upoznam različite metode, a evo dve koje su mi lično najviše pomogle:

MoSCoW metoda

• Must have: Kritične funkcionalnosti bez kojih proizvod ne može da funkcioniše.
• Should have: Važne funkcionalnosti koje nisu kritične, ali donose značajnu vrednost.
• Could have: Dodatne funkcionalnosti koje bi mogle poboljšati iskustvo, ali nisu prioritet.
• Won’t have: Funkcionalnosti koje se u ovoj fazi ne implementiraju.

Ovo mi je bila omiljena metoda dok nisam shvatila da nekako sve završi u “Must have” kategoriji. Ko bi rekao da stakeholderi misle da je baš sve kritično? Više o MoSCoW metodi pročitaj ovde >>

Weighted Scoring

• Definišeš kriterijume (npr. prihod, korisnički uticaj, konkurentska prednost, tehnička izvodljivost) i dodeljuješ im koeficijente.
• Svaka inicijativa dobija ocene prema kriterijumima, pa se sabira ukupni rezultat.

Ovo je sjajno za sastanke gde stakeholderi se svađaju oko prioriteta. Kad sve svedeš na brojeve, odjednom svi postanu racionalniji – barem na trenutak.�

Više o Weighted Scoring metodi pročitaj ovde >>

3. Kreiraj roadmap baziran na isporuci vrednosti

Pričala sam jednom sa kolegom Product Ownerom koji je rekao: “Znaš šta je problem sa našim roadmap-om? Izgleda kao da smo postavili sebe kao kupce – a ne naše korisnike.“

Ta rečenica mi je odzvanjala u glavi danima.
Pravi roadmap se ne bavi taskovima, već fazama isporuke vrednosti korisnicima.

Primer:�

Kad ovako postaviš stvari, roadmap postaje jasan plan puta, a ne nabacana lista želja. I to je ono što zaista želiš.

Zaključak

Na kraju dana, roadmap koji ima smisla ne fokusira se na taskove, već na korisničke probleme.
Možeš imati najlepši Gantt chart ili najdetaljniji backlog na svetu, ali ako ne rešavaš prave probleme, gradiš auto za ljude koji traže bržeg konja.

Korišćenjem metodologija poput korisničkih intervjua, MoSCoW prioritizacije i iterativnog planiranja, možeš kreirati jasan i prilagodljiv plan razvoja.�

Sledeći korak: U sledećem blog postu obrađujemo kako da backlog ne bude samo spisak taskova, već alat za isporuku vrednosti korisnicima.�

A sada, iskreno: Kako tvoj tim trenutno kreira roadmap?

P.S. I ne, ne očekujem samo pozitivne odgovore. Znamo svi da je stvarnost često drugačija od teorije.