Jak prioritizovat požadavky na funkce, které se hromadí

Sledování požadavků na funkce vyřeší, kde žijí. Nevyřeší, který jde první, a na téhle druhé otázce se týmy skutečně zaseknou. Backlog tří set seskupených, oštítkovaných požadavků pořád potřebuje rozhodovací pravidlo, protože “postav to nejvíc požadované” funguje jen dokud jsou dva požadavky blízko sebe a třetí má hlasitou zastánkyni, což je většina týdnů. Rámce níže nejsou konkurenční odpovědi na stejnou otázku. Každý sedí na jiný typ požadavku, a používat jeden na všechny je obvykle skutečná chyba.

Co dělá prioritizaci požadavků na funkce jinou než prioritizaci roadmapy?

Rozhodnutí o roadmapě začíná u strategie a ptá se, co stavět. Rozhodnutí o požadavku na funkci začíná u poptávky, která už existuje, a ptá se, jestli na ni jednat, a tyhle dva táhnou dostatečně často různými směry, že požadavek může mít vysokou poptávku a přesto být špatný na postavení, nebo mít nízkou poptávku a přesto stát za to, protože odemyká strategický účet. Zacházet s každým požadavkem jako s hlasem pro roadmapu tuhle kontrolu přeskočí.

Co je RICE, a funguje pro požadavky na funkce?

RICE hodnotí nápad podle dosahu, dopadu, jistoty a úsilí, pak vydělí první tři čtvrtým, aby dostal srovnatelné číslo. Byl postaven pro nápady roadmapy, kterým už tým věří, kde ta těžká část je srovnávat různé sázky mezi sebou. Požadavky na funkce přicházejí už s číslem dosahu, počtem lidí, kteří žádali, což je konkrétnější než dosah, jaký obvykle má čerstvý nápad roadmapy. Kde se RICE napíná s požadavkem, je jistota a dopad: tým si může být jistý, že požadavek je skutečný, a přesto nemít základ, jak moc pohne metrikou, protože “dopad” pro požadavek, který má už jméno a stopu skutečných uživatelů, je jiný druh odhadu než dopad nápadu, který mimo místnost ještě nikdo neviděl.

Používej RICE na požadavky, které se vážně zvažují a ještě nejsou rozhodnuté. Neaplikuj ho na každý příchozí požadavek; úsilí na hodnocení se vyplatí jen u těch dost blízkých, aby potřebovaly rozhodčí.

Vážit podle příjmu, nebo podle toho, kdo žádal?

Podle toho, kdo žádal, ale ne jen podle příjmu. Účet blízko obnovení, účet, který už eskaloval, a účet, jehož požadavek odemyká probíhající obchod, nesou naléhavost, kterou plochá číslice příjmu sama nezachytí, a požadavek od zkušební registrace pořád může mít váhu, pokud blokuje rozhodnutí, které se brzy stane příjmem. Vážení příjmem je z tohohle nejsnazší na výpočet, a právě proto nejsnazší přecenit: správně odstraní šum od účtů bez skutečné sázky, a stejně snadno může snížit požadavek, který by přivedl mnohem větší účet, pořád v pipeline.

Jakou roli hrají hlasy doopravdy?

Levný, průběžný signál pro požadavky, které už existují, a špatný způsob, jak zjistit, jaké požadavky by vůbec měly existovat. Počet hlasů dosáhne jen na uživatele, kteří požadavek už našli a považovali ho za hodný kliknutí, což znamená, že celkový počet hlasů veřejné roadmapy odráží viditelnost stejně jako poptávku: starý požadavek blízko vrcholu seznamu dál sbírá hlasy částečně proto, že je snadné ho najít, a novější, stejně skutečný požadavek začíná od nuly. Článek o veřejné roadmapě doporučuje hlasy na roadmapě vůbec nezobrazovat. Zacházej s hlasy jako se signálem, který potřebuje seskupit a vážit podle aktuálnosti, ne jako s žebříčkem stavěným postupně. Tickety podpory vs. požadavky na funkce pokrývá další slepé místo v počtu hlasů: skutečná mezera může generovat skoro žádné hlasy, pokud uživatelky, které na ni narazí, nikdy nenajdou nástěnku, zatímco se hlasitě objevuje v podpoře.

Kdy vyhrává nejhlasitější zákazník, a je to problém?

Někdy, a je to problém jen když si toho nikdo nevšimne. Zákazník, který často eskaluje, píše podrobné tikety nebo má přímou linku na někoho v týmu, uvidí své požadavky prozkoumané rychleji než tišší zákazník se stejně platným požadavkem, a proces prioritizace, který to nikdy nekontroluje, bude systematicky zvýhodňovat toho, kdo nejvíc trvá na svém, ne toho, kdo má nejsilnější případ. Hlasití zákazníci nejsou problém, který je třeba opravit; jejich požadavky jsou často doopravdy důležité. Oprava je zvyk: pravidelně projet backlog podle zdroje a zkontrolovat, jestli stejná hrstka účtů vysvětluje většinu nedávno vydaného, a zeptat se, jestli to odpovídá tomu, kde skutečná poptávka doopravdy je.

Jak se rozhodnutí o prioritizaci stane odpovědí?

Každé rozhodnutí tady vytvoří vítěze a poražené, a oba si zaslouží odpověď, která pojmenuje skutečné zdůvodnění, ne jen změnu stavu bez vysvětlení. Jak odmítnout požadavek na funkci pokrývá, co říct prohrávajícímu požadavku, způsobem, který udrží vztah nedotčený místo aby to znělo jako generické odmítnutí. Práce se seskupováním a štítkováním, která tohle všechno umožňuje, je pokrytá ve sledování požadavků na funkce; prioritizace funguje jen na požadavcích už zaznamenaných a seskupených dost dobře na to, aby se daly srovnávat.

FAQ

Jaký je nejlepší rámec pro prioritizaci požadavků na funkce? Žádný sám o sobě. Používej hrubé počty na nalezení nejhlasitějšího signálu, RICE na srovnání krátkého seznamu vážných kandidátů, a kontrolu příjmu nebo účtu na zachycení případů, kdy tichá poptávka od strategického účtu váží víc než hlasitější, ale méně důležitá skupina.

Měly by se požadavky na funkce prioritizovat stejně jako nápady roadmapy? Ne. Nápady roadmapy začínají u strategie; požadavky na funkce začínají u poptávky, která už existuje. Hodnotit je společně způsobí, že dobře podložená strategická sázka s malou existující poptávkou soustavně prohrává s požadavkem, který má prostě víc lidí, co o něj žádali.

Odrážejí hlasy na veřejné roadmapě poptávku přesně? Jen mezi lidmi, kteří požadavek už našli. Starší, viditelnější požadavky sbírají hlasy rychleji, bez ohledu na to, kolik skutečné poptávky stojí za novějším, takže zacházej s celkovým počtem hlasů jako se signálem, seskupeným a váženým podle aktuálnosti, ne jako s žebříčkem stavěným postupně.

Jak často by se měly priority požadavků na funkce přehodnocovat? Podle pevného cyklu, ne jen když někdo eskaluje. Měsíční nebo čtvrtletní průchod, který požadavky znovu seskupí a přehodnotí váhy, zachytí odchylku, jako hrstku účtů dominující tomu, co se vydává, kterou čistě reaktivní proces nikdy sám neodhalí.

Technická tvrzení v tomto článku nikdo nezávisle neověřil. Pokud tu něco nesedí, dej nám vědět a opravíme to.

Související na changeloop: Dokumentace pro vývojáře, Srovnání nástrojů pro changelog