Feature-Requests priorisieren, wenn der Stapel wächst

Feature-Requests zu erfassen löst, wo sie leben. Es löst nicht, welcher als Nächstes ausgeliefert wird, und diese zweite Frage ist die, an der Teams tatsächlich hängen bleiben. Ein erfasster, gruppierter, beschrifteter Backlog mit dreihundert Requests braucht immer noch eine Entscheidungsregel, weil “baue das meistgefragte Ding” nur funktioniert, bis zwei Requests nah beieinander liegen und ein dritter eine laute Fürsprecherin hat, was die meisten Wochen der Fall ist. Die Frameworks unten sind keine konkurrierenden Antworten auf dieselbe Frage. Jedes passt zu einer anderen Art von Request, und für alle dasselbe Framework zu verwenden ist meist der eigentliche Fehler.

Was macht das Priorisieren von Feature-Requests anders als das Priorisieren einer Roadmap?

Eine Roadmap-Entscheidung startet bei der Strategie und fragt, was gebaut werden soll. Eine Feature-Request-Entscheidung startet bei bereits existierender Nachfrage und fragt, ob darauf reagiert werden soll, und die beiden ziehen oft genug in verschiedene Richtungen, dass ein Request hohe Nachfrage haben kann und trotzdem falsch zu bauen ist, oder niedrige Nachfrage und trotzdem lohnenswert, weil er einen strategischen Account entblockt. Jeden Request wie eine Roadmap-Stimme zu behandeln überspringt diese Prüfung.

Was ist RICE, und funktioniert es für Feature-Requests?

RICE bewertet eine Idee nach Reichweite, Wirkung, Vertrauen und Aufwand und teilt dann die ersten drei durch den vierten, um eine vergleichbare Zahl zu bekommen. Es wurde für Roadmap-Ideen gebaut, an die ein Team schon glaubt, wo der schwierige Teil ist, ungleiche Wetten miteinander zu vergleichen. Feature-Requests bringen schon eine Reichweiten-Zahl mit, die Anzahl der Leute, die gefragt haben, was konkreter ist als die Reichweite, die eine frische Roadmap-Idee normalerweise hat. Wo RICE bei einem Request unter Spannung gerät, sind Vertrauen und Wirkung: ein Team kann sicher sein, dass ein Request echt ist, und trotzdem keine Grundlage haben, wie sehr er eine Kennzahl bewegen wird, weil “Wirkung” für einen Request, der schon einen Namen und eine Spur echter Nutzerinnen hat, eine andere Art von Schätzung ist als Wirkung für eine Idee, die außerhalb des Raums noch niemand gesehen hat.

Nutze RICE für Requests, die ernsthaft in Betracht gezogen werden und unentschieden sind. Führe es nicht bei jedem eingehenden Request aus; der Bewertungsaufwand lohnt sich nur bei denen, die nah genug beieinander liegen, um einen Tiebreaker zu brauchen.

Sollte nach Umsatz gewichtet werden, oder danach, wer gefragt hat?

Danach, wer gefragt hat, aber nicht nur nach Umsatz. Ein Account kurz vor der Vertragsverlängerung, ein Account, der schon eskaliert hat, und ein Account, dessen Request einen laufenden Deal entblockt, tragen alle eine Dringlichkeit, die eine flache Umsatzzahl allein nicht erfasst, und ein Request von einer Testregistrierung kann trotzdem wichtig sein, wenn er eine Entscheidung blockiert, die bald zu Umsatz wird. Umsatzgewichtung ist von diesen am leichtesten zu berechnen und aus genau diesem Grund am leichtesten zu übervertrauen: sie entfernt korrekt Rauschen von Accounts ohne echten Einsatz, und sie kann genauso leicht einen Request abwerten, der einen viel größeren Account, der noch in der Pipeline ist, an Land ziehen würde.

Welche Rolle spielen Stimmen tatsächlich?

Ein günstiges, laufendes Signal für Requests, die schon existieren, und ein schlechter Weg, herauszufinden, welche Requests überhaupt existieren sollten. Eine Stimmenzahl erreicht nur die Nutzerinnen, die den Request schon gefunden und für klickenswert gehalten haben, was bedeutet, dass die Stimmensumme einer öffentlichen Roadmap genauso viel Sichtbarkeit wie Nachfrage widerspiegelt: ein alter Request oben in der Liste sammelt weiter Stimmen, teilweise weil er leicht zu finden ist, und ein neuerer, ebenso echter Request startet bei null. Der Artikel zur öffentlichen Roadmap plädiert dafür, Stimmen ganz von der Roadmap wegzulassen. Behandle Stimmen als einen Input, der gruppiert und nach Aktualität gewichtet werden muss, nicht als eine Rangliste, die geradlinig abgearbeitet wird. Support-Tickets vs. Feature-Requests behandelt den anderen blinden Fleck bei Stimmenzahlen: eine echte Lücke kann fast keine Stimmen erzeugen, wenn die Nutzerinnen, die darauf stoßen, das Board nie finden, während sie im Support trotzdem laut auftaucht.

Wann gewinnt die lauteste Kundin, und ist das ein Problem?

Manchmal, und es ist nur ein Problem, wenn es niemand bemerkt. Eine Kundin, die häufig eskaliert, detaillierte Tickets schreibt oder eine direkte Leitung zu jemandem im Team hat, bekommt ihre Requests schneller gesehen als eine leisere Kundin mit einem ebenso berechtigten Anliegen, und ein Priorisierungsprozess, der das nie prüft, wird systematisch bevorzugen, wer am beharrlichsten ist, statt wer den stärksten Fall hat. Laute Kundinnen sind nicht das Problem, das behoben werden muss; ihre Requests sind oft echt wichtig. Die Lösung ist eine Gewohnheit: regelmäßig den Backlog nach Quelle durchgehen und prüfen, ob dieselbe Handvoll Accounts für das meiste verantwortlich ist, was zuletzt ausgeliefert wurde, und fragen, ob das zur tatsächlichen Nachfrage passt.

Wie wird aus einer Priorisierungsentscheidung eine Antwort?

Jede Entscheidung hier erzeugt Gewinnerinnen und Verliererinnen, und beide verdienen eine Antwort, die die tatsächliche Begründung nennt, nicht nur eine Statusänderung ohne Erklärung. Wie man einen Feature-Request ablehnt behandelt, was einem verlorenen Request gesagt wird, auf eine Weise, die die Beziehung intakt lässt statt sich wie eine Formularablehnung zu lesen. Die Gruppierungs- und Beschriftungsarbeit, die all das überhaupt möglich macht, wird in Feature-Request-Tracking behandelt; Priorisierung funktioniert nur bei Requests, die schon erfasst und gut genug gruppiert wurden, um verglichen zu werden.

FAQ

Was ist das beste Framework, um Feature-Requests zu priorisieren? Keines davon allein. Nutze rohe Zahlen, um das lauteste Signal zu finden, RICE, um eine kurze Liste ernsthafter Kandidaten zu vergleichen, und eine Umsatz- oder Account-Prüfung, um Fälle zu erwischen, in denen leise Nachfrage von einem strategischen Account eine lautere, aber weniger bedeutsame Gruppe überwiegt.

Sollten Feature-Requests genauso priorisiert werden wie Roadmap-Ideen? Nein. Roadmap-Ideen starten bei der Strategie; Feature-Requests starten bei bereits existierender Nachfrage. Bewertet man sie zusammen, verliert eine gut begründete strategische Wette mit wenig existierender Nachfrage konsequent gegen einen Request, für den einfach mehr Leute gefragt haben.

Spiegeln Stimmen auf einer öffentlichen Roadmap die Nachfrage genau wider? Nur unter Leuten, die den Request schon gefunden haben. Ältere, sichtbarere Requests sammeln Stimmen schneller, unabhängig davon, wie viel echte Nachfrage hinter einem neueren steckt, also behandle Stimmensummen als einen Input, gruppiert und nach Aktualität gewichtet, nicht als Rangliste, die der Reihe nach abgearbeitet wird.

Wie oft sollten Feature-Request-Prioritäten neu bewertet werden? Nach einem festen Zyklus, nicht nur wenn jemand eskaliert. Ein monatlicher oder vierteljährlicher Durchgang, der Requests neu gruppiert und die Gewichtung neu prüft, erkennt Drift, wie eine Handvoll Accounts, die dominiert, was ausgeliefert wird, die ein rein reaktiver Prozess nie von selbst zutage bringt.

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