Wanneer een featureverzoek eigenlijk een bugreport is
5 min lezen
“Kunnen jullie een instelling toevoegen om de exportlimiet te verhogen?” leest als een featureverzoek, en de meeste triagesystemen labelen het meteen zo. Soms is het dat ook. Soms faalt de export bij een getal onder de gedocumenteerde limiet door een bug, en de klant, die de code niet kan zien, heeft de meest plausibele oplossing verzonnen die ze kan beschrijven: geef me een groter getal en misschien werkt het dan. Welke labels zijn de moeite waard behandelt het type-label dat een backlog verdeelt in featureverzoeken en bugs; dit is het geval waarin de eigen woorden van een klant het label de verkeerde kant op sturen, en de kosten van het fout krijgen zijn een langzame drift naar een backlog vol wensen die niemand echt wil zodra je eronder kijkt.
Hoe ziet een featureverzoek eruit dat eigenlijk een bug is?
Het noemt een workaround in plaats van het probleem. Een echt featureverzoek beschrijft meestal een resultaat dat het product helemaal niet ondersteunt: “laat me dit voor later plannen”, “voeg een donkere modus toe”. Een verkeerd geclassificeerde bug beschrijft een specifiek getal, drempel of gedrag dat klinkt als een ontbrekende instelling maar eigenlijk een symptoom is: “verhoog de timeout”, “voeg een retry-optie toe”, “laat me meer rijen tegelijk exporteren”. Het kenmerk is dat de aanvrager een implementatie voorstelt, een instelling, een schakelaar, een override, in plaats van een doel te beschrijven, omdat ze de feature al heeft geprobeerd zoals gedocumenteerd en het deed niet wat de documentatie zegt dat het zou moeten doen.
| Signaal | Featureverzoek | Bug vermomd als featureverzoek |
|---|---|---|
| Wat de aanvrager beschrijft | Een resultaat dat het product niet kan | Een parameter die ze wil veranderen |
| Of gedocumenteerd gedrag dit al dekt | Nee, echt ontbrekend | Ja, maar werkt niet zoals gedocumenteerd |
| Of meer inspanning het verzoek doet verdwijnen | Nee | Soms, als de bug drempelafhankelijk is |
| Waar het naartoe zou moeten | Productbacklog | Bugrij |
Waarom is dit belangrijker dan het klinkt?
Omdat de twee rijen verschillende eigenaren, tijdlijnen en succescriteria hebben, en een bug die als featureverzoek is ingediend wordt geprioriteerd tegen featureverzoeken, wat om aandacht concurreert met echte producthiaten in plaats van opgelost te worden op de tijdlijn die een bug verdient. Featureverzoeken bijhouden behandelt waarom het mengen van bugs en features in één rij de luidste klachten voor de echte verzoeken laat dringen; een featureverzoek dat stiekem een bug is, richt de omgekeerde schade aan, blijft in de productbacklog stemmen verzamelen voor een “feature” die zou verdwijnen zodra de onderliggende bug is opgelost, wat het prioriteringssignaal verspilt voor iedereen die die backlog leest.
Hoe onderscheid je het als de eigen woorden van de klant de verkeerde kant op wijzen?
Vraag wat ze verwachtte dat er zou gebeuren, niet wat ze wil dat je toevoegt. “De export liep vast op 500 rijen en ik heb er 2.000 nodig, kunnen jullie de limiet verhogen” klinkt als een featureverzoek voor limietverhoging totdat de vervolgvraag, “is 500 de gedocumenteerde limiet”, onthult dat het gedocumenteerde getal 5.000 was en de export vroegtijdig faalt. Die ene vraag, wat ze verwachtte tegenover wat er gebeurde, doet het meeste sorteerwerk, omdat een echt featureverzoek geen gedocumenteerd gedrag heeft waar het bij achterblijft; er is niets te verwachten omdat de mogelijkheid nog niet bestaat.
Moeten supportmedewerkers of engineers dit beslissen?
Supportmedewerkers doen de eerste ronde, omdat zij het ticket het eerst zien, maar het label zou makkelijk te veranderen en goedkoop om fout te doen moeten zijn, geen eenmalige beslissing die het item voor altijd in de verkeerde rij vastzet. Een lichte tweede controle, een engineer die wekelijks nieuwe “featureverzoek”-labels doorneemt op alles dat naar een verborgen bug ruikt, vangt de gevallen die een supportmedewerker zonder codebase-context niet had kunnen herkennen. Dit hoeft niet formeel te zijn; het is meer een blik van vijf minuten dan een reviewproces.
Verandert het sluiten van de lus zodra de echte bug is gevonden?
Ja, en het verbetert het bericht dat je kunt sturen. De klantfeedbacklus sluiten behandelt het informeren van een aanvrager wanneer hun wens uitkomt; een geherclassificeerde bug krijgt een betere versie van dat bericht, omdat “we hebben de bug erachter gevonden en opgelost” klinkt als competentie, terwijl “we hebben de feature gebouwd waar je om vroeg” alleen bij toeval waar zou zijn geweest, omdat het echte featureverzoek, een daadwerkelijk hogere exportlimiet, misschien nooit gebouwd wordt zodra de bug weg is en de oorspronkelijke limiet van 5.000 rijen genoeg is.
Wat gebeurt er als de verkeerde classificatie nooit wordt opgemerkt?
De backlog vult zich met wensen die op echte vraag lijken en dat niet zijn, en prioriteringsbeslissingen die tegen die backlog worden genomen erven de vertekening. Een “feature” met veertig stemmen kan in werkelijkheid veertig mensen zijn die dezelfde bug tegenkomen, en het letterlijke verzoek bouwen, een instelling om een limiet te verhogen die nooit echt de beperking was, levert complexiteit die niets oplost, terwijl de onderliggende bug doorgaat met nieuwe “featureverzoeken” genereren van klanten die dit topic nog niet hebben gevonden.
FAQ
Is het de moeite waard om een formele stap toe te voegen om elk featureverzoek tegen bekende bugs te checken? Geen formele stap, meer een gewoonte: wie een nieuw featureverzoek triageert zou moeten vragen “beweert het gedocumenteerde gedrag al dit te doen” voordat het label wordt toegepast, omdat die ene vraag de meeste verkeerde classificaties vangt zonder procesoverhead toe te voegen.
Wat als de klant blijft volhouden dat het een featureverzoek is, ook nadat de bug is gevonden? Leg uit wat je hebt gevonden en waarom de instelling die ze voorstelde niet meer nodig zou zijn zodra de bug is opgelost. De meeste klanten vragen om een workaround omdat ze aannamen dat de echte oplossing niet beschikbaar was, niet omdat ze specifiek die instelling wilden.
Verliest een geherclassificeerd item de stemmen of reacties die het als featureverzoek verzamelde? Het zou ze zichtbaar moeten behouden, omdat die stemmen het bewijs zijn dat tot het vinden van de bug heeft geleid, en dat spoor verbergen maakt dezelfde verkeerde classificatie de volgende keer, op een ander ticket, moeilijker te herkennen.
Kan dit ook andersom gebeuren, een bugreport dat eigenlijk een featureverzoek is? Minder vaak, maar ja: “dit is kapot” betekent soms “dit doet niet wat ik aannam dat het zou doen”, wat een ontbrekende mogelijkheid is, geen defect. Dezelfde vraag, wat ze verwachtte tegenover wat gedocumenteerd is, sorteert ook in deze richting.
De technische beweringen in dit artikel zijn niet onafhankelijk gecontroleerd. Klopt er iets niet, laat het ons weten, dan corrigeren we het.