Research Operations: was im Kundenteam liegen muss

Research Operations: was im Kundenteam liegen muss

Research Operations: was im Kundenteam liegen muss

Research Operations: was im Kundenteam liegen muss

|

Verankerung

Von

leefs Redaktion

Research wird wiederholbar, wenn seine Bestandteile dokumentiert sind und im Kundenteam liegen. Dieser Beitrag beschreibt, welche Bestandteile eines Research-Betriebs so übergeben werden, dass das Team sie selbst weiterführt: Leitfäden, Auswertungsraster, Befundkatalog, Schweregradlogik, Panelverwaltung und Repository. Die Liste lässt sich in eine Beauftragung aufnehmen.

Voraussetzungen

Die Übergabe setzt voraus, dass mindestens ein Zyklus gemeinsam durchlaufen wurde und das Team dabei mitgeschaut hat. Es braucht eine benannte Person im Team, die den Betrieb übernimmt, in der Regel eine Research-Rolle oder eine Produktverantwortliche mit Zeitanteil. Und es braucht einen Ort, an dem die Bestandteile liegen: ein Repository, das mehr ist als ein Ordner mit Berichten. Die Bestandteile werden in der Reihenfolge übergeben, in der sie im Zyklus gebraucht werden.

Schritt 1: Leitfäden als Vorlagen übergeben

Was: Interviewleitfäden und Testpläne aus den gemeinsamen Zyklen werden zu Vorlagen: mit Kopfteil (Fragestellung, Nutzergruppe, Aufgaben), Ablauf und Hinweisen zur Moderation. Je Vorlage ist dokumentiert, in welchem Vorhaben sie entstanden ist und was beim nächsten Einsatz angepasst werden muss.

Warum: Ein Leitfaden ohne Kontext wird kopiert, ohne dass jemand die Fragen prüft. Mit Kontext kann das Team erkennen, welche Teile aus dem Vorhaben stammen und welche allgemein sind.

Ergebnis: Ein Satz Vorlagen für Interview und Usability-Test, den das Team ohne Rückfrage anpasst.

Schritt 2: Auswertungsraster dokumentieren

Was: Das Raster, mit dem Rohnotizen zu Befunden verdichtet werden, wird beschrieben: welche Felder eine Beobachtung hat, wie Beobachtungen zu einem Befund zusammengeführt werden, welche Regel bestimmt, ab wann eine Beobachtung ein Befund ist.

Warum: Die Verdichtung ist der Schritt, der im Ergebnis unsichtbar bleibt. Ohne dokumentiertes Raster wertet jede Person anders aus, und Befunde aus verschiedenen Zyklen sind nicht vergleichbar.

Ergebnis: Ein Auswertungsraster mit Feldern, Regeln und einem Beispiel aus einem gemeinsamen Zyklus.

Schritt 3: Schweregradlogik festlegen

Was: Die Kriterien, nach denen ein Befund einen Schweregrad bekommt, werden aufgeschrieben und kalibriert, etwa ob der Befund zum Abbruch der Aufgabe führt oder ob ein Umweg zum Ziel bleibt. Die Kalibrierung erfolgt an Befunden aus dem letzten Zyklus, die das Team gemeinsam einstuft und mit der ursprünglichen Einstufung vergleicht.

Warum: Schweregrade steuern die Priorisierung. Wenn ihre Logik nicht dokumentiert ist, wird sie beim nächsten Zyklus anders angewendet, und die Priorisierung verliert ihre Grundlage.

Ergebnis: Eine Schweregradlogik mit Kriterien und kalibrierten Beispielen.

Schritt 4: Befundkatalog als fortlaufende Liste anlegen

Was: Alle Befunde aus allen Zyklen liegen in einem Katalog mit stabiler Kennung, Status (offen, in Umsetzung, behoben, nachgeprüft) und Verweis auf die Beobachtungen, aus denen sie stammen.

Warum: Ein Befund, der nur in einem Bericht steht, wird nach dem nächsten Release vergessen. Im Katalog bleibt sichtbar, was behoben wurde und was nicht, und die Nachprüfung im nächsten Zyklus hat einen Bezugspunkt.

Ergebnis: Ein Befundkatalog, den das Team nach jedem Zyklus fortschreibt.

Schritt 5: Panelverwaltung übergeben oder abgrenzen

Was: Wenn das Team ein eigenes Panel betreibt, werden Datenhaltung, Einwilligungen, Kontaktpflege und Screening-Kriterien übergeben, mit den Datenschutzvereinbarungen, die dazugehören. Wenn der Zugang zur Zielgruppe extern bleibt, wird das ausdrücklich festgehalten: Das Team übernimmt Screening und Terminierung, der Zugang wird als eigene Leistung beauftragt.

Warum: Panelverwaltung ist laufende Arbeit. Ein Panel, das niemand pflegt, ist nach dem nächsten Vorhaben unbrauchbar. Die Entscheidung, ob es im Team liegt, hängt von der Regelmäßigkeit des Bedarfs ab.

Ergebnis: Entweder ein übergebenes Panel mit Verantwortlicher oder eine dokumentierte Abgrenzung.

Schritt 6: Repository einrichten

Was: Alle Bestandteile liegen an einem Ort, in dem sich nach Nutzergruppe, Aufgabe, Vorhaben und Befund suchen lässt. Erkenntnisse aus Interviews werden als einzelne Aussagen mit Quelle abgelegt, zusätzlich zum Bericht.

Warum: Ein Repository macht Erkenntnisse aus früheren Zyklen für neue Fragestellungen auffindbar. Ohne Repository wird dieselbe Frage im nächsten Vorhaben neu erhoben.

Ergebnis: Ein Repository mit Vorlagen, Raster, Schweregradlogik, Befundkatalog und Erkenntnissen, das das Team pflegt.

Typische Fehler

  • Die Übergabe findet am Ende statt, als Dokumentenpaket. Übergeben wird je Bestandteil, wenn er im Zyklus gebraucht wird, und das Team wendet ihn unter Begleitung einmal an.

  • Es gibt keine benannte Person. Dann pflegt niemand den Katalog, und das Repository veraltet.

  • Die Schweregradlogik wird übergeben, aber nicht kalibriert. Das Team stuft anders ein als vorher, ohne es zu merken.

  • Die Panelverwaltung wird übergeben, obwohl der Bedarf projektweise ist. Der Zugang geht verloren.

Ergebnis

Am Ende liegen sechs Bestandteile im Kundenteam, jeder mit einer Verantwortlichen und einem Beispiel aus einem gemeinsamen Zyklus. Ihr Team kann es danach selbst. Für Zugang und Spezialverfahren, die im Team nicht ausgelastet wären, bleibt eine dokumentierte Abgrenzung, die sich als Leistung beauftragen lässt. Diese Liste können Sie in eine Beauftragung aufnehmen: Jeder Bestandteil ist ein Lieferergebnis mit Übergabetermin.