Featureverzoeken bijhouden zonder ze kwijt te raken

Het bijhouden van featureverzoeken faalt bijna altijd op een van twee manieren. Ofwel hebben verzoeken geen plek om heen te gaan, dus leven ze in inboxen en Slack-threads waar ze een voor een vergeten worden, ofwel hebben ze een plek die niemand meer bekijkt, dus worden ze allemaal samen vergeten. Een werkend systeem moet beide storingen overleven: het heeft één plek nodig waar elk verzoek terechtkomt, en een reden om die plek volgende maand weer te openen.

Waar komen featureverzoeken eigenlijk vandaan?

Uit meer kanalen dan de meeste bijhoudsystemen voorzien. Een supportticket met een “zou fijn zijn als”. Een reactie op een publieke roadmap. Een salesgesprek waarin een prospect precies het ene ding noemt dat de deal blokkeert. Een widget in het product. Elk kanaal heeft een eigen eigenaar en eigen tools, en juist daarom verspreiden verzoeken zich: de supportticketrij en de backlog van het productteam zijn zelden hetzelfde systeem, en een verzoek dat maar een van de twee bereikt, heeft in de praktijk maar één afdeling bereikt.

Eén intakeformulier voor elk kanaal werkt niet, omdat niemand het gebruikt. Wat wel werkt is één bestemming waar elk kanaal naartoe leidt, ook al is de routing eerst vijf minuten per dag kopiëren en plakken totdat het geautomatiseerd is.

Wat breekt het bijhouden van featureverzoeken echt?

Bijna altijd twee dingen. Ten eerste een ontbrekende bestemming: verzoeken worden beantwoord in het kanaal waar ze binnenkwamen en nooit ergens duurzaam vastgelegd, waardoor hetzelfde verzoek van drie verschillende klanten eruitziet als drie losstaande, ongerelateerde antwoorden in plaats van één signaal. Ten tweede, vaker, een bestemming die volloopt en niet meer gelezen wordt. Een spreadsheet met 400 rijen zonder filter is geen bijhoudsysteem meer; het is een archief dat toevallig beschrijfbaar is.

De tweede storing is de gevaarlijkste, omdat het lijkt alsof bijhouden werkt. Verzoeken worden geregistreerd. Niets lijkt kapot totdat iemand vraagt “hoeveel mensen hebben om X gevraagd” en het eerlijke antwoord is “we zouden alle 400 rijen moeten lezen om het te weten”.

Wat moet een featureverzoek eigenlijk vastleggen?

Genoeg om later drie vragen te beantwoorden zonder het oorspronkelijke bericht opnieuw te lezen: wat er gevraagd werd, waar mogelijk in de eigen woorden van de aanvrager; wie het vroeg, en hoe diegene te bereiken als het antwoord uiteindelijk “we hebben het gebouwd” is; en wat er nodig is om te weten of dit een gangbaar verzoek is of een eenmalig geval. Een letterlijk citaat telt meer dan een parafrase, omdat een parafrase geschreven door wie het verzoek ook trieerde al zijn eigen interpretatie meedraagt, en dat is precies wat een tweede lezer zes maanden later niet meer kan controleren.

Welke labels zijn de moeite waard?

Twee, en ze beantwoorden verschillende vragen. Een type-label scheidt een featureverzoek van een bugreport, omdat beide een andere eigenaar en tijdlijn nodig hebben, en ze mengen in één rij laat de luidste klachten voor de verzoeken dringen. Een prioriteit-label, beperkt tot een kleine set als low, medium en high, scheidt “blokkeert iemand in het gebruik van het product” van “zou leuk zijn”, omdat beide een heel andere reactietijd verdienen en geen van beide het tempo van de ander zou moeten overnemen. Het type-label goed zetten veronderstelt dat het verzoek is wat het beweert te zijn; wanneer een featureverzoek eigenlijk een bugreport is behandelt het geval waarin de eigen woorden van een klant dat label de verkeerde kant op sturen.

Geautomatiseerde triage kan beide toepassen op het moment dat een verzoek binnenkomt. Bij changeloop krijgt een widget-inzending in dezelfde stap het label feature-request of bug en een priority:low|medium|high-label, plus een from-widget-tag zodat de bron zichtbaar is zonder het item te openen. Dat is genoeg om de backlog in een minuut in plaats van een middag te filteren: laat me elk hoge-prioriteitsverzoek zien dat deze maand via de widget binnenkwam.

Een derde label is de moeite waard zodra er een publieke roadmap is: een status die een aanvrager zelf kan checken. Publieke roadmap behandelt de statussen planned, building en shipped volledig; kort gezegd verandert dat label een privérij in iets dat een aanvrager kan raadplegen zonder opnieuw te vragen.

Hoe beslis je wat je hierna bouwt?

Eerst groeperen, dan tellen. Tien verschillend geformuleerde verzoeken voor dezelfde onderliggende capaciteit lezen als tien verspreide rijen in een spreadsheet, en als een sterk signaal zodra ze gegroepeerd zijn, en die groepering is meestal de ontbrekende stap, niet het tellen. Een ruw aantal zonder groepering beloont meestal de feature met de meest pakkende naam, niet die met de meeste echte vraag erachter.

Weeg naar wie het vraagt, niet alleen naar hoeveel er vragen. Een verzoek van een account dat bijna verlengt draagt een andere urgentie dan hetzelfde verzoek van een trialaccount, en een bijhoudsysteem dat die context weggooit voor een kale telling optimaliseert voor het cijfer dat het makkelijkst te berekenen is, niet het nuttigste.

Elke beslissing hier produceert ook verzoeken die verliezen, en die verdienen ook een reactie; hoe je een featureverzoek afwijst behandelt wat je zegt tegen wie een verzoek deed dat het niet haalde. Groeperen en wegen is maar de helft van “wat bouwen we hierna”; featureverzoeken prioriteren behandelt de echte frameworks, RICE, omzetweging en ruwe tellingen, en waar elk breekt.

Hoe sluit je de cirkel als er iets uitkomt?

Dit is de stap die bijhoudsystemen het vaakst overslaan, en degene die aanvragers echt opmerken. De feedbackloop met de klant sluiten behandelt de mechaniek volledig; wat hier hoort, is dat de cirkel sluiten alleen werkt als het oorspronkelijke verzoek gekoppeld bleef aan de aanvrager. Een featureverzoek-template gebouwd vanuit een GitHub-issue, waarbij de identiteit van de aanvrager aan de issue hangt in plaats van begraven in een reactie, is wat een automatische “uitgebracht”-melding mogelijk maakt in plaats van een die iemand moet onthouden te sturen. Featureverzoek-template toont het concrete template en waar elk veld voor dient.

FAQ

Welke tool moet ik gebruiken om featureverzoeken bij te houden? Wat het team al dagelijks bekijkt, verslaat elke speciale tool die niemand opent. Een GitHub-issuetracker werkt goed als engineering daar al leeft; een lichtgewicht bord werkt goed als product daar leeft. De tool doet er minder toe dan of hij wordt teruggeopend.

Hoe voorkom ik dat featureverzoeken dubbel worden? Groepeer op onderliggende capaciteit voordat je op formulering trieert. Zoeken in bestaande verzoeken voordat je een nieuwe aanmaakt, vangt de meeste duplicaten; een maandelijkse groeperingsronde vangt de rest. Duplicaten samenvoegen zonder de originele stem te verliezen behandelt wat je met de formulering doet zodra het groeperen zelf klaar is, zodat de samenvoeging het verzoek niet stilletjes versmalt tot wat de eerst binnengekomen indiening toevallig vroeg.

Moet elk featureverzoek een reactie krijgen? Elk verzoek moet een bevestiging krijgen, al is die kort, maar niet elk verzoek heeft direct een beslissing nodig. Een zichtbare status, zoals een roadmap-label dat de aanvrager zelf kan checken, vervangt de meeste individuele reacties die een team anders zou moeten geven.

Wat is het verschil tussen het bijhouden van verzoeken en een publieke roadmap? Bijhouden is het interne overzicht van elk verzoek, inclusief degene die nooit uitkomen. Een publieke roadmap is de subset waar een team zich publiekelijk aan committeert, met een status die de aanvrager kan zien zonder opnieuw te vragen.

De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.

Meer op changeloop: Documentatie voor ontwikkelaars, Changelog-tools vergeleken