Erst Feedback und Nutzungsdaten abgleichen, dann Arbeit daraus machen

Feedback schreiben nur die, die sich dazu aufraffen. Diese Gruppe ist kleiner und lauter als „eure Nutzer“, und sie verschiebt die Vorstellung des Teams davon, was die Leute eigentlich wollen.

In der Factory, die öffentlich auf software-factory.dev entsteht, gleicht eine Automation namens Feedback Digest diese Schieflage aus. Ich finde, ihr Vorgehen ist einen genaueren Blick wert. Die Definition der Automation liegt auf GitHub (öffnet in einem neuen Tab).

Ein stündlicher Lauf über zwei Eingaben

Gestartet wird sie von der Cron-Zeile 0 * * * *, also zu jeder vollen Stunde. Wer nicht warten will, startet sie manuell.

Pro Lauf zieht sie zwei Quellen heran. Aus der Produktdatenbank kommen die neuen Feedback-Einträge, dazu die Nutzungsereignisse der vergangenen sieben Tage. Anschließend verteilt sie das Feedback:

• Bugs kommen auf einen Stapel.
• Feature-Wünsche kommen auf einen zweiten, gebündelt nach Thema: Aus fünf Rückmeldungen zum PDF-Export wird eine.
• Was allgemeines Rauschen ist, kommt auf den dritten.

Was Feedback bedeutet, hängt von der Nutzung ab

So weit ist das normale Triage. Interessant ist, was danach passiert: Der Digest legt das Feedback neben die Nutzungsdaten.

• Gibt es Beschwerden über ein Feature, das kaum genutzt wird, liest er das als Auffindbarkeitsproblem. Ein Qualitätsproblem sieht er darin nicht.
• Wird ein Feature viel genutzt und kommt kein Feedback, gilt es als in Ordnung.
• Kommt beides zusammen, bekommt das Feature Priorität.

Ein und dieselbe Beschwerde bedeutet damit drei verschiedene Dinge. Es kommt darauf an, ob das Feature überhaupt jemand benutzt.

Nur zwei Arten von Issues entstehen automatisch

Dieses Detail lohnt sich zum Übernehmen. Der Digest macht nicht aus jeder Rückmeldung ein Issue. Von sich aus legt er genau zwei Arten an:

• Bug-Reports mit reproduzierbaren Schritten, dem Pfad der Seite und der Gegenüberstellung von erwartetem und tatsächlichem Verhalten.
• Feature-Wünsche, die in zwei oder mehr ähnlichen Einsendungen vorkommen.

Für alles andere macht er einen Vorschlag, und ein Mensch entscheidet.

Ist kein neues Feedback da, endet der Lauf kommentarlos. Einen leeren Digest postet er nicht in den Team-Chat. Dass keine Nachricht kommt, sagt ja auch etwas.

Eine Rückmeldung ist die Erfahrung einer Person

Gerade beim Feedback liegt man leicht daneben. Instinktiv nimmt man jede Rückmeldung für bare Münze und schiebt sie sofort ins Backlog. Hinter einer Rückmeldung steht aber eine einzelne Person, hinter den Nutzungsdaten das Verhalten aller. Der Digest traut einem Signal, wenn beides zusammenpasst oder derselbe Wunsch mehrfach kommt.

Nach welchen Kriterien wird bei euch aus Nutzerfeedback echte Arbeit, und welche Belege braucht es vorher?

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

• The software-factory pattern →
• Agentic Software Factory: Advanced Team Training →