03.12.2019 | Allgemein

Aus dem Tag eines Data Scientists

Er soll der „sexiest job of the 21st century“ sein: der Data Scientist. Doch wenn man sich die verschiedenen Stellenbeschreibungen unter diesem Titel ansieht, stellt sich schnell die Frage: Was macht so ein Data Scientist den ganzen Tag?

Zusammenfassung:

Was macht ein Data Scientist bei SKOPOS ELEMENTS den ganzen Tag?
Die Bandbreite an Tätigkeiten ist riesig. Abwechslung ist bei uns garantiert.

Die Breite der mit „Data Science“ beschriebenen Rollen ist enorm groß. Insofern kann ich in diesem Artikel nur beispielhaft beschreiben, wie wir bei SKOPOS ELEMENTS arbeiten und was einen Data Scientist bei uns erwartet.

Eines kann ich direkt vorwegnehmen: Der Job ist super vielseitig und kann bei uns sehr unterschiedliche Facetten umfassen. Da wir als Beratung hauptsächlich in Projekten tätig sind, hängt es dabei natürlich auch davon ab, womit wir uns im Detail beschäftigen. Das bringt nochmal zusätzliche Abwechslung in den Alltag. Nicht immer ist es dann Deep Learning, aber dafür lernt man immer wieder neue Fragestellungen, neue Daten und vor allem auch neue Methoden kennen.

Vormittag

08:45 Uhr — Ankunft im Büro. Erstmal gilt es, sich einen Überblick zu verschaffen und den Tag zu strukturieren. Heute stehen sowohl einige Meetings an, als auch ein paar inhaltliche Arbeiten. Die Kopfhörer mit Noise Cancelling werden nach der morgendlichen Bahnfahrt nochmal an den Strom angeschlossen, um später einsatzbereit zu sein.

09:00 Uhr — Letzte Nacht kam es wohl bei der automatischen Aktualisierung einer Datenbank zu einem Fehler. Ich schaue direkt nach, woran es lag. Der Fehler ist schnell gefunden (ein Sonderzeichen kam nicht korrekt enkodiert bei uns an und wurde anschließend an eine API geschickt, die damit nicht arbeiten konnte) und behoben. Prozess neu angestoßen – erstes Problem für diesen Tag gelöst.

09:30 Uhr — Für ein neues Projekt konzipieren wir derzeit ein Dashboard. Nachdem eine grobe Skizze für die Inhalte, Darstellungsweisen und Filter gefunden wurde, gilt es jetzt, das entsprechende Datenmodell zu definieren. Wir stimmen uns im Team ab, welche Datenfelder wir benötigen und wie wir den Datensatz strukturieren. Hierbei kombinieren wir Befragungsdaten, das dazugehörige Codebuch und externe Daten. Beispielsweise nutzen wir die Geo-Koordinaten von untersuchten Standorten, um sie auf einer Karte darzustellen. Die Zusammenführung und Aufbereitung der Daten werden wir in Alteryx umsetzen, das Dashboard dann in Tableau. Erfahrungsgemäß kommt es immer mal wieder zu Änderungswünschen, sodass wir sicherlich in Kürze nochmal zusammensitzen und das Datenmodell anpassen werden.

10:15 Uhr — Die Kopfhörer sind aufgeladen und kommen auf die Ohren. Es gilt Python-Code zu schreiben. In einem Proof-of-Concept konnten wir zeigen, dass unsere Textklassifikation auf Basis eines Convolutional Neural Network (CNN) funktioniert. Ein CNN ist eine Form eines neuronalen Netzes, also grob gesagt ein Algorithmus, der den Verschaltungen eines Gehirns nachempfunden ist. Nach dem erfolgreichen Proof-of-Concept wollen wir das nun in das Live-Projekt implementieren. Auf diese Weise kann die Klassifikation nahezu live von unserem Kunden eingesehen werden. Das Modell haben wir in der Python-Bibliothek Keras umgesetzt und nun geht es darum, das Modell in unsere Alteryx-Workflows einzubinden. Dazu schreibe ich an einem eigenen Tool für das sogenannte Python SDK. Über diese Schnittstelle können wir sehr frei eigene Tools entwickeln und in unseren Workflows nutzen. Leider ist die Dokumentation des SDK nicht immer so richtig hilfreich, also ist immer ein wenig Recherche notwendig. Am Ende habe ich einen Zwischenstand, bei dem ich gerade nicht so richtig weiterkomme, sodass ich mich anderen Themen zuwende.

11:45 Uhr — Wir haben bis Ende der Woche ein Angebot für eine Anfrage versprochen, an das ich mich als nächstes setze. Hier ist noch ein wenig Ruhe vonnöten, deswegen bleiben die Kopfhörer auf. In der Anfrage ging es um die Verbindung von Befragungs- und CRM-Daten. Es gibt bereits eine Kundensegmentierung aus der Marktforschung, die nun für eine bessere Ansprache von Kunden in das CRM überführt werden soll. Problem: Es gibt keine Zuordnung zwischen Befragten und Kunden im CRM. Aufgrund des Vorgesprächs haben wir bereits eine Vorstellung von den Daten, die sowohl aus der Befragung als auch im CRM vorliegen. Ich schreibe ein erstes Konzept, wie man die Brücke zwischen den Daten schlagen kann. Am Ende gibt es noch ein paar offene Punkte, die ich mir für ein kurzes Telefonat mit dem Kunden am nächsten Tag vornehme.

Mittagspause

13:15 Uhr — Seit ein paar Wochen steht einmal wöchentlich ein Food-Truck auf dem Gelände, der unter anderem Burger oder auch vegane Gerichte anbietet. Oft trifft man sich im Esszimmer und plaudert mit Kolleginnen und Kollegen auch aus den anderen Units oder spielt eine Runde Kicker. Bei gutem Wetter kann man aber auch gut draußen die Pause machen und noch eine Runde ums Gelände laufen. Die Kopfhörer liegen natürlich inzwischen wieder auf dem Schreibtisch — jetzt will man ja die Kollegen möglichst gut hören können.

Nachmittag

14:00 Uhr — Es ist Zeit, mal wieder wirklich analytisch aktiv zu werden. Eine Kollegin fragte vor einiger Zeit, ob wir uns eine smarte Analyse von Befragungsdaten überlegen könnten. Auf Basis der Daten erscheint ein Mehrebenen-Modell sinnvoll: Die Daten sind einigermaßen hierarchisch und wir könnten in der Analyse vom sogenannten Shrinkage profitieren, da einige Level weniger Fallzahlen aufweisen. Die Datenaufbereitung hatte ich in R vor ein paar Tagen schon angefangen, jetzt überlege ich mir eine Beschreibung des Modells und versuche, einen ersten Modell-Prototypen mit dem R-Package brms zu entwickeln. Leider komme ich heute damit nicht ganz so weit, wie gehofft und nehme mir vor, morgen daran weiter zu arbeiten.

15:00 Uhr — Wöchentlich treffen wir uns mit einem unserer größten Kunden zum telefonischen Jour fixe und besprechen den aktuellen Stand des Projekts. Das Projekt führen wir in Kooperation mit einer anderen Unit der SKOPOS-Gruppe durch. Wir geben also insbesondere ein Update über den aktuellen Stand bei der Weiterentwicklung der Reporting-Dashboards. Anschließend reflektieren wir intern das Gespräch und priorisieren und verteilen Aufgaben.

16:00 Uhr — Einmal im Monat treffen wir uns zum Analytics Jour fixe und besprechen eine Methode, ein Paper oder ein Learning aus einem Projekt. Heute sprechen wir über Zeitreihenanalysen und Facebooks Prophet-Bibliothek. Schnell stellen wir fest, dass wir das zugrundeliegende GAM (General Additive Model) für unsere Zwecke adaptieren könnten. Da wir in einem Projekt ohnehin Zeitreihenanalysen nutzen, wäre das die ideale Gelegenheit, das mal auszuprobieren.

17:30 Uhr — Der Feierabend nähert sich. Ein paar E-Mails sind in den letzten zwei Stunden dann doch noch eingegangen, die jetzt noch abgearbeitet werden wollen, bevor es zurück nach Bonn geht. Ich mache mir Notizen, womit ich mich morgen früh als Erstes beschäftigen werde. Bisher sieht der Terminkalender noch recht leer aus – es verspricht ein Tag zu werden, an dem ich mich tiefer in Code einarbeiten kann, als das heute möglich war.

Fazit:

Das war sicherlich ein besonders vielseitiger Tag! Und nicht jeder Tagesablauf ist immer so strukturiert. Manchmal ergeben sich Meetings spontan oder Zeiten stehen ganz im Zeichen eines einzelnen Projekts. Solche Phasen sind immer gut, um über mehrere Stunden tiefer in R, Python oder Alteryx einzutauchen. Klar, ich habe jetzt sicherlich mehr Kundenkontakt als jüngere Kolleginnen oder Kollegen im Team und es hängt auch immer von den aktuellen Projekten ab, was derzeit so ansteht. An manchen Tagen gibt es zum Beispiel auch Besuche oder Workshops beim Kunden vor Ort, sodass hier noch Reisezeit hinzukommt (in der man dann zum Beispiel Artikel für DataAnalyst.eu schreiben kann). Der beschriebene, idealtypische Tag ist aber auf jeden Fall ein Querschnitt durch die verschiedensten Aufgaben, die man bei uns so erleben kann. In anderen Unternehmen oder Branchen mögen Routinen auch nochmal ganz anders aussehen.

Was dieser Tag aber auf jeden Fall zeigt: Die Aufgaben können sehr vielfältig sein und umfassen nicht nur das Schreiben von Code in dunklen Kellerräumen. Neben ganz verschiedenen Aufgaben bei der Datenaufbereitung, -analyse und -visualisierung gibt es auch immer Abstimmungen mit Kollegen und Kunden. Das ist sicherlich nicht in jedem Data Science Team so relevant wie bei uns. Als Beratung ist das aber ein wichtiger Teil unserer Tätigkeit und macht den Job so abwechslungsreich.

Jeder hat eigene Vorstellungen davon, was einen Job „sexy“ macht. Aber Abwechslung, das Arbeiten mit und Analysieren von Daten und jeden Tag auch etwas Neues zu lernen, sind Dinge, die für mich persönlich absolut dazugehören. Das kann der Beruf des Data Scientists bestimmt bieten. Und die große Breite an Themen und Schwerpunkten hinter dieser Job-Bezeichnung ermöglicht es auch, dass man seine eigenen Schwerpunkte setzen kann: Während ich meinen Schwerpunkt eher auf dem Thema Datenanalyse habe, setzen sich andere Kolleginnen und Kollegen eher mit der Kommunikation und Visualisierung der Ergebnisse oder der Anbindung von Datenbanken auseinander.

Mir persönlich macht die Abwechslung zwischen verschiedenen Arbeitsweisen, Methoden und Projekten sehr großen Spaß. Man lernt in jedem Projekt immer etwas Neues und wird bei uns nie den Satz hören „Das haben wir schon immer so gemacht“. In meinem Fall ändert sich der Job gerade enorm, da durch die Gründung von SKOPOS ELEMENTS neben den operativen Tätigkeiten noch weitere Aufgabengebiete abseits von Data Science hinzukommen. Aber zusammen mit Basti, meinem Mitgründer und Co-Geschäftsführer, sind wir immer Spielertrainer: Wir arbeiten beide noch intensiv an Projekten mit, weil es uns immer Spaß bereitet und uns zwingt, auch inhaltlich immer auf dem neuesten Stand zu sein.

Dieser Artikel ist zuerst im Blog von DataAnalyst.eu erschienen.

Blog von DataAnayst.eu