Když je požadavek na funkci ve skutečnosti hlášení chyby

“Můžete přidat nastavení, které zvýší limit exportu?” se čte jako požadavek na funkci, a většina triážních systémů ho tak hned označí. Někdy tomu tak je. Někdy export selže na čísle pod dokumentovaným limitem kvůli chybě, a zákaznice, která nevidí kód, si vymyslela nejpravděpodobnější řešení, jaké dokáže popsat: dejte mi větší číslo, možná to bude fungovat. Které štítky stojí za to pokrývá štítek typu, který dělí backlog na požadavky na funkce a chyby; tohle je případ, kdy vlastní slova zákaznice míří štítek špatným směrem, a cena omylu je pomalý drift k backlogu plnému požadavků, které nikdo doopravdy nechce, jakmile se pod ně podíváte.

Jak vypadá požadavek na funkci, který je ve skutečnosti chyba?

Pojmenovává obchvat místo problému. Skutečný požadavek na funkci obvykle popisuje výsledek, který produkt vůbec nepodporuje: “nechte mě tohle naplánovat na později”, “přidejte tmavý režim”. Špatně klasifikovaná chyba popisuje konkrétní číslo, práh nebo chování, které zní jako chybějící nastavení, ale ve skutečnosti je to příznak: “zvyšte timeout”, “přidejte možnost opakování”, “nechte mě exportovat víc řádků najednou”. Znamením je, že žadatelka navrhuje implementaci, nastavení, přepínač, přepsání, místo aby popsala cíl, protože už funkci vyzkoušela tak, jak je dokumentovaná, a ta neudělala to, co dokumentace říká, že by měla.

Proč na tom záleží víc, než to zní?

Protože dvě fronty mají různé vlastnice, časové plány a kritéria úspěchu, a chyba zapsaná jako požadavek na funkci je prioritizovaná proti požadavkům na funkce, soutěží o pozornost se skutečnými mezerami produktu místo toho, aby byla opravena v časovém plánu, jaký si chyba zaslouží. Jak sledovat požadavky na funkce pokrývá, proč míchání chyb a funkcí v jedné frontě nechává nejhlasitější stížnosti předbíhat skutečné požadavky; požadavek na funkci, který je tajně chyba, dělá opačnou škodu, zůstává v backlogu produktu a sbírá hlasy pro “funkci”, která by zmizela, jakmile by se opravila základní chyba, což plýtvá signálem priorizace pro každého, kdo ten backlog čte.

Jak rozeznat, když vlastní slova zákaznice míří špatným směrem?

Zeptejte se, co očekávala, že se stane, ne co chce, abyste přidali. “Export se zasekl na 500 řádcích a potřebuju 2000, můžete zvýšit limit” zní jako požadavek na funkci zvýšení limitu, dokud navazující otázka, “je 500 dokumentovaný limit,” neodhalí, že dokumentované číslo bylo 5000 a export selhává předčasně. Právě tahle jedna otázka, co očekávala oproti tomu, co se stalo, udělá většinu třídicí práce, protože skutečný požadavek na funkci nemá dokumentované chování, kterému by nedostál; není co očekávat, protože schopnost ještě neexistuje.

Měly by to rozhodovat agentky podpory, nebo inženýrky?

Agentky podpory dělají první průchod, protože vidí tiket první, ale štítek by měl být snadné změnit a levné zmýlit, ne jednorázové rozhodnutí, které navždy uzamkne položku do špatné fronty. Lehká druhá kontrola, inženýrka, která týdně prochází nové štítky “požadavek na funkci” a hledá cokoli, co páchne přestrojenou chybou, zachytí ty, které agentka podpory bez kontextu kódu nemohla rozpoznat. Nemusí to být formální; je to spíš pětiminutový pohled než revizní proces.

Mění se uzavření smyčky, jakmile je nalezena skutečná chyba?

Ano, a zlepšuje to zprávu, kterou můžete poslat. Uzavření smyčky zpětné vazby od zákazníka pokrývá informování žadatelky, když se její přání vydá; překlasifikovaná chyba dostane lepší verzi téhle zprávy, protože “našli jsme a opravili chybu za tímhle” zní jako kompetence, zatímco “postavili jsme funkci, o kterou jste žádala”, by bylo pravda jen náhodou, protože skutečný požadavek na funkci, opravdu vyšší limit exportu, možná nikdy nebude postaven, jakmile chyba zmizí a původní limit 5000 řádků stačí.

Co se stane, když je špatná klasifikace nikdy nezachycena?

Backlog se plní požadavky, které vypadají jako skutečná poptávka a nejsou, a rozhodnutí o prioritizaci proti tomu backlogu dědí zkreslení. “Funkce” se čtyřiceti hlasy může ve skutečnosti být čtyřicet lidí narážejících na stejnou chybu, a postavení doslovného požadavku, nastavení pro zvýšení limitu, který nikdy nebyl skutečným omezením, dodá složitost, která nic neopraví, zatímco základní chyba dál generuje nové “požadavky na funkce” od zákaznic, které tohle vlákno ještě nenašly.

FAQ

Vyplatí se přidat formální krok pro kontrolu každého požadavku na funkci proti známým chybám? Ne formální krok, spíš zvyk: kdokoli triážuje nový požadavek na funkci by se měl zeptat “tvrdí dokumentované chování už, že tohle dělá,” než štítek uplatní, protože právě tahle otázka zachytí většinu špatných klasifikací bez přidání procesní zátěže.

Co když zákaznice trvá na tom, že je to požadavek na funkci i po nalezení chyby? Vysvětlete, co jste našli a proč nastavení, které navrhovala, už nebude potřeba, jakmile se chyba opraví. Většina zákaznic žádá obchvat, protože předpokládaly, že skutečná oprava není dostupná, ne protože chtěly konkrétně to nastavení.

Ztrácí překlasifikovaná položka hlasy nebo komentáře, které nasbírala jako požadavek na funkci? Měla by si je zachovat, viditelné, protože ty hlasy jsou důkaz, který vedl k nalezení chyby v první řadě, a skrývání téhle stopy ztěžuje zachycení stejné špatné klasifikace příště, na jiném tiketu.

Může se to stát i obráceně, hlášení chyby, které je ve skutečnosti požadavek na funkci? Méně často, ale ano: “tohle je rozbité” někdy znamená “tohle nedělá to, co jsem předpokládala, že bude dělat,” což je chybějící schopnost, ne defekt. Stejná otázka, co očekávala oproti tomu, co je dokumentováno, třídí i tímhle směrem.

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