Informationen
Jobs
1
Finde, was du suchst.
Profil
In deinem persönlichen Profilbereich kannst du den Status deiner Bewerbung einsehen, unvollständige Bewerbungen zwischenspeichern und aktuelle News und Events einsehen
deDeutsch
02. September 2019
Entwickeln für die OTTO-Plattform: Was haben wir bisher erreicht?
Worum geht es?
Ich weiß, der letzte Artikel ist bereits ein Jahr her. Das liegt nicht daran, dass es so wenig zu berichten gäbe, sondern so viel. Aber der Reihe nach.
Wie im vorigen Teil zu lesen war, haben wir begonnen das Geschäftsmodell von OTTO vom Händler zur Plattform umzubauen. Im Rahmen unserer Plattformstrategie entwickeln wir neue Unternehmensfähigkeiten, damit wir unseren Kund*innen und Partnern den größtmöglichen Nutzen für ihr jeweiliges Bedürfnis bieten können.
Für alle die sich fragen, was es mit der Plattformstrategie von OTTO auf sich hat, empfehle ich dieses Interview mit meinem Kollegen Tim Buchholz, der als Principal Platform Business zusammen mit seinem Team die Transformation vorantreibt.
Dazu gehört es auch, einen funktionierenden Marktplatz aufzubauen. Dieser symbolisiert für uns beispielsweise die Fähigkeit, dass Partner im Self-Service Produkte anbieten können. Als Plattformanbieter wollen wir darüber hinaus unser Service-Universum ausbauen und unseren Partnern von der Finanzierung bis zur Logistikleistung das Rundum-Paket anbieten. Zusammen mit meinen Kolleg*innen arbeite ich genau daran. Und inzwischen sind wir einen großen Schritt vorangekommen. Wie uns das gelungen ist, möchte ich im Folgenden skizzieren.
Überblick
In der Rückschau kann man dieses Projekt in folgende Phasen unterteilen, wobei wir sie nicht so von Anfang an geplant haben. Das haben wir im Laufe der Zeit so entwickelt und in welcher Reihenfolge wir die Zukunft angehen, überlegen wir ebenfalls immer Schritt für Schritt. So können wir die aktuellen Gegebenheiten jederzeit berücksichtigen.
In diesem Blogartikel beschreibe ich folgende Phasen:
Phasen der Plattformentwicklung bei OTTO
Phasen der Plattformentwicklung bei OTTO
Step 1: Vorplanung
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:
Post-Its im Rahmen des Event-Stormings
Warum Zettel und nicht digital? Das hat vor allem praktische Gründe: Es ist tatsächlich viel einfacher und im wahrsten Sinne des Wortes greifbarer, mit vielen Leuten direkt vor der Wand zu stehen und ganz einfach Zettel zu verschieben. So bekommen wir im Team einen transparenten Einblick in die ToDos unserer Kolleg*innen und wissen, wer an welchem Thema arbeitet und wie der Status quo ist
Mit dieser Ausgangsbasis haben wir eine sogenannte Kontextmap erstellt. Zur Veranschaulichung im folgenden nur ein stark herausgezoomtes Bild:
Kontextmap, die sich aus dem Event-Storming ergeben hat.
Ein Beispiel für einen Kontext, der hier abgebildet ist, ist die Bezahlabwicklung. Damit ihr euch besser vorstellen könnt, was ich damit meine. Diese Kontextmap vereint mehrere Informationen:
- Jeder Kontext beschreibt eine in sich abgeschlossene Fachlichkeit.
- Jeder Kontext ist möglichst unabhängig von den umliegenden Kontexten und erfüllt auch alleine einen unternehmerischen Zweck.
- Die Beziehungen zeigen, welche Kontexte miteinander Daten austauschen (möglichst asynchron).
- Jeder Kontext sollte von einem einzigen Produktteam bearbeitet werden können.
Beim Beispiel Bezahlabwicklung ist die die verantwortete Fachlichkeit, die tatsächliche Anbindung verschiedener Zahlungsdienstleister. Die Verantwortung dafür, zu entscheiden, von welchem Kunden wir welche Ein -und Auszahlungen erwarten, liegt wiederum in einem anderen Kontext.
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.
Projekt Deep Sea
Agile Projectmanagement
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:
1. Möglichst viel Verantwortung in die Produkt-Teams
Die Produkt-Teams bestehen im Wesentlichen aus folgenden Rollen:
Die Rollen unserers agilen Productteams
- Productowner (PO): Ein*e Kolleg*in aus dem Business, welche*r im Team sitzt und erarbeitet, in welche Richtung das Produkt weiterentwickelt wird.
- Business-Designer (BD): Ein*e IT-Kolleg*in, welche*r die fachlichen Anforderungen in konkrete Stories umsetzen kann. Spoiler: Perspektivisch werden die Rollen von PO und BD wohl zusammenwachsen.
- Business Analyst (BA): Einige wenige Teams, mit fachlich sehr komplexen Kontexten besitzen zusätzlich einen Business Analysten als Expert*in für ein bestimmtes Thema.
- Technical Designer (TD): Der TD ist ein*e Senior-Entwickler*in, der/die das Team in der Team-externen Kommunikation zu technischen Themen vertritt und intern mit den anderen Entwickler*innen die technische Architektur konzipiert.
- Devs: Die Entwickler*innen bilden das Herzstück jedes Produkt-Teams und sorgen dafür, dass die fachlichen Wünsche in lauffähige Software umgesetzt werden. Devops ist ein integraler Bestandteil aller Teams. Unsere Entwickler sind auch bei der Konzeption der Produkte eingebunden und können so auch ihr technisches KnowHow und Innovationskraft in die Produktentwicklung einfliessen lassen.
- Scrummaster: Sie betreuen bis zu zwei Teams und sorgen dafür, dass soziale Probleme im Team gelöst werden aber auch, dass eine kontinuierliche Verbesserung des Teams mit den Scrum-Methoden stattfindet. Das betrifft sowohl die Softwarequalität als auch die Entwicklungsgeschwindigkeit
Das Produkt-Team vereint in sich damit das komplette Know-how, welches für die Weiterentwicklung des Produkts notwendig ist. Das betrifft insbesondere:
- Fachliche Roadmap
- Softwareentwicklung
- Betrieb
- Kostenverantwortung
- Qualitätssicherung
- Security, Performance, Skalierung, Wartbarkeit usw.
Unternehmens-übergreifend gibt es darüber hinaus noch einen Strategieprozess . Dieser findet alle drei Monate statt. Dabei geht es vor Allem um die Priorisierung von Themen, für die mehrere Teams notwendig sind.
Ein Beispiel für ein Thema, welches mehrere Teams betrifft ist der sog. Kundenstorno - also wenn ein*e Kund*in ein bestelltes Produkt wieder storniert. Hierfür muss (1) die Bestellabwicklung angepasst werden, aber auch (2) die Bezahlung sowie die (3) Partner-Kommunikation. Es werden also mindestens Kolleg*innen aus diesen drei Kontext-Teams benötigt, um dieses Problem zu lösen.
Im Strategieprozess kommen alle POs, plus einiger weiterer Stakeholder, zusammen und bewerten die relevanten Themen gemeinsam. Auf dieser Grundlage können sie entscheiden, ob ein teamübergreifendes Thema entweder gleichzeitig von allen benötigten Teams bearbeitet werden kann oder in die nächste Bearbeitungsphase geschoben wird.
2. Scrum - mit zweiwöchentlichen Sprints als übergreifenden Taktgeber und Arbeitsmethode, um kontinuierliche Verbesserung und Planung in den Teams zu ermöglichen
Alle Teams arbeiten im gleichen, zweiwöchentlichen Takt. Dadurch ist es sehr einfach kurzfristig auf neue Erkenntnisse zu reagieren, weil alle Teams sich in diesem Zeitraum gegenseitig, beispielsweise mit einer neuen Schnittstelle, helfen können. Bei kleineren Herausforderungen, die im Alltagsgeschäft auftauchen, helfen sich alle gegenseitig sofort.
3. Hilfreiche Gremien um Team-übergreifende Aufgaben zu bearbeiten
Wir haben sowohl für die POs als auch für die TDs jeweils eine Austauschrunde eingeführt, damit dort regelmäßig Team-übergreifende Themen angesprochen und gelöst werden können. Für die anschließende Erarbeitung der Lösung bilden wir normalerweise kurzlebige Arbeitsgruppen, die sich aus Freiwilligen zusammensetzen.
4. Regelmäßige Projekt-Insights
Extrem wichtig für unser Projekt, in dem wir uns sehr viele Freiheiten nehmen können, ist Transparenz und Vertrauen. Uns war früh klar, dass nur durch Transparenz das Vertrauen unserer Kolleg*innen in unser Vorgehen gewährleistet werden kann. Da wir nun aber möglichst wenig reporting wollten, waren für uns unsere regelmäßigen Reviews und Showcases wichtig.
- Was verstehen wir unter Review:
Jedes Team führt am Ende jedes Sprint ein Review durch und zeigt anhand der laufenden Software, welche neuen Features (fachlich oder nicht funktional) umgesetzt wurden. Hier nimmt das jeweilige Team sowie Kolleg*innen aus anderen Teams und Stakeholder, die einen besonderem Fokus auf bestimmte Fachlichkeiten haben, teil. Nach der Präsentation der Ergebnisse der letzten zwei Wochen und dem Ausblick auf den nächsten Sprint erfolgt so stets ein guter Richtungs-Check mit den Stakeholdern. - Was verstehen wir unter Showcase:
Alle zwei Wochen präsentieren jeweils zwei Teams, die wesentlichen, neuen Features aller Teams. Hier sind regelmäßig über 100 Kolleg*innen, von dem/der Entwickler*in über den/die Sachbearbeiter*in bis zum Vorstand/ zur Vorständin, dabei. Auf diese Weise wissen alle Interessierten jederzeit sehr gut, wo das Projekt steht und wie wir vorankommen. Wir sind uns bewusst, dass dieses Vorgehen für die präsentierenden Teams aufwändig ist. Genau deshalb rotiert dieser Job, sodass wir die Aufgabe auf verschiedenen Schultern verteilen.
5. Frühzeitige Beachtung nicht funktionaler Anforderungen
Schon sehr früh haben sich insbesondere die TDs überlegt, wie wir garantieren können, dass die nicht funktionalen Anforderungen sichergestellt werden. Dafür haben wir alle Themencluster gesammelt und mit Details versehen. Danach hat jedes Team diese Themen für sich abgeleitet und Stories definiert.
Auf diese Weise war jedem Team bewusst, was zu beachten ist, aber die konkrete Umsetzung liegt trotzdem immer in den umsetzenden Teams. Darüber hinaus haben wir frühzeitig spezielle Support-Abteilungen, sog. Security-Teams, eingebunden, um die Teams bei der Umsetzung zu unterstützen.
6. Internationalisierung: Projektsprache Englisch
Uns war früh klar, wie groß dieses Projekt wird und dass wir viele Entwickler*innen benötigen werden. Wir haben das Projekt also von Anfang an auf die Sprache Englisch ausgerichtet, um auf diese Weise die Möglichkeit zu haben an unserem Standort Hamburg viele nicht-deutschsprachige Entwickler*innen zu integrieren.
So ist auch die Zusammenarbeit mit unseren Entwicklungsteams in Indien problemlos möglich. Außerdem stellte sich nach anfänglichen Berührungsängsten heraus, dass es auch ein großer Motivationsschub für alle Kolleg*innen darstellt, in internationalen Teams zu arbeiten. Für alle, die Interesse haben, werden selbstverständlich Englischkurse angeboten.
Technical Architecture
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.
Step 2: MVP bis Februar 2019
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.
Step 3: Woran arbeiten wir jetzt?
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.
Begriffserklärung
Projekt lhotse
Mit dem Projekt Lhotse wurde der Webshop (www.otto.de) im Jahr 2013 komplett neu entwickelt. Das Projekt war ein großer Erfolg, schon zu dieser Zeit haben wir in verteilten Teams gearbeitet. Wir konnten unser IT-Know-how massiv ausbauen und einen hochmodernen flexiblen Webshop aufbauen.
Domain driven design (DDD)
Domain Driven Design ist eine Arbeitsmethode, um komplexe Geschäftsprozesse in handhabbare Bausteine zu modellieren. Der Hauptgedanke ist dabei, dass die Fachlichkeit das Systemdesign beeinflusst - mit dem Ziel, möglichst unabhängige fachliche Einheiten zu entwickeln. Das passt sehr gut zu der Philosophie von OTTO in unabhängigen Produkt-Teams zu arbeiten.
Event Storming
Event Storming ist eine Methode um innerhalb eines Workshops gemeinschaftlich einen Geschäftsprozess zu verstehen und mit Events, Akteuren und dann Kontexten zu beschreiben. Sie eignet sich besonders um mit vielen Fachexperten relativ schnell gemeinschaftlich Geschäftsprozesse zu modellieren. Event Storming ist oftmals ein sehr schneller Einstieg um dann mittels Domain Driven Design die Soll-Systemwelt noch tiefergehend zu modellieren.
0Noch keine Kommentare
Dein Kommentar
Antwort auf: Direkt auf das Thema antworten
Geschrieben von
Christian Finckler
(ehemaliger) Technischer Architekt bei OTTO
Ähnliche Beiträge
Stefanie04.10.2023Einrichten eines Kanban-Boards in Jira mit Unterspalten
212In diesem Blog-Beitrag möchte ich die Entwicklung unseres Kanban-Boards in Jira vorstellen und erläutern, wie wir die fehlende Funktion der Unterspalten umgangen haben.ArchitekturDevelopmentArbeitsmethoden
Birgit28.07.2023Warum API Guidelines eine coole Sache sind
17Nach einem Standard arbeiten? Echt jetzt? Software-Entwickler*innen wissen doch, wie man APIs baut. Außerdem wollen sie flexibel sein und haben weder Lust noch Zeit, sich durch ein langes Regelwerk zu arbeiten. Und selbst wenn man es gelesen hat, heißt das noch lange nicht, dass man auch damit einverstanden ist. Ja, fair. Aber in der Software-Entwicklung gibt's einige Herausforderungen zu meistern. Vor allem, wenn in autonomen Teams gearbeitet wird und man es mit Unternehmenswachstum zu tun hat. Dieser Post gibt einen Einblick, wie wir bei OTTO zu API Guidelines gekommen sind und sie in die Umsetzung gebracht haben.ArchitekturDevelopmentArbeitsmethoden
