Dubbele featureverzoeken: zonder de stem te verliezen
5 min lezen
Drie klanten vragen in drie verschillende weken om dezelfde mogelijkheid, op drie verschillende manieren geformuleerd, en een triageproces gebouwd om duplicaten te vangen doet zijn werk: het groepeert ze, telt ze als één verzoek met drie stemmen, en de backlog blijft schoon. Dat is het makkelijke deel. Welke labels zijn de moeite waard behandelt groeperen op onderliggende capaciteit voordat je op formulering trieert als de mechanische fix voor duplicaten; wat het niet behandelt is wat er met de woorden zelf gebeurt zodra drie verzoeken één regel worden, en dat verlies is meestal groter dan het probleem van dubbeltellen dat het oploste.
Wat gaat er echt verloren als duplicaten worden samengevoegd?
De specifieke formulering die elke aanvrager gebruikte, die vaak informatiever is dan het stemaantal waarin het instort. De ene klant vraagt misschien om “een manier om gefilterde resultaten te exporteren”, een andere om “CSV-export die mijn opgeslagen filters respecteert”, en een derde om “export zonder verborgen kolommen”. Alle drie zijn hetzelfde onderliggende verzoek, correct gegroepeerd, maar elke formulering draagt een net iets andere nadruk op wat voor die persoon belangrijk is, en een samenvoeging die alleen de formulering van de eerste indiening behoudt, gooit de andere twee helemaal weg. De telling overleeft; de textuur die iemand zou helpen de juiste versie van de feature te bouwen, niet.
Waarom maakt de textuur uit als het stemaantal al zegt dat er vraag bestaat?
Omdat vraag en ontwerp verschillende vragen zijn, en alleen de specifieke formulering beantwoordt de tweede. Tien stemmen op “export” vertelt een team dat de feature het waard is om te bouwen; het zegt niets over of “export” CSV, PDF, een geplande e-mail of een API-endpoint betekent, en een samenvoeging die negen van de tien originele indieningen laat vallen ten gunste van de formulering van de eerste kan de specificatie stilletjes versmallen tot wat die eerste aanvrager toevallig vroeg, zelfs als de andere negen iets subtiel anders wilden. Wat een featureverzoek eigenlijk moet vastleggen behandelt precies dit gat vanaf de intake-kant; duplicaten samenvoegen is waar het weer opduikt na de intake, precies op het punt waar een team het bereik van wat er echt gevraagd is het hardst nodig heeft.
Hoe ziet een samenvoegproces eruit dat de formulering bewaart in plaats van te weggooien?
Toevoegen in plaats van vervangen. Het canonieke item houdt één titel aan voor de backlogweergave, maar de originele formulering van elke samengevoegde indiening blijft eraan hangen, ofwel als een lijst citaten of als gelinkte bron-tickets, zodat iedereen die het item later beoordeelt het werkelijke bereik kan zien van wat mensen vroegen in plaats van de samenvatting van één teamlid ervan. Dit kost bijna niets om te bouwen, een veld op het ticket in plaats van een nieuw systeem, en het is het verschil tussen een samenvoeging die informatie comprimeert en een die alleen de weergave ervan comprimeert.
Feature: Gefilterde CSV-export
Stemmen: 12
Samengevoegde verzoeken:
- "een manier om gefilterde resultaten te exporteren" (acct_4421)
- "CSV-export die mijn opgeslagen filters respecteert" (acct_8832)
- "export zonder verborgen kolommen" (acct_1097)
...Verdient elk duplicaat het om te worden samengevoegd, of zijn er valse matches?
Sommige zijn valse matches, en “klinkt vergelijkbaar” behandelen als “is hetzelfde verzoek” is zijn eigen faalmodus. “Laat me mijn data exporteren” en “laat me alleen de gefilterde weergave exporteren” kunnen gegroepeerd worden door een trefwoordmatch op “exporteren” terwijl ze eigenlijk twee verschillende scopes van dezelfde algemene capaciteit beschrijven; ze samenvoegen blaast ofwel het stemaantal op voor het verkeerde ding of, erger, levert de smallere versie omdat die toevallig eerst aankwam. Een menselijke doorloop van de groepering, zelfs een snelle, vangt dit voordat het zich opstapelt; een automatische gelijkenismatch alleen zal te veel samenvoegen op vocabulaire en te weinig op intentie.
Wanneer moet dubbelecontrole eigenlijk plaatsvinden: bij intake of later?
Allebei, om verschillende redenen. Controle bij intake vangt het voor de hand liggende geval, een nieuw verzoek dat iets herhaalt dat al openstaat, voordat het ooit een eigen ongetrackt item wordt; een gelijkeniszoekopdracht tegen openstaande verzoeken op het moment van indienen handelt de meeste hiervan af zonder dat er een mens bij betrokken is. Een tweede ronde later, op een langzamer ritme, vangt het geval dat intake mist: twee verzoeken die op dat moment net verschillend genoeg geformuleerd waren om langs een trefwoord- of embeddingmatch te glippen, maar die, zodra een team een tiental varianten heeft gezien, blijken dezelfde onderliggende mogelijkheid te beschrijven. De tweede ronde overslaan laat bijna-duplicaten voor onbepaalde tijd verspreid staan onder aparte titels, elk met zijn eigen kleine stemmenaantal dat nooit optelt tot het aantal dat het gebouwd zou hebben gekregen.
Zou de aanvrager moeten weten dat zijn indiening is samengevoegd in een bestaand item?
Ja, en dit is dezelfde discipline als de klantfeedbacklus sluiten toegepast één stap eerder dan gebruikelijk: een aanvrager die iets indiende en nooit meer iets hoort, concludeert dat zijn verzoek nergens toe leidde, zelfs als het correct werd samengevoegd in een item met elf andere stemmen dat uiteindelijk werd uitgerold. Een korte bevestiging, “we hebben dit gecombineerd met een bestaand verzoek dat anderen ook hebben gedaan”, kost één bericht en voorkomt dat een klant hetzelfde verzoek elke paar maanden opnieuw indient omdat hij geen zicht heeft op of het ooit echt werd bijgehouden.
Verandert samenvoegen wie krediet krijgt als de feature wordt uitgerold?
Het zou iedereen moeten omvatten, niet alleen wie het eerst indiende. De feedbacklus
sluiten behandelt aanvragers laten weten wanneer hun wens wordt
uitgerold; voor een samengevoegd item betekent dat elk account dat aan de samenvoeging hangt, niet
alleen degene wiens formulering de canonieke titel werd, want vanuit het perspectief van elke
aanvrager vroeg zij hierom en het werd uitgerold, ongeacht wiens formulering een triageproces
toevallig bewaarde. Met Changeloop betekent dat dat de pull request elke gekoppelde issue noemt
(Fixes #142, fixes #187); een issue die hij niet noemt, krijgt geen reactie.
FAQ
Hoeveel formulering is het waard om te bewaren per samengevoegd verzoek, een citaat of een volledige ticketlink? Een kort citaat is meestal genoeg voor het gangbare geval, omdat het doel ervan is een reviewer het bereik van formuleringen in één oogopslag te laten zien; bewaar ook de volledige ticketlink wanneer het origineel significante extra context had, zoals een screenshot of een gedetailleerde workflowbeschrijving die een citaat van één regel zou platslaan.
Maakt het bewaren van de formulering van elk duplicaat de backlog moeilijker te scannen? Niet als het standaard is ingeklapt. De canonieke titel is wat een snelle reviewer ziet; de samengevoegde formulering is één klik of één uitklap verwijderd, aanwezig voor wie dieper onderzoek doet maar zonder de weergave te overladen voor iemand die alleen stemmen telt.
Wat als twee verzoeken identiek lijken maar eenmaal gebouwd verschillende dingen blijken te willen? Splits ze weer op zodra dat duidelijk wordt, en behandel de originele samenvoeging als een redelijke beslissing genomen met de destijds beschikbare informatie, niet als een fout die herhaling moet vermijden. Een groeperingssysteem dat nooit iets ontkoppelt, zal uiteindelijk een paar verkeerde samenvoegingen permanent ingebakken hebben.
Is er een stemdrempel waarboven een samengevoegd verzoek een menselijke review van de onderliggende formulering zou moeten krijgen? Geen vast getal, maar elk verzoek dat een bouwbeslissing nadert verdient dit ongeacht het stemaantal, omdat dat het punt is waarop het verschil tussen “export” en “export als CSV met opgeslagen filters” ophoudt een nuance te zijn en de specificatie wordt.
De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.