Metody určení priorit

Co ve vývoji aplikace upřednostnit a co musí počkat? Přehled hlavních metod pro stanovení priorit — RICE, MoSCoW, Kano, ICE a další — včetně praktických příkladů.

Proč prioritizovat

Backlog má tendenci růst rychleji, než je tým schopen dodávat. Požadavky přicházejí od uživatelů, členů týmu, supportu i dalších stakeholderů. Bez systému prioritizace se snadno stane, že děláte věci podle toho, kdo hlasitěji křičí.

Používám mix z níže uvedených metod, ale nedržím se žádné striktně. Za roky práce jsem si odnesl pár zkušeností:

• Nedělat bezhlavě všechno, co si zákazník vymyslí. Uživatelé často popisují řešení, ne problém. Úkolem PM je pochopit skutečnou potřebu.
• Hlasitější zákazník obvykle není ten nejdůležitější. Korporátní klient s vysokým MRR má jinou váhu než free uživatel, který píše každý týden.
• Nezapomínat na technický dluh. Hodně teorií pracuje se spokojeností zákazníka. Něco však zákazník nevidí a neumí ocenit (např. refaktoring, bezpečnostní updaty). A občas je dobré zařadit taky prvek, který udělá radost samotnému týmu.
• Efektivita dodávky. I když není nějaká funkce dle metod prioritní, může být vhodné ji udělat společně s jiným úkolem, protože programátoři to mají v hlavě a nemusí se později znovu seznamovat s kontextem.
• Třešničky budují vztah. Drobnosti jako animace, gamifikace nebo easter eggs nejsou z pohledu požadavků důležité, ale pomáhají budovat emocionální vztah k produktu.
• Jednoduchost nad sofistikovaností. Často je lepší zvolit metodu jednodušší a srozumitelnější, než nějakou příliš sofistikovanou, které ostatní strany nepochopí.

Absolutní vs. relativní odhady

U většiny metod se pracuje s odhady veličin — jak pracná bude funkce, jaký přinese užitek. Problém je, že skutečné hodnoty předem neznáme.

Absolutní odhady (např. „tato funkce vyžaduje 20 hodin“) mají nevýhodu v přesnosti — zeptejte se deseti lidí a dostanete deset různých čísel. Navíc backlog často zpracovává neprogramátor, který dokáže odhadnout effort jen řádově.

Relativní odhady jsou praktičtější. Nejčastější škály:

• Číselné: 1–5 nebo 1–10
• T-shirt sizing: XS, S, M, L, XL
• Fibonacciho řada: 1, 2, 3, 5, 8, 13, 21
• Vizuální symboly: hvězdičky, emoji

Výhoda relativních odhadů: je snazší říct „tohle je dvakrát složitější než tamto“ než odhadnout přesný počet hodin.

Value / Effort matice

Nejjednodušší metoda, se kterou začínám u menších projektů nebo když potřebuji rychle roztřídit backlog. Pracuje se dvěmi veličinami:

• Value (hodnota): Jak moc přispěje tento úkol k uspokojení zákazníků nebo ke splnění cílů? Škála např. 1–10.
• Effort (úsilí): Jak velké úsilí je potřeba pro dodání? Škála např. XS=1, S=3, M=5, L=8, XL=13.

Výpočet: V/E skóre = Value / Effort

V/E skóre = Value / Effort. Protože Value je pozitivní veličina a Effort negativní, je vhodné spočítat jejich podíl. Ten pak bude říkat, že čím vyšší je výsledek podílu, tím dává větší smysl přidělit úkolu vyšší prioritu.

Když se vynese do grafu s osami Value a Effort, tak vzniknou kvadranty:

• Quick wins – velká hodnota dosažitelná s malým úsilím.
• Big Bets – velká hodnota s velkým úsilím
• Maybes – malá hodnota s malým úsilím
• Time sinks – malá hodnota s velkým úsilím 

Při prioritizaci se tedy nabízí začít od Quick wins, naopak Time sinks nechat u ledu.

Kdy použít: Rychlé třídění backlogu, menší týmy, situace kdy nepotřebujete přesné skóre ale spíš kategorii.

Metoda RICE

Propracovanější metoda od Intercomu. Používá se, třeba když potřebujete obhájit priority před ostatními — čísla působí objektivněji než „mám pocit, že tohle je důležitější“. Bere v úvahu 4 veličiny:

• Reach: dosah – jak velkého počtu uživatelů se to týká. Uváděno v absolutních počtech uživatelů.
• Impact: dopad – jak moc to ovlivní uživatele, jak moc splnění přispěje k dosažení našeho hlavního cíle. Škála může být různá: 3=masivní, 2=vysoký, 1=střední, 0,5=nízký a 0,25=minimální, nebo např. jednoduchá škála 1-10.
• Effort: jak velké úsilí je potřeba pro dodání, kolik zdrojů, nákladů to bude stát. Uváděno ve škále např. S=5, M=10, L=20 nebo rovnou v absolutních číslech, např. člověkohodiny.
• Confidence: jistotu – jak moc jsme si tímto úkolem jistí? Jak ho dokážeme splnit, jak moc pomůže ke zvýšení spokojenosti a zda zasáhne předpokládaný počet uživatelů. 1=vysoká, 0,8=střední, 0,5=nízká nebo pomocí škály 1-10.

RICE skóre = RICE = (Reach × Impact × Confidence) / Effort

Čím je výsledek vyšší, tím vyšší priorita. Někdy se také používá výpočet pomocí součtu v čitateli: (Reach+Impact+Confidence) / Effort.

Příklad

Mám SaaS produkt s 5000 aktivními uživateli měsíčně. V backlogu jsou tyto featury:

Výsledné pořadí: Onboarding wizard a fix bugu (800) → Dark mode (667) → PDF export (500) → API (19)

Všimněte si, že API pro enterprise klienty vyšlo nejhůř — i přes masivní impact na jednotlivce je nízký reach a confidence. V praxi bych tohle možná přehodnotil, protože 50 korporátních klientů může generovat víc než 5000 free users. RICE je vodítko, ne automat.

Kdy použít: Větší backlog (20+ položek), při potřebě obhájit priority čísly.

Metoda ICE

Zjednodušená varianta RICE, kterou lze použít pro rychlejší odhady.

Tři veličiny (všechny na škále 1–10):

• Impact: Jaký dopad bude mít na cíl?
• Confidence: Jak jsme si jistí?
• Ease: Jak snadné je to implementovat? (opak Effort)

Výpočet: ICE = Impact × Confidence × Ease

Výhoda oproti RICE: jednodušší, rychlejší.
Nevýhoda: nezohledňuje Reach, takže feature pro 10 uživatelů může vyjít stejně jako feature pro 10 000.

Kdy použít: Rychlé prioritizace, menší produkty, situace kdy reach není klíčový faktor.

Metoda MoSCow

JJednoduchá kategorizace vhodná pro scope jednoho releasu nebo MVP.

• Must have: Bez toho to nemá smysl releasovat
• Should have: Důležité, ale dá se bez toho žít
• Could have: Bylo by fajn mít
• Won’t have (this time): Teď ne, možná později

Pozor na past: Tento přístup svádí k přeceňování důležitosti. Když se všechno označí jako „Must have“, metoda ztrácí smysl. Dobrá pomůcka: Must have by mělo být max 60% scopu.

Kdy použít: Plánování releasu, definice MVP, komunikace se stakeholdery („tohle bude v první verzi, tohle ne“).

Metoda WSJF (Weighted shortest job first)

Metoda z frameworku SAFe, vhodná pro větší organizace. Pracuje s veličinami:

• Business Value: Hodnota pro business
• Time Criticality: Urgentnost (je deadline?)
• Risk Reduction / Opportunity Enablement: Snižuje to riziko nebo otevírá nové příležitosti?
• Job Size: Velikost úkolu (effort)

Výpočet: Součet prvních třech metrik dohromady tvoří náklady zpoždění (costs of delay – CoD) – tedy hodnotu, o kterou přijdeme, když daná věc nebude. Používá se např. Fibonacciho škála. WSJF je podíl CoD/Effort.

Cost of Delay = Business Value + Time Criticality + Risk Reduction
WSJF = Cost of Delay / Job Size

Např. (Value =5 + Urgency=8 + Opportunity = 5) / Effort = 3, pak skóre WSJF =6. Provedením výpočtu pro všechny položky v backlogu se pak určí nejvyšší WSJF – ty dy, které v nejkratším čase zajistí nejvyšší přínos.

Kdy použít: Enterprise prostředí, SAFe týmy, situace kde hraje roli timing a urgentnost.

Kano model

Jde o jiný pohled – nezabývá se pořadím, ale typem hodnoty, kterou feature přináší. Pracuje s diagramem zákaznické spokojenosti na dvou osách: spokojenost vs. investice. Rozděluje úpravy do skupin:

• Must-be (Basic): Očekávaná funkčnost. Když chybí, uživatel je nespokojený. Když je, bere ji jako samozřejmost. (Příklad: možnost se přihlásit)
• Performance: Čím více, tím lépe. Lineární vztah mezi funkcionalitou a spokojeností. (Příklad: rychlost načítání)
• Delighters (Attractive): Nečekané featury, které nadchnou. Když chybí, nikdo si nevšimne. Když jsou, uživatel je nadšený. (Příklad: personalizované doporučení)
• Indifferent: Uživateli je jedno, jestli to je nebo není.

Kdy použít: Strategické plánování, rozhodování o diferenciaci produktu, pochopení co skutečně buduje kompetitivní výhodu.

Detailně popsáno např. zde.

Opportunity Scoring (Ulwick)

Jednoduchá metoda založená na Jobs-to-be-Done teorii. Měří mezeru mezi důležitostí a spokojeností. Postup je jednoduchý:

1. Identifikujte „jobs“ — úkoly, které uživatel potřebuje splnit
2. Pro každý job se uživatelů zeptejte:
   • Jak důležitý je tento úkol? (1–10)
   • Jak jste spokojeni se současným řešením? (1–10)

Výpočet: Opportunity = Importance + (Importance – Satisfaction)

Vysoká důležitost + nízká spokojenost = největší příležitost.

Kdy použít: Discovery fáze, hledání product-market fit, rozhodování o nových produktech. 

The One Thing

Moje oblíbená – je inspirována knihou The One Thing, i když v trochu jiném pojetí. Název je samovysvětlující – položíte si otázku:

• Kterou jednu věc v tomto {sprintu/týdnu/měsíci/…} musíme udělat, i kdyby se nic jiného nepovedlo, a která nás posune nejdál.

Pokud umíte jednoznačně odpovědět, máte prioritu 1 vyřešenou a pokračujete dál.

Kterou metodu kdy použít?

Další metody prioritizace

• Eisenhowerova matice (důležitost vs. urgentnost) s kvadranty Do, Plan, Delegate, Eliminate
• Story Mapping
• PriX metoda
• Product tree
• Conjoint analýza
• Buy a feature

Co říkají ostatní

Na závěr pár výstřižků z diskuse na redditu: jsou mezi nimi perly na pobavení, ale zároveň je tam hodně zkušeností:

Takhle dávám priority v mý obří korporátní dinosauří technologický firmě:
P1: [úmyslně ponecháno prázdné, aby eskalace vypadaly hezky]
P2: Někdo aktivně řve
P3: Normální prioritní práce
P4: neuděláme to, ale někdo se na to bude zlobit
P5: neuděláme to, ale nikdo si toho nevšimne.

—

… zvážit alespoň jednu „teoretickou“ metodu prioritizace, kterou implementuješ (RICE je běžná pro začátek), ale to pokryje hlavně nové funkce. Pak budeš chtít použít tu prioritizaci jako základ. Budeš muset započítat nějakou část kapacity na opravy chyb a technický dluh (10-25 %), a prakticky budeš muset započítat i část kapacity na neplánovaný urgentní požadavky (5-15 %) – to jsou obvykle CEO nebo jiní vyšší stakeholdeři, co prosazujou svou osobní prioritu na nějaký problém, co se má eskalovat. Pokud se část z toho dostane do bodu, kdy se míň než ~70 % tvojí kapacity utratí na plánovaný prioritizovaný práci na roadmapě po 2 sprinty za sebou, tak máš asi problém s managementem a/nebo zdroji, co se musí eskalovat. Jediný reálný důvod, proč by dev tým měl mít vstup do priority práce, je, když je sekvence práce neefektivní/iracionální. Tj. nedává smysl pracovat nejdřív na funkci A, pokud je funkce B předpokladem. Téměř ve všech ostatních situacích je odpověď, kterou dáš svýmu dev týmu, „tohle je business priorita a co dává smysl teď řešit…

—

Pro můj tým jsou priority:
– Úspěch zákazníků – ujistěte se, že zákazníci vyhrávají. Více hodnoty, snadné přijetí, snadné použití
– Obchodní úspěch – ujistěte se, že vaše firma vyhrává. Více zákazníků, více příjmů (nebo přijetí nebo inovace). – Zjistěte, jak se váš produkt celkově shoduje.
– Když si nejste jisti, dělejte #1 opravdu, opravdu dobře.

—

Upřímně řečeno, většina vedoucích má silné předsudky a nedovolí vám prioritizovat, pokud vám dají autonomii, dělejte #1 více než 2 a bavte se u toho. Pro prioritizaci občas používám RICE, ale co to vždycky přebilo, je naštvaný zákazník.

—

Takhle si já řadím backlog na každý sprint:
– Bugy nebo eskalace (ne funkce!) od zákazníků/z terénu, které přímo ovlivňují udržení zákazníků nebo nové výnosy
– Bugy, které jsou v podstatě blokátory pro produkt/funkce, za které je tým zodpovědný
– Roadmap – nové funkce/vylepšení; prioritizované na základě dopadu a zkontrolované oproti kapacitě týmu/dostupným dovednostem daného sprintu
– Další high prio bugy nebo problémy s technickým dluhem
– Úkoly, které pomáhají zvýšit naši rychlost (např. části produktu, které nejsou pokryty automatizovanými testy – brzdí naši schopnost spolehlivě dodávat)
Někdy potřebujeme deprioritizovat high prio bugy, jindy dělat víc úkolů atd.

—

Co fungovalo u mě:
– Rozdělit backlog do 4 kyblíků: Musí se opravit, Strategické sázky, Rychlé výhry, Technický dluh
– Prioritizovat na základě: co teď odblokuje, co odemkne později
– Týdenní třídění s vedoucím inženýrem, neskopovat sólo
– Když si nejsem jistý: ukazovat pokrok, ne dokonalost
Vývojáři se méně brání, když vidí jasné důvody, i když jsou nedokonalé.

—

Prioritizace RICE upřednostňuje věci, které dobře skórují. Stejně jako u odhadů, skutečnost je úplně jiná. Prioritizace RICE je často forma tasseografie: snaha předpovědět budoucnost na základě zbytků kávy, co ti zbydou v hrnku. Stejně jako kávová sedlina neobsahuje žádné informace o budoucnosti, RICE nepředpovídá, jak cenná věc je. Je to proto, že RICE je často šum. Až na případy, kdy ladíš něco existujícího, pak to může být docela přesné.

Jak porovnáš velkou sázku (třeba něco, co trvá hodně měsíců), pro co teď nemáš nic, vs. něco malého, co zabere pár týdnů? Viděl jsem, jak se ty malé sázky deprioritizovaly kvůli velkým sázkám kvůli RICE skóre (byla vypočítána cena zpoždění). Aby toho nebylo málo, není to jen šum, ale obchodní případy jsou založeny na předpokladech, a pokud se některý z nich neudrží, celá věc se zhroutí.
Je snadné se fixovat na RICE skóre. Je mnohem důležitější být strategický, dělat průzkum a mít rychlé iterace, abys získal lepší informace, než leštit RICE čísla, která poskytnou falešnou iluzi jistoty.
A jo, měj velké sázky, ale otestuj si ty předpoklady, než se pustíš do něčeho velkého….

—

Nestíháš, tvoji developeři nestíhají, ale dokud dělají na něčem, co přidává hodnotu, tak by to mělo stačit.
Oprava bugů – tvůj produkt by měl fungovat, jak se očekává, lidi, co za to platí, by neměli mít žádný problémy.
Cokoliv, co přidává hodnotu a tvůj tým to chce stavět.
Pokud nedokážeš senior developerovi vysvětlit, proč ho chceš na X místo Y, tak je asi jedno, na čem bude dělat. Nech je dělat na Y, pokud chtějí – šťastní developeři jsou produktivní developeři.

—

Oprav věci, co jsou blbě udělaný a opravujou hodnotu už dodaných věcí (obvykle má největší efekt).
Soustřeď se na věci, co mají nejvyšší cenu zpoždění, tzn. zeptej se sám sebe: Pokud to dodáme o měsíc – nebo cokoli je v tvým případě rozumný – později, o kolik míň peněz vyděláme?
Jasně, 2) zahrnuje hodně pocitu na tvý straně (protože ti chybí data), hodně předpokladů o tom, co si tvoji uživatelé/zákazníci budou cenit.
Udělej je transparentní. Zapiš si je. Diskutuj s ostatníma. Zapoj User Research. Dodávej malý věci, abys mohl rychle ověřit svoje předpoklady a přizpůsobit se novýmu poznání.

Další zdroje:

• RICE scoring model – Intercom
• Product prioritization techniques – Roadmunk
• PriX metoda pro startupy – Pixelfield
• Kano model – Folding Burritos
• Opportunity Scoring – Strategyn