Agentur-Review bei der Otto Group.

Die Ausgangslage

Damals war ich Senior Android Dev im internen Mobile-Team der Otto Group. Wir bauten eine White-Label-Lösung für die eCommerce-Apps mehrerer Group-Unternehmen — Sheego, MyToys und andere. Klein und schnell: zwei Android-, zwei iOS-Devs, mit dem Anspruch, pro Group-Unternehmen in etwa vier Wochen eine App auszuliefern.

Ein Joint-Venture aus dem Konzern hatte zu der Zeit eine eigene eCommerce-App, gebaut von einer externen Agentur. Sie war vor unserer White-Label-Lösung entstanden und lief seit knapp zwei Jahren mit dieser Agentur. Anfangs ging es schnell — mittlerweile häuften sich die Probleme. Die Produktmanager*innen der Konzern-Gesellschaft traten an unser Mobile-Team heran und schilderten vier Beobachtungen: „Bugs häufen sich.“, „Features verzögern sich.“, „Die App fühlt sich langsam an.“, „Einkaufen funktioniert in der App schlechter als auf der mobilen Website.“

Sie kamen nicht, weil sie die Agentur loswerden wollten. Sie kamen, weil ihnen jemand fehlte, der die Aussagen der Agentur einordnen konnte — ein Experten-Team, das ähnliche Apps baut und dem sie uneingeschränkt vertrauen konnten.

Was ich gefunden habe

Wir starteten mit einem Workshop mit den Produktmanager*innen, danach ein halber Tag vor Ort bei der Agentur: Code-Tour, gemeinsames Durchgehen der Architektur, Fragen — warum diese Bibliothek, warum diese Trennung, warum dieser Release-Prozess. Die Agentur gab uns Repo-Zugang; den eigentlichen Review machten wir remote. Ich übernahm den Android-Teil, ein Kollege aus dem Mobile-Team den iOS-Teil.

Das Muster war auf beiden Plattformen dasselbe: keine erkennbare Architektur, alles hing von allem ab. Neue Features brachen regelmäßig ältere Features. An vielen Stellen fehlte Error-Handling — ein Fehler in einer Komponente kontaminierte den ganzen App-State.

Drei der vier Beobachtungen aus dem Kickoff erklärten sich damit direkt. „Bugs häufen sich“ und „Features verzögern sich“ sind die unausweichlichen Symptome eines solchen Codes. „Die App fühlt sich langsam an“ hatte einen zusätzlichen, strukturellen Grund. Dort lag der Hebel für unsere wichtigste Empfehlung.

Die Auswertung

Wir hielten die Ergebnisse in mehreren Wiki-Seiten fest: Code- und Architekturbeobachtungen, ihre Ursachen, priorisierte Empfehlungen für die Agentur und einen Vorschlag, wie eine eCommerce-App auf Android und iOS strukturell besser aussehen könnte.

Der strukturelle Teil kam aus unserer eigenen Praxis. eCommerce-Apps werden meist um den Webshop herum gebaut, mit vielen Webviews — und Webviews sind langsam, vor allem auf den Seiten, an denen Nutzer*innen lange verweilen: Suche, Suchergebnisse, Kategorien, Produktlisten. In unserer White-Label-Lösung hatten wir genau diese Seiten durch native Views ersetzt, gespeist über eine spezialisierte API zwischen App und Webshop. Ergebnis: ein Großteil der Nutzer-Journey läuft nativ, mit dem Tempo und der UX, die Nutzer*innen von einer App erwarten — und die Konversion steigt, weil sich die App besser anfühlt als die mobile Website, nicht schlechter.

Das war die Antwort auf „Die App fühlt sich langsam an“ und „Einkaufen funktioniert in der App schlechter als auf der mobilen Website“ gleichzeitig. Und es war keine theoretische Empfehlung — es war ein Ansatz, den wir in unseren eigenen Apps gerade in Produktion hatten.

Was sich danach verändert hat

Die Agentur übernahm einen Teil der Empfehlungen. Nicht alles — manche hätten ein Refactoring erfordert, das im laufenden Sprint nicht möglich war. Aber genug, damit sich das Verhältnis zwischen Konzern-Gesellschaft und Agentur veränderte.

Die naheliegende Alternative — die Konzern-Gesellschaft vom Agentur-Setup auf unsere White-Label-Lösung zu portieren — hatten wir diskutiert und verworfen. Die App hatte zu viele maßgeschneiderte Features, die wir hätten nachbauen müssen. Das wäre ein langer Weg zurück zum Status quo gewesen, bevor wirklich etwas besser geworden wäre.

Aber das Dokument war nicht das eigentliche Ergebnis. Das eigentliche Ergebnis war: die Produktmanager*innen hatten jetzt Vokabular, Maßstäbe, eigene Hypothesen darüber, was technisch realistisch ist und was nicht. Und vor allem wusste die Agentur jetzt, dass das Joint-Venture ein Mobile-Team an der Seite hatte, das jeden Aufwand und jede Empfehlung im Detail einordnen kann. Die Asymmetrie — Agentur weiß alles, Auftraggeber weiß nichts — war der Boden, auf dem das ursprüngliche Problem überhaupt erst hatte wachsen können. Sie war jetzt nicht mehr da.

Was die Produktmanager*innen mir später zurückspielten: die Agentur strengte sich anders an. Estimates wurden vorsichtiger formuliert. „Das ist gerade nicht möglich“ verschwand aus den Gesprächen. Harte Zahlen habe ich aus dieser Zeit nicht. Was ich habe, ist das, was die PMs sagten: „Es wurde besser.“

Warum ich diesen Fall so oft erzähle

Wenn ich heute mit Unternehmen spreche, die ihre App von einer externen Agentur bauen lassen, höre ich oft eine ähnliche Konstellation: keine tiefe Mobile-Expertise im Haus, die Agentur seit ein paar Jahren, ein wachsendes Bauchgefühl, dass etwas nicht stimmt — und keine Möglichkeit, dieses Bauchgefühl in eine Aussage zu übersetzen, mit der man verhandeln kann.

Die naheliegende Reaktion in dieser Lage ist, die Agentur auszutauschen oder die App neu zu bauen. Beides ist fast immer teurer und langsamer, als es aussieht. Bis Sie mit einem neuen Setup wieder dort sind, wo Sie heute sind, haben Sie Geld und Zeit ausgegeben, ohne dass für die Nutzer*innen etwas besser geworden ist. Schlimmer noch: aus Nutzer*innen-Sicht sieht eine Rewrite-Phase genauso aus wie eine vernachlässigte App — keine neuen Features, weniger Bugfixes, das Gefühl, dass die Entwickler*innen nicht mehr zuhören. Beides — Aufwand und verlorenes Nutzer-Vertrauen — muss erst amortisiert sein, bevor das neue Setup überhaupt anfängt, sich auszuzahlen.

Mein Job damals im Mobile-Team und mein Job heute als Fractional Mobile Expert ist derselbe: dafür zu sorgen, dass die Frage richtig gestellt wird, bevor jemand viel Geld in einen Rebuild oder Vendor-Wechsel steckt. Oft ist die ehrlichste Antwort: das bestehende Setup lässt sich reparieren. Dieser Fall war der Beweis.