Christoph Tempich

Datenprodukte bauen mit Agile Data Science

Autor: Rolf Schulte Strathaus

Produkte, die auf Datenanalyse basieren, sind speziell. Vor allem, da man „Data Scientists“ im Team braucht. Christoph Tempich von inovex wird in seinem Vortrag erläutern, woran das liegt und wie man damit umgeht.
Christoph hat letzte Woche mit Rolf von eparo vorab schon ein bisschen aus dem Nähkästchen geplaudert.

Rolf: Hallo Christoph, schön, dass es mit dem Interview klappt. Erste Frage: Was ist dein Hintergrund?
Christoph: Meine ersten Berufserfahrungen habe ich in der Beratung gesammelt. Dabei habe ich viele Projekte an der Schnittstelle zwischen IT, Telco und Business gemacht. Nach meiner Promotion im Bereich „Anwendungen von künstlicher Intelligenz“ war das damals thematisch zumindest naheliegend. Das Vortragsthema „Daten“ spielte für mich also immer schon eine sehr große Rolle. In meinen Projekten ging es oft um Fragen der Organisation und Organisationsentwicklung. Bei inovex, der Firma, für die ich seit sieben Jahren arbeite, unterstütze ich unsere Kunden beim Finden und Ausgestalten von Anwendungsfällen, zum Beispiel im Kontext der Fragestellung „Welche Implikationen haben technologische Änderungen auf die Strategie und die Organisation?“.
Das Thema Agilität spielt für einen Dienstleister wie uns, der viel Softwareentwicklung macht, natürlich immer eine große Rolle. In den meisten Projekten wird heute agil entwickelt.
Diese Themenwelten verbinde ich in meinem Vortag, da sich unsere Kunden vermehrt die Frage stellen, wie sie Data Science in ihre agile Softwareentwicklung einbinden können. Unsere Kunden wollen gerne Produkte bauen, die irgendwie aus Daten einen Mehrwert kreieren. Deshalb kommt auf einmal ein Data Scientist in das Team. Oft treffen dann zwei Welten aufeinander. Ein Kunde sagte mir mal: „Wenn ein Projekt im Produktmanagement lange dauert, dann sind das zwei Wochen.“ Und der Data Scientist würde sagen: „Wenn bei mir ein Projekt schnell geht, dann sind das sechs Monate.“ Das sind also komplett unterschiedliche Mindsets. In dieser Situation stellt sich dann die Frage, wie man die Prinzipien, die man aus der agilen Softwareentwicklung schätzt, auf die Modellierung übertragen bekommt.

Rolf: Das heißt, bei den Datenprodukten hast du einfach eine viel längere Denkphase, die man nicht runterbrechen kann? Oder wie muss ich das verstehen?
Christoph: Aus meiner Sicht erklärt sich einiges aus der Ausbildungshistorie der typischen Data Scientists. Typischerweise haben diese Menschen nämlich früher in der Forschung gearbeitet. Dort publiziert man ein Ergebnis in der Regel nicht, weil man einen Kundenprozess verbessert hat, sondern weil man eine – im Vergleich mit anderen Algorithmen – beste Lösung gefunden hat. Daraus entsteht zum Teil die Haltung, dass ein Ergebnis hervorragend sein muss, damit es überhaupt Beachtung findet. Im Produktumfeld kann eine kleine Verbesserung allerdings oft schon einen Mehrwert darstellen. Diese Perspektive versuche ich zu vermitteln. Dazu muss die Frage beantwortet werden, wie man ein Data-Science-Problem so zerteilt, dass es auch in Zwei-Wochen-Rhythmen zu Verbesserungen führt. Dabei spielt auch der Rest des Teams eine wichtige Rolle. Das Team muss es schaffen, so kleine Inkremente zu definieren, dass sie in kurzen Sprints erledigt werden können und somit auch wieder zum Kunden ausgeliefert werden können.

Rolf: Das heißt, du musst dem Akademiker beibringen, wie die wahre Welt funktioniert.
Christoph: (lacht) Letztlich, ja. Es geht aber vor allem um das wechselseitige Verständnis. Während „den Akademiker“ eher das Streben nach Perfektion auszeichnet, will der Produktmanager vielleicht erst einmal herausfinden, ob es überhaupt ein Kundenproblem gibt und wie er es lösen kann. Ein Beispiel aus unseren Projekten: Wir sind bei REWE Online in die Berechnung des angepeilten Auslieferungszeitpunktes involviert. REWE verschickt eine SMS mit dem voraussichtlichen Ankunftszeitpunkt der Lieferung. Als Data Scientist kann man da sehr viel berechnen. Zunächst muss der Produktmanager aber klären, ob der Kunde es bevorzugt, morgens um acht eine SMS zu bekommen, mit einem Lieferzeitpunkt zwischen 13:00 und 14:00 Uhr, also mit einer Stunde Unsicherheit, oder ob der Kunde eher daran interessiert ist, den Ankunftszeitpunkt sehr genau, dafür aber später am Tag zu bekommen. Es kann auch verschiedene Kundengruppen mit unterschiedlichen Präferenzen geben. Aus meiner Sicht muss der User Experience-Experte beantworten, wie das Datenprodukt beschaffen sein muss, damit es aus Kundensicht einen Mehrwert darstellt, während der Data Scientist einschätzen muss, was in einem Sprint davon zu schaffen ist und wie Iterationen aussehen könnten. Dabei kann sich auch herausstellen, dass noch Daten benötigt werden, die der Data Engineer für den nächsten Sprint schon aufbereiten kann. Manchmal braucht man auch noch Tracking-Punkte aus dem Frontend, damit Aussagen möglich werden. Es ergibt sich also ein Zusammenspiel von unterschiedlichen Personen, das durchaus iterativ, in kleinen Schritten realisiert werden kann.

Rolf: Und damit das wirklich gut funktioniert, muss eigentlich der Data Scientist auch den Nutzer verstehen, oder?
Christoph: Im besten Fall, ja. Oder der Produktmanager muss mit dem Data Scientist in einer gemeinsamen Sprache sprechen.

Rolf: Gefühlt ist es ja oft so, dass man etwas wirklich selber verstehen muss, um auch eigene Lösungsvorschläge machen zu können.
Christoph: Für mich ist dies ein Kernziel der agilen Organisation, dass durch Autarkie und Autonomie erreicht werden kann. Das Team versteht als Ganzes das Kundenproblem. Dafür werden cross-funktionale Skills benötigt. In der agilen Softwareentwicklung sind diese Skills bekannt. Für die Entwicklung von Datenprodukten haben sich die benötigten Skills noch nicht etabliert. Aktuell gibt es noch viele Teams, in denen nur Data Scientists arbeiten. In diesen Teams besteht die Gefahr, sich zu sehr auf die algorithmischen Lösungen zu konzentrieren und zu wenig das eigentliche Kundenproblem zu verstehen. Das erhöht die Gefahr von wechselseitigen Missverständnissen.

Rolf: Habt ihr damit schon Erfahrungen gemacht?
Christoph: Im Markt sehen wir die unterschiedlichsten Ansätze. Es gibt Firmen, die organisieren Data Scientists eher als Competence-Center. Dabei kommt es aber öfters zu fachlichen Missverständnissen. Für die Etablierung im Unternehmen kann das dennoch zunächst gut sein, damit das Team ein generelles Verständnis für die Datennutzung als Produkt im Unternehmen etablieren kann. Wenn dann allerdings kontinuierlich etwas in Produkte umgesetzt werden soll, ist diese Organisationsstruktur weder effektiv noch effizient. Es gibt andere Firmen, die eher „Data Product Teams“ gebaut haben, die also im agilen Sinne aufgebaut sind und die autonom agieren können. Die kommen besser zurecht.

Rolf: Was braucht es denn noch, damit diese „Data Product Teams“ funktionieren?
Christoph: Der organisatorische Anteil alleine reicht nicht, damit die Teams wirklich selbstorganisiert arbeiten können. Dazu sage ich noch mehr in meinem Vortrag.

Rolf: Dieses Fazit habe ich jetzt schon von den verschiedensten Speakern gehört. Das sollten wir auf der Working Products weiter diskutieren. Vielen Dank für das Gespräch.