Hallo! Mein Name ist Anatoly Savchenko, ich bin Entwickler und gleichzeitig Scrum Master im Team des AutoTech- Dienstes. Wie Sie vielleicht erraten haben, arbeiten wir in Scrum. Alle zwei Wochen führen wir eine Sprint-Überprüfung durch - ein Treffen, bei dem das Team und die Stakeholder diskutieren, was getan wurde. Basierend auf diesen Informationen kann das Team Rückschlüsse darauf ziehen, ob die Entwicklung in die richtige Richtung geht, welche Verbesserungen noch erforderlich sind usw. Vor kurzem haben wir wertvolle neue Erfahrungen bei der Abhaltung dieses wichtigen Treffens gesammelt. Ich möchte dir von ihm erzählen.

Feedback-Tools

Natürlich ist eine Sprint-Überprüfung nicht der einzige Feedback-Kanal: Wir haben ein UX-Labor, wir verarbeiten Überprüfungen in Geschäften für mobile Anwendungen, Supportanrufe, Überprüfungen verschiedener Internetressourcen, wir führen Benutzerumfragen auf der Website durch und vieles mehr.
Dies ist für private Benutzer.

Darüber hinaus arbeiten wir mit Geschäftspartnern zusammen, denen wir zusätzliche Funktionen und Arbeitstools zur Verfügung stellen. Wir haben eine engere Interaktion mit ihnen. Unsere Manager sind immer in Kontakt mit ihnen (Mail, Telefon), es gibt Chats in Instant Messenger, die Mitglieder des Entwicklungsteams sind. So kommen wir unseren Geschäftsanwendern näher: Wir kennen sie besser, verstehen ihre Bedürfnisse, hören sie und fühlen ihren Schmerz oder ihre Freude.

Und das sind alles wunderbare und notwendige Kommunikationskanäle. Aber sie geben Informationen nach der Veröffentlichung. Außerdem ist das Entwicklungsteam in diesem Fall noch ziemlich weit von den Benutzern entfernt. Aus diesem Grund können Sprint-Bewertungen für ein Team, ein Produkt und letztendlich für Benutzer am vorteilhaftesten sein.

Sprint Review - wie vorher

Unsere Meetings fanden im Allgemeinen auf einem guten Niveau statt: Wir erhielten schnelle und qualitativ hochwertige Kommentare von unseren Stakeholdern (dh internen Kunden - Managern) und anderen Kollegen von Avito. Es entstand eine eher kammerische Situation, aber irgendwann vermissten wir die Fülle des Feedbacks. Wir wollten etwas ändern. Und unser agiler Trainer Levon Goncharov von AgileVerse brachte uns auf die Idee, externe Benutzer - unsere Geschäftspartner - direkt zum Meeting einzuladen.

Levon Goncharov, Mitbegründer von AgileVerse: „Ich habe die Jungs getroffen, als sie beschlossen, ihre Prozesse zu verbessern. Sie verstanden, dass etwas schief lief und suchten nach einer Antwort. Während der Diagnose sprach jedes Teammitglied irgendwie von der Notwendigkeit zu verstehen, "wie der Benutzer lebt". Es hat jemanden unter dem Gesichtspunkt der Motivation beeinflusst, jemand musste verstehen, wie man das Projekt architektonisch entwickelt. Dies ist im Prinzip ein ziemlich häufiges Problem von Scrum-Teams - sie verwandeln eine Sprint-Überprüfung in ein Meeting, in dem sie erzählen, was getan wurde, und nicht als Schöpfer, sondern als Darsteller denken. Um dies zu verhindern, müssen Sie darüber nachdenken.

Nr. 1 Denken Sie bei der Entwicklung eines Produkts mehr über Funktionen oder Benutzerprobleme nach?
№2 Wissen Sie, wie Ihr Benutzer lebt und warum er Ihr Produkt verwenden sollte?
Nr. 3 Kommunizieren Sie häufig mit denen, die Ihr Produkt verwenden?
Ich habe dem Team geraten, diese Probleme zu diskutieren und das Format der Sprint-Überprüfung zu ändern.

Der Fall des Chats mit Benutzern trat ziemlich schnell auf. Bis zum Ende des Sprints wollten wir ein neues Tool für Partner vom Fließband veröffentlichen, das noch niemand zuvor gesehen hatte. Und wir haben uns für "hot" entschieden, um Feedback zu einem Produkt zu sammeln, das noch nicht veröffentlicht wurde.

Vorbereitung

Zunächst haben Levon und meine Kollegen die Erwartungen an ein neues Treffen gesammelt. Danach haben wir die Tagesordnung geplant und alle erforderlichen Materialien vorbereitet.
Ich kann sagen, dass man allein über die Vorbereitung einen ganzen Beitrag schreiben könnte. Es ermöglichte uns, ein integrales Bild des Treffens zu erstellen und absolut alles zu berücksichtigen (natürlich haben wir nicht alles berücksichtigt, weil es unmöglich ist, aber wir haben dies auch berücksichtigt).

Zuerst haben wir das Ziel und das Bild des Ergebnisses auf ein Flipchart gemalt. Wir haben Punkte für den allgemeinen Plan des Treffens registriert. Detaillierung der Füllung jeder Stufe.
Wir haben die Timings aller Phasen registriert (und mehrmals umgeschrieben). Wir haben die erforderlichen Materialien für jede Phase festgelegt und aufgeschrieben, woran Sie denken müssen, um an der Besprechung teilzunehmen.

Kurz gesagt, das haben wir bekommen.

Zweck

1. Sprechen Sie den Teamfokus für das Quartal
2. Verstehen Sie, wie das aktualisierte Benutzerkonto (LKP) die Anforderungen erfüllt
3. Zeigen Sie Teaser und formulieren Sie einen Plan für 1-2 Sprints

Planen

1. Eröffnung (5 Minuten)
   a. Agenda
   b. Wir sagen Ihnen, wie Sie Feedback geben können
   c. Das Team treffen
2. Gemeinsamer Teil (15 Minuten)
   a. Was hast du gemacht
   b. Zukunftspläne (Fokus auf das Quartal)
   c. Fragen und Antworten
3. Demo (15 Minuten)
   a. Besprechen Sie
   b. Teaser
4. LCP-Dialog (10 Minuten)
   a. Was hast du gefunden (was ist so, was ist nicht)
   b. Wenn wir fertig sind (ungefährer Sprint)
   c. Was ersetzen? (über das Leben des Benutzers sprechen)
5. Feedback zum Überprüfungsformat einholen (5 Minuten)

Ergebnisbild

1. Vierteljährliches Feedback
2. Liste der Verbesserungen an der Lackierung
3. Besprechen Sie die schwersten Schmerzen des Benutzers und schreiben Sie den Rest auf
4. Besprechen Sie ein gemeinsames Verständnis von Teasern und planen Sie 1-2 Sprints
5. Feedback der Teilnehmer zum Format der Bewertung

Levon Goncharov, Mitbegründer von AgileVerse: „Wenn wir eine Beispiel- Meeting-Agenda ausfüllen, schreiben wir alles auf, was darauf passieren kann und wie wir es verwalten können. Wir gingen davon aus, dass Benutzer anfangen würden, über völlig häufige Schmerzen zu sprechen, und brachten dies in das Sprint-Review-Design ein. Bei der Vorbereitung wurde jedoch klar, dass dafür nicht genügend Platz vorhanden war. Daher haben wir vor dem Meeting nützliche Informationen erhalten, die wir nicht zu allgemeinen Themen ansprechen können. "

Wie ist es gelaufen?

Die Hauptidee war es, unseren Benutzern eine Live-Erfahrung des Kontakts mit dem Produkt zu ermöglichen und maximales Feedback zu erhalten. Folgendes haben wir uns ausgedacht: Wir haben jeden unserer Gäste mit einem Produkt hinter einen Laptop gestellt, neben dem sich immer zwei Teammitglieder befanden. Die eine Aufgabe besteht darin, über das Produkt zu sprechen und Fragen zu beantworten, und die zweite darin, so viel wie möglich alles aufzuzeichnen, was passiert, und es dann zusammen mit dem Eigentümer des Produkts zu verarbeiten.

Nun, es stellte sich heraus, dass jeder Gast etwas mehr als zwei Teammitglieder hatte

Die Diskussion erwies sich als gesättigt, und wir haben sogar die Zeit für die Anzeige des Produkts verlängert. Infolgedessen haben wir nicht nur viele nützliche Kommentare erhalten, sondern auch erfahren, wie die Arbeit unseres Partners von innen heraus aufgebaut wurde. Dies hilft uns bei der Planung weiterer Arbeiten am Produkt.

Es sah aus wie die erste Version des Produkts

Wir wollten das Maximum an nützlichen Informationen auf einer Seite platzieren, aber für Benutzer stellte sich heraus, dass die Benutzeroberfläche überlastet war. Darüber hinaus waren einige Informationen einfach unverständlich.
Wir haben die Kommentare und Wünsche unserer Gäste aufgezeichnet, die wichtigsten und wichtigsten Punkte notiert und sofort mit den Partnern besprochen, was und wann wir sie umsetzen werden.
Das Feedback hat uns dabei geholfen zu überdenken, wie wir dem Benutzer Informationen bequem und klar präsentieren können. Zum Zeitpunkt des Schreibens wurden bereits Änderungen mit der höchsten Priorität vorgenommen, wodurch die ursprüngliche Version erheblich verändert wurde.

Produktversion nach Änderungen

Dank frühzeitiger Rückmeldungen konnten wir eine Situation vermeiden, in der wir unseren Benutzern ein Rohprodukt gaben, das unterwegs bearbeitet werden musste.

Als Team haben wir sehr wertvolle Erfahrungen gesammelt. Das sagen meine Kollegen.

Vadim Ivanov, CEO von Autoteks: „Ich halte diese Art der Feedback-Sammlung für eine sehr nützliche und notwendige Praxis, die auf eine gute Weise viel früher implementiert werden musste: Es ist eine Sache, Sprint-Bewertungen in der gemütlichen Atmosphäre positiv gesinnter Kollegen zu sehen / zu hören, es ist eine ganz andere, sie sofort zu sehen eine lebhafte Benutzerreaktion auf die geleistete Arbeit. Die Meinung von Geschäftsanwendern ist doppelt nützlich, wie Sie kennen ihre Bedürfnisse und Probleme oft genauer. Schon der erste Versuch erwies sich als erfolgreich. Das gesamte Team war sehr enthusiastisch und in den Prozess involviert. Es gelang ihm, wertvolle Kommentare zu sammeln, die es bereits vor der ersten Veröffentlichung der neuen Funktionalität sofort zur Arbeit brachte, und so ein Produkt für Partner viel besser vorzubereiten. Und zusätzliche Arbeitskosten für die Vorbereitung der Veranstaltung haben sich mehr als gelohnt. Ich empfehle jedem, solche Methoden zu Hause anzuwenden und keine Angst vor Experimenten zu haben. “

Mansur Ahmadi, QA Autotech: „Im Kopf des Ingenieurs weicht das Bild des Endbenutzers und seiner Benutzeroberfläche häufig vom tatsächlichen Bild der Welt ab, was wiederum zu nicht den am besten geeigneten Lösungen führen kann. Beim letzten Treffen war dies ganz klar, als unser Gast seine Vision des Produkts darlegte. Diese Vision, die ihm mehr Glück geben würde. Diese Vision, auf die wir uns konzentrieren sollten. Meiner Meinung nach sind es genau solche Treffen, die dazu beitragen, schneller zu ihm zu kommen. “

Andrey Tumkin, Produktbesitzer Autoteks: „Das erste, was Ihnen einfällt, bevor Sie echte Benutzer zu einer Demo einladen, ist, warum? In den frühen Stadien haben wir ihre Schmerzen offenbart und nach der Veröffentlichung sammeln wir Feedback und nehmen Korrekturen vor. Aber nicht so einfach.
Erstens verlieren Sie Zeit und Geld, anstatt Benutzerprobleme sofort zu lösen. Zweitens kann selbst CusDev, das vor der Entwicklung durchgeführt wurde, nicht alle Probleme identifizieren, die bei einem realen Produkt auftreten. Drittens wird kein anderer Prozess ein solches Team in das Produkt einbeziehen. "

Fazit

Das Treffen mit Benutzern ist nicht nur ein Instrument zur Verbesserung und Einholung von Feedback, sondern auch ein echter Aufbau von Beziehungen zu denen, für die Sie ein Produkt herstellen, und ein Bewusstsein für die Bedeutung dieser Arbeit.
Unser Team war sehr inspiriert von den gesammelten Erfahrungen, daher planen wir, eine solche Praxis regelmäßig einzuführen - ein oder zwei Mal im Monat. Ich möchte, dass Sie ein ähnliches Treffen abhalten und sehen, was daraus wird. Viel Glück