Den Feedback-Loop vom Changelog aus schließen

Ein Kunden-Feedback-Loop schließt sich, wenn der Person, die das Feedback gegeben hat, gesagt wird, was daraus geworden ist. Nicht, wenn es abgelegt wird. Nicht, wenn es priorisiert wird. Nicht einmal, wenn es ausgeliefert wird. Wenn es ihr gesagt wird. Die meisten Teams erledigen die ersten drei Schritte gut und den letzten gar nicht, und wundern sich dann, warum die Leute, die Feedback schicken, aufhören, es zu schicken.

Dieser Artikel handelt von diesem letzten Schritt, und von einer konkreten Behauptung: Der Changelog ist der richtige Ort, um den Loop zu schließen, weil er das eine Artefakt ist, das genau in dem Moment schon existiert, in dem der Loop geschlossen werden kann.

Was ist ein Kunden-Feedback-Loop?

Ein Kunden-Feedback-Loop ist der Weg von einer Nutzerin, die euch etwas sagt, bis zu dieser Nutzerin, die erfährt, was ihr damit gemacht habt. Er hat vier Schritte: das Feedback sammeln, entscheiden, was damit zu tun ist, das Ergebnis ausliefern, und der fragenden Person Bescheid geben. Der Loop ist offen, bis der vierte Schritt passiert. Ein Team, das Feedback sammelt und Fixes ausliefert, aber niemandem je Bescheid gibt, hat einen Posteingang, keinen Loop.

Die vierte Zeile ist die, um die es in diesem Artikel geht. Sie bricht aus einem strukturellen Grund, nicht aus einem kulturellen: Bis ein Feature ausgeliefert wird, liegt die Anfrage, die es verursacht hat, in einem anderen System als das, was ausgeliefert wurde, und niemandes Aufgabe ist es, beide zu verbinden. Der Loop beginnt früher, damit, wie die Anfrage überhaupt gestellt wird; Kundenfeedback einholen behandelt Formulierung und Zeitpunkt.

Warum bleiben Feedback-Loops offen?

Feedback-Loops bleiben offen, weil Anfrage und ausgelieferte Änderung an verschiedenen Orten leben und der Link dazwischen von Hand hergestellt wird, wenn überhaupt. Die Anfrage liegt in einem Feedback-Tool, einem Support-Postfach oder einer Tabelle. Die Änderung liegt in einem Pull Request. Die Ankündigung liegt in einem Changelog oder einer E-Mail. Drei Systeme, drei Verantwortliche, und der Link vom dritten zurück zum ersten ist ein Mensch, der sich Monate später erinnert, wer gefragt hat.

Es gibt einen zweiten Grund. Der Bescheid-Schritt wird meist als Marketing-Aufgabe gerahmt (“Feature ankündigen”) statt als Support-Aufgabe (“der Person antworten”). Ankündigungen gehen an alle und erreichen niemanden konkret. Die Person, die im März um das Feature gebeten hat, liest die Ankündigung im Juni, falls überhaupt, als Neuigkeit, nicht als Antwort. Der Loop schließt sich nur, wenn die Nachricht an sie adressiert ist.

Warum den Loop vom Changelog aus schließen?

Weil der Changelog-Eintrag das eine Artefakt ist, das genau im richtigen Moment existiert, genau die richtigen Worte enthält, und von genau der richtigen Person geschrieben wird. Er existiert, wenn die Änderung live ist, und nicht davor. Er sagt, was sich geändert hat, in den Worten der Leserin, was genau die Nachricht ist, die die anfragende Person braucht. Und er wird von jemandem geschrieben, der gerade den Pull Request gelesen hat, was der einzige Moment ist, in dem der Link zur ursprünglichen Anfrage noch sichtbar ist.

Vergleicht die Alternativen. Den Loop vom Feedback-Tool aus zu schließen bedeutet, dass das Feedback-Tool wissen muss, wann das Feature ausgeliefert wurde, was heißt, dass jemand einen Status von Hand aktualisiert. Ihn vom Pull Request aus zu schließen bedeutet, die Kundin beim Merge zu informieren, bevor die Änderung live ist, ein gebrochenes Versprechen mit Zeitstempel, sobald sich das Deployment verzögert. Ihn von der Marketing-Ankündigung aus zu schließen bedeutet, auf eine zu warten, und die meisten ausgelieferten Änderungen bekommen nie eine.

Der Changelog sitzt in der Mitte: nach dem Merge, im Moment des Release, mit fertiger Formulierung.

Wie schließt sich der Loop, Schritt für Schritt

Das ist der Mechanismus, den wir betreiben. Er wird hier als Spezifikation beschrieben statt als Produkttour, weil jeder Schritt von Hand oder mit anderen Werkzeugen erledigt werden kann; was zählt, ist die Reihenfolge.

1. Feedback wird zu einem Issue im Repository, das es beheben wird. Eine Widget-Einreichung wird als beschriftetes GitHub-Issue abgelegt (feature-request oder bug, eine Priorität, und from-widget), wobei die E-Mail-Adresse der einreichenden Person aus dem Issue-Text herausgehalten wird. Das Issue lebt neben dem Code, damit Schritt drei es finden kann. Ein von Hand angelegtes Issue, etwa aus einer Feature-Request-Vorlage, liegt außerhalb dieses Wegs: Schritt fünf kommentiert es nicht, also schließt diesen Loop selbst.
2. Der Fix referenziert das Issue. Der Pull Request sagt Fixes #142, GitHubs eigenes Schließ-Schlüsselwort. Nichts Neues zu lernen, und es ist derselbe Satz, den Entwicklerinnen ohnehin schreiben.
3. Der Changelog-Eintrag wird aus dem gemergten Pull Request entworfen und trägt den Link. Beim Merge wird der Entwurf erstellt, #142 wird aus dem PR-Text gelesen und an den Entwurf angehängt. Der Link entsteht, während er noch günstig ist, von einer Maschine, aus Daten, die schon da sind.
4. Ein Mensch prüft den Eintrag. Formulierung, Zielgruppe, ob er überhaupt veröffentlicht werden sollte. Ein verworfener Entwurf schließt nichts, was korrekt ist: Ein interner Umbau, der zufällig ein Issue referenziert hat, ist keine Neuigkeit.
5. Bei Freigabe wird die anfragende Person informiert. Ein Kommentar wird auf dem Issue gepostet, zu dem ihr Feedback wurde, “Shipped —” gefolgt vom Titel des Eintrags und einem Link zum veröffentlichten Eintrag, und das Widget zeigt der einreichenden Person denselben ausgelieferten Eintrag. Einmal, nie zweimal, und erst nachdem ein Mensch den Eintrag freigegeben hat. Derselbe Eintrag geht über Feed und Widget an alle, die nicht gefragt haben.

Die Reihenfolge in Schritt fünf ist das ganze Design. Die anfragende Person beim Merge zu informieren wäre früher und leichter, und es wäre ungefähr so oft falsch, wie sich Deployments verzögern. Ein Feature-Flag bricht sogar diese Reihenfolge, weil genehmigt und veröffentlicht passieren kann, während das Feature für das Konto der anfragenden Person noch unsichtbar ist; Feature-Flags und Feature-Requests behandelt die zusätzliche Prüfung, die dieser Schritt braucht, sobald ein Flag im Spiel ist.

Wie sieht ein geschlossener Loop für die Kundin aus?

Er sieht aus wie eine Antwort. Die Kundin hat eine Anfrage über ein Widget geschickt, und eines Tages zeigt das Widget sie als ausgeliefert an, mit Link zu einem Eintrag, der es in ihren Worten beschreibt; auf GitHub bekommt das Issue dieselbe Nachricht als Kommentar. Sie hat keinen Newsletter abonniert, keine Roadmap geprüft, nicht im Changelog gesucht. Ihr wurde Bescheid gegeben.

Das ist die Erfahrung, die das nächste Stück Feedback auslöst. Leute schicken Feedback an Produkte, die antworten. Die Seite Changelog-Beispiele enthält Einträge von Teams, deren Nutzer nachweislich immer wieder mit Anfragen zurückkommen, und der gemeinsame Nenner ist nicht das Werkzeug; es ist, dass die Einträge wie Antworten lesen.

Wie misst man einen Feedback-Loop?

Messt den Anteil ausgelieferter Änderungen, der mindestens eine anfragende Person informiert hat, und die Zeit von Auslieferung bis Bescheid. Zwei Zahlen, beide leicht, sobald der Link existiert, und unmöglich davor.

• Abschlussrate: Von den diesen Monat veröffentlichten Changelog-Einträgen, wie viele verlinkten mindestens eine Anfrage, und davon, wie viele haben die anfragende Person informiert? Ist die zweite Zahl viel niedriger als die erste, scheitern Benachrichtigungen; ist die erste niedrig, werden Anfragen nicht aus Pull Requests referenziert, und der Fix ist ein Satz in der PR-Vorlage.
• Zeit von Ausliefern bis Bescheid: Wie lange zwischen dem Live-Gehen des Eintrags und dem Bescheid an die anfragende Person? Mit dem Mechanismus oben sind es Sekunden. Von Hand sind es typischerweise Wochen, oder nie, und “nie” ist die Zahl, die zählt.

Messt den Loop nicht am Volumen des gesammelten Feedbacks. Sammeln ist der leichte Schritt, und ein Team, das ihn misst, wird ihn optimieren, was mehr offene Loops erzeugt.

Wo passt die Roadmap hinein?

Eine öffentliche Roadmap ist eine Art, den Loop früh zu schließen: Sie sagt anfragenden Personen, dass ihre Anfrage gehört wurde, bevor sie ausgeliefert wird. Das ist nützlich, und es ersetzt nicht den letzten Schritt. “Geplant” ist ein Versprechen über die Zukunft; “Ausgeliefert” ist eine Tatsache über die Gegenwart. Betreibt die öffentliche Roadmap aus denselben Issues, mit einem Label pro Spalte, sodass dieselbe Anfrage von geplant zu ausgeliefert wandert, ohne irgendwo neu eingegeben zu werden. Der Wechsel zu ausgeliefert ist eine Label-Änderung (roadmap:shipped), die niemand für euch vornimmt, wenn der Eintrag freigegeben wird, also erledigt sie im selben Review.

FAQ

Was sind die vier Schritte eines Kunden-Feedback-Loops? Sammeln, entscheiden, ausliefern, Bescheid geben. Der Loop ist offen, bis der vierte Schritt passiert. Die meisten Frameworks fügen in der Mitte Analyse- und Priorisierungsschritte hinzu; das sind Verfeinerungen von “entscheiden”, und keiner davon schließt irgendetwas.

Sollte man Kunden Bescheid geben, wenn man eine Anfrage ablehnt? Ja, und das ist die am meisten vernachlässigte Nachricht im Loop. Ein klares “das machen wir nicht, und hier ist warum” beendet das Warten. Schweigen lässt den Loop für immer offen und die Kundin nachprüfen.

Wie unterscheidet sich das Schließen des Loops von einer Feature-Ankündigung? Eine Ankündigung geht an alle. Den Loop zu schließen ist eine Antwort an die Leute, die gefragt haben, auf dem Kanal, über den sie gefragt haben. Macht beides; es sind unterschiedliche Nachrichten an unterschiedliche Leserinnen.

Was, wenn die anfragende Person nicht auf GitHub ist? Die meisten sind es nicht, und das ist in Ordnung. Das Widget zeigt ihnen weiterhin den Status dessen, was sie geschickt haben, einschließlich des ausgelieferten Eintrags und seines Links, also brauchen sie nichts außer der Seite, von der aus sie geschrieben haben. Der Kommentar auf dem Issue ist für die Leute, die das Repository sehen können.

Funktioniert dieser Loop auch mit GitLab oder Bitbucket statt GitHub? Das Widget und der Changelog schon; der automatische Kommentar aus Schritt fünf heute noch nicht. Ein Team auf GitLab oder Bitbucket bekommt trotzdem jede Einreichung, legt sie trotzdem als Issue an und zeigt der anfragenden Person trotzdem einen Status im Widget, aber diesen einen Loop bis zurück zum Issue selbst zu schließen, ist bis zu dieser Integration ein manueller Schritt.

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-Beispiele