Wenn ein Feature-Request eigentlich ein Bug-Report ist

„Könnt ihr eine Einstellung hinzufügen, um das Export-Limit zu erhöhen?” liest sich wie ein Feature-Request, und die meisten Triage-Systeme labeln es sofort als einen. Manchmal ist es das. Manchmal schlägt der Export bei einer Zahl unter dem dokumentierten Limit wegen eines Bugs fehl, und der Kunde, der den Code nicht sehen kann, hat sich die plausibelste Lösung ausgedacht, die er beschreiben kann: Gebt mir eine größere Zahl, vielleicht funktioniert es dann. Welche Labels lohnen sich behandelt das Typ-Label, das ein Backlog in Feature-Requests und Bugs aufteilt; hier ist der Fall, in dem die eigenen Worte eines Kunden das Label in die falsche Richtung lenken, und die Kosten des Fehlers sind ein langsames Abdriften zu einem Backlog voller Wünsche, die niemand wirklich will, sobald man genauer hinsieht.

Wie sieht ein Feature-Request aus, der eigentlich ein Bug-Report ist?

Er benennt einen Workaround statt das Problem. Ein echter Feature-Request beschreibt meist ein Ergebnis, das das Produkt gar nicht unterstützt: „Lass mich das für später planen”, „fügt einen Dunkelmodus hinzu”. Ein fehlklassifizierter Bug-Report beschreibt eine bestimmte Zahl, Schwelle oder ein Verhalten, das nach fehlender Einstellung klingt, aber tatsächlich ein Symptom ist: „erhöht das Timeout”, „fügt eine Retry-Option hinzu”, „lasst mich mehr Zeilen auf einmal exportieren”. Das Erkennungsmerkmal ist, dass die Anfragende eine Implementierung vorschlägt, eine Einstellung, einen Schalter, eine Überschreibung, statt ein Ziel zu beschreiben, weil sie das Feature bereits wie dokumentiert ausprobiert hat und es nicht getan hat, was die Dokumentation verspricht.

Warum zählt das mehr, als es klingt?

Weil die beiden Queues unterschiedliche Besitzerinnen, Zeitpläne und Erfolgskriterien haben, und ein als Feature-Request eingereichter Bug wird gegen Feature-Requests priorisiert, konkurriert um Aufmerksamkeit mit echten Produktlücken statt auf dem Zeitplan behoben zu werden, den ein Bug verdient. Feature-Requests tracken behandelt, warum das Mischen von Bugs und Features in einer Queue die lautesten Beschwerden echte Anfragen verdrängen lässt; ein Feature-Request, der heimlich ein Bug ist, richtet den umgekehrten Schaden an, sitzt im Produkt-Backlog und sammelt Stimmen für ein „Feature”, das verschwinden würde, sobald der zugrundeliegende Bug behoben ist, was das Priorisierungssignal für alle verschwendet, die dieses Backlog lesen.

Wie erkennt man den Unterschied, wenn die eigenen Worte des Kunden in die falsche Richtung zeigen?

Fragt, was sie erwartet haben, nicht, was sie hinzugefügt haben wollen. „Der Export hat bei 500 Zeilen gedeckelt und ich brauche 2.000, könnt ihr das Limit erhöhen” klingt nach einem Limit-Erhöhungs-Feature-Request, bis die Nachfrage „ist 500 das dokumentierte Limit” enthüllt, dass die dokumentierte Zahl 5.000 war und der Export früh fehlschlägt. Genau diese eine Frage, was erwartet gegen was passiert ist, erledigt den größten Teil der Sortierarbeit, weil ein echter Feature-Request kein dokumentiertes Verhalten hat, hinter dem er zurückbleibt; es gibt nichts zu erwarten, weil die Fähigkeit noch nicht existiert.

Sollten Support-Mitarbeitende oder Entwicklerinnen diese Entscheidung treffen?

Support-Mitarbeitende machen den ersten Durchgang, weil sie das Ticket zuerst sehen, aber das Label sollte leicht zu ändern und billig falsch zu machen sein, keine einmalige Entscheidung, die den Eintrag für immer in der falschen Queue festlegt. Eine leichtgewichtige zweite Prüfung, eine Entwicklerin, die wöchentlich neue „Feature-Request”-Labels nach allem durchschaut, das nach verdecktem Bug riecht, fängt die auf, die eine Support-Mitarbeitende ohne Codebase-Kontext nicht hätte erkennen können. Das muss nicht formal sein; es ist eher ein Fünf-Minuten-Scan als ein Review-Prozess.

Ändert sich das Schließen der Schleife, sobald der echte Bug gefunden ist?

Ja, und es verbessert die Nachricht, die ihr senden könnt. Den Feedback-Loop mit Kunden schließen behandelt, wie man einer Anfragenden mitteilt, wenn ihr Wunsch ausgeliefert ist; ein umkategorisierter Bug bekommt eine bessere Version dieser Nachricht, weil „wir haben den Bug dahinter gefunden und behoben” nach Kompetenz klingt, während „wir haben das Feature gebaut, um das ihr gebeten habt” nur zufällig wahr gewesen wäre, weil der echte Feature-Request, ein tatsächlich höheres Export-Limit, vielleicht nie gebaut wird, sobald der Bug weg ist und das ursprüngliche 5.000-Zeilen-Limit genügt.

Was passiert, wenn man die Fehlklassifizierung nie erkennt?

Das Backlog füllt sich mit Wünschen, die wie echte Nachfrage aussehen und es nicht sind, und Priorisierungsentscheidungen, die gegen dieses Backlog getroffen werden, erben die Verzerrung. Ein „Feature” mit vierzig Stimmen könnten in Wahrheit vierzig Leute sein, die auf denselben Bug treffen, und den wörtlichen Wunsch zu bauen, eine Einstellung, um ein Limit zu erhöhen, das nie tatsächlich die Einschränkung war, liefert Komplexität, die nichts behebt, während der zugrundeliegende Bug weiter neue „Feature-Requests” von Kunden erzeugt, die diesen Thread noch nicht gefunden haben.

FAQ

Lohnt es sich, einen formalen Schritt hinzuzufügen, um jeden Feature-Request gegen bekannte Bugs zu prüfen? Kein formaler Schritt, eher eine Gewohnheit: Wer auch immer einen neuen Feature-Request triagiert, sollte fragen „behauptet das dokumentierte Verhalten schon, das zu tun”, bevor das Label vergeben wird, weil diese eine Frage die meisten Fehlklassifizierungen fängt, ohne Prozessaufwand hinzuzufügen.

Was, wenn der Kunde auch nach dem Fund des Bugs auf dem Feature-Request besteht? Erklärt, was ihr gefunden habt und warum die vorgeschlagene Einstellung nicht mehr nötig wäre, sobald der Bug behoben ist. Die meisten Kunden bitten um einen Workaround, weil sie angenommen haben, der echte Fix sei nicht verfügbar, nicht, weil sie speziell die Einstellung wollten.

Verliert ein umkategorisierter Eintrag die Stimmen oder Kommentare, die er als Feature-Request gesammelt hat? Er sollte sie sichtbar behalten, weil diese Stimmen der Beleg sind, der überhaupt zum Finden des Bugs geführt hat, und diese Spur zu verstecken macht dieselbe Fehlklassifizierung beim nächsten Mal, bei einem anderen Ticket, schwerer zu erkennen.

Kann das auch umgekehrt passieren, ein Bug-Report, der eigentlich ein Feature-Request ist? Seltener, aber ja: „das ist kaputt” bedeutet manchmal „das tut nicht, was ich angenommen habe”, was eine fehlende Fähigkeit ist, kein Defekt. Dieselbe Frage, was erwartet gegen was dokumentiert ist, sortiert auch in diese Richtung.

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.

Mehr bei changeloop: Entwicklerdokumentation, Changelog-Tools im Vergleich