Wie misst man die Kundenzufriedenheit in Scrum?

Rollengrenzen und Verantwortungsbereiche beziehen sich nicht nur auf Aufgaben und Bereiche der Entscheidungsfindung, sondern auch auf Verantwortlichkeiten. Und es gibt einen Unterschied zwischen Rechenschaftspflicht und Verantwortung. Meiner Ansicht nach ist der Produkteigentümer der einzige Inhaber der Rechenschaftspflicht gegenüber den Endnutzer-Stakeholdern. Es wird nicht geteilt, IMHO. Die Entwickler tragen zwar eine gewisse Verantwortung gegenüber den Stakeholdern, aber das endet damit, dass eine elegante Lösung mit minimalen Fehlern gegen die Anforderungen der Stakeholder entwickelt wird. Das ultimative Glück liegt beim Product Owner. Ebenso ist der Entwickler für die Zufriedenheit des Product Owners verantwortlich.

Kein Indikator oder Messinstrument ist zu 100 % valide. Jedes Messwerkzeug, das wir in jeder Branche haben, leidet unter Gültigkeitsproblemen oder Messfehlern. Dies gilt, wenn Sie versuchen, etwas extrem Konkretes zu messen, und noch schlimmer, wenn Sie etwas sehr Abstraktes wie Glück und Zufriedenheit messen.

Es gibt so viele Variablen, die in die Kundenzufriedenheit einfließen, einschließlich einer Tonne, die nichts mit der Transaktion zu tun hat, die Sie bei der Interpretation der Zufriedenheitsergebnisse abschwächen müssen. Daher müssen Sie sich NICHT auf eine Methode zur Zufriedenheitsmessung verlassen.

Natürlich sind Umfragen wichtig. Aber das Erstellen der Umfragen mit den richtigen Arten von Fragen und das anschließende Interpretieren dieser Umfragen, um die genauesten Schlussfolgerungen zu ziehen, erfordert Fachwissen, Zeit und Geld. Aber ohne sie geht es nicht weiter.

Sie können auch andere Marker verwenden, um auf die Kundenzufriedenheit zu schließen – der Prozess der Inferenz ist an und für sich subjektiv und unterliegt voreingenommenen Ergebnissen. Zum Beispiel das Kaufverhalten. In Ihrem Fall würde sich dies durch die Annahme einer Lieferung durch den Product Owner, die Annahme der Lieferung durch die Stakeholder, die Verringerung der Fehlerfindung während des Tests, die Verringerung der Fehlerfindung während der Produktion, die Bitte um mehr Geschäft, die Überweisung an andere Abteilungen, die Steigerung des Umsatzes usw.

Ein Kunde beschwert sich chronisch, kauft aber weiter. Dies würde meiner Meinung nach darauf hindeuten, dass sie insgesamt glücklich und zufrieden mit dem Produkt sind, aber andere Gründe haben, einschließlich der Dinge, die dem Kunden eigen sind, wie Persönlichkeits-Make-up, die die Beschwerden antreiben. Diese Interpretation birgt Risiken, weshalb Sie sich nicht auf eine Messmethode oder gar einen Interpreten verlassen.

Ich hoffe das hilft.

Ich denke, wenn Ihr Ziel darin besteht, die Kundenzufriedenheit zu messen, dann ist es irrelevant, was Ihr Product Owner denkt. Es würde keinen Sinn machen, den Product Owner nach der Kundenzufriedenheit zu fragen, falls er dafür verantwortlich ist, den Kunden glücklich zu machen. Warum? Denn falls er mit seinem Kunden nicht über solche Dinge spricht, hat er nur Vermutungen darüber.

Ich denke, der wertvollste Beitrag wäre, ab und zu mit dem Kunden zu sprechen (informell, ohne zusätzliche Arbeit für den Kunden oder Product Owner, um Formulare oder andere Papierkram auszufüllen). Sie müssen nur sicherstellen, dass Ihr Product Owner dies akzeptiert und er sollte auch derjenige sein, der Sie dem Kunden vorstellt und dem Kunden von der Idee erzählt.

Ich denke, ein Zufriedenheitsgrad, gemessen in Punkten oder so, ist nicht sinnvoll. Wenn Sie seine Zufriedenheit verbessern möchten, müssen Sie verstehen, was er "sagt".

Auch Zufriedenheit ist nicht sehr "objektiv", sondern eher "subjektiv". Ich bin sicher, es wird sich für den Kunden falsch anfühlen, wenn sein Zufriedenheitsgrad „gemessen“ wird, falls so etwas wirklich möglich ist. Also würde ich eher den Ansatz wählen, oft mit ihm zu sprechen (ein paar Tage nach jeder Erhöhung?).