In Organisationen sind wir es gewohnt, mit Strukturen und Prozessen zu arbeiten. Egal ob hierarchisch oder flach, es gibt klare Verantwortlichkeiten mit Abgrenzungen, Schnittstellen und Übergabepunkten. Wir malen Prozessdiagramme mit Rollen, die ihre Aufgaben nacheinander oder nebeneinander zu erledigen haben. Als Übergabemedien fungieren in der Regel Daten. Das können einzelne Events sein, Informationen über ein Ergebnis oder ganze Dokumente, die einen bestimmten Status erreichen.
So fand ich mich bei der Vorbereitung von Janine Ellners und meiner Vortragsreihe „DDC Meets Change“ wieder, als ich solche Diagramme erstellte. Weitere Informationen zu Datadriven Company findet ihr hier im Cattle Crew Blog oder in einem Beitrag im BI Spektrum . Für die Ausgangssituation gelang mir das gewohnt leicht. Die Fachseite stellt einen Anforderungs-CR, eine User-Story, erstellt vom Product Owner geht daraus hervor und wird an die Entwickler übergeben. Am Ende des Sprints kommt ein Produktinkrement dabei heraus. Das geht zurück an die Fachabteilung, die dann übernehmen soll. Einfach, sequenziell und das Sinnbild des agilen Stille-Post Analytics-Kreislaufs. Die Fachseiten dürfen dann mal gucken, was für eine Kennzahl entstanden ist und wie man diese nutzt.
Hürden und wie man sie überwindet
Um genau die Hürden, die damit verbunden sind aufzulösen, hat Janine mit ihren Kollegen im Kundenprojekt ein Vorgehen erarbeitet, das mehr als Miteinander gestaltet ist: Im besten Fall wird nicht nur eine User-Story unter dem Türschlitz hindurch ins Refinement Meeting geschoben. Sondern der Anforderer kommt gleich mit dazu (durch die geöffnete Türe, wenn möglich). Product Owner, Entwickler und Anforderer sitzen an einem Tisch, konzipieren, priorisieren, schätzen gemeinsam. Während der Entwicklung unterstützt man sich bei Rückfragen. Nach der Entwicklung von Datenhaltung, Datenaufbereitung, Kennzahlen und Dimensionen geht es gemeinsam an die Auswertung. Egal ob klassischer Report, Dashboard oder erste Ad-hoc Analysen. Im Pairing zwischen Entwicklern und Fachseite soll gemeinsam das erste Outcome produziert, die ersten Analysen erstellt und die ersten Erkenntnisse interpretiert werden. Der Entwickler wird zum Coach für das, was er gebaut hat. Zum „You build it, you run it“, was man DevOps Teams gerne andichtet, kommt ein „We built it, we celebrate it” zwischen Entwickler und Fachseite dazu. Die Inhalte entstehen gemeinsam.
Der Versuch, das mit unseren gängigen Prozessdiagrammen darzustellen, misslang mir völlig. Ein „normales“ Prozessdiagramm brachte die Message kaum rüber. Ich habe herumgeschoben, weitere Beziehungspfeile eingezeichnet und am Ende war ein urhässliches Prozess-Ei geboren, maximal unleserlich und unverständlich. Aus Jugendschutzgründen habe ich es irreversibel entfernt und kann es an dieser Stelle leider nicht zeigen. Nach weiteren versuchen und vernichtendem Feedback der KollegInnen folgte ich einer Eingebung und malte ein Yin-Yang Symbol in den Farben, die in unserem Vortrag Entwickler und Fachseite repräsentierten, um das Miteinander dieser oft gegensätzlich anmutenden Rollen darzustellen. Der klassische Punkt auf der jeweils anderen Seite gefiel mir sofort, denn er impliziert etwas ganz wichtiges, damit oben beschriebene Arbeitssymbiose gelingen kann: Das Gegenseitige lernen und sich annähern. Die Empathie für die andere Seite.
Beide Seiten im Detail
Ein Fachbereich, der nicht nur Self-Service können, sondern auch Refinements beiwohnen soll, braucht zumindest ein rudimentäres Verständnis dafür, wie Kennzahlen und Dimensionen funktionieren, wie man Dinge über Zeitbezüge auffächern kann und welche Rolle Granularitäten in semantischen Modellen bedeuten. Er braucht aber auch ein Stück Verständnis für Aufwände, die aus technischen Schulden oder Datenschutzanforderungen entstehen und nicht immer direkten Mehrwert bieten.
Ein Entwickler sollte sich auf der anderen Seite davon lösen, ein „null“-Value nur als technisch zu behandelndem Vorkommnis zu werten, sondern die Bedeutung interpretieren und im besten Fall übersetzen: Haben wir keine Informationen über den Kündigungsgrund, weil der Kunde ihn nicht angeben wollte, oder wurde der Kunde gar nicht erst gefragt? Wie können wir zu einer schlüssigen fachlichen Aussage kommen? Steckt mehr dahinter als nur „Die Daten sind halt nicht da?“. Es ist wichtig zu verstehen, für wen entwickelt wird. Für einen versierten Nutzer, der sich viele Freiheiten wünscht und gerne selbst filtert? Oder für einen Nutzer, der möglichst schnell und einfach eine Kennzahl hinzuziehen möchte, in der alle Storni und uninteressanten Status bereits gefiltert sind? Ein Geldautomat wird für ein breites Publikum designt und kommt schließlich ohne Linux-Konsole als Frontend daher, selbst wenn man damit weniger Entwicklungskosten hätte und evtl. flexibler in der Bedienung wäre. Das leuchtet ein. Software wurde spätestens mit dem Siegeszug von Smartphones immer intuitiver wo es nötig war und es gibt heute für jede Zielgruppe oder Persona ein passendes Human-Computer-Interaction Design auf den Endgeräten. Die Zielgruppe und deren Fertigkeiten wird bei jeder neuen App und Software mitgedacht. Wieso tut man dies nicht auch bei den Daten?
Was kann man aus Yin und Yang lernen?
Zurück zum Yin-Yang: Jeder bleibt auf seinem Gebiet Experte, versteht aber die andere Seite. Nur gemeinsam kann ein gutes Ergebnis entstehen. Ohne die andere Seite geht es nicht. So weit funktioniert die Analogie gut. In Vorbereitung auf diesen Artikel habe ich das getan, was alle guten Informatiker tun: Sie googlen. “Yin-Yang”. Dabei finde ich heraus, das Yin-Yang Symbol aus der chinesischen Philosophie heißt genau genommen Taijitu oder Taji, „das Äußerste“, und soll so eine Art Weltformel für die Funktionsweise unseres Universums sein. Keine Angst, so größenwahnsinnig bin ich (noch) nicht. Dennoch, je mehr ich mich damit beschäftige, desto mehr gefällt mir das Symbol als Metapher für unsere neue Analytics-Arbeitsweise:
Das Yin bezeichnet den Nordhang eines Berges, das Yang die Südseite. Die beiden Seiten sind notwendigerweise untrennbar miteinander verbunden. Sie machen den Anschein, Gegensätze zu sein (die eine schattig und kühl, die andere sonnig und heiß), aber stehen im Einklang zueinander. Ohne Analytics-Anforderung braucht es keine Entwicklung. Ohne Entwicklung kann man sich die Anforderungen sparen. Es gibt eine gemeinsame Bergspitze. Will man auf den Analytics-Zenit, so gelingt das nur gemeinsam. Als Betrachter von außen muss man viele Meilen machen, um herumzulaufen und beide Seiten zu sehen und zu verstehen. Jede Seite hat individuelle Eigenarten und Bedürfnisse, ist anders, obwohl es der gleiche Berg mit dem gleichen Gipfel ist. Wohnt man auf einer Seite und kommt nie herum, versteht man die andere Seite nicht, kann die Temperatur- und Lichtunterschiede nicht nachfühlen, den anderen Blickwinkel auf die Spitze nicht begreifen.
Im Unternehmen können Change-Begleiter dabei helfen „herumzulaufen“, zu verstehen und zu transportieren. Sie können ermutigen, einen Austausch anregen und moderieren. Es braucht diese mutigen auf beiden Seiten, die starten, sich herum trauen und versuchen das erste Dashboard gemeinsam zu bauen, vielleicht nicht direkt das schwerste. Beide Seiten müssen sich trauen die dummen Fragen zu stellen und die (vermeintlich) einfachen Dinge zu erklären. Für Entwickler ist die Rolle als Coach häufig eine neue Kompetenz, die nur durch Machen gelernt wird. Für Fachseiten ist das Dashboard bauen, selbst in einer datengestützt arbeitenden Organisation oft nur selten durchgeführte Praxis.
Eine weitere Interpretation für das Yin-Yang liefert das chinesische „Buch der Wandlungen“, nach welchem die beiden Seiten immer im wechselseitigen Wandel stehen. Auf Bewegung folgt Ruhe, auf ein Hoch ein Tief usw. Kommt euch das bekannt vor? Die agile, iterative Entwicklungsweise passt wunderbar auf diese Metapher. Erst ein POC (Proof of Concept), dann die Entscheidung. Nachfolgend das MVP (Minimal Viable Product) und damit die ersten dauerhaften Mehrwerte. Dann vielleicht ein MLP (Minimal Loveable Product) und daraus resultierend gesteigerte „Gier“ im Unternehmen nach den neuen Zahlen, die wieder zu Folgeanforderungen führen.
Das Analytics-Yin-Yang bietet eine überraschend einfache Darstellung für den sehr stark verwobenen Austausch, der zwischen Fachseite und Entwicklungsseite nötig ist. Im Gegensatz zu klassischer Software-Entwicklung, wo Abläufe, Bedienung und Funktionalität im Fokus stehen, spielt das Business-Know-How eine deutlich zentralere Rolle in der Data & Analytics-Entwicklung, da das Verständnis und die Interpretation von Kennzahlen eben nicht nur schwarz oder weiß ist, sondern ganz viel dazwischen und im Zweifel auch alles, je nach Blickwinkel und Anforderung. Dennoch, in der klassischen Software-Entwicklung wird das Endanwenderbedürfnis bereits seit vielen Jahren enorm stark beachtet. Damit die Analytics einen Schritt nach vorne macht braucht es hier beidseitig eine Annäherung. Das ist eine Herausforderung und eine Chance.
Das Analytics-Yin-Yang wird auch in Zukunft bei meinen Workshops und Vorträgen zu finden sein und ist vielleicht so eine Art Prozessdiagramm, für alle, die keine Prozessdiagramme mögen. Denn es geht nicht um das du und ihr, sondern um das wir. Vielleicht erreicht dieser Artikel ein paar gleichgesinnte, die ihren DDC-Bestrebungen ein Symbol geben möchten. In dem Fall, bitte bedienen. 🙂
