Es ist viel Bewegung im Technologiemarkt für wachsende Commerce Modelle. Es gibt nur wenige Commerce Modelle die stark wachsen, und die zeichnen sich zum Endkunden damit aus regelmäßig relevante Dinge auf die Desktopseite, in die App oder in die Voice Schnittstelle zu deployen. Dann gibt es wieder Commerce Modelle mit riesigen IT Teams, aber irgendwie kommt da nur wenig kundenrelevantes vorne an. Warum eigentlich? AboutYou ist eines der Modelle bei dem viel passiert und die eine sehr pragmatische Vorgehensweise haben, die fast 1:1 dem von Spryker entspricht. Mit dem Gründer und CTO von AboutYou habe ich u.a. darüber gesprochen, warum die gerade so populäre Microservices Sicht für die meisten Onlinemodelle nicht zielführend ist bzw. die meisten Unternehmen die davon sprechen eher einen „Distributed Monolith“ bauen und damit die Nachteile aller Softwarewelten vereinen. Im ersten Teil des Interviews erzählt er darüber wie AboutYou zu dieser Erkenntnis gelangt ist und wie man auch mit über 100 Leuten in der Produktentwicklung noch pragmatisch steuern kann, und wozu man noch weitere Entwickler in den Marketingabteilungen braucht. Und wie man diese Teams dann organisiert. Und wie man den Shift von Desktop zu Mobile meistert. Und und und und….
Sehr sehr spannend! Ich habe eine Menge gelernt und der zweite Teil (kommt Anfang nächster Woche hier auf Kassenzone) ist ebenso spannend. Sebastian spricht auf der bereits fast ausverkauften Code.Talks Commerce Conference in Berlin Ende April über diese Learnings. Die Conference richtet sich an Developer und Leute im E-Commerce die mit der Produktentwicklung zu tun haben. Mit dem Code „Kassenzone-ctcs-10“ sind die Tickets etwas günstiger!
Die Kassenzone Interviews sind verfügbar bei:
Soundcloud, iTunes, Youtube, Facebook oder per RSS-Feed
PODCAST & Interview Transkription – für alle Leser, die Audio & Video nicht so gerne konsumieren. Die Transkription wird gesponsert von PAYBACK – hier mehr erfahren und App herunterladen.
Online-Technologie mit Sebastian Betz, AboutYou
Sebastian ist Geschäftsführer IT bei AboutYou. In diesem Podcast geht es darum, was es eigentlich heißt, ein „Tech-Unternehmen“ zu sein – was viele Einzelhandelskonzepte neuerdings von sich behaupten. Ebenfalls Thema: Wie man ein Shop-System in der Größenordnung von AboutYou konkret baut. Wer sich aus entwicklungstechnischer oder betriebswirtschaftlicher Sicht für diese Fragestellung besonders interessiert, ist zu den Code-Talks Commerce Special am 27.04-28.04 in Berlin eingeladen. Podcast-Zuhörer bekommen sogar vergünstigte Tickets (einfach mal am Anfang reinhören…)
„Dass die Leute das verstehen, was sie da bauen, ist elementar wichtig“
2:30
Alex: Wie seid ihr eigentlich bei der Gründung von AboutYou damals vorgegangen?
Sebastian: Wir sind auf der grünen Wiese gestartet – sprich: Wir hatten gar nichts. So bestand der Fokus darin, schnell die Produkte zu entwickeln, die wir brauchten. Wir fingen mit dem Shop an und bauten parallel ein Backend-System, dass die Bestellungsabwicklung sicherstellt und in der Lage ist, Stammdaten und Bestände zu übertragen, zu verarbeiten, und zu interpretieren. Dazu kam das Purchasing-Management, womit wir imstande sind, unsere Einkaufsprozesse erstmal abzubilden und dann zu optimieren.
Vom Anfang an galt es, alles selber zu bauen, was Prozesse optimieren und uns folglich hebeln kann. Also: Fast die ganze Infrastruktur. Wir legten mit 10 Mitarbeitern im IT-Bereich los: Mittlerweile sind wir etwas mehr als 100 Tech-Leute. So haben wir fast alle Kompetenzen in house und entwickeln agil in den einzelnen Teams. So haben wir sehr kurze Integrationszeiten und können uns darauf konzentrieren, die besten Produkte für unsere Kunden zu entwickeln.
Alex: Wie habt ihr denn entschieden, welche Kompetenzen ihr braucht? Und alles ganz neu zu bauen – diese Diskussion haben wir bei Spryker geführt – ist ja ein großer Wurf: eigenes PIM-System, eigener Shop… Wie individuell ist das, was ihr gebaut habt?
Sebastian: All die Sachen, die für Endkunden sichtbar sind – Shop, Mobile App & Co – Die müssen auf jeden Fall in unserer Hand liegen. Nur wenn wir diese Sachen selber entwickeln können, sind wir überhaupt in der Lage, die Produkte und die Experience für unsere Kunden zu optimieren. Dann haben wir bei Backend-Systemen geguckt, was es überhaupt so gibt: So in Bereichen wie Einkaufsschnittstellen, Warenverfügbarkeit und anderen internen Prozessen – Sachen, die dem Kunden gegenüber gar nicht sichtbar sind. Das sind 8-10 Systeme, die nun bei uns intern entwickelt werden.
Alex: Habt ihr auch ein eigenes System für Mobile?
Sebastian: Klar: Desktop- und Mobile-Site sowie Mobile-App sind für uns Kundenschnittstellen. Auch unser Check-Out ist ein Eigenprodukt, das wir für all unsere Shops nutzen. Weil das alles Customer-Interfaces sind.
6:50
Alex: Eurer Mitgründer Tarek sagt, es gibt zwei treibende Business-Units: Marketing (seinen Bereich) und IT (deinen Bereich). Der Rest – Einkauf, Finanzen usw. folgt dann. Ist das, simpel gesagt, euer Erfolgsgeheimnis?
Sebastian: Wir glauben sehr stark daran. Alle drei Themen – Operations & Co., Marketing, und IT – brauchen Menschen, die sich dafür verantwortlich fühlen: In diesem Fall Hannes, Tarek, respektive meine Wenigkeit.
Wir sind jetzt in Summe bei gut 300 Mitarbeitern. So sind wir zu über einem Drittel wirklich Tech. Die anderen zwei Drittel teilen sich dann auf Marketing und Operations auf. Wobei wir auch in den anderen Bereichen Tech-Leute sitzen haben, vor allem im Marketing: Attribution, Web-Tracking und –Analytics, usw. Dabei entscheidet Marketing was gemacht werden soll. Das Wie wird dann mit der IT abgesprochen.
Das ist extrem wichtig, denn wir haben eine sehr harmonische Systemlandschaft. Darin dürfen sich keine SIlos aufbauen, die sehr stark von den technologischen Kompetenzen einzelner Leute abhängen. Sonst hat man Systeme, die man nach vorne raus nicht mehr richtig warten kann.
(Alex will wissen, wie Sebastian selber zu den Tech-Stacks steht. Wie stark setzt er auf PHP? Welche Rolle nehmen komplexere Sprachen ein? Sebastian antwortet, dass es bei den allermeisten Funktionen relativ gleich sei, welche Programmiersprache benutzt wird. Wichtiger sei die Architektur.
PHP nehme sich aber allein deswegen sehr stark aus, weil es eben viele Entwickler gebe und das Ökosystem dafür sehr groß sei. Darüber hinaus sei es wichtig, dass alle in der Firma dieselbe Programmiersprache verwenden: So könne jeder sich überall einarbeiten und neue Teams für verschiedene Projektschwerpunkte gebildet werden. Auch neue Mitarbeiter könnten dann in drei oder vier Werktage das Onboarding absolvieren. Die Verständlichkeit des Quell-Codes habe daher immer oberste Priorität.
Alex kontert, dass das zwar einfach gesagt, aber nicht leicht umgesetzt ist. Bei Spryker, was ja ein Framework ist, könne man viel mehr Zeit für soliden, sauberen Code aufwenden. Aber im tagtäglichen Betrieb sei das sicherlich viel schwieriger, weil Lösungen schnell rausmüssten.)
13:30
Alex: Wie schafft ihr es denn, dass der Code trotz alltäglicher Anforderungen auch die Prinzipien einhält?
Sebastian: Da sind wir eben sehr strikt. Wir haben sehr umfassende Guidelines, die mit unserer Philosophie beginnen, wie Software geschrieben werden soll. Was ist unser Verständnis von gutem Code? Was sind unserer Erwartungen an Wartbarkeit und Qualität? Das versuchen wir sofort im Onboarding-Prozess auch zu vermitteln. Und wir sind sehr restriktiv damit, wie der Code aussehen soll.
Dabei definieren wir guten Code anders als in so einem Lehrbuch für Software-Entwicklung. Uns ist beispielsweise wichtig, das man alles gut kapseln kann, damit jeder versteht, was jedes Stück Code macht. Es geht um Simplizität. Lieber soll der Code so einfach wie möglich gebaut sein. Die Funktion soll ersichtlich sein, damit man nicht ständig die Dokus durchforsten muss und gut durch den Quell-Code durchnavigieren kann. Alle Komplexitäten sollen daher so weit wie möglich weggekapselt sein.
Dabei tagt bei uns kein Board, der drüber guckt, bevor es live geht. Uns ist Geschwindigkeit extrem wichtig. Was wir aber schon machen, sind klassische Review-Termine, in denen wir Code-Feedback geben. Pro Unit haben wir einen Tech-lead, also sechs im Unternehmen, sowie ein-bis-drei Lead-Developer innerhalb jeder Unit.
Alex: Führt das dazu, dass Autodidakten aus der TYPO3-WordPress-Welt einen längeren Anlernprozess haben?
Sebastian: Das kann man so gar nicht sagen. Ziel ist, dass du unseren Code immer gut verstehen kannst – egal aus welcher Richtung du kommst. Und deswegen ist unser Quell-Code eben keine Raketenwissenschaft und somit gut zugänglich. Unser Motto ist ja: Umso einfacher der Quell-Code, desto besser ist der auch.
17:50
Alex: Es kursiert auch die Theorie, dass man ohnehin alle fünf Jahre alles neu bauen muss, weil weder du noch ich weiß, wie übermorgen verkauft wird. Musstet ihr schon mal neu bauen? Oder habt ihr beim Start ein belastbares Fundament gegossen, auf dem ihr seitdem aufbaut?
Sebastian: Wir mussten schon neu bauen – vor allem aus Learnings, die wir machten: Bei Prozessen, Stammdaten, Händler-Integration… Wir hatten anfangs sehr stark auf Micro-Services gesetzt, was per se auch nicht falsch war, um dann festzustellen, dass wir die Applikationen teilweise falsche geschnitten hatten. So hatten wir Prozessketten, die drei oder vier Micro-Services durchlaufen mussten, um am Ende ein fertiges Produkt zu haben.
Wir merkten, dass wir jeden einzelnen Prozess-Schritt überwachen mussten. Und allein dieses Monitoring ist so komplex, weil man für jede Abänderung an jedem Produkt jedes einzelne System durchsuchen und dann anpassen muss.
Das zweite Learning war Skalierbarkeit. Vor zwei Jahren hatten wir „Crazy Christmas“ und machten um Weihnachten herum sehr viel Umsatz. Dabei stellten wir fest, dass das System bei Echtzeit-Verfügbarkeit und -Handling im Shop noch Verbesserungspotenzial aufwies. So haben wir das komplette System mit einem kleinen Team komplett neugemacht und sind dann mit einem Big-Bang live gegangen. Das alte System haben wir dabei ausgetauscht gegen das neue, was genau richtig war.
20:45
Alex: Mich würde eurer IT-Organisation interessieren. Du hast ja früher eine Agentur aufgebaut in Darmstadt und bist dann hier mit 10 Leuten in einem Raum gestartet: Die kann man wahrscheinlich gut auf Zuruf steuern. Jetzt habt ihr sechs Units und eine ganze Menge Developer. Wie steuert man das? Und wo kommen die Impulse? Sagt Marketing, was es braucht? Wo kommt die Road-Map her?
Sebastian: Im Endeffekt haben wir Units, weil wir flexibel sein wollten. Bei 12 oder 15 Teams, die alle agil entwickeln, funktioniert es auch. Das Problem ist aber, dass man Fokusthemen schlecht vorhersehen kann: Was ist in einem Monat das Allerwichtigste etwa bei Personalisierung? Das betrifft dann viele Sub-Teams.
So haben wir uns für Units entschieden, die jeweils einen Themenbereich umfassen. Themen können dabei so etwas wie Device/Mobile sein, oder Backend-Prozesse; Check-out/Zahlung/Bestellungsabwicklung wäre auch so ein Bereich. Innerhalb jeder Unit haben wir dann einen Tech- und einen Produkt-Lead. Letzterer ist als Führungsperson damit beschäftigt, die Prioritätslisten zu managen und Feedback von Stakeholdern aufzunehmen. Jede Unit hat nämlich viele davon: Einkauf, Marketing, Geschäftsführung – also uns. Wir gehen mit dem Produkt-Lead die Prioritäten durch und dann wird das mit dem Tech-Lead besprochen.
Er ist dafür zuständig, dass alles nach unseren Coding-Prinzipien umgesetzt wird, dass wir das so aufbauen, dass wir es hoffentlich so bald nicht wieder wegschmeißen müssen. Darunter haben wir dann die Circles. Diese sind vergleichbar mit Teams, die beispielsweise die Desktop-Seite bearbeiten. Oder – in etwas Spezifischer – Buying-Prozesse oder Inspiration auf der Desktop-Seite. Sie sind so etwa in Scrum-Größe: Und für uns ergibt es Sinn, die Dev-Teams kleinzuhalten: Hier greift schnell Brooke‘s Law. Wenn du eine Pizza bei einem Pizza-Bäcker bestellst und sie braucht 15 Minuten, kriegst du die nicht dadurch schneller, dass du drei Pizza-Bäcker zusätzlich an den Auftrag dransetzt. Du brauchst dann sogar länger.
Das ist etwas simplifiziert, aber die Geschwindigkeit der Entwicklung korreliert eben nicht mit wie vielen Leuten du darauf hast. Deswegen kleinere, dafür flexiblere Teams. Die Zahl ist dynamisch und Unit-spezifisch. Sie ist auch wechselnd. Alle neun Monate machen wir eine Retrospektive: Pro Unit machen wir die Fokus-Themen aus und schneiden die Circles dann nach diesen Themen. Anforderungsgetrieben können wir dann alles von zwei bis fünf Circles haben.
(Auf Anfrage geht Sebastian näher darauf ein, welchen Themen auf welchen Ebenen sich Circles widmen – und warum. Danach will Alex wissen, ob bestimmte Arbeitsumfänge wie Desktop oder Mobile oder About-You-Produkte wie Edited herausgekapselt und an andere Standorts vergeben werden könnten. Sebastian verneint: Umfänge seien zwar aus Entwicklungssicht ein Stück weit trennbar, aber was in einer bestimmten Kapsel gut funktioniert, werde mit hoher Wahrscheinlichkeit flächendeckend übernommen. So würde er sich immer für mehr Entwickler vor Ort als für neue Standorte entscheiden. Die persönliche Kommunikation sei zudem für den Erfolg von Projekte über mehrere Funktionen hinweg entscheidend. In einem Umfeld, in dem alle Produkte weniger miteinander vernetzt seien – etwa WordPress – könne man bestimmt besser mit verschiedenen Teams in aller Welt arbeiten. Bei AboutYou würde das nicht funktionieren.)
30:45
Alex: Ihr stellt als Pure-Play Produktdaten und Marketing als ihre Kernkompetenzen nach vorne – und den Rest kann salopp gesagt Hannes machen. Bei Unternehmen aus der analogen Welt ist aber die IT das lästige Cost-Center. Zwar sind Teams bei Legacy-Unternehmen nicht klein, aber sie sind keineswegs führend. Sie müssen halt dafür sorgen, dass der ganze Kram online geht – zu möglichst geringen Kosten.
Können diese Unternehmen so eine flexible Organisationsstruktur wie die eure einfach übernehmen, oder müssen sie das neu aufbauen? Innerhalb der Otto-Gruppe tauscht ihr euch nämlich bestimmt aus.
Sebastian: Ich glaube das ist von Unternehmen zu Unternehmen unterschiedlich. Einer der größten Treiber dabei ist die Größe des Tech-Teams. Bei meiner früheren Firma CreativeTask mit 10-15 Mitarbeitern konnte man, wie du vorhin kurz erwähntest, rumlaufen und alles per Zuruf steuern. Du brauchst andere Prozesse, um effizient zu sein, wenn das Unternehmen 50-200 Leute hat. Und wenn du allein 200 Tech-Mitarbeiter hast, sieht es wiederum anders aus.
So gibt es meiner Meinung nach keinen einen Prozess, den man auf alle Unternehmen raufdrücken kann. Was es aber schon gibt, das sind dieselben Kerndisziplinen, die man immer wieder meistern muss. Eine davon ist: Organisationaufbau. Für uns ist es sinnvoll, die kleinen Teams zu haben, die mit spezifischen Prio-Listen arbeiten. So kann man alles granular steuern.
(Alex will wissen, wie viele Themen bereichsübergreifend sind und welche schon in Circles gelöst werden können. Er fragt, wie oft Ergebnisse umgesetzt und wie sie ausgewertet werden. Sebastian erklärt, dass fast alle Themen – ob Personalisierung oder Artikeldaten, ob Suche oder Busiuness-Intelligence – mehr als ein Circle betreffen. So gehe es um die genaue Aufteilung der Arbeitspakete und deren Koordinierung zwischen den Circles. Es gebe aber äußerst selten das eine große Board, auf dem alles zusammenläuft und auf dem eine Übersicht präsentiert werden soll.)
35:00
Alex: Damals bei Otto gab es immer so ein großes Tracking-Board, da alle drei-vier Jahre an einem großen Relaunch gearbeitet wurde. Da hatte man das Gefühl, keine Feature-Requests reingeben zu können, weil die Antwort immer war: „Es geht in einem Dreivierteljahr live“. Das zerstört jegliche Team-Dynamik. Ihr löst das mit kleinen Teams und kleinen Schritten…
Sebastian: Wobei ich nicht weiß, ob das auch für viel größere Organisationen so anwendbar ist. Das ist aber das, was wir für uns bei AboutYou in den letzten drei Jahren gelernt haben. Das nächste Thema sind Arbeitszyklen: Wir sind weg von drei-vier Monaten auf fast tägliche Releases runter.
Was auch noch sehr wichtig ist: Das Drumherum. So ein Software-Entwicklungsprozess ist mehr als das reine Code-Schreiben. Es geht auch darum, wie deine Server-Architektur aussieht, wie die Dokumentation der Schnittstellen angelegt ist, wie Deployment und Testing organisiert wird. Wenn das alles nicht stimmt, kann das die Entwicklung lahmlegen. Auch ist es wichtig, dass alle Zugriff auf die aktuellsten Datensätze haben und nicht mit veraltetem auskommen müssen.
Ein weiterer wichtiger Punkt: Das Anforderungsmanagement. Wir versuchen zu optimieren, wie Anforderungen geschrieben werden. Eine Anforderung für eine Frontend-Interface zu formulieren, ist komplett was anderes, als eine Anforderung für einen Backend-Prozess zu schreiben. Vor allem letzteres muss man für einen Developer so verständlich aufbereiten, dass er den ganzen Prozess nachvollziehen kann. Gerne visualisiert. Je nachdem, wie das Ticket geschrieben wurde, variiert die Geschwindigkeit und die Qualität der Umsetzung.
Deswegen haben wir eine Process-Management-Abteilung bei uns etabliert, die nicht nur auf die Einhaltung von Kanban- und Scrum-Entwicklung innerhalb der einzelnen Circles achtet, sondern auch dafür Sorge trägt, wie Anforderungen geschrieben und präsentiert werden. So machen sie auch Tests: Sie legen Circle A dies und Circle B das vor, um festzustellen, ob es einen Effekt auf die Geschwindigkeit oder die Qualität gibt. Wir merken, dass das ein großer Hebel ist: Letztendlich sagen die Anforderungen, was die Developer tun sollen. Sind sie zu schwammig formuliert, verlieren Entwickler Zeit mit dem Versuch, sie zu verstehen – oder alle denkbare Cases umzusetzen.
39:00
Alex: Wo kommen denn bei euch die meisten Anforderungen her? Marketing? Einkauf? Und prämiert ihr die am besten formulierten Anforderungen im Sinne der guten Beispiele?
Sebastian: Es kommt auf das System an. Bei der Einkäufer-Schnittstelle sind die Leute, die damit arbeiten, die Stakeholder und so diejenigen, die meisten Anforderungen reingeben. Beim Backend sowie Komponenten wie Desktop und Mobile kommen aber die Impulse eher aus dem Tech-Bereich selbst. Da entsteht 80-90% von dem, was entwickelt wird, aus der Produkt-Sphäre heraus.
Bei den Anforderungen sind wir davon weggegangen, dass der Ideenurheber die immer selber formulieren soll. Er macht einen Feature-Request, der vom Produkt-Lead dann in eine Anforderung übersetzt wird und dann im Circle in eine Story übertragen. Wir machen Trainings mit den Leuten: Wir setzen uns hin, lassen sie die Stories vortragen, und fragen uns: „Wenn ich dasselbe entwickeln würde, würde ich das so verstehen? Könnte ich damit arbeiten, wenn ich erst eine Woche hier wäre?“ Durch die Brille geben wir dann Feedback. Dass die Leute das verstehen, was sie da bauen, ist elementar wichtig.
(Alex fragt, ob sie diese Herangehensweise selber im Trial-and-Error-Verfahren entwickelt oder sich mit anderen Firmen dazu ausgetauscht haben. Sebastian erklärt, dass der Blick in andere Firmen – vor allem in USA – schon wichtig war und ist. Im Zweifel sehen sie aber intern nach jedem Sprint, nach jeder Iteration, was gut und was schlecht lief, und passen dann selber Prozesse an. Im IT-Bereich gebe es nie die eine goldene Lösung, weil jede Firma anders sei.)
42:00
Alex: Bei euch habe ich das Gefühl, dass ihr euch so ungefähr jedes Ticket noch selber anguckt. Mir scheint es, als ob Tarek noch höchstpersönlich das Facebook-Profil optimiert. Bei der Umsatzgröße, die ihr erreicht habt, ist das zwar honorabel und ehrenwert. Aber kommt irgendwann der Punkt, wo ihr das soweit abgeben könnt, dass ihr – sagen wir mal – drei Monate in den Urlaub fahren könntet? Ohne dass die Umsätze oder die Code-Qualität sinken…
Sebastian: Ich bin zwar tief in allem Themen drin, aber es ist definitiv nicht so, dass alles in sich zusammenfallen würde, wenn ich paar Monate weg wäre. Wir haben eine sehr gute Führungsebene aufgebaut, die in diesen ganzen Prozessen sehr involviert ist. Wir schreiben die Coding-Guidelines zusammen, überlegen zusammen, was wir besser machen könnten.
Es ist wichtig, dass ich noch drin bin, das alles verstehe, und Anreize gebe – was eine meiner Hauptaufgaben ist. Ich bin letztendlich quasi der einzige, der jedes einzelne Team sieht und weiß, woran sie arbeiten und wie sie arbeiten. So kann ich sehen, wo es Sinn macht, generell zu optimieren, oder wo es eher zielführend ist, ein einzelnes Team zu optimieren. Wäre ich nicht da, würde längst nicht alles zusammenbrechen, aber eben diese Arbeit müsste dann ein anderer machen.
Alex: Und bekommt ihr regen Besucherverkehr aus der Otto Gruppe von Leuten, die sich fragen, wie ihr das eigentlich macht?
Sebastian: Es laufen nicht ständig welche rum, die sich das angucken wollen, aber Interesse daran ist vorhanden…
Alex: Salesforce hat eine Besucher-Abteilung eingerichtet, die täglich zwei Gruppenführungen anbietet. Nachfrage wäre bei euch, glaube ich…
Sebastian: Wobei wir auch mal zur Otto Group rübergehen. Sie haben auch ein sehr großes Know-How. So ist es nicht wie ein Zoo-Besuch, wenn sie hier sind, sondern eher ein Austausch auf Augenhöhe.
(Da Alex noch nicht dazugekommen ist, Fragen aus der WhatsApp-Gruppe zu stellen, entscheidet er sich für eine Pause. Im zweiten Teil des Podcasts wird es darum gehen, was einen guten Shop ausmacht: Welche Features sind notwendig, wie baut man sie, wie testet und skaliert man sie?)