Ein Beta-Panel ist eine Gruppe von Betrieben, die Vorabversionen einer Anwendung im laufenden Betrieb benutzen und zurückmelden, was sie beobachten. Damit das Produktteam mit den Rückmeldungen arbeiten kann, braucht das Panel Rollen, einen Rhythmus entlang der Releases und eine Rückmeldeschleife bis in das Backlog und zurück. Der Beitrag beschreibt das Muster, wie wir es für Digital Farming aufgebaut und betrieben haben, ohne Zahlen.
Ausgangslage: Rückmeldungen ohne Struktur landen nirgends
Viele Produktteams haben Kontakt zu Betrieben, die neue Versionen früh benutzen. Die Rückmeldungen kommen per Telefon an den Vertrieb, per Mail an den Support, im Gespräch auf der Messe oder über den Händler. Sie sind wertvoll und gehen verloren, weil niemand sie sammelt, einordnet und beantwortet. Ein Beta-Panel ist der Versuch, diesen Kontakt in eine Form zu bringen, in der Rückmeldungen zu Beobachtungen, Beobachtungen zu Backlog-Einträgen und Backlog-Einträge zu einer Antwort an die Betriebe werden. Nach ISO 9241-210 ist die Einbeziehung der Nutzenden über den gesamten Entwicklungsprozess ein Grundsatz; das Beta-Panel ist die Form, in der sie zwischen den Studien stattfindet.
Rollen
Vier Rollen halten das Panel am Laufen. Sie können in einer Organisation auf weniger Personen verteilt sein, aber jede Aufgabe braucht eine Zuständigkeit.
Panelbetreuung. Spricht Betriebe an, pflegt die Merkmale (Betriebstyp, Kulturen, Maschinenpark, Region), holt Einwilligungen ein, verteilt Vorabversionen, nimmt Rückmeldungen entgegen und gibt Antworten zurück. Sie ist die einzige Stelle, die mit den Betrieben spricht, damit Ansprache und Rückmeldung nachvollziehbar bleiben.
Research. Übersetzt Rückmeldungen in Beobachtungen mit Kontext: Welche Version, welche Aufgabe, welche Bedingung, welche Abweichung. Ergänzt das Panel um Feldbesuche und Sessions, wenn eine Rückmeldung nicht aus der Ferne einzuordnen ist.
Product Owner. Entscheidet, welche Beobachtungen in das Backlog gehen, in welcher Priorität, und was den Betrieben dazu gesagt wird.
Vertrieb und Support. Kennen die Betriebe und liefern Kandidaten für das Panel. Sie geben Rückmeldungen, die sie erreichen, an die Panelbetreuung weiter, statt sie selbst zu beantworten.
Rhythmus entlang der Releases
Das Panel folgt zwei Kalendern: dem Release-Zyklus des Produkts und dem Kulturkalender der Betriebe. Beide werden zu Beginn übereinandergelegt.
Vor dem Release erhalten die Betriebe die Vorabversion mit einer kurzen Beschreibung dessen, was neu ist und worauf das Team achten möchte. Während der Nutzung sammelt die Panelbetreuung Rückmeldungen über einen festen Kanal, und Research ordnet sie laufend ein. Nach dem Release erhalten die Betriebe eine Antwort: was aufgenommen wurde, was nicht und warum. Liegt ein Release in einer Arbeitsspitze der Betriebe, verschiebt sich die Rückmeldephase, nicht das Release; das Panel darf in der Ernte ruhen und wird danach wieder angesprochen.
Rückmeldeschleife bis in das Backlog
Jede Rückmeldung durchläuft dieselben Stationen. Eingang bei der Panelbetreuung mit Betrieb, Version und Datum. Einordnung durch Research als Beobachtung mit Aufgabe, Bedingung und Abweichung, oder als Frage, die einen Feldbesuch braucht. Entscheidung durch den Product Owner, mit Verweis auf die Beobachtung im Backlog-Eintrag. Antwort an den Betrieb durch die Panelbetreuung.
Der Verweis im Backlog ist der wichtigste Teil. Ein Eintrag, der auf eine beobachtete Situation verweist, wird im Team anders behandelt als ein Wunsch ohne Herkunft. In unserer Arbeit für einen Landmaschinenhersteller wurden Produktentscheidungen teamübergreifend nach beobachteter Nutzung getroffen, weil jede Entscheidung auf eine Beobachtung aus dem Panel oder aus dem Feld zurückführbar war.
Pflege zwischen Releases
Zwischen Releases hat das Panel zwei Aufgaben: die Merkmale der Betriebe aktuell halten und die Betriebe im Panel halten. Merkmale ändern sich mit Maschinenwechseln und Betriebsentwicklung. Betriebe bleiben, wenn sie Antworten bekommen, nicht zu oft angesprochen werden und eine Aufwandsentschädigung erhalten, die zum Aufwand passt. Ausscheidende Betriebe werden dokumentiert und ihre Daten nach dem Löschkonzept entfernt. Neue Betriebe kommen über Vertrieb, Support, Studien oder Empfehlung hinzu, mit eigener Einwilligung.
Grenzen
Ein Beta-Panel ersetzt weder den Usability-Test noch die Feldbeobachtung. Es liefert Rückmeldungen aus der Nutzung, die die Betriebe selbst bemerken; Umwege, die zur Gewohnheit geworden sind, bleiben unerwähnt. Deshalb ergänzt Research das Panel um Beobachtung vor Ort. Zudem ist das Panel auf die Märkte und Betriebstypen begrenzt, aus denen es besteht. Wer die Zusammensetzung des Panels nicht dokumentiert, weiß nicht, für wen die Rückmeldungen gelten.
Was danach vorliegt
Ein Beta-Panel mit dokumentierten Rollen, einem Kalender aus Release-Zyklus und Kulturkalender, einem Kanal für Rückmeldungen, einem Backlog, dessen Einträge auf Beobachtungen verweisen, und einem Pflegeplan mit Einwilligungen und Löschkonzept. Umfang und Zusammensetzung des Panels stehen im Betriebshandbuch, nicht in diesem Beitrag.