Tickety Podpory vs. Požadavky Na Funkce: Čemu Věřit?

Nástěnka požadavků na funkce zachycuje to, co uživatelky žádají, když mají čas se posadit a popsat, co chtějí. Ticket podpory zachycuje, na čem uživatelky vězí právě teď, často podrážděné, často bez slovní zásoby popsat úhledně podkladový požadavek. Oba jsou skutečný signál, a týmy, které se dívají jen na jeden ze dvou, nakonec sebejistě řeší špatný problém, protože každý kanál systematicky nadměrně zastupuje jiný typ uživatelky a jiný typ potřeby. Prioritizace požadavků na funkce pokrývá řazení toho, co už je na nástěnce; tohle je o mezeře mezi tím, co se na nástěnku vůbec dostane, a tím, co se objevuje jen jako ticket podpory.

Proč by se stejný podkladový problém objevil v jednom kanálu a ne v druhém?

Protože oba kanály mají odlišné náklady na aktivaci, a velikost těch nákladů určuje, kdo je překoná. Podání požadavku na funkci vyžaduje iniciativu: uživatelka musí věřit, že požadavek stojí za formulaci, najít nástěnku, a napsat něco souvislého, což vybírá zapojené, trpělivé uživatelky už investované do produktu. Podání ticketu podpory vyžaduje ve srovnání skoro žádnou iniciativu, často jen kliknutí na „pomoc” uprostřed úkolu, což znamená, že zachycuje frustrované uživatelky v danou chvíli, včetně těch, které by se s nástěnkou požadavků vůbec neobtěžovaly. Skutečná mezera v produktu může být na nástěnce funkcí neviditelná a v podpoře hlasitá jednoduše proto, že uživatelky, které na ni narazí, jsou ty nejméně ochotné podat formální požadavek.

Znamená objem ticketů pro chybějící funkci totéž co počet hlasů pro ni?

Ne, protože měří odlišné populace za odlišných podmínek. Požadavek na funkci se sto hlasy reprezentuje sto lidí, kteří si udělali čas najít a podpořit existující požadavek, což je silný signál trvalé, promyšlené poptávky. Sto ticketů podpory o stejné podkladové mezeře, podaných ve stejném období, pravděpodobně reprezentuje uživatelky, které v danou chvíli narážejí na zeď, z nichž některé by na to úplně zapomněly, jakmile bezprostřední tření pomine. Zacházení s oběma jako s ekvivalentním signálem „sto lidí tohle chce” nadhodnocuje objem ticketů, protože tickety je levné generovat a hlasy ne.

Co znamená, když má funkce tickety podpory, ale skoro žádné hlasy na nástěnce?

Často, že požadavek existuje, ale uživatelky, které na něj narazí, nevědí, že nástěnka existuje, nevěří, že by hlasování něco změnilo, nebo na problém narážejí příliš zřídka, aby se obtěžovaly změnit kanál kvůli formální registraci. Tohle je přesně populace, kterou nástěnka požadavků strukturálně míjí, a nízký počet hlasů tady je důkaz mezery v měření, ne nízké poptávky. Zacházejte s klastrem ticketů podpory kolem chybějící funkce jako s vlastním signálem, který stojí za to sami zaregistrovat na nástěnku jménem uživatelek, místo abyste ticketům nedůvěřovali, aby nezůstal neviditelný pro toho, kdo prioritizuje jen podle počtu hlasů.

Nástěnka čte se jako nízká priorita:
"Export to CSV": 4 hlasy za 6 měsíců

Podpora vypráví jiný příběh:
"Export to CSV": 31 ticketů za stejné období, každý z
jiného účtu, každý uzavřený s „aktuálně nepodporováno,
předáme zpětnou vazbu"

Znamená nárůst ticketů podpory vždy, že podkladovým problémem je chybějící funkce?

Ne, a tady mohou oba kanály zmást opačným směrem. Nárůst ticketů je stejně často způsoben matoucím rozhraním kolem už existující funkce, chybou, nebo změnou, která vyšla bez odpovídajícího vysvětlení, z čehož nic z toho se nevyřeší postavením něčeho nového. Čtení každého nárůstu ticketů jako „uživatelky chtějí funkci, kterou nemáme” produkuje roadmapu plnou věcí, které byly ve skutečnosti mezery v dokumentaci nebo zamaskované problémy použitelnosti. Ticket podpory vám řekne, kde je tření; sám o sobě vám neřekne, jestli je řešením nová funkce, změna rozhraní, nebo lepší článek nápovědy, a plést si to plýtvá inženýrským časem na špatné řešení.

Jak by měly být oba signály doopravdy kombinovány při rozhodování, co postavit?

Používejte tickety k nalezení, kde je tření, a používejte nástěnku požadavků, plus přímý kontakt tam, kde je nástěnka řídká, k potvrzení, jak skutečně vypadá požadovaný výsledek. Klastr ticketů identifikuje skutečný, pociťovaný problém; zřídka specifikuje řešení dost přesně, aby se na něm dalo stavět, protože frustrovaná uživatelka v rozhovoru s podporou popisuje symptomy, ne specifikace. Nástěnka požadavků, když má dost hlasů na stejný podkladový problém, obvykle nese víc z detailu „co by tohle doopravdy uspokojilo”, protože napsání požadavku je už akt specifikace toho, co chcete, ne jen hlášení toho, co je špatně.

Měly by agentky podpory samy zaznamenávat tickety jako požadavky na funkce?

Ano, a to je oprava s největší pákou pro mezeru mezi oběma kanály. Agentka, která rozpozná ticket jako zamaskovaný požadavek na funkci, místo aby ho prostě vyřešila a šla dál, ho může zaznamenat na nástěnku jménem zákaznice, což přímo uzavře mezeru v měření místo požadavku, aby zákaznice sama objevila a použila druhý kanál. Tohle funguje jen, pokud zaznamenání trvá agentce sekundy, ne minuty, aby tření z toho bylo nižší než tření z prostého uzavření ticketu a přechodu k dalšímu.

FAQ

Měly by se hlasy požadavků na funkce někdy diskontovat, pokud všechny pocházejí z jednoho účtu nebo týmu? Ano, važte podle odlišných účtů nebo organizací místo hrubého počtu hlasů, protože pět hlasů od pěti lidí ve stejné firmě reprezentuje priority jedné zákaznice, ne pět nezávislých potvrzení poptávky.

Vyplatí se postavit funkci, která se hodně objevuje v ticketech, ale má skoro žádné hlasy? Často ano, pokud objem ticketů doopravdy pochází z odlišných účtů a podkladová potřeba je potvrzená místo předpokládané; zacházejte s nízkým počtem hlasů jako s artefaktem měření nákladů na aktivaci nástěnky, ne jako s důkazem, že poptávka není skutečná.

Jak na první pohled odlišit ticket o zmatku v rozhraní od skutečného ticketu o chybějící funkci? Podívejte se, jestli řešení spočívá ve vysvětlení existující schopnosti, nebo v omluvě za chybějící. Vzorec řešení „aha, ono to tam vlastně je” ukazuje na problém rozhraní nebo objevitelnosti; vzorec „to zatím nepodporujeme” ukazuje na skutečnou mezeru.

Záleží na tomto rozlišení stejně moc při velmi malém objemu podpory? Méně mechanicky, protože hrstku ticketů je snadné číst jednotlivě bez potřeby souhrnné analýzy, ale podkladová zkreslení, tickety nadměrně zastupují frustrované uživatelky a nedostatečně zastupují trpělivé, jsou přítomná na jakémkoli měřítku a stojí za to mít je na paměti i když čtete každý ticket sami.

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