SKOPOS GROUP

Wir sind ein Teil der SKOPOS GROUP für zeitgemäße Marktforschung.

Eine breit aufgestellte Unternehmensgruppe, die alle zeitgemäßen Marktforschungs-Dienstleistungen unter einem Dach vereint. Digital und innovativ. Von national bis international. Von Kunden-Befragung über UX-Research bis Insight-Community. Von Mitarbeiter-Befragung über Mystery-Shopping bis Customer-Experience und Data Science decken wir alle relevanten Themen und Methoden ab.

Journal Nützliches Wissen aus der Welt der Data Science
Data Thinking

Design Thinking + Data Science = Data Sprints

Wenn es um die Entwicklung von Datenprodukten geht, sitzen oft viele Abteilungen, Nutzergruppen und Stakeholder in einem Boot. Dennoch sollen Entwicklungsphasen kurzgehalten werden. Mit unseren Data Sprints unterstützen wir Dich, in kurzer Zeit Prototypen für Datenprodukte zu entwickeln. Hier erzählen wir Dir wie das funktioniert!

Zusammenfassung:

  • Datenprodukte können Pipelines, Analysen oder Reportings sein: Wann immer Daten zielgerichtet eingesetzt werden, entstehen Datenprodukte.
  • Data Scientists, Entwickler, Nutzer, Budgetverantwortliche: Es gibt viele, die bei der Entwicklung von Datenprodukten involviert sind. Mit Sprints bekommst du alle an einen Tisch.
  • In fünf Tagen von der Fragestellung zum Prototyp: Die agile Methode des Data Sprints macht es möglich.
  • Im Data Sprint verbinden wir agile Methoden aus dem Design Thinking mit Expertenwissen zu Data-Science-Lösungen.

Was sind überhaupt Datenprodukte?

Wir sprechen von Datenprodukten (Data Products) immer dann, wenn wir Daten zielgerichtet zur Beantwortung einer Fragestellung einsetzen und dafür „etwas“ entwickeln, das dann in der Folge nutzbar ist.

Hier drei Beispiele:

Das kann eine Daten-Pipeline sein, um Daten aus Deinem CRM in Dein Business Data Warehouse zu überführen. Bei dieser Pipeline werden vielleicht Daten restrukturiert, nur aktive Kunden übernommen und neue Felder angelegt. Um diese Pipeline aufzusetzen müssen inhaltliche und technische Anforderungen abgestimmt und der genaue Prozess definiert werden. Es gibt also Abstimmungsbedarf.

Ein zweites Datenprodukt wäre ein Machine-Learning-Modell, zum Beispiel zur Erkennung von fehlerhaften Ergebnissen in der Produktion: Mittels Kamera werden die Produktionsergebnisse fotografiert und ein Modell wertet automatisch aus, ob das Produkt qualitativ hochwertig genug ist, um ausgeliefert zu werden. Hier ist das Modell das Datenprodukt, weil es das Ergebnis unseres Projekts ist. Die Entwicklung eines solchen Modells erfordert dabei viel Abstimmung zwischen Data Scientists, Produktmanagern, Produktionsleitern und anderen Beteiligten.

Letztlich kann auch ein Dashboard ein Datenprodukt sein: Auch wenn hier Ergebnisse über eine Daten-Pipeline und ein Machine Learning-Modell erst entstehen. Denn, wenn das Ergebnis für unseren Kunden primär das Dashboard ist – und damit die Visualisierung von Ergebnissen oder Modellvorhersagen – arbeiten wir darauf hin, das Dashboard als Endprodukt zu betrachten. Neben Abstimmungen zur Daten-Pipeline und zum Modell gilt es hier sich mit den künftigen Nutzern des Dashboards über Look & Feel und Funktionalitäten abzustimmen.

Es gibt also verschiedene Formen von Datenprodukten, die sich in Umfang und Komplexität unterscheiden können. Allen Datenprodukten ist aber, wie bei jedem Produkt, gemein, dass es verschiedene Teams und Abteilungen gibt, die bei der Entwicklung eine Rolle spielen. Also gibt es Abstimmungsbedarf, damit die Entwicklung des Datenprodukts kein Zeitgrab wird.

Wenn es um Produktentwicklung im digitalen Zeitalter geht, ist man schnell beim Thema Agilität und agile Methoden. Und was in Software Entwicklung und Design gut funktioniert, funktioniert auch bei Data Science sehr gut. Daher unterstützt uns die Data Sprint­-Methode dabei, effektiv und effizient Datenprodukte zu entwickeln. Gemeinsam mit unseren Kollegen von der SKOPOS NOVA wollen wir Dir diese Methode heute vorstellen:

Der Data Sprint

Der Data Sprint lehnt sich an das Konzept des Design Sprints an: Innerhalb von fünf Tagen soll ausgehend von einer Fragestellung ein Prototyp für eine Lösung entwickelt werden. Die Lösung soll dabei die Anforderungen von unterschiedlichen Stakeholdern so wie die Perspektive der künftigen Nutzer berücksichtigen. Bei einem Data Sprint spielt zusätzlich das Thema Daten eine entscheidende Rolle: Ein Review der bestehenden Daten (Welche Daten haben wir bereits? Und wie können wir sie nutzen?) ist dabei ein wesentlicher Bestandteil der Vorbereitung und des Sprints selber.

Aber was heißt nun „Sprint“? Rennen wir vom Foyer bis zur Kantine? Natürlich nicht – es geht darum, in kurzen intensiven Einheiten auf die Lösung hinzuarbeiten. Dabei gliedert sich der Data Sprint in mehreren Phasen:

Fünf Phasen des Data Sprints: von der Fragestellung bis zum Testen und Evaluieren des Prototypes.

Jede dieser Phasen bringt uns näher an die Umsetzung in Form eines Prototyps heran. Während wir zu Beginn des Sprints gemeinsam das Ziel und die Fragestellung schärfen, gehen wir ziemlich schnell vom „Was?“ zum „Wie?“. Dabei gilt es Entwickler und Nutzer zu Wort kommen zu lassen und Entscheider einzubeziehen. Denn genau darum geht es zur Mitte des Sprints: Entscheidungen darüber zu treffen, was in einem Prototyp umgesetzt werden soll.

Während bei einem klassischen Design Sprint nun innerhalb eines Tages der Prototyp entwickelt wird, kann dies – je nach Datenprodukt – beim Data Sprint auch ein paar Tage mehr in Anspruch nehmen. Doch beiden gemein ist, dass die Anforderungen für den Prototypen zuvor in Workshop-Format gemeinsam entwickelt und abgestimmt wurden. Und dass der Prototyp kein fertiges Produkt ist: Hier mag es noch Ecken und Kanten geben und manche Features nur Platzhalter sein. Am Ende soll es aber die Anforderungen aus dem Sprint abbilden – und so den zukünftigen Nutzern (und allen anderen, die im Prozess des Data Sprints beteiligt waren) ein Bild davon vermitteln, wie die fertige Lösung aussehen könnte.

Testet man dies dann in einer geeigneten Zielgruppe – entweder ganz systematisch mittels Usertests oder durch Interviews mit den Beteiligten – erhält man wertvolles Feedback, das für die weitere Entwicklung wichtig ist.

Auf diese Weise erhält man innerhalb von nur einer Woche Ergebnisse, die sonst mehrere Wochen oder gar Monate in Anspruch nehmen würden. Ganz schön agil also. Wenn die richtigen Leute beim Sprint dabei sind, ist auch der Weg zur Akzeptanz der Lösung schon vorgeebnet.

Das Sprint-Team

Doch wer sollte beim Sprint dabei sein? Das Sprint-Team sollte maximal 6-7 Leute umfassen, die hauptsächlich mit dem Projekt oder der Fragestellung beschäftigt sind. Sie sollten Experten für das Produkt selber sein und Entscheidungen über die nächsten Schritte treffen können.

In solchen Projekten gibt es darüber hinaus aber noch Experten, die mit dem Produkt selber nicht so viel zu tun haben, aber an anderen essentiellen Stellen arbeiten. Beispielsweise die Architekten des Data Ware House (DWH) in der IT-Abteilung. Solche Experten nehmen auch am Sprint teil – aber häufig nur in einzelnen Sessions.

Genauso gibt es häufig Bereichsleiter oder Budget-Verantwortliche, die die Entscheidung darüber treffen wie es mit dem Prototyp weitergeht. Diese Teilnehmer müssen im Sprint dabei sein und zumindest bei ausgewählten Sessions teilnehmen. Wenn kein Entscheider im Sprint mit dabei ist, stirbt im schlimmsten Fall jede noch so gute Idee. Die aktive Beteiligung von Kollegen, die am Ende über die Idee entscheiden, sorgt für frühe Einigkeit über Ziele und die Wege dorthin.

„Kurz gesagt: Ein Sprint-Team muss aus verschiedensten Disziplinen und Hierarchien zusammengesetzt sein, damit die Ergebnisse des Sprints auch langfristig erfolgreich sein können.“

Während Entscheider und ausgewählte Experten nicht an allen Tagen dabei sein müssen, nimmt das Sprint-Team hingegen am gesamten Sprint teil. Das Sprint-Team sammelt das Wissen von zusätzlichen Experten in Interviews – zum Beispiel um die Fragestellung weiter zu präzisieren oder die Machbarkeit einzelner Features zu prüfen –, trägt es zusammen und bereitet Vorschläge und Ideen vor, über die am Ende gemeinsam mit Budget-Verantwortlichen und Entscheidern abgestimmt wird.

In der Vorbereitung des Data Sprints wird genau überlegt, wer zum Sprint-Team dazu gehören soll und welche Experten im Sprint befragt werden sollen. Die Vorbereitung ist also mindestens genauso wichtig wie der Sprint selber.

Fazit

Data Sprints sind eine großartige Methode, um innerhalb von kurzer Zeit von einer Fragestellung zu einem Prototyp für ein Datenprodukt zu kommen. Egal, ob es sich dabei um eine Daten-Pipeline, eine Analyse, ein Vorhersagemodell oder ein Dashboard handelt: Die Einsatzzwecke der Methode sind so vielfältig wie die Möglichkeiten auf Basis von Daten Entscheidungen zu treffen. Während manchmal die Idee existiert nur im Chaos können neue Lösungen entstehen, zeigt die Data Sprint-Methode: Durch einen Rahmen, in dem Kreativität und systematisches Vorgehen zusammenspielen, können großartige Produkte entstehen.

Wenn Du jetzt Lust hast, dein nächstes Data Science-Projekt mit Unterstützung eines Data Sprints zu entwickeln: Dann sprich uns an! Wir passen die Methode auf Dich, Deine Fragestellung und Dein Team an, damit du in vier Tagen einen großartigen Prototyp entwickeln kannst!

Du möchtest ein Data Science-Projekt agil entwickeln?

In vier Tagen mit deinem Team von Fragestellung zu ersten Ergebnissen?
Dann melde dich bei uns!

Warum mit uns?
Deine Anfrage

Unser hochmotiviertes Team freut sich, von Dir und Deiner Fragestellung zu hören.

  • Hidden
  • Hidden

Mehr lesen?