Entwickeln für die OTTO-Plattform: Was haben wir bisher erreicht?

In diesem Blogartikel beschreibe ich folgende Phasen:

• Step 1: Vorplanung
• Step 2: MVP bis Februar 2019
• Step 3: Status Quo

So ein großes Projekt ist natürlich nicht einfach. Am Anfang stellen sich erstmal eine Menge Fragen, beispielsweise:

• Was genau soll entwickelt werden?
• Wie wollen wir uns organisieren?
• Welche Technologien und Architekturen wollen wir nutzen?
• Wie nennen wir das Projekt?

Mit diesen Fragen kann man sich natürlich Monate oder Jahre beschäftigen und wird trotzdem nie den perfekten Plan entwickeln. Das kennen viele von uns ja noch aus der Wasserfall-Welt. Daher war für uns früh klar, dass wir agil entwickeln wollen. Aber agil, bedeutet eben auch nicht planlos.

Wir haben daher ein zweimonatiges Vorprojekt mit ca. 30 Personen aus der IT und dem Business gestartet. Mittels der Methode des Domain Driven Designs haben wir uns der Frage genähert, welche Fähigkeiten wir als Plattform brauchen. Es hat, trotz vieler Vorkenntnisse, sehr geholfen noch einmal ganz neu über alle Themen nachzudenken.

Understand the Business:

Zuerst haben wir uns mit der Methode des Event-Stormings in unsere Kund*innen sowie des Partners hineinversetzt und erarbeitet, welche Schritte alle nacheinander passieren müssen, damit ein optimaler Geschäftsprozess entsteht. Dabei entsteht im Grunde eine Wand voller Ideen, die wir auf Klebezetteln gesammelt haben. Von links nach rechts führen diese Zettel durch die Kunden- bzw. Partner-Journey:

Mit diesen Informationen waren wir gerüstet ein Minmum Viable Product (MVP) zu definieren. Ein MVP war für uns beispielsweise die Entwicklung einer live deployten Software für den Markplatz, um gemeinsam mit unseren ersten Beta-Test-Partnern Erfahrungen sammeln zu können. So haben wir unmittelbares, direktes Feedback bekommen und konnten Verbesserungen schnell umsetzen.

Wir haben zu Beginn so viele Abstriche wie möglich gemacht, um die Komplexität erst einmal klein zu halten. Das hieß für dieses MVP, dass wir in einem ersten Schritt nur zwei Zahlungsarten und keine Versandkosten entwickelt haben. Dadurch konnten wir schnell Ergebnisse liefern. Wir waren uns aber sicher, dass mit unserem agilen Ansatz spezifische Features nach und nach ergänzen können - dezentral, also ohne gemeinsame (und teilweise zeitintensiver) Abstimmung aller Teams.

Für dieses MVP haben wir uns als Zieltermin Februar 2019 gesetzt. Und soviel kann ich an dieser Stelle schon einmal recht stolz verraten: Wir haben den Termin gehalten.

Names do matter!

Namen erscheinen zwar oft wie Schall und Rauch. Doch sie helfen stark bei der Kommunikation und der Identifikation mit dem eigenen Werk. In Analogie zum Lhotse-Projekt  haben wir diesem Projekt den Namen DeepSea gegeben. Der Name symbolisiert für uns, dass wir nun nicht nur den an der Oberfläche sichtbaren Teil erneuern, sondern eben auch den Teil der sich eher unter der Oberfläche abspielt. Und dort, in der Tiefsee, gibt es auch viel Unbekanntes.

Neben der inhaltlichen Frage, haben wir uns im Vorprojekt auch Gedanken gemacht, wie wir das Projekt organisatorisch durchführen wollen. Besonders wichtig war uns dabei, dass die Teams sich so weit wie möglich auf sich konzentrieren können und nicht ständig mit Status-Reports belastet werden. Trotzdem wollen wir unsere Führungskräfte regelmäßig zum Status quo informieren, damit sie uns -wo nötig- bestmöglich unterstützen können. 

Das waren unsere sechs Erfolgsrezepte:

Gestartet sind wir mit der Definition unseres Technischen Manifests. Darin haben wir unser Selbstverständnis festgehalten, welche Ansprüche wir an unsere Softwareentwicklung stellen. Grundlegend unterteilt es sich in die zwei Abschnitte Makroarchitektur und Mikroarchitektur.

Macroarchitektur

Um dezentrale Produkt-Teams zu unterstützen sollen diese auch technologisch möglichst unabhängig voneinander sein. Daher haben wir folgende Regeln definiert:

• Jedes Team entwickelt Self-Contained-Systems. Damit einher geht eine unabhängige Deploybarkeit und der weitgehende Verzicht auf synchrone Kommunikation
• Jedes Team betreut seine eigene Infrastruktur in seinen eigenen AWS-Accounts
• Jedes Team sollte jederzeit deployen können. Üblicherweise mit Continous Deplyoment
  

Microarchitektur

• Innerhalb ihres Verantwortungsbereichs sind die Teams frei in der Wahl der Technologien, aber aufgrund ihrer Verantwortung müssen sie das verfügbare Know-how, mögliche Synergieeffekte usw. selbstständig berücksichtigen.
• Bei DeepSea sind die verwendeten Technologien tatsächlich sehr divers. Sehr häufig verwendete Technologien sind Java, Terraform, DynamoDB und MongoDb und SQS/SNS

Bei Interesse gehe ich auf diesen Punkt gerne nochmal in einem eigenen Beitrag ein. Lasst einfach einen Hinweis in den Kommentaren unter dem Artikel da.

Unter MVP wird in der Softwareentwicklung das Minimum Viable Product verstanden. Also ein möglichst kleines Produkt, welches dennoch einen Business-Mehrwert bringt. Ziel ist es, möglichst schnell am Markt zu sein und eine Basis für die kontinuierliche Weiterentwicklung zu erzeugen.

In die MVP-Phase (ca. 6 Monate) sind wir mit drei Produkt-Teams gestartet. Wir sind von Beginn an mit den gewählten Vorgaben aus dem Vorprojekt gestartet und haben daher auch sofort mit zweiwöchentlichen Sprints begonnen. So konnten wir bereits nach dem ersten Sprint lauffähige Software zeigen. Nach etwa drei Monaten waren wir soweit eingespielt, dass wir drei weitere Produkt-Teams gegründet haben und damit alle benötigten Produkte für das MVP entwickeln konnten. Damit die drei neuen Teams von den bereits gemachten Erfahrungen profitieren konnten, sind aus den bestehenden Teams jeweils Personen hinüber gewechselt.

In den letzten zwei Monaten vor Deadline begann die gemeinsame Testphase mit den ersten Partnern, welche tatsächlich sehr smooth ablief. Obwohl wir alle continous deployen und demenstprechend technisch gesehen bereits lange live waren, war der Rollout-Termin trotzdem sehr spannend. Denn das war der Termin, an dem wir tatsächlich im Webshop otto.de den Schalter umlegten, mit denen die neuen Partnerprodukte tatsächlich gefunden und bestellt werden konnten.

Die Entwicklung dieses MVPs war für uns sehr lehrreich, weil wir vieles so erst erproben konnten ohne die gesamte Komplexität berücksichtigen zu müssen. Unsere ersten beiden Partner waren ebenfalls sehr zufrieden.

Die ersten Wochen nach unserem MVP fokussierten wir uns auf die Lieferung einiger Features, die uns sehr wichtig erschienen, um das MVP "genussfähig" zu machen. Beispielsweise die Möglichkeit des Kundenstornos. Schwerpunktmäßig arbeiten wir seitdem aber am Partner-Wachstum. Dazu gehört die vereinfachte und vor allem automatisierte Registrierung als Partner, der auf otto.de Produkte verkaufen möchte sowie die Ausweitung unserer Sortimente.  Dazu verrate ich im nächsten Artikel mehr.

Ist die spannendste Phase bereits vorbei? Mitnichten! Ganz stark in den Fokus kommen nun die Themen Partner-UI, welche besonders für kleinere Partner essentiell ist und die Weiterentwicklung der logistischen Services um die Abwicklung für unsere Partner weiter zu vereinfachen. Diese unglaublich spannende Reise hat also gerade erst begonnen. Wenn ihr diesen Artikel interessant fandet, schreibt es gerne in den Kommentaren.