Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Stefan Tilkov: Hallo und herzlich Willkommen zu einer neuen Episode des INNOQ-Podcasts. Heute ist mein Gast John-Paul Bader und unser Thema ist Metric-Driven Development. Hallo, John.

John-Paul Bader: Hallo, Stefan.

Stefan Tilkov: John, erzähl uns doch ganz kurz, wer du bist und was du bei uns tust.

John-Paul Bader: Ja, ich bin der John, im Internet auch als hukl anzutreffen, ich bin Senior-IT-Consultant, das ist glaube ich meine offizielle Job-Beschreibung bei INNOQ, ich bin Programmierer, Entwickler, DevOp-Admin, so in dem Bereich bewege ich mich gerne. Im Backend, weniger gerne im Frontend.

Stefan Tilkov: Das Thema, über das wir heute reden wollen, hast du Metric-Driven Development genannt, da liegt die Frage natürlich nahe: Was ist das? Kannst du das mal für uns definieren?

John-Paul Bader: Ja. Den Begriff habe ich gewählt, im Wesentlichen, für mich trifft es das am besten, allerdings glaube ich, dass der Begriff im Internet schon ein bisschen anders belegt ist und ich fürchte fast auch mehr in die Richtung Monitoring von Backend-Services geht und wie schnell Response-Times sind oder Fehlerraten und so weiter. Ein anderer Weg, wie Leute das verstehen, ist Business-mäßig, so KPI- und Marketing-mäßig, aber in Wirklichkeit ist das für mich ein Mix aus 3 verschiedenen Komponenten und die eine Komponente, die bis jetzt noch nicht genannt wurde, wäre dann noch das User-Verhalten. Im Prinzip ist es so, es gibt so einen schönen Spruch: If you can’t measure it, you can’t manage it. Da geht es im Prinzip darum, dass man für sein Business oder sein Geschäft oder was auch immer man für einen Dienst oder eine App betreibt, Metriken erhebt, um bestimmte Probleme, die sich sonst ganz langsam einschleichen, früh zu erkennen und dann auch ganz agil darauf zu reagieren.

Stefan Tilkov: Wir hatten ja vor einer Weile schon einmal eine Folge zum Thema Monitoring und Logging, da kamen auch Metriken vor. Das war mit Tammo, ich glaube, Episode 20 oder so. Kannst du das nochmal ein bisschen abgrenzen, also reden wir jetzt heute auch über Monitoring-Tools, im Backend, über den ELK-Stack – oder was auch immer die aktuelle Nachfolge-Variante davon ist – oder reden wir über etwas anderes?

John-Paul Bader: Ja, wie gesagt, es kann ein Teil davon sein, aber eigentlich ist es etwas anderes, also bei diesem Metric-Driven Development, wie ich es verstehe, steht der User oder der oder die Benutzerin im Vordergrund. Das heißt, es geht darum, erstmal User zu gewinnen, dafür zu sorgen, dass sie auch bleiben und sie im Idealfall auch zu motivieren, wiederzukommen und die ganzen Metrics so aufzustellen, dass man das auch wirklich erfassen kann. Ganz oft hört man ja in Projekten von Chefs oder Product Ownern „Der Markt will dies, die Konkurrenz macht das, ich glaube, unser Kunde will jenes”. Und ich glaube, ganz oft sind die eigenen Erwartungen, die man an die Benutzer hat, falsch. Man wird ganz oft auch überrascht von dem Verhalten der Nutzer, wie sie eigentlich die Plattform nutzen und es geht sozusagen darum, das in Zahlen zu erfassen und dann darauf einzugehen, wenn man merkt: Oh, hier läuft irgendetwas falsch oder hier ist scheinbar etwas, das die User wollen, was wir noch gar nicht richtig, wie soll man sagen, ge-featured oder bereitgestellt haben. Und die Idee ist eben, wenn man diese ganzen Metrics hat, dass man dann auch entsprechend auf so etwas schnell eingehen kann.

Ein Beispiel vielleicht dazu, das nehme ich jetzt mal ein kleines bisschen vorweg: Eine Metric ist eben der sogenannte User-Funnel oder Conversion-Funnel, wo man sehen kann, was die User so machen auf der Webseite und wie sie vielleicht auch das Produkt erfahren, jeder einzelne Schritt wird dann getrackt. Ich war mal in einem Projekt, da kam dann der Business-Analyst zu uns und meinte: „Hier in Schritt 3, beim Laden unserer Application, haben wir seit dem letzten Deployment oder seit dem letzten Release 3% weniger User, die durch diesen Schritt durchkommen.” Und der hat uns solange genervt, bis wir herausgefunden hatten, was an unserem letzten Release das verursacht haben könnte, und bis wir das gefixt hatten. Denn wenn man eine größere User-Anzahl hat, dann sind 3% potentiell ziemlich kritisch, ne?

Stefan Tilkov: Das heißt, wir fokussieren uns sehr stark auf den Benutzer, mit dem, worüber wir heute sprechen, wir fokussieren uns auf die Interessen des Benutzers oder des Kunden oder des Users, das finde ich gut. Kannst du ein bisschen erklären, wie man da vorgeht, wenn man das in den Mittelpunkt stellt?

John-Paul Bader: In dem Projekt im Speziellen war es so. Aber es gibt viele solche Berichte, auch von erfolgreichen Firmengründern, von so One-Man-Shows, die das im Prinzip genauso aufgezogen haben. Und zwar kann man ganz früh, also bevor es überhaupt ein Produkt gibt, mit sogenannten Paper-Prototypes, das haben wir auch gemacht. Das heißt, es gab in dem Fall eine Idee für ein Spiel, für eine App im App-Store, aber bevor das Spiel überhaupt eine Zeile Code bekommen hatte oder ein digitales Design, haben Leute tatsächlich Paper-Prototypes gemacht und haben Leute eingeladen und haben das mit diesen Paper-Screens durchgesprochen, um überhaupt ein Gefühl dafür zu bekommen, ob da ein Interesse besteht oder ob die Leute das Konzept verstehen.

Was ich damals auch überraschend fand, dass man wirklich so früh anfangen kann, aber gleich von Anfang an wurden diese User Tests dann ausgewertet und geguckt, ob das irgendwen angesprochen hat. Dann gab es noch Click Dummies als nächsten Zwischenschritt und bevor überhaupt das Team aufgebaut wurde mit Backend- und Frontend-Entwicklern und Designern und was nicht alles, wurden sozusagen noch die Click-Dummies gebaut und auch wieder durch User Tests geschickt und geguckt, ob die User verstehen, was man von ihnen will und ob sie mit der Benutzung zurechtkommen. Und dann, wenn der Prototyp gebaut wird, also der erste Entwurf für die echte App, auch da wurden bei uns schon Metrics eingebaut. Und ein essentieller Bestandteil ist dieser Conversion-Funnel.

Für Leute, die das noch nie gehört haben oder sich nichts darunter vorstellen können: Wenn man eine Webseite lädt oder wenn man eine Applikation startet, dann gibt es in der Initialisierung einfach verschiedenste Schritte. Erstmal wird das HTML ausgeliefert oder die GUI geladen, dann muss mit dem Server gesprochen werden, um die User-Daten zu laden und je nachdem, was dann für User-Daten kommen und welche Mondphase gerade ist, muss man vielleicht noch etwas anderes nachladen und dann gibt es eben verschiedene Schritte in der Initialisierung. Dann gibt es die Interaktion vom User, der dann vielleicht das Spiel startet und eine Runde spielt oder in der App, wenn es ein Web-Store ist, anfängt, nach Artikeln zu suchen. Der nächste Schritt ist dann: Es wird etwas gefunden, was macht der User oder die Userin dann, klickt er auf ein Produkt oder bricht er ab, ist er weg, endet da der User-Funnel? Funnel ist wie ein Filter, das heißt, am Anfang kommen vielleicht 100 User, die schaffen den ersten Schritt und dann bei Schritt 2, in dem vielleicht irgendeine Werbung nachgeladen wird oder die User-Daten, das dauert bei manchen vielleicht aufgrund der Internet-Verbindung schon zu lange und man verliert 2%. Dann hat man nur noch 98%. Und mit jedem Schritt werden es prinzipiell immer weniger. Das hatten wir dort gleich von Anfang an eingebaut, sodass man sieht, wo quasi unsere Probleme in der Usability oder auch in der Technik sind. Wenn zum Beispiel das Backend einfach zu langsam war, um bestimmte Daten zu liefern und die User dann schon die Geduld verloren haben, dass man das sofort sieht.

Stefan Tilkov: Ich kenne den Begriff und die Vorgehensweise vor allem aus unseren E-Commerce-Projekten, wo es ja typischerweise darum geht, wie viele Leute haben sich denn tatsächlich von der Produktsuche aus in den nächsten Schritt, den Bestellprozess [9:05], wie viele haben den Bestellprozess denn tatsächlich abgeschlossen? Aber, so wie du es jetzt sagst, ist es ja noch viel allgemeiner und würde sich nicht nur auf, sagen wir mal, business-orientierte, vielleicht vom Marketing-getriebene Dinge beziehen - das ist natürlich ein bisschen unfair, auch das ist natürlich eigentlich technisch, meine Frage muss ich umformulieren. Was ich meine, ist: Conversion-Funnel assoziiere ich immer automatisch mit einem typischen Bestellprozess im E-Commerce, aber so wie du es gerade dargestellt hast, ist es ja sehr viel allgemeiner und könnte im Prinzip auf jede beliebige Stelle einer Anwendung oder einer App oder einer Webseite oder was auch immer wir gerade haben. Richtig?

John-Paul Bader: Absolut, genau! Und es war auch wirklich so, man liest das auch ab und zu, dass jede Sekunde zählt bei der User Conversion. Im Sinne von: Der oder die Userin lädt die App oder die Webseite und bleibt dann auch und wird zum aktiven Nutzer. Das haben wir da zum Beispiel auch ganz krass gesehen: Wenn der Setup-Call beim Laden des Ganzen ein paar Millisekunden langsamer war, dann ist im Funnel direkt etwas gedroppt. Und das trifft einfach auch auf jeden zu. Aber es gibt natürlich dann im Weiteren, je nachdem, was es für eine App ist, da muss man seinen Funnel entsprechend dem Geschäftsmodell oder was auch immer anpassen, worum es dann eben akut geht. Im Webshop ist es ganz straightforward, wir haben in dem Fall so ein Spiel gemacht, in dem dann auch getrackt wurde, wieviele Runden derjenige gespielt hat und wie viele Leben er verbraucht hat und wieviel Geld er ausgegeben hat. Irgendwann geht es natürlich auch ums Business und um die sogenannte „Buyer Conversion”, also Nutzer zu zahlenden Nutzern zu machen, aber das ist dann auch nur ein Teilaspekt davon.

Stefan Tilkov: Okay. Wenn du sagst, dass man damit sehr früh anfängt, wie muss ich mir das in den ganz frühen Phasen vorstellen: Entwickelt man den Funnel oder das Modell, wie auch immer man das nennen will, parallel zur Anwendung oder macht man erst die Anwendung und überlegt sich dann, was man genau da als Metriken herausziehen will?

John-Paul Bader: Wenn man das wirklich ganz früh startet und vielleicht auch noch kein anderes Projekt vorher so gemacht hat und keine Ahnung hat, dann ist das natürlich auch so ein bisschen experimentieren, also auch in der Firma war das am Anfang natürlich noch nicht alles sofort auf Anhieb richtig, aber ich würde es auf jeden Fall parallel machen. Man kann immer noch neue Schritte im Funnel hinzufügen, aber so die wichtigsten Schritte, die sollten, finde ich, schon gleich von Anfang an drin sein, weil selbst in einer Soft-Launch-Phase, selbst, wenn die Firma das nur intern testet, sind die Daten einfach sehr viel wert.

Stefan Tilkov: Die Konzepte, sind wir die damit weitestgehend durch? Sollen wir uns schon auf Tools und Technik stürzen oder gibt es noch konzeptionell grundsätzliche Dinge, die wir vorher besprechen sollten?

John-Paul Bader: Ein sehr großer Aspekt davon, und das habe ich davor selten gesehen und danach auch nicht, ich habe bisher sonst eigentlich nur davon gehört, sind A/B-Tests und zwar auch auf massiver Skala und auch auf enormer Detail-Ebene. Man weiß ja zum Beispiel, dass Amazon das Design des Webshops auch teilweise automatisch durch A/B-Tests anpasst, so sieht es dann teilweise auch aus beim Bestellvorgang. Ich finde zum Beispiel diesen Warenkorb-Bestellschritt total furchtbar, wenn man nicht Prime-Kunde ist, aber deren A/B-Test-System hat halt gesagt, dass das vielleicht die höchste Conversion bringt.

Stefan Tilkov: Ich glaube, du musst kurz erklären, was A/B-Tests überhaupt sind.

John-Paul Bader: Okay. Kein Problem. Man partitioniert die User-Basis. Sagen wir einmal, jeder User hat eine eindeutige ID und man kann jetzt mit Modulo 2 oder was auch immer die User-Base erst einmal in 2 Teile teilen. Und die User-Base A bekommt die Webseite oder die App so, wie sie jetzt aktuell released ist, und die User-Base B, die andere Partition, bekommt eine leichte Variante davon, wo vielleicht ein Button größer ist oder an einer anderen Position oder wo ein Feature anders funktioniert oder eine andere Konfiguration für Preise oder was auch immer dahinter steckt. Und dann beobachtet man diese beiden Gruppen und deren User-Funnel und Tracking-Daten und kann dann im Nachhinein sehen, welche der beiden Gruppen besser durchgekommen ist oder besser performed hat oder mehr gekauft hat, ne?

Stefan Tilkov: Okay.

John-Paul Bader: Genau. Und davon hatte ich auch vorher schon einmal gelesen, aber hatte nie gedacht, dass das noch so einen massiven Einfluss hat, denn es hat dazu geführt, dass das Team sehr unabhängig war von Chefs oder von von außen hereingetragenen Argumenten. Unser Chef sagte zum Beispiel damals: „Ich glaube nicht, dass dieses Feature funktioniert, aber macht mal, wir haben ja A/B-Tests.” Und dann haben wir den A/B-Test gemacht und es stellte sich heraus, es ist viel besser und der Chef hat sich kleinlaut entschuldigt, dass er so herumgetönt hat und es hat zum Beispiel auch dazu geführt - wir hatten eine Praktikantin und die meinte, dass es in Indien ein anderes Farbempfinden gibt, dass es dort viel Lila, Orange und Gelb gibt und ob wir nicht mal einen A/B-Test machen wollen, in dem wir für indische User einen Interface-Teil einfach mehr im indischen Farbschema gestalten und alle so: „Naja, hmm, okay, ist jetzt im Frontend kein großer Aufwand. Okay, wir probieren es mal.” Und keiner hat jetzt wirklich daran geglaubt, dass das etwas bringt. Aber tatsächlich war die Conversion-Rate im Funnel dann 3% besser und dann macht man das einfach, dann gibt es keine Diskussionen und keinen Ego-Trip von irgendwelchen Managern, die meinen: „Nee, ich glaube nicht, dass es so ist.” Man kann es einfach ausprobieren und dafür braucht man dann natürlich auch ein kleines bisschen Infrastruktur und auch fähige Leute natürlich, aber wenn man das hat - wir haben teilweise an manchen Tagen 50 A/B-Tests gleichzeitig laufen gehabt und die Erkenntnisse haben immer wieder die eigenen Erwartungen überrascht.

Stefan Tilkov: Wieviel Aufwand war es, die Resultate zu interpretieren? Ich stelle mir das nicht immer so trivial vor, dass man einfach sagen kann: Hier, haben wir ausprobiert, 5% mehr, Thema durch. Manchmal mag es ja sehr komplexe Zusammenhänge geben: Die eine Metrik geht hoch, die andere geht herunter, aber man weiß nicht genau, was ist jetzt Ursache und was ist Wirkung. Habt ihr in dem Projekt Spezialisten darauf angesetzt, die dann genau das interpretiert haben oder konnten das alle?

John-Paul Bader: In der Firma war es so aufgesetzt, dass sie eine zentrale Business-Intelligence-Abteilung hatten, die sich quasi um die gesamten Tracking-Daten und so weiter gekümmert haben, aber in jedem Team gab es auch noch einen dedizierten Business-Analyst oder Data-Scientist - wie auch immer, ich bin da immer etwas unsicher, welcher Job-Titel da jetzt genau der Korrekte ist - auf jeden Fall Leute, die gut mit Statistik und Mathe sind im Generellen, die dann eben auch teilweise sagen: „Ja, das A/B-Test-Ergebnis sieht zwar so aus, als wäre alles super, aber es hat noch nicht genug Signifikanz erreicht.” Denn die Qualität der Nutzer – das klingt jetzt auch ein bisschen fies, aber es gibt da einfach auch qualitative Unterschiede in der Datenqualität und auch von der Menge her und dem Zeitraum, in dem dieser Test läuft, wo dann gesagt wurde: „Wir müssen noch 2 Wochen warten, bis wir uns sicher sind, dass das jetzt keine Fluktuation ist oder dass das wirklich eine Signifikanz hat“, und das hätten wir Entwickler da jetzt nicht selbst leisten können und wollen. Ich würde da auf jeden Fall empfehlen, sich da jemanden zu holen, der sich damit wirklich auskennt.

Stefan Tilkov: Ja, das ergibt viel Sinn. Gut, dann lass uns doch nochmal ein bisschen über Technik sprechen. Wenn man sich jetzt entschieden hat, das Ganze zu machen, was für technische Hilfsmittel, was für Techniken und Tools, setzt man denn ein dafür?

John-Paul Bader: Also dieser Anfang, den ich da skizziert hatte mit den Paper-Prototypes und Click-Dummy-User-Tests, das erfordert noch nicht viel, außer, dass man sich vielleicht auch da mal ein paar Blogposts und Bücher zu Paper-Prototypes und User-Tests durchliest, da gibt es auch sehr viele Varianten, da habe ich jetzt so keine konkrete Empfehlung, aber das ist auf jeden Fall sehr wenig Aufwand, das können kleine Teams ohne große technische Abhängigkeiten machen. Dieses Tracking vom User-Funnel erfordert zumindest einmal, dass man einen Endpunkt hat, um diese Tracking-Daten entgegen zu nehmen und am besten eine Datenbank, um sie wegzuspeichern. Da kann man auch am Anfang, wenn man noch nicht Millionen von Usern hat, stumpf mit einer SQL-basierten Lösung arbeiten oder dann eben gleich auf so etwas wie Cassandra oder andere Dinge gehen, die dann eben unfassbare Datenmengen bearbeiten. Wir haben tatsächlich Kafka verwendet, worin die Tracking-Daten gespeichert wurden, und dann wurde das von Consumern in die verschiedenen Analyse-Tools gepumpt. Das ist dann schon die erwachsene Variante, nenne ich das mal. Man kann auch im Kleinen, wie gesagt, ganz locker mit einem Webserver, mit einer kleinen Web-App und einer SQL-Datenbank anfangen und dann freuen sich die Business-Analysten auch schonmal.

Stefan Tilkov: Ich wollte kurz dazwischenfragen: Wie siehst du das Thema Tracking in Bezug auf das im Moment allseits beliebte Thema Datenschutz?

John-Paul Bader: Wir haben uns auch damals schon bemüht, keine personenbezogenen Daten zu erheben, wenn man jetzt zum Beispiel Apps im Appstore macht oder irgendetwas mit Facebook linkt, mittlerweile geben einem Apple oder Google auch keine eindeutige User-ID mehr, sondern für die App jeweils eine spezifische. Die IP-Adressen die hatten wir zumindest für GeoIP in der Annahme noch ausgewertet, aber nicht gespeichert, aber klar: Heutzutage müsste man natürlich noch seinen entsprechenden Disclaimer mit irgendwohin packen. Allerdings sind diese ganzen Tracking-Mechanismen auch wunderbar ohne personenbezogene Daten möglich. Klar ist das für die Business-Analysten oder die Marketing-Leute extrem interessant, was das für eine Person ist, wie alt die ist, aber es geht auch ohne.

Stefan Tilkov: In gewisser Weise, sobald es sinnvoll aggregiert oder aufsummiert ist oder nur noch statistische Daten sind, ist es ja auch kein Problem mehr. Es ist ja durchaus legitim, dass ein Unternehmen wissen will, wie gut Variante A gegenüber Variante B funktioniert, solange man damit eben keine Leute aushorcht. Dass kann ich schon nachvollziehen.

John-Paul Bader: Exakt. Das war aber früher tatsächlich, als bei Facebook dieses Bewusstsein noch nicht da war, da war ich damals schon sehr erschrocken, was da an Profiling möglich wäre. Glücklicherweise gibt es ja jetzt diese EU-Regelung, um allen zumindest mal wieder ins Gedächtnis zu rufen: Moment mal.

Stefan Tilkov: Fallen dir noch weitere Techniken und Tools ein?

John-Paul Bader: Für die A/B-Tests braucht man auf jeden Fall ein eigenes System, damit man nicht den Überblick verliert, welche Gruppen man schon hatte und welche Gruppen-Identifier. Es gibt auf jeden Fall mittlerweile sehr viele Services, die gerade diesen Conversion-Funnel und A/B-Test für einen lösen oder die Infrastruktur dafür anbieten, und das kostet natürlich wieder Geld. Wenn man das selbst bauen würde, auch da kann man ganz simpel erstmal anfangen mit einer SQL-Datenbank und sozusagen nur die A/B-Testgruppen in die Tracking-Datenbank schreiben und in die A/B-Test-Datenbank, was dieser A/B-Test ist und zu welchem Produkt oder zu welchem Feature er gehörte und so weiter und so fort. Das geht alles auch noch im kleinen Sinne. Aber für A/B-Tests braucht man auf jeden Fall auch noch ein eigenes Repository, um da nicht den Überblick zu verlieren. Und dann haben wir natürlich auch, was wir eingangs jetzt schon so ein bisschen beiseite gewischt haben, Backend-Metriken erhoben, also gerade so etwas wie New Relic bietet sich an oder wenn man sich so ein Grafana oder was auch immer selbst aufbauen möchte. In der Firma war es nämlich auch so, dass alle Projekte für alle sichtbar waren, also alle Daten waren für alle sichtbar, damit man sich auch immer messen konnte, wie gut performed jetzt unser Produkt oder unser Feature oder was auch immer im Vergleich zu den anderen und gerade, weil wir da gesehen haben, dass teilweise Millisekunden zählen, gab es natürlich auch immer so Backend-Monitoring, bei dem wir dann gesehen haben: Ah, diese Transaktion oder dieser Call, der ist jetzt plötzlich nach dem letzten Deployment langsamer geworden. Oder auch Error-Tracking: Selbst die kleinsten Errors, wenn die sich so mitschleifen und keiner sich darum kümmert, weil jeder denkt: Ach, das sind jetzt nur 0.5% der User. Das sind vielleicht die 0.5% bezahlenden User. Die ganzen Funnels und so, die ersetzen natürlich nicht das klassische Monitoring und sollten da auch mit einfließen.

Stefan Tilkov: Wie hoch schätzt du die Wahrscheinlichkeit, dass jemand anfängt, Gaming The System zu betreiben und irgendwie versucht, die Metriken in eine positive Richtung zu drängen, obwohl das gar nicht der Realität entspricht? Hast du sowas schonmal erlebt?

John-Paul Bader: In diesem Fall nicht, weil dieses unabhängige Business-Analytics-Team die Zahlen schon immer sehr nüchtern analysiert und vorgetragen hat und im Zweifel, wenn da ein zu eifriger Projektmanager war, auch gesagt hat: „Nee, Moment mal.” Es ist aber natürlich die Frage, wie man das aufhängt und welche Wichtigkeit man dem in dem Firmenorganigramm beimisst. Da war es halt so, dass auch die Business-Analysten eine sehr prominente und wichtige Rolle hatten und dementsprechend gab es keinen, der gesagt hat: „Was die sagen, das stimmt nicht. Ich weiß besser Bescheid.” Insofern: Ich habe es noch nicht erlebt, aber ich könnte mir gut vorstellen, dass es in weniger gut organisierten Teams dann auch solche Tendenzen geben könnte. Aber dann lügt man sich halt in die eigene Tasche.

Stefan Tilkov: Siehst du ein Problem darin, wenn man auf der einen Seite modularisieren möchte, also unabhängige Teil-Teams haben möchte, die autonom agieren, und gleichzeitig aber übergreifend solche Metriken erheben will oder würdest du die Metriken dann auf die einzelnen Teams verteilen und erst später aggregieren?

John-Paul Bader: In dem Fall war es jetzt so – und das fand ich schon auch sehr gut – dass es ein zentrales Team gab, das die Infrastruktur bereitgestellt hat und eine Reihe von Funnel-Tracking-Calls sozusagen globalgalaktisch definiert hat. Und dann konnte jedes Team selbst für das individuelle Produkt noch ganz viele andere Tracking-Calls und Funnel-Calls dazu definieren. Um die Teams so ein bisschen vergleichbar zu halten, gab es ein Set von Calls, die alle implementieren mussten, gleich von Anfang an, aber das war auch so ziemlich das einzige Dogma oder wie auch immer, das alle machen mussten. Ansonsten gab es eben viel Freiheit und die Leute konnten auch ihre eigenen Consumer und ihre eigenen Auswertungen schreiben. Nur wenn man dann zu euphorisch war mit einer Metrik, dann kam vielleicht nochmal das große Business-Analytics-Team und hat vielleicht nochmal prüfend draufgeschaut. Das hängt ein bisschen von der Firma ab und ob man jetzt ein großes Produkt entwickelt und das schon über 10 Jahre oder ob man viele unterschiedliche Produkte macht oder ob man – in dem Fall war es eben eine Spiele-Firma, die viele Spiele gemacht hat und deswegen viele Teams parallel hatte – das kann ich jetzt nicht so generalisieren. Aber es macht auf jeden Fall Sinn, wenn es unterschiedliche Teams gibt, zu versuchen, eine Vergleichbarkeit herzustellen, auf einem simplen Level.

Stefan Tilkov: Dann lass uns doch nochmal auf den Punkt kommen, warum man das ganze eigentlich tut. Was siehst du denn als die Vorteile von diesem Ansatz?

John-Paul Bader: Zum einen würde ich sagen, dass das wirklich agile Softwareentwicklung ermöglicht, weil wir wissen ja alle: Viele reden von agiler Entwicklung oder Management, keiner tut es, die meisten denken ja, sie sind schon agil, wenn sie in der Lage sind, in einem Jira die Tickets hoch und runter zu schieben und zu priorisieren. Aber eigentlich geht es ja auch darum, wirklich eben dynamisch auf Dinge zu reagieren und wie ich am Anfang schon meinte: Wenn man es nicht messen kann, kann man es nicht managen. Oder es gibt diesen schönen Spruch: Knowing is half the battle. Und wenn man eben diese Metriken hat und das User-Verhalten sieht, dann kann man eben auch mal vom großen Jahresplan abweichen und sagen: Pass mal auf, wir haben gesehen, wenn wir jetzt am Mittwoch einen Sale machen, dann kriegen wir den doppelten Revenue und wir machen jetzt einen A/B-Test, wo der Sale noch zusätzlich am Montag stattfindet und gucken, ob die Leute weniger kaufen oder ob sie sogar noch mehr kaufen und so.

Durch die A/B-Tests macht man eben viele Experimente und manchmal kommen da Erkenntnisse heraus, die dann beim nächsten Sprint den Fokus ändern und eben nicht dieses „Ja, wir haben jetzt eine Deadline bis zum Release bis da und dahin und wir marschieren stur dahin und schieben vielleicht nur zwischendurch ein paar Tickets um.” Das fand ich sehr schön, dann, wie gesagt, gibt es dem Team auch eine ziemlich gute Eigenverantwortung und auch Ownership eben dann selbst Ideen hinein bringen können. Wir hatten dann bei Sprint-Plannings auch einfach immer gefragt: Hat noch jemand eine Idee, was man vielleicht noch besser machen könnte? Und haben dann im Zweifel einen A/B-Test draus gemacht. Das hat sehr dafür gesorgt, dass das Team da auch mitgedacht hat und überlegt hat: Was könnte man da noch machen? Und man hatte am Ende eben die Fakten in der Hand und eben nicht diese Bauchgefühlsentscheidung oder die ego-getriebene Richtung, in die man ohne Wenn und Aber marschiert, man kann eben auf die Zahlen reagieren und das empfinde ich mit als die größten Vorteile daran.

Stefan Tilkov: Sehr schön. Wenn man sich mit dem Thema weiter beschäftigen möchte, hast du ein paar Empfehlungen? Gibt es Online-Ressourcen oder Bücher oder ähnliche Dinge, die man sich mal zu Gemüte führen sollte?

John-Paul Bader: Ja, es gibt - weil es, wie gesagt, ein Komplex aus verschiedenen Elementen ist - verschiedene Quellen, es gibt Bücher zum Thema User-Tests, wie ich ja schon gesagt hatte, zum Beispiel gibt es dieses eine, sehr bekannte Buch „Don’t Make Me Think: A Common Sense Approach to Web Usability”, das ist auf jeden Fall schon mal ein sehr guter Einstieg, um in die Mentalität hinein zu kommen. Dann gab es vor einer Weile auch ein Buch „Designing with Data: Improving The User Experience With A/B Testing” von O’Reilly, das ist auch eines der wenigen Bücher, die nicht so ultimativ marketing-fokussiert sind. Denn im Internet findet man ganz viel: wie kann ich mehr Sales generieren? Klar, darum geht es auch, das kann man damit auch erreichen, aber wenn man erst einmal gucken will, wie man das überhaupt organisiert, dann vielleicht erst einmal das. Und dann gibt es noch ein Buch mit einem etwas reißerischen Titel, das sich aber zumindest primär um diese Conversion-Funnels kümmert und nicht soviel um andere Sachen, und das heißt: „DotCom Secrets: The Underground Playbook for Growing Your Company Online”, also alles mit einem Teelöffel Salz genießen, ne? Aber es gibt in allen dreien schon einige Ideen und Inspirationen. Ein Buch gab es noch zum A/B-Testing-Thema, das packe ich dann noch in die Show-Notes.

Stefan Tilkov: Das verlinken wir sowieso alles dort.

John-Paul Bader: Genau und wenn man ansonsten etwas zu Conversion-Funnels sucht, A/B-Testing und wie man das am besten aufsetzt, da wird eine Google-Suche auch einige Blog-Posts hervorbringen, die weitere Inspiration liefern. Es gibt da nicht den generellen, ultimativen Plan für alles, man muss da schon selbst auch ein bisschen an sein aktuelles Produkt anpassen aber, ja, Inspiration wird es sicher geben.

Stefan Tilkov: Gut, dann sind wir durch mit unserer Zeit, ich fand es sehr, sehr spannend, vielen Dank für deine Zeit, John!

John-Paul Bader: Gerne.

Stefan Tilkov: Und Dank an die Zuhörer fürs Zuhören. Bis zum nächsten Mal. Ciao!

John-Paul Bader: Wiederhören.