Feature-Request-Tracking, ohne Anfragen zu verlieren

Feature-Request-Tracking scheitert fast immer auf eine von zwei Arten. Entweder haben Anfragen keinen festen Ort und leben in Postfächern und Slack-Threads, wo sie einzeln vergessen werden, oder sie haben einen Ort, an dem niemand mehr nachschaut, und werden gemeinsam vergessen. Ein System, das funktioniert, muss beide Ausfallarten überstehen: Es braucht einen Ort, an dem jede Anfrage landet, und einen Grund, diesen Ort nächsten Monat wieder zu öffnen.

Woher kommen Feature-Requests eigentlich?

Aus mehr Kanälen, als die meisten Tracking-Systeme einplanen. Ein Support-Ticket mit einem „wäre schön, wenn”. Ein Kommentar auf einer öffentlichen Roadmap. Ein Sales-Call, in dem eine Interessentin genau das eine Feature nennt, das den Deal blockiert. Ein Widget im Produkt. Jeder Kanal hat eine eigene Besitzerin und eigenes Werkzeug, und genau deshalb verstreuen sich Anfragen: Die Ticket-Queue des Supports und das Backlog des Produktteams sind selten dasselbe System, und eine Anfrage, die nur eines der beiden erreicht, hat effektiv nur eine Abteilung erreicht.

Ein einziges Intake-Formular für jeden Kanal funktioniert nicht, weil niemand es annimmt. Was funktioniert, ist ein Ziel, in das jeder Kanal einläuft, auch wenn das Routing anfangs eine Person ist, die fünf Minuten Copy-Paste pro Tag macht, bis es automatisiert ist.

Was bricht Feature-Request-Tracking tatsächlich?

Fast immer zwei Dinge. Erstens ein fehlendes Ziel: Anfragen werden im Kanal beantwortet, in dem sie ankamen, und nirgends dauerhaft festgehalten, sodass dieselbe Anfrage von drei verschiedenen Kunden wie drei unabhängige Einzelantworten aussieht statt wie ein Signal. Zweitens, häufiger, ein Ziel, das vollläuft und aufhört, gelesen zu werden. Eine Tabelle mit 400 Zeilen ohne Filterung ist kein Tracking-System mehr, sondern ein Archiv, das zufällig beschreibbar ist.

Der zweite Ausfall ist der gefährlichere, weil er aussieht, als würde Tracking funktionieren. Anfragen werden erfasst. Nichts wirkt kaputt, bis jemand fragt „wie viele haben schon nach X gefragt”, und die ehrliche Antwort lautet: „Wir müssten alle 400 Zeilen lesen, um es zu wissen.”

Was sollte ein Feature-Request-Eintrag festhalten?

Genug, um drei Fragen später zu beantworten, ohne die Ursprungsnachricht erneut zu lesen: Worum wurde gebeten, wenn möglich in den eigenen Worten der Anfragerin; wer hat gefragt, und wie erreicht man sie, falls die Antwort „wir haben es gebaut” lautet; und was es braucht, um zu wissen, ob das eine verbreitete Bitte oder ein Einzelfall ist. Ein Originalzitat zählt mehr als eine Paraphrase, weil eine Paraphrase, geschrieben von wer auch immer die Anfrage triagiert hat, bereits deren Lesart trägt, und genau die kann eine zweite Leserin sechs Monate später nicht mehr nachprüfen.

Welche Labels lohnen sich?

Zwei, und sie beantworten unterschiedliche Fragen. Ein Typ-Label trennt einen Feature-Request von einem Bug-Report, weil beide unterschiedliche Besitzerinnen und Zeitpläne brauchen, und eine gemeinsame Queue lässt die lautesten Beschwerden die Bitten verdrängen. Ein Priorität-Label, klein gehalten mit low, medium und high, trennt „blockiert jemanden bei der Nutzung des Produkts” von „wäre nett”, weil diese beiden sehr unterschiedliche Reaktionszeiten verdienen und keine das Tempo der anderen übernehmen sollte. Das Typ-Label richtig zu setzen setzt voraus, dass die Anfrage ist, was sie zu sein behauptet; wenn ein Feature-Request eigentlich ein Bug-Report ist behandelt den Fall, in dem die eigenen Worte eines Kunden dieses Label in die falsche Richtung lenken.

Automatisierte Triage kann beide sofort beim Eingang setzen. In changeloop bekommt eine Widget-Meldung im selben Durchgang das Label feature-request oder bug und ein priority:low|medium|high-Label, dazu ein from-widget-Tag, damit die Quelle sichtbar ist, ohne den Eintrag zu öffnen. Das reicht, um das Backlog in Minuten statt Nachmittagen filterbar zu machen: zeig mir jeden High-Priority-Feature-Request aus dem Widget diesen Monat.

Ein drittes Label lohnt sich, sobald es eine öffentliche Roadmap gibt: ein Status, den eine Anfragerin selbst verfolgen kann. Public Roadmap beschreibt die Zustände planned, building und shipped vollständig; kurz gesagt macht dieses Label aus einer privaten Queue etwas, das eine Anfragerin selbst nachschauen kann, statt erneut nachzufragen.

Wie entscheidet man, was als Nächstes gebaut wird?

Erst gruppieren, dann zählen. Zehn unterschiedlich formulierte Anfragen für dieselbe zugrunde liegende Fähigkeit lesen sich als zehn verstreute Tabellenzeilen und als ein starkes Signal, sobald sie gruppiert sind, und genau diese Gruppierung ist meist der fehlende Schritt, nicht das Zählen. Eine rohe Anzahl ohne Gruppierung belohnt tendenziell das Feature mit dem einprägsamsten Namen, nicht das mit der tatsächlich größten Nachfrage dahinter.

Nach wem fragt, gewichten, nicht nur wie viele fragen. Eine Anfrage von einem Konto kurz vor der Verlängerung trägt eine andere Dringlichkeit als dieselbe Anfrage von einem Trial-Signup, und ein Tracking-System, das diesen Kontext zugunsten einer nackten Zahl wegwirft, optimiert auf die am leichtesten berechenbare Zahl, nicht auf die nützlichste.

Jede Entscheidung hier erzeugt auch Anfragen, die verlieren, und die verdienen ebenfalls eine Antwort; wie man einen Feature-Request ablehnt behandelt, was man den Anfragerinnen sagt, deren Bitte es nicht geschafft hat. Gruppieren und Gewichten ist nur die halbe Miete bei “was als Nächstes gebaut wird”; Feature-Requests priorisieren behandelt die tatsächlichen Frameworks, RICE, Umsatzgewichtung und rohe Zahlen, und wo jedes davon bricht.

Wie schließt man die Schleife, sobald etwas ausgeliefert ist?

Das ist der Schritt, den Tracking-Systeme am häufigsten auslassen, und der, den Anfragende tatsächlich bemerken. Die Feedback-Schleife zum Kunden schließen behandelt die Mechanik vollständig; was hier hingehört: Das Schließen der Schleife funktioniert nur, wenn die ursprüngliche Anfrage mit der Person verknüpft blieb. Eine Feature-Request-Vorlage aus einem GitHub-Issue, bei der die Identität der Anfragerin am Issue hängt statt in einem Kommentar vergraben zu sein, macht eine automatische „ausgeliefert”-Benachrichtigung möglich statt einer, an die jemand manuell denken muss. Feature-Request-Vorlage zeigt die konkrete Vorlage und wofür jedes Feld steht.

FAQ

Welches Tool sollte ich für Feature-Request-Tracking nutzen? Was das Team ohnehin täglich anschaut, schlägt jedes Spezialtool, das niemand öffnet. Ein GitHub-Issue-Tracker funktioniert gut, wenn Engineering schon dort lebt; ein leichtgewichtiges Board funktioniert gut, wenn Produkt dort lebt. Das Tool zählt weniger als die Frage, ob es wieder aufgeschlagen wird.

Wie verhindere ich doppelte Feature-Requests? Nach zugrunde liegender Fähigkeit gruppieren, bevor nach Formulierung triagiert wird. Eine Suche in bestehenden Anfragen vor dem Anlegen einer neuen fängt die meisten Duplikate ab; ein monatlicher Gruppierungsdurchgang den Rest. Duplikate zusammenführen, ohne die ursprüngliche Stimme zu verlieren behandelt, was mit der Formulierung passieren sollte, sobald die Gruppierung selbst erledigt ist, damit der Merge die Anfrage nicht still auf die zuerst eingetroffene Einreichung verengt.

Sollte jeder Feature-Request eine Antwort bekommen? Jeder sollte eine Bestätigung bekommen, selbst eine kurze, aber nicht jeder braucht sofort eine Entscheidung. Ein sichtbarer Status, etwa ein Roadmap-Label, das die Anfragerin selbst nachschauen kann, ersetzt die meisten Einzelantworten, die ein Team sonst schulden würde.

Was unterscheidet Feature-Request-Tracking von einer öffentlichen Roadmap? Tracking ist das interne Protokoll jeder Bitte, auch der, die nie ausgeliefert wird. Eine öffentliche Roadmap ist die Teilmenge, zu der sich ein Team öffentlich verpflichtet, mit einem Status, den die Anfragerin sehen kann, ohne erneut zu fragen.

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