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

Další zdroje:

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