Jak sledovat požadavky na funkce, aniž byste je ztratili

Sledování požadavků na funkce téměř vždy selhává jedním ze dvou způsobů. Buď požadavky nemají kam jít, takže žijí v poštovních schránkách a Slack vláknech, kde se zapomínají jeden po druhém, nebo mají místo, kam jít, ale nikdo se tam už nevrací, takže se zapomenou všechny naráz. Fungující systém musí obstát proti oběma selháním: potřebuje jedno místo, kam každý požadavek dopadne, a důvod to místo příští měsíc znovu otevřít.

Odkud požadavky na funkce vlastně přicházejí?

Z víc kanálů, než většina sledovacích systémů počítá. Ticket podpory obsahující “bylo by fajn, kdyby”. Komentář na veřejné roadmapě. Obchodní hovor, kde potenciální klientka pojmenuje tu jednu věc, která blokuje uzavření obchodu. Widget v produktu. Každý kanál má vlastní vlastnici a vlastní nástroje, a právě proto se požadavky rozptylují: fronta ticketů podpory a backlog produktového týmu jsou zřídka stejný systém, a požadavek, který dosáhne jen jednoho z nich, v praxi dosáhl jen jednoho oddělení.

Jeden příjmový formulář pro každý kanál nefunguje, protože ho nikdo nepřijme. Funguje jeden cíl, do kterého se každý kanál vlévá, i kdyby směrování zpočátku znamenalo, že člověk dělá pět minut kopírování a vkládání denně, dokud se neautomatizuje.

Co sledování požadavků na funkce skutečně rozbíjí?

Téměř vždy dvě věci. První je chybějící cíl: na požadavky se odpovídá v kanálu, kam přišly, a nikde se trvale nezaznamenávají, takže stejný požadavek od tří různých zákaznic vypadá jako tři izolované, nesouvisející odpovědi místo jednoho signálu. Druhá, častější, je cíl, který se zaplní a přestane se číst. Tabulka se 400 řádky bez filtrování už není sledovací systém; je to archiv, který náhodou jde upravovat.

Druhé selhání je nebezpečnější, protože vypadá, že sledování funguje. Požadavky se zaznamenávají. Nic se nezdá rozbité, dokud se někdo nezeptá “kolik lidí žádalo o X” a poctivá odpověď zní “museli bychom přečíst všech 400 řádků, abychom to věděli”.

Co by měl požadavek na funkci vlastně zaznamenávat?

Dost na to, aby později odpovídal na tři otázky bez opětovného čtení původní zprávy: co bylo požadováno, pokud možno vlastními slovy té, kdo žádala; kdo žádal, a jak ji kontaktovat, pokud odpověď nakonec zní “postavili jsme to”; a co by bylo potřeba vědět, aby se poznalo, jde-li o běžný požadavek, nebo ojedinělý případ. Doslovná citace má vyšší hodnotu než parafráze, protože parafráze napsaná tou, kdo požadavek třídila, už nese její vlastní čtení, a právě to čtení druhá osoba o šest měsíců později nemůže ověřit.

Které štítky stojí za to?

Dva, a odpovídají na různé otázky. Štítek typu odděluje požadavek na funkci od hlášení chyby, protože oba potřebují jinou vlastnici a jiný časový plán, a míchání obou v jedné frontě nechává nejhlasitější stížnosti předbíhat požadavky. Štítek priority, udržovaný na malé sadě jako low, medium a high, odděluje “blokuje někomu použití produktu” od “bylo by to fajn”, protože oba si zaslouží velmi odlišnou dobu odezvy a žádný by neměl přebírat tempo toho druhého. Správné nastavení štítku typu předpokládá, že požadavek je to, za co se vydává; když je požadavek na funkci ve skutečnosti hlášení chyby pokrývá případ, kdy vlastní slova zákaznice míří ten štítek špatným směrem.

Automatizovaná triáž může obě aplikovat v okamžiku, kdy požadavek dorazí. V changeloop dostane odeslání přes widget ve stejném kroku štítek feature-request nebo bug a štítek priority:low|medium|high, plus tag from-widget, aby byl zdroj vidět bez otevírání položky. To stačí na filtrování backlogu za minutu místo odpoledne: ukaž mi každý vysoce prioritní požadavek na funkci, který tento měsíc přišel z widgetu.

Třetí štítek stojí za to, jakmile existuje veřejná roadmapa: stav, který si žadatelka může zkontrolovat sama. Veřejná roadmapa pokrývá stavy planned, building a shipped celé; krátce, tenhle štítek mění soukromou frontu v něco, co si žadatelka může projít, aniž by se znovu ptala.

Jak se rozhodne, co se staví dál?

Nejdřív seskupit, pak počítat. Deset různě formulovaných požadavků na stejnou základní schopnost se čte jako deset rozptýlených řádků v tabulce, a jako silný signál, jakmile jsou seskupené, a tohle seskupení je obvykle chybějící krok, ne počítání. Syrový počet bez seskupení má tendenci odměňovat funkci s nejchytlavějším jménem, ne tu s největší skutečnou poptávkou za sebou.

Važ podle toho, kdo žádá, ne jen podle toho, kolik jich žádá. Požadavek od účtu blízko obnovení nese jinou naléhavost než stejný požadavek od zkušební registrace, a sledovací systém, který tenhle kontext zahodí ve prospěch holého počtu, optimalizuje na číslo nejsnazší spočítat, ne to nejužitečnější.

Každé rozhodnutí tady taky vytvoří požadavky, které prohrají, a ty si taky zaslouží odpověď; jak odmítnout požadavek na funkci pokrývá, co říct těm, jejichž požadavek to nezvládl. Seskupování a vážení je jen polovina “co stavět dál”; prioritizace požadavků na funkce pokrývá skutečné rámce, RICE, vážení příjmem a hrubé počty, a kde každý z nich selhává.

Jak se uzavře smyčka, jakmile se něco vydá?

Tohle je krok, který sledovací systémy nejčastěji přeskočí, a ten, kterého si žadatelky opravdu všimnou. Uzavření smyčky zpětné vazby se zákazníkem pokrývá mechaniku celou; co sem patří, je to, že uzavření smyčky funguje jen tehdy, když původní požadavek zůstal propojený s tou, kdo ho podala. Šablona požadavku na funkci postavená z GitHub issue, s identitou žadatelky připojenou k issue místo pohřbené v komentáři, je to, co umožňuje automatické oznámení “vydáno” místo takového, na které si někdo musí vzpomenout. Šablona požadavku na funkci ukazuje konkrétní šablonu a k čemu slouží každé pole.

FAQ

Jaký nástroj použít na sledování požadavků na funkce? To, co tým už denně kontroluje, poráží jakýkoli specializovaný nástroj, který nikdo neotvírá. Tracker issues na GitHubu funguje dobře, pokud tam už žije engineering; lehká nástěnka funguje dobře, pokud tam žije produkt. Na nástroji záleží méně než na tom, jestli se znovu otevírá.

Jak zabránit duplicitám požadavků na funkce? Seskupovat podle základní schopnosti dřív, než se třídí podle formulace. Hledání mezi existujícími požadavky před vytvořením nového zachytí většinu duplicit; měsíční seskupovací průchod zachytí zbytek. Slučování duplicit bez ztráty původního hlasu pokrývá, co udělat s formulací, jakmile je samotné seskupení hotové, aby sloučení tiše nezúžilo požadavek na to, o co žádalo podání, které přišlo první.

Měl by každý požadavek na funkci dostat odpověď? Každý by měl dostat potvrzení, i krátké, ale ne každý potřebuje rozhodnutí hned. Viditelný stav, jako štítek roadmapy, který si žadatelka může zkontrolovat sama, nahrazuje většinu individuálních odpovědí, které by tým jinak dlužil.

Jaký je rozdíl mezi sledováním požadavků a veřejnou roadmapou? Sledování je interní záznam každého požadavku, včetně těch, které se nikdy nevydají. Veřejná roadmapa je podmnožina, ke které se tým veřejně zavazuje, se stavem, který žadatelka vidí, aniž by se znovu ptala.

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