Komplexität vs Ninjas

Neulich gesehen: „a complex implementation is a sign of a weak analytics team“, sinngemäß „eine komplexe Implementation ist ein Zeichen eines schwachen Analyticsteams“.

Das ist natürlich harsch, aber so ganz falsch ist es nicht.

Warum ist eine Implementierung komplex und was hat das mit dem Team zu tun?

Historischer Ballast

Historischer Ballast dürfte Gund Nummer 1 sein, also der Umstand, daß über die Zeit neue Aspekte hinzugekommen sind und niemand die alten Zöpfe abgeschnitten hat.

Ich habe das sicher schon oft genug gesagt: Ich halte das regelmäßige Zurechtstutzen der Analyticsimplementierung für ebenso wichtig wie das Stutzen eine Apfelbaumes im Garten. Wer Früchte ernten will, der muß sich um seine Implementierung kümmern, sonst wuchert sie zu.

Schwierig ist das, weil die Benutzer der Plattform natürlich gerne Neues sehen, im Zweifelsfall aber ungern Altes abgeben. „Also zur Zeit sehe ich mir den Report nicht an, aber werfen Sie den nicht weg, den brauchen wir sicher nochmal!“ Kennt jeder.

Ich würde postulieren, daß ein Wachsen der Anzahl der Reports nur dann sinnvoll ist, wenn gleichzeitig auch die Zahl der Benutzer zunimmt. Irgendwer muß die zusätzlichen Reports ja ansehen und analysieren!

Deswegen ist es Aufgabe des Analyticsteams, die Reports oft und gnadenlos auf das Nötige zu reduzieren.

(Tip: Automatische Reports und Dashboards einfach mal testweise abschalten und sehen, ob sich jemand beschwert.)

Und nicht nur die Reports: Auch die Implementierung sollte reduziert werden! Jede Variable, die keinen offensichtlichen Nutzen bringt, jedes ungenutzte Stück Javascript, jede überflüssige VISTA oder Processing Rule — weg damit!

Warum? Weil Komplexität stört, das Auffinden von Information schwieriger macht und die Benutzer verwirrt. Weil ein simpler, eindeutiger Weg besser ist als mehrere, komplizierte. Ausnahmen bestätigen die Regel, aber nur solange jemand da ist, der sie genau nachvollziehen kann.

Spezifikation

Es gibt auch viele Fälle, in denen die Komplexität von Anfang an fest eingebaut war. Das passiert zum Beispiel wenn ganz am Anfang Kunde und Consultant nicht gut zusammenarbeiten. Oder in Situationen, wo zuviele Stakeholders den Prozeß unnötig in die Breite ziehen.

Das Space Shuttle ist ein gutes Beispiel für eine Situation, in der ein ursprünglich recht gut definiertes Anforderungsprofil vollkommen in’s Absurde erweitert wurde, weil ein neu hinzugekommener Stakeholder (die US Air Force) mit Anforderungen ankam, die zum Konzept nicht paßten. Resultat waren Kompromisse, die das Projekt stark einschränkten sowie steigende Komplexität. Von den Kosten gar nicht zu reden.

„Jaja, die Amerikaner“ denkt man da. Und dann geht man zum nächsten Meeting mit Kollegen aus dem Einkauf, die unbedingt per Webanalyticstool den Wareneingang tracken wollen.

Was kann man da tun?

Ich plädiere für zwei Dinge:

1. Öfter mal ‚Nein‘ sagen
2. Vor der Implementierung mit Consulting (oder einem Partner) zusammenarbeiten, damit das Analyticsteam genau weiß was es tut und somit intern vernünftig verhandeln kann

Zweiteres ist in den meisten Fällen Vorraussetzung für ersteres oder macht es zumindest ungleich einfacher.

Nicht jede Anforderung aus dem Unternehmen läßt sich auf Anhieb als sinnvoll oder unsinnig erkennen, manchmal braucht man ein tiefgehendes Verständnis sowohl des Tools als auch der Rahmenbedingungen.

Und nur damit wir uns nicht falsch verstehen: Ich bin der erste, der sich über eine kniffelige Problemstellung freut und besonders über eine geschickte Lösung jenseits 08/15. Nur würde ich sowas nie auf unbedarfte Benutzer loslassen.

Beispiel Tracking auf diesem Blog. Man kann in WordPress nicht einfach so Javascript einbauen, jedenfalls nicht wenn man auf wordpress.org hostet. Bleibt nur ein statisches Pixel, das liefert mir aber nicht genug Informationen. Also habe ich einen ganz schrecklichen Hack gebaut, ehrlich gesagt so schrecklich, daß ich ihn nicht erklären werde. Don’t do this at home, kids.

Kurz: Wenn niemand versteht, was ein Teil der Implementierung tut, dann soll der Teil weg! Und das gilt insbesondere, wenn das Analyticsteam den Teil nicht versteht!

Personal

Teams ändern sich, Mitarbeiter wechseln Rollen und Firmen.

Manchmal ändert sich dadurch die Kompetenz des Teams insgesamt, und manchmal leider nicht zum besseren.

Beispiel: Ein Retailer im UK hatte jahrelang mit einem Partner gearbeitet. Dieser hatte in der s_code.js jede Menge Code zum Scrapen der Seiten verbaut, weil die internen Prozesse langsam waren und er damit dem Marketingteam trotzdem Daten liefern konnte.

Sowas ist ebenso toll wie gefährlich.

Was macht ein Analyseteam, wenn es einen starken Mitarbeiter verliert? Und in unserem Kontext: Was macht das Team mit den Teilen der Implementierung, die es nicht versteht?

Das: Dokumentieren oder wegwerfen.

Ich würde als Team zunächst probieren, die hinterlassene Lösung zu dokumentieren, und zwar so detailliert, daß ich sicher sein kann sie verstanden zu haben.

Teile die ich nicht verstehen und daher nicht gut dokumentieren kann, würde ich eliminieren.

Das kann bedeuten, daß Funktionalität verloren geht, ja.

Ich halte es langfristig für besser, eine simplere aber verstandene Lösung zu pflegen als eine magische Blackbox.

Nicht vergessen: Falsch interpretierte Daten sind schlimmer als keine Daten!

Fazit

Es gibt viele andere Gründe warum eine Implementierung komplex ist, die drei angeführten sind nur die häufigsten in meiner Umgebung.

Ein starkes Analyticsteam kann alle drei lösen, teils durch Entwicklung der Kompetenz, teils durch Reduzierung der Komplexität. Man trifft sich irgendwo in der Mitte.

Klar ist: Wenn das Team sich nicht darum kümmert oder von anderen Teilen im Unternehmen gedrängt wird, die Komplexität zu erhöhen, dann ist das langfristig nicht tragbar und führt fast zwangsläufig zu einer Ablehnung des Tools (siehe auch hier).

In anderen Bereichen im Leben funktioniert das super, z.B. würde ich meinen Kindern den Fotoapparat sofort wieder wegnehmen, wenn sie sich damit gegenseitig verkloppen würden oder permanent mit dem Finger auf die Linse fassen.

Wer ein Analyticsteam managt hat ein starkes Eigentinteresse, dem Team die Rückendeckung zu geben, die es hier braucht. Das macht das Team effizienter und stärkt sein Image. Individuelle Mitarbeiter fühlen sich besser, wenn sie genau wissen, mit was sie da arbeiten. Damit sollte man hoffentlich weniger Churn sehen. Andere Stakeholder haben eine Chance, die Daten zu verstehen.

Komplexität ist böse und hinterhältig. Das Analyticsteam ist unsere einzige Hoffnung! Auch das gehört dazu, wenn man „Analytics Ninja“ sein will.