vorheriger Artikel
Eine besonders fruchtbare aktuelle Diskussion (siehe auch den Blogeintrag meines Kollegen Simon Nehls) dreht sich um die Frage, was ein Data-Science-Team eigentlich sinnvollerweise herstellt. Die beiden Möglichkeiten sind dabei schnell benannt: Auf der einen Seite steht die "Analyse", also ein einmalig erstelltes, eher statisches Endergebnis; die meisten denken hier sofort an eine PowerPoint-Präsentation. Auf der anderen Seite steht die "App", also ein interaktives, ständig mit frischen Daten versorgtes Endprodukt, häufig in Form einer Website oder einer Mobile App.
Apps auf dem Vormarsch
Bei dieser Diskussion sind die Befürworter der App momentan in der Offensive. Ihnen spielt die Tatsache in die Hand, dass das vor zehn Jahren noch von statischen Webseiten geprägte Internet immer interaktiver und dynamischer wird und damit unser aller Erwartungshaltung in Richtung der App verschiebt. Wenn mein Informationsmedium Nummer eins interaktiv und ständig aktuell ist, sehe ich nicht ein, warum das beim Output meines Data-Science-Teams anders sein sollte. Alles andere ist ja gar nicht mehr zeitgemäß. Dieses Argument ist beliebt, aber oberflächlich und pauschal. Wenn man sich ein wenig mehr Differenzierung gönnt, wird die Diskussion merklich spannender. Die App als Endprodukt verändert nämlich die Arbeitsweise eines Data-Science-Teams tiefgreifend. Dass es sich für jedes Data-Science-Team lohnt, sich auf diese Veränderung einzulassen, will dieser Blogeintrag zeigen. Es geht dabei nicht darum, sich auf die App als Arbeitsergebnis festzulegen, sondern geschickt auf der Klaviatur der möglichen Endprodukte zu spielen.
Apps sind ein Teamsport...
Wenn die Medien über den Data Scientist berichten, wird dabei häufig der Singular verwendet - möglicherweise, weil Data Scientists immer noch so selten sind, dass automatisch das Bild vom einsamen Datenhelden im Kopf entsteht. Fest steht aber: Der Data Scientist in der Einzahl produziert im Regelfall keine Apps. Die App ist meist eine Teamleistung, weil ein interaktives und dynamisches Endprodukt gegenüber der Analyse zusätzliche Kompetenzen verlangt in Webtechnologien, Softwareentwicklung und dem Design von User Interfaces. Diese Zusatzanforderungen sorgen dafür, dass die ohnehin umfangreiche Palette von Fähigkeiten, die ein Data Scientist braucht, sich so weit verbreitert, dass sie endgültig unrealistisch wird. Es braucht also mindestens zwei Kollegen mit unterschiedlichen Schwerpunkten, die arbeitsteilig zusammenarbeiten. Das einfachste Modell ist dabei ein linearer Ablauf (mit Schleifen), bei dem entlang einer Kette von Anforderungsdefinition, Datenbeschaffung, Datenaufbereitung, Modellierung, Visualisierung, Deployment (unten mehr zu diesem Stichwort) nicht mehr einer oder eine alles macht, sondern unterschiedliche Personen für unterschiedliche Teile der Kette verantwortlich sind.
...und Teamsport formt ein Team
Für die Entwicklung eines Data-Science-Teams haben Apps darum zwei sehr interessante Effekte. Der eine (naheliegendere) ist eine Veränderung der Teamkultur und Zusammenarbeit. Man ist sehr viel mehr aufeinander angewiesen, und das hilft, das Durchlaufen der klassischen Teamprozesse von Forming, Storming, Norming, Performing zu beschleunigen. Da Data-Science-Teams fast immer relativ frisch und noch im Aufbau begriffen sind, ist das ein wichtiger Aspekt.
Der andere Effekt ist wichtig für den schnellen Aufbau eines schlagkräftigen Teams: Eines der Hauptprobleme bei der Suche nach neuen Mitarbeitern im Data-Science-Bereich ist die Tatsache, dass ein Data Scientist eine sehr breite Palette von Fähigkeiten mitbringen muss. Wenn ich, zumindest wenn das Endprodukt eine App ist, ohnehin einen arbeitsteiligen Ablauf habe, dann kann ich die Arbeitsteiligkeit auch noch ein kleines bisschen weiter treiben, als das unbedingt notwendig wäre (also drei oder vier Spezialisten für eine App statt zwei oder drei), und komme zu schlankeren Anforderungsprofilen für jeden der Beteiligten. Die Chancen, jemand Passenden zu finden, werden dadurch deutlich größer werden. Ein Webentwickler (also ein deutlich weniger rares Profil) zum Beispiel kann sich durchaus in ein Data-Science-Team hineinentwickeln, wenn dieses Team häufig Apps herstellt. Er wird dadurch im Regelfall nicht zum Data Scientist, aber er trägt zur Teamproduktivität erheblich bei.
Sichtbarkeit durch Apps...
Eine gut gemachte App, die regelmäßig zu treffende, wichtige Entscheidungen unterstützt, hat eine Art Leuchtturmfunktion. Sie kann im Unternehmen nachhaltig für das Data-Science-Team werben und als greifbares Beispiel für den Nutzen der Arbeit bei Budgetdiskussionen sehr hilfreich sein. Nicht ohne Grund gibt es dort, wo Aufmerksamkeit gemessen wird und Geld bringt, einen Trend zur App: im Datenjournalismus der Onlinemedien.
Interessante Beispiele aus dem Alltag gibt es hier:
Auch öffentliche Institutionen, die ihre Arbeit vor dem Steuerzahler rechtfertigen und sich um Transparenz bemühen müssen, haben den Wert von interaktiven Apps erkannt. Da wäre zum Beispiel die schöne App zu nennen, mit der die Federal Reserve Bank of New York die geographische Verteilung der öffentlichen Ausgaben für Schulen in New York nachvollziehbar macht. Gut gemachte Apps sind unmittelbar ansprechend, es macht Spaß, mit ihnen zu arbeiten, und gerade für immer wiederkehrende Entscheidungssituationen in Unternehmen oder in der Interaktion mit Endkunden sind sie eine gute Wahl.
...und durch Analysen
Bei allen Vorteilen hat die App als Endprodukt für das Data-Science-Team auch Nachteile. Es besteht die Gefahr, dass das Team hinter dem Produkt verschwindet. Dass die Oberfläche wahrgenommen wird, aber nicht konzeptionelle Arbeit dahinter, dass die tiefe Sachkenntnis verborgen bleibt, die essentiell ist, um eine gute App zu bauen. Die Technik ist sichtbar, nicht die Kompetenz dahinter. Und es bleibt ein klassischer Bestandteil der Data Science auf der Strecke (zumindest, falls denn in unserer jungen Disziplin irgendetwas schon klassisch ist): das Storytelling. Eine interaktive App mag den Anwender "führen", aber letztlich ist sie immer eine individuelle Entdeckungsreise. Eine Geschichte aber ist ein linearer Ablauf, der ein lineares Medium braucht - die statische Analyse also. Ich weiß, dass jetzt viele aufheulen, die mit Recht darauf hinweisen, dass es sehr kluge Versuche gibt, auch das "Geschichtenerzählen in interaktiven Medien" zu erforschen und zu lehren, insbesondere im Umfeld der Videospiele. Die Tatsache bleibt jedoch, dass das ein sehr hoher Anspruch ist, der noch sehr viel schwieriger zu realisieren ist als das lineare Data Science Storytelling - ein Anspruch, der im Alltag unter Zeitdruck nur in Ausnahmefällen realisierbar ist.
Die klassische Analyse ist dort eine große Chance für die Sichtbarkeit des Teams, wo am Schluss nicht einfach eine PowerPoint-Datei verschickt wird, sondern der Data Scientist sie vorstandstauglich präsentiert. Das ist keine Aufgabe für den "reinen Techniker", sondern für den rhetorisch versierten, mit tiefem Businesswissen ausgestatteten Data Scientist mit Storytelling-Talent und analytischer Tiefe. Wenn er diese Aufgabe gut löst, kann er für die Sichtbarkeit des Teams einen Beitrag leisten, den keine App ersetzt: auf Fragen mit tiefem Wissen antworten. Gesicht zeigen. Die Kompetenz des Teams persönlich sichtbar machen. Ein Vorstand wird sich bei wichtigen Richtungsentscheidungen in komplexen Situationen nie nur allein auf "die Daten" verlassen. Die Kompetenz derjenigen, die diese Daten richtig zu befragen und zu interpretieren wissen, wird er nicht mehr missen wollen, wenn er sie einmal persönlich kennengelernt hat. Auch in dieser Weise sollte sich ein Data-Science-Team strategisch im Unternehmen positionieren.
Tempo!
Die Wahl des Endproduktes beeinflusst auch die Geschwindigkeit, mit der es geliefert werden kann. Die Analyse ist im Regelfall schneller erstellt als die App (das kommt allerdings auch auf Prozesse und Toolunterstützung an - aber das ist ein Thema für einen separaten Blogartikel). Sie kann daher Wunder wirken in Fällen, in denen sehr schnell eine Antwort hermuss. Gleichzeitig kann die App dort Last vom Team nehmen, wo absehbar ist, dass sich dringende Anfragen in ähnlicher Weise wiederholen. Es lohnt sich zudem, im Entwicklungsprozess die beiden Endprodukte miteinander zu verbinden. Die Analyse kann als Prototyp für die App dienen, und wenn man die Analysen der letzten Monate durchgeht, wird man vielleicht eine Häufung ähnlicher Aufgaben feststellen, die sich als App bereitstellen lassen.
Fazit
Es lohnt sich für jedes Data-Science-Team, die eigene "App-Fähigkeit" herzustellen und zu lernen, sowohl die Analyse als auch die App geschickt und flexibel einzusetzen. Wer sich auf eines der beiden Endprodukte festlegt, verschenkt Chancen.
