Ako prioritizovať funkcie v digitálnom produkte: postup v 5 krokoch

Čo potrebujete pripraviť skôr, než začnete prioritizovať funkcie?

Na prioritizáciu je potrebné mať k dispozícii štyri vstupy: jeden merateľný cieľ produktu, kompletný zoznam nápadov a požiadaviek (backlog), aspoň hrubý odhad náročnosti od vývojárov a dáta o používateľoch. Bez cieľa chýba kritérium pre poradie a bez odhadu náročnosti nemožno posúdiť, či sa funkcia oplatí.

• Cieľ a KPI: napríklad skrátiť spracovanie objednávky z 2 dní na 4 hodiny alebo zvýšiť počet aktívnych používateľov o 20 % za štvrťrok.
• Backlog na jednom mieste: postačí tabuľka, Jira, Trello alebo Notion. Podstatné je, aby žiadna požiadavka nezostala iba v e-maile.
• Účastníci workshopu: zástupca za biznis (majiteľ alebo produktový manažér), zástupca za používateľov (obchod, podpora, UX) a zástupca za techniku (vývojár alebo architekt).
• Dáta: analytika používania, tikety zo zákazníckej podpory, záznamy z rozhovorov so zákazníkmi a pri internom softvéri aj popis súčasných procesov.
• Čas: prvé kolo pre 30 až 50 položiek zvyčajne zaberie pol dňa až deň workshopu, ďalšie kolá sú kratšie.

Pri úplne novom produkte väčšinu týchto vstupov poskytuje discovery fáza projektu. Pri internom systéme je vhodným základom analýza firemných procesov, pretože ukazuje, kde sa reálne stráca čas.

Krok 1: Ako zistiť, ktoré funkcie podporujú cieľ produktu?

Výstupom tohto kroku je jedna veta o cieli a jeden až tri ukazovatele, voči ktorým posudzujete každú funkciu. Funkcia, ktorá žiadny z nich neposúva, patrí na koniec zoznamu, aj keď pôsobí atraktívne. Tento filter zvyčajne vyradí tretinu nápadov ešte pred použitím akejkoľvek metódy.

Tento krok má väčšiu váhu, než sa zdá. Podľa správy Pendo z roku 2019 sa až 80 % funkcií v priemernom softvérovom produkte používa zriedka alebo vôbec, pričom iba 12 % funkcií generuje 80 % denného používania. Funkcia, ktorá nepodporuje cieľ, je preto skôr nákladom navyše než pridanou hodnotou.

1. Sformulujte cieľ obchodne, nie technicky: „obchodníci zapíšu stretnutie do 1 minúty“, nie „chceme mobilnú verziu CRM“.
2. Ku každému cieľu priraďte KPI s aktuálnou a cieľovou hodnotou.
3. Určte časový horizont, napríklad najbližší štvrťrok alebo prvú verziu produktu.
4. Pri každej položke backlogu si položte otázku: Ktorý KPI to zlepší a o koľko? Ak na ňu nikto nevie odpovedať, položka zatiaľ nemá prioritu.

Ak zatiaľ overujete, či má produkt zmysel, cieľom je naučiť sa čo najviac pri čo najmenšom rozsahu. Tento prístup podrobnejšie vysvetľujeme v článku o MVP pre firmy.

Krok 2: Ako zozbierať a vyčistiť backlog funkcií?

Cieľom je jeden zoznam, v ktorom každá položka popisuje problém používateľa, nie hotové riešenie, a je dostatočne malá na ohodnotenie. Takto vyčistený backlog umožňuje objektívne porovnanie. Pokiaľ sa v ňom mieša „nové tlačidlo“ s „celým modulom fakturácie“, každé poradie bude skreslené.

1. Zbierajte podnety zo všetkých zdrojov: spätná väzba zákazníkov, podpora, obchod, vedenie, analýza konkurencie, vlastné dáta o používaní a nápady tímu.
2. Prepíšte požiadavky na problémy: namiesto „export do Excelu“ zapíšte „účtovníčka každý piatok ručne prepisuje 40 objednávok“. Často sa ukáže lacnejšie riešenie, napríklad API prepojenie s účtovným systémom.
3. Zlúčte duplicity: tri oddelenia často žiadajú to isté inými slovami.
4. Rozdeľte veľké položky: všetko, čo podľa vývojárov trvá viac ako 2 až 3 týždne, rozdeľte na menšie časti, ktoré prinášajú hodnotu aj samostatne.
5. Označte závislosti: napríklad notifikácie nefungujú bez používateľských rolí. Závislosť môže neskôr posunúť položku vyššie, než by jej patrilo podľa skóre.
6. Pripíšte zdroj a počet žiadostí: položka, ktorú žiada 15 zákazníkov, má iný význam ako nápad jedného človeka.

Krok 3: Ktorú metódu prioritizácie zvoliť?

Metódu volíme podľa situácie. MoSCoW sa hodí na rýchle vymedzenie rozsahu MVP, RICE na porovnanie desiatok položiek pomocou čísel, Kanov model na pochopenie spokojnosti zákazníkov a matica hodnota vs. úsilie na rýchly vizuálny prehľad na workshope. Väčšina tímov kombinuje dve metódy: jednu na hrubé triedenie, druhú na presné poradie.

Metóda	Kedy ju použiť	Ako funguje
MoSCoW	Vymedzenie MVP alebo pevného termínu	Must have, Should have, Could have, Won't have (teraz nie). Položky „Must“ by mali zabrať najviac okolo 60 % kapacity.
RICE	20 a viac položiek, dostupné dáta	Skóre = (Dosah × Dopad × Istota) / Úsilie
Kanov model	Produkt s konkurenciou, dôraz na spokojnosť	Základné funkcie (bez nich zákazník odíde), výkonnostné (čím viac, tým lepšie), nadšenie (príjemné prekvapenie)
Hodnota vs. úsilie	Rýchly workshop, menší backlog	Matica 2 × 2, hľadáte „quick wins“: vysoká hodnota, nízke úsilie

Ako vyzerá RICE v praxi?

Dosah je počet používateľov za obdobie. Dopad sa hodnotí na škále 3 (obrovský), 2 (vysoký), 1 (stredný), 0,5 (nízky) a 0,25 (minimálny). Istota nadobúda hodnoty 100 %, 80 % alebo 50 % a úsilie sa uvádza v človekomesiacoch.

Funkcia	Dosah/štvrťrok	Dopad	Istota	Úsilie	RICE
Rýchle zadanie stretnutia v CRM	800	2	80 %	2	640
Pripomienka follow-upu	3 000	0,5	50 %	1	750
Pokročilý reporting pre vedenie	200	3	100 %	4	150

„Malá“ pripomienka dosiahla vyššie skóre než funkcia s vysokým dopadom, pretože sa dotkne veľkého počtu ľudí a vyžaduje málo úsilia. Práve takéto výsledky sú dôvodom, prečo je vhodné počítať, nie iba odhadovať.

Krok 4: Ako ohodnotiť funkcie a zostaviť finálne poradie?

Výstupom je zoradený zoznam, na ktorom sa zhodne biznis aj technika. Hodnotu posudzujú ľudia blízko zákazníkov, úsilie vývojári a na záver poradie upravíte podľa závislostí, rizika a kapacity. Skóre je podklad na rozhodnutie, nie automat, ktorý rozhoduje za Vás.

1. Hodnoťte oddelene: biznisovú a používateľskú časť (dosah, dopad) vyplní produktový tím, úsilie odhadnú vývojári. Kto odhaduje oboje, podvedome upraví čísla podľa toho, čo chce presadiť.
2. Odhadujte v rozpätiach: „2 až 4 týždne“ je presnejšie ako „3 týždne“. Väčšia neistota má znížiť istotu v RICE. Ako robiť odhady realisticky, opisuje článok o odhade rozpočtu na softvérový projekt.
3. Vypočítajte skóre a zoraďte.
4. Upravte poradie podľa závislostí: ak funkcia č. 2 potrebuje infraštruktúru z funkcie č. 9, posuňte č. 9 vyššie.
5. Vyhraďte kapacitu na údržbu: časť každého šprintu ponechajte na opravy, výkon a bezpečnosť, inak produkt časom spomalí.
6. Určte hranicu: podľa kapacity tímu stanovte, čo sa realizuje v najbližšom období. Všetko pod hranicou dostane jasné „teraz nie“, nie neurčité „možno“.
7. Zapíšte zdôvodnenie: jedna veta, prečo je položka na danom mieste. O pol roka Vám to ušetrí rovnakú diskusiu.

Krok 5: Ako premeniť poradie na roadmapu a priebežne ho overovať?

Výstupom je roadmapa rozdelená na obdobia „teraz, ďalej, neskôr“ a pravidelný rytmus, v ktorom poradie aktualizujete podľa skutočných dát. Prioritizácia nie je jednorazové rozhodnutie. Po spustení každej funkcie meriate, či posunula KPI, a z výsledkov sa učíte lepšie odhadovať dopad ďalších položiek.

1. Rozdeľte zoradený backlog do horizontov: teraz (aktuálny šprint alebo mesiac, presne), ďalej (1 až 3 mesiace, orientačne), neskôr (témy, nie termíny).
2. Pri každej funkcii vopred určte spôsob merania úspechu: konkrétny ukazovateľ a dátum vyhodnotenia, zvyčajne 2 až 6 týždňov po spustení.
3. Väčšie alebo neisté funkcie najprv overte na prototype. Pomôže Vám návod, ako otestovať prototyp s používateľmi.
4. Backlog prehodnocujte v krátkom rytme (napríklad raz za 2 týždne pri plánovaní šprintu) a celú roadmapu raz za štvrťrok.
5. Porovnávajte odhadovaný a skutočný dopad. Ak sa trvalo mýlite, upravte škály, nie iba čísla.

Tému, ako roadmapu komunikovať vedeniu a zákazníkom bez sľubovania pevných termínov, rozoberáme v článku o plánovaní roadmapy digitálneho produktu.

Aké sú najčastejšie chyby pri prioritizácii funkcií?

Najčastejšie chyby sú rozhodovanie podľa názoru najvyššie postavenej osoby, snaha realizovať všetko naraz, prioritizácia riešení namiesto problémov a nemeranie výsledku po spustení. Každej z nich sa dá predísť jednoduchým pravidlom, ktoré tím dodržiava pri každom kole prioritizácie.

• HiPPO efekt (názor najlepšie plateného človeka): každá položka vyžaduje dáta alebo zdroj, nie iba autora. Aj nápad riaditeľa prejde skórovaním.
• Všetko je „Must have“: do „Must“ patria iba funkcie, bez ktorých produkt nesplní svoj cieľ. Ak ich je viac, než dovoľuje kapacita, rozsah je nesprávne nastavený.
• Rozhoduje ten, kto je najhlasnejší: jeden nespokojný zákazník nie je trend. Sledujte počet žiadostí a ich hodnotu.
• Podceňovanie úsilia: optimistické odhady sú hlavným dôvodom, prečo sa softvérový projekt predraží. Pridajte rezervu a znížte istotu.
• Poradie raz a navždy: trh aj procesy sa menia. Bez pravidelného prehodnotenia pracujete podľa zastaraných predpokladov.
• Ignorovanie existujúcich procesov: funkcia, ktorá nezodpovedá tomu, ako firma reálne pracuje, sa nebude používať, aj keby mala najvyššie skóre.

Kedy sa oplatí prizvať k prioritizácii partnera na vývoj?

Partnera odporúčame prizvať, keď nemáte interného produktového manažéra ani architekta, keď backlog obsahuje funkcie, ktorých náročnosť nevie nikto vo firme odhadnúť, alebo keď produkt musí zodpovedať zložitým firemným procesom, napríklad CRM, zákazníckemu portálu či prepojeniu viacerých systémov. V takom prípade sa prioritizácia a odhad vývoja nedajú oddeliť.

V BeCode staviame softvér na mieru okolo reálnych procesov klienta, a preto u nás prioritizácia začína pri procese, nie pri zozname funkcií. V praxi postupujeme takto:

• Spoločný workshop: zmapujeme procesy, ciele a KPI a premeníme požiadavky na problémy.
• Technický odhad priamo pri stole: vývojári a architekt hodnotia úsilie a závislosti, takže poradie od začiatku zohľadňuje, čo je reálne.
• Rozsah prvej verzie: navrhneme MVP, ktoré rieši najväčší problém, a architektúru, ktorá unesie ďalšie funkcie bez prerábania.
• Dáta po spustení: nastavíme meranie, aby ďalšie kolá prioritizácie vychádzali z čísel, nie z dojmov.
• Automatizácia namiesto funkcií: časť požiadaviek vyriešime AI automatizáciou alebo integráciou rýchlejšie, než by to dokázala nová obrazovka.

Ak Váš backlog obsahuje množstvo požiadaviek a nie je jasné, čím začať, radi ho s Vami prejdeme na spoločnom workshope a premeníme ho na realistický plán prvej verzie. Cena takejto spolupráce závisí od veľkosti backlogu, počtu systémov na prepojenie a od toho, či ide o nový produkt alebo rozšírenie existujúceho. Ako sa rozpočet skladá, vysvetľuje článok koľko stojí webová aplikácia pre firmu.

Časté otázky

Ako si určiť priority pri práci na MVP?

Pri MVP prioritizujte iba funkcie, ktoré overujú hlavný predpoklad produktu, teda či používateľ problém naozaj má a Vaše riešenie mu pomôže. Použite MoSCoW: do „Must have“ zaraďte len kľúčový tok od registrácie po hlavný úžitok a všetko ostatné odložte. Čo presne patrí do prvej verzie, vysvetľuje článok o minimálnom životaschopnom produkte.

Čo robiť, keď je všetko vysoká priorita?

Keď je všetko vysoká priorita, v skutočnosti neexistuje poradie. Vynúťte porovnávanie: zoraďte položky od prvej po poslednú bez zdieľaných miest, alebo použite RICE, ktoré priradí každej položke jedno číslo. Pomáha aj pevný limit, napríklad najviac päť položiek v stave „teraz“. Ostatné dostanú jasné rozhodnutie „neskôr“.

Kto má mať posledné slovo pri prioritizácii funkcií?

Posledné slovo má mať jedna zodpovedná osoba, zvyčajne produktový manažér alebo produktový vlastník, nie hlasovanie celej firmy. Rozhoduje však na základe vstupov: hodnotu dodáva biznis a ľudia blízko zákazníkov, náročnosť vývojári. Ak firma takúto rolu nemá, môže ju dočasne pokryť skúsený partner na vývoj.

Ako prioritizovať backlog v praxi, nielen podľa teórie?

V praxi funguje jednoduchý rytmus: raz za dva týždne prejdete nové položky a rýchlo ich ohodnotíte, napríklad maticou hodnota vs. úsilie. Raz za štvrťrok prepočítate RICE pre celý backlog a porovnáte odhady so skutočnými výsledkami. Staré položky, ktoré pol roka nikto nepotreboval, môžete odstrániť. Ak sú dôležité, vrátia sa.

Ako zapojiť zákazníkov do prioritizácie funkcií?

Zákazníkov sa nepýtajte, aké funkcie chcú, ale aké problémy riešia a koľko ich to stojí. Realizujte krátke rozhovory s piatimi až desiatimi používateľmi, sledujte tikety podpory a dáta o používaní. Odpovede zapisujte do backlogu ako problémy spolu s počtom zákazníkov, ktorí ich zmienili. Tento počet následne vstupuje do dosahu v RICE.