Ich habe mit vielen Kollegen aus der Analysebranche gesprochen, die unbedingt wollen, dass ihr Team niemals die „Produktion“ berührt. Es gibt zwar gute Gründe, vorsichtig zu sein, wenn man Änderungen vornimmt, die sich auf die Kunden auswirken könnten, aber ich glaube, dass es in dem Maße, in dem Software immer datengesteuerter wird, entscheidend ist, sichere Wege zu finden, um Analyseteams in die Lage zu versetzen, datengesteuerte Anwendungen zu erstellen und bereitzustellen.
Was ist Produktion?
Zunächst eine Begriffsdefinition. „Produktion“ ist eine Umgebung. In der Regel gibt es mehrere Umgebungen, in denen der Code ausgeführt werden kann (in der Reihenfolge ihrer Entstehung):
- Lokale Entwicklung
- Fernentwicklung
- Staging / QA
- Produktion
Jede „Anwendung“ hat mehrere Umgebungen, von denen eine diejenige ist, die für Nicht-Entwickler bestimmt ist. Die Umgebung für Nicht-Entwickler wird in der Regel „Produktion“ genannt.
Hier ist meine These: Es ist entscheidend, dass die Analyseteams Einfluss auf die kundenorientierten Anwendungen nehmen.1 Natürlich gibt es Ausnahmen, und verschiedene Arten von Anwendungen haben einen unterschiedlichen „Grad“ an Datenabhängigkeit. In der Vergangenheit haben einige Unternehmen gezögert, ihre Anwendungen datengesteuerter zu machen, weil ihre Software-Ingenieure nicht über die nötigen Datenkenntnisse verfügten und sich nicht trauten, das Analyseteam die Anwendung beeinflussen zu lassen. Sie sollten natürlich Entscheidungen über das Hinzufügen neuer Funktionen auf der Grundlage ihres Nutzens treffen und nicht nur, weil irgendein Blogger Ihnen das empfohlen hat. Wenn es nicht möglich ist, dies auf sichere Weise zu ermöglichen, dann sollten Sie Ihre kundenorientierte Anwendung so ändern, dass dies möglich ist.
Wenn Sie diesen letzten Absatz schockierend fanden, dann werde ich Sie jetzt von den Socken hauen: Alle Ihre Analysten arbeiten bereits jeden Tag in der Produktion. Lassen Sie mich mit Ihnen meinen liebsten2 und unausstehlichsten Satz durchgehen. Die Leute lieben mich auf Partys. Fragen:
- Das BI-Tool, das Sie konfigurieren, um den Benutzern in Ihrem Unternehmen Berichte zur Verfügung zu stellen – ist das nicht produktiv?
- Das R-Skript, das Daten zusammenstellt, sie bereinigt und Visualisierungen für eine PPT bereitstellt, die an das Führungsteam gemailt wird – ist das nicht produktiv?
- Die Excel-Datei (mit Code), die verwendet wird, um eine millionenschwere Bestandsentscheidung zu treffen – ist das nicht produktiv?
Erinnern Sie sich: Nur weil Sie keine Entwicklungsumgebung haben, bedeutet das nicht, dass Ihre Benutzerumgebung nicht produktiv ist!
Viele Startups verwenden „produktiv“ als Abkürzung für ihre benutzerseitige Webanwendung (je nach Unternehmensstadium kann es sich um einen Rails-Monolithen handeln oder auch nicht). Ich möchte nicht nur darauf hinweisen, dass Sie aufhören sollten, solch unklare Begriffe zu verwenden, sondern auch dafür plädieren, darüber nachzudenken, warum Sie Analysten und Datenwissenschaftler, die keine Ingenieure sind, in die Lage versetzen wollen, eine kundenorientierte Anwendung bereitzustellen. Abschließend möchte ich Ihnen einige Strategien vorstellen, wie Sie dies umsetzen können.
Warum das Analyseteam befähigen, auf die Kunden einzuwirken?
Der Aufbau datengesteuerter Anwendungen ist für das moderne Software-Engineering und die Produktentwicklung unabdingbar. Die Anwendungen von morgen werden von vorne bis hinten datenintegriert sein, und wenn es eine Mauer zwischen Ihren Datenexperten und Ihren Anwendungsentwicklern gibt, werden Sie eine schlechte Zeit haben.
Hier sind einige Beispiele für datengesteuerte Produkte, die Sie vielleicht entwickeln möchten:
- Einführung von Thompson-Stichproben für mehrarmige Bandit-Tests von Website-Varianten
- Cluster von Kunden für gezielte Marketing-E-Mails oder Landing-Page-Varianten
- Vorhersage von Kunden, die wahrscheinlich abwandern, und Vergabe eines Gutscheincodes an nur diese Kunden
- Einführung von Produktempfehlungs-/Suchranking-Algorithmen
Wenn Sie diese datengesteuerten Produkte entwickeln möchten, sollten Ihre Datenexperten daran arbeiten. Hier einige Gründe, warum Sie darüber nachdenken sollten, die Grenzen zwischen Ihrem Analytics3Wie üblich verwende ich in diesem Beitrag die Begriffe „Analytics“ und „Analysten“ im weitesten Sinne, d. h. für Datenwissenschaftler, Datenanalysten und andere Datenexperten. team und dem Rest Ihres Softwareentwicklungsteams zu verwischen:
- Datenwissenschaftler sind Ihre Algorithmenexperten, und kontinuierliche Integration ist wichtig
- Sie wollen, dass Ihre App von Daten angetrieben wird!!
- Datenwissenschaftler kennen die Daten am besten, daher ist es unwahrscheinlich, dass sie Fehler machen
- Die Arbeit eines anderen zu produzieren ist ein Scheißjob
- Die Iteration von Analysen durch eine enge Priorisierung zu blockieren, verlangsamt alle und führt zu Frustration
Es ist unumstritten, dass Produktmanager oder Designer neue Inhalte über ein CMS auf der Website bereitstellen. Wenn dies Markdown unterstützt, sollte es auch trivial sein. Auch Analysten können über ein CMS die Gewichtung von Algorithmen ändern. Warum sollten sie also nicht auch ein Modell bereitstellen können, solange dieses Modell mit der API übereinstimmt, die die App erwartet? Da Ihr Analyseteam möglicherweise nicht über alle Tools oder Fähigkeiten für die Arbeit an einer komplexen Webanwendung verfügt, möchten Sie natürlich sicherstellen, dass es diese Änderungen auf sichere und effektive Weise vornehmen kann (d. h. es kann die Tools verwenden, mit denen es vertraut ist, und die anderen Teile werden abstrahiert).
Wie kann das Analyseteam die Kunden beeinflussen?
Nachdem wir nun erörtert haben, warum dies eine gute Idee sein könnte, können wir über einige Möglichkeiten sprechen, wie dies sicher und effektiv geschehen kann. Hier sind einige Beispiele, die ich in der Vergangenheit gesehen habe (und ich würde mich freuen, wenn Sie weitere gute Muster kennen):
- Mikrodienste
- Der Algorithmus für das Produktranking kann hinter einer API leben, so dass das Analyseteam Änderungen vornehmen kann, ohne den Rest der App zu berühren
- Benutzerprofile
- Sie können wichtige Benutzerattribute in einer Tabelle aufbewahren, auf die Ihre Web-App Zugriff hat (z.g., über einen Redis-Cache), die vom Analyseteam verwaltet wird (ETL, ML, was auch immer, solange sich die API nicht ändert)
- Gewichte / Scores
- Wenn Sie ein Modell haben, das mit Gewichten oder Attributen arbeitet, um einen „Score“ zu erstellen (z.B., eine Betrugsrisikobewertung), dann können Sie diese Gewichtungen in einer Tabelle speichern, auf die das Analyseteam schreibend zugreifen kann
Ich habe schon früher über das Code-als-Konfiguration-Designmuster geschrieben, und im Allgemeinen ist dies ein großartiges Muster, um Nicht-Ingenieure in die Lage zu versetzen, Code sicher in Produktionsumgebungen einzusetzen. Harlan Harris, ein Freund des Blogs, hat auch über die Verwendung domänenspezifischer Sprachen geschrieben, um das Testen, Koordinieren und Bereitstellen von Modellen für maschinelles Lernen in der Produktion zu erleichtern.