Ve většině produktových týmů je backlog místem, kde naléhavost umírá. Všechno, co do něj vstoupí, bylo v okamžiku přidání naléhavé – stížnost zákazníka, požadavek obchodního týmu, funkce konkurence, interní nápad. O šest měsíců později je to všechno pořád tam, všechno pořád působí naléhavě a nikdo přesně neví, co dělat dál.
Problém není nedostatek nástrojů. Existují desítky rámců pro stanovování priorit: RICE, MoSCoW, Kano, ICE, vážené bodování. Problém je v tom, že většina rámců vyžaduje určitou falešnou přesnost – přiřazování čísel neznámým veličinám – a díky tomu působí rigorózně, zatímco ve skutečnosti jen „vypere“ intuitivní odhad přes tabulku.
To, co opravdu funguje, je jednodušší: dvě dimenze, posouzené upřímně, a disciplína jednat podle výsledku.
Stanovování priorit se zredukuje na dvě otázky. První: o kolik zlepší tohle výsledek, na kterém nám záleží? (Dopad.) Druhá: kolik nás bude stát to dodat? (Úsilí.) Všechno ostatní je buď zpřesněním těchto dvou, nebo odvedením pozornosti od nich.
Jistota se někdy přidává jako třetí dimenze – „jak moc jsme si jistí dopadem?“ – a stojí za to ji mít na paměti. V praxi ale většina týmů ví, kdy jen hádá. Disciplína spočívá v tom, odhad upřímně označit, a ne ho bodovat na stupnici 1–5 a dosazovat do vzorce.
Těžké není pochopit mřížku – těžké je být upřímný při jejím vyplňování. Každý tým má funkce, které by rád vytvořil a které patří mezi „Žrouty času“, ale pořád se přeřazují mezi „Velké sázky“. Rámec funguje jen tehdy, když je tým schopen být upřímný ohledně dopadu.
Dopad je dimenze, kterou týmy považují za nejobtížněji posuditelnou, protože často vyžaduje předpovídat budoucnost. Pokušením je ohodnotit ho číselně a cítit se přitom vědecky. Lepší přístup je kvalitativní, ale strukturovaný.
U každé zvažované funkce si položte tři otázky:
Týmy systematicky podceňují úsilí. Je to dobře zdokumentované – souvisí to s plánovacím omylem a optimistickým zkreslením – a je to obzvlášť výrazné u funkcí, které zasahují více systémů, vyžadují koordinaci mezi týmy nebo zahrnují schopnosti, které tým dosud nevytvořil.
Pomáhají dvě praktiky. Za prvé, vždy se před ohodnocením úsilí zeptejte vývojářů, ne až po něm. Produktoví manažeři, kteří úsilí hodnotí jednostranně, ho téměř vždy podcení. Za druhé, použijte koncept „neznámých neznámých“ jako výslovný násobitel úsilí. Každá funkce, která zasahuje do nové oblasti kódu, rozhraní třetí strany nebo uživatelského toku, který nebyl nedávno testován, si zaslouží skóre úsilí 1,5× vyšší, než naznačuje zjevná práce.
Většina naléhavosti v backlogu produktu není skutečná naléhavost – je to čerstvost. Zákazník si minulý týden stěžoval, takže jeho požadavek působí palčivě. Konkurent minulý měsíc něco spustil, takže dohnat to působí kriticky. Čerstvost ale není totéž co důležitost a reagovat na čerstvost 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 se o tom dozvěděli před půl rokem místo minulého týdne. Pokud je odpověď ne, je to působení zkreslení z čerstvosti, ne strategická priorita. Zaznamenejte to, v klidu to vyhodnoťte proti mřížce a odolejte nutkání dát tomu zelenou jen proto, že je to čerstvé.
Mřížka nedává vždy jasnou odpověď. Dvě položky skončí ve stejném kvadrantu s podobným skóre a vy si stejně musíte jednu vybrat. V takovém případě pomohou dvě rozhodující kritéria: strategická shoda (která vás přiblíží tomu, kde chcete být za 18 měsíců?) a vratnost (kterou je těžší vzít zpět, pokud se ukáže jako chybná?). Upřednostněte položku, která je strategicky lépe zarovnaná a snadněji vratná.