Ve většině produktových týmů je backlog místem, kde naléhavost umírá. Všechno, co vstoupilo, bylo naléhavé, když bylo přidáno – stížnost zákazníka, požadavek prodeje, funkce konkurence, interní náppad. Šest měsíců později je všechno stále tam, všechno se stále cítí naléhavé, a nikdo přesně neví, co dělat dál.
Problém není nedostatek nástrojů. Existují desítky rámců prioritizace: RICE, MoSCoW, Kano, ICE, vážené bodování. Problém spočívá v tom, že většina rámců vyžaduje určitou falešnou přesnost – přiřazování čísel neznámým – což je činí zdánlivě rigorózními, zatímco ve skutečnosti jen prodávají intuitivní pocit pomocí tabulky.
To, co opravdu funguje, je jednodušší: dvě dimenze, čestně posouzené, a disciplína jednat podle výsledku.
Prioritizace se redukuje na dvě otázky. Nejdříve: jak moc se zlepší výsledek, který nás zajímá? (Dopad.) Za druhé: kolik nás to bude stát na doručení? (Úsilí.) Všechno ostatní je buď vylepšením těchto dvou, nebo rozptýlením od nich.
Důvěra se někdy přidává jako třetí dimenze – „jak si jsme jisti dopadem?" – a stojí za to mít na paměti. V praxi ale většina týmů ví, kdy hádat. Disciplína spočívá v tom, označit odhad čestně, ne jej skórovat na stupnici 1–5 a přidat do vzorce.
Těžká část není pochopení mřížky – je to být čestný při jejím vyplňování. Každý tým má funkce, které chce vytvořit, které patří do "Časových pastí", ale stále se reklasifikují jako "Velké sázky." Rámec funguje pouze v případě, že tým může být čestný ohledně dopadu.
Dopad je dimenze, kterou týmy najdou nejhardší k posouzení, protože často vyžaduje předvídání budoucnosti. Pokušení je jej skórovat numericky a cítit se vědecky. Lepší přístup je kvalitativní, ale strukturovaný.
Položte tři otázky pro každou funkci, kterou zvažujete:
Týmy systematicky podceňují úsilí. To je dobře dokumentováno – souvisí to s omylem plánování a optimismem zkreslení – a je obzvláště výrazné pro funkce, které se dotýkají více systémů, vyžadují koordinaci mezi týmy, nebo zahrnují schopnosti, které tým nevytvořil dříve.
Dvě postupy pomohou. Nejdříve se vždy zeptejte inženýrství před skórováním úsilí, ne po. PMs, kteří skórují úsilí jednostranně, téměř vždy podceňují. Zadruhé, použijte koncept "neznámé neznámé" jako explicitní multiplikátor úsilí. Jakákoli funkce, která se dotýká nové oblasti kódu, rozhraní třetí strany, nebo toku uživatele, který nebyl nedávno testován, si zaslouží skóre úsilí 1,5x vyšší, než je zřejmá práce naznačuje.
Většina naléhavosti v backlogu produktu není skutečná naléhavost – je to novost. Zákazník si stěžoval minulý týden, takže jejich požadavek se cítí naléhavě. Konkurent minulý měsíc spustil něco, takže se jeho shodování cítí kriticky. Ale novost není totéž co důležitost, a reagování na novost je jeden z nejspolehlivějších způsobů, jak nechat skutečně důležitou práci sklouznout.
Praktický test: zeptejte se sami sebe, zda byste to stále považovali za naléhavé, kdybyste o tom slyšeli před šesti měsíci místo minulého týdne. Pokud je odpověď ne, je to zkreslení novosti při práci, ne strategická priorita. Zaznamenejte to, vyhodnoťte to klidu proti mřížce, a odolávejte tahu na fast-track jen proto, že je to čerstvé.
Mřížka ne vždy produkuje čistou odpověď. Dvě položky přistávají ve stejném kvadrantu s podobnými skóre, a stále si musíte vybrat jeden. V těchto případech jsou užitečny dva tiebreakery: strategické zarovnání (která vás přibližuje k tomu, kde chcete být za 18 měsíců?) a vrácení (která je těžší vrátit, pokud je špatně?). Upřednostňujte položku, která je více strategicky zarovnána a více vratná.