5
.
July
2022
|
Technology
Schon Henry Ford sagte: „Scheitern ist einfach die Gelegenheit, wieder von vorne anzufangen, diesmal intelligenter!“ Seit über 20 Jahren sind wir als Agentur nicht nur beratend, sondern auch in der Umsetzung von komplexen e-Commerce Projekten tätig. Zu unserem Arbeitsalltag bei mediawave gehört scheitern also ebenso dazu, wie unsere vielen Erfolge. Häufig werden in Gesprächen nach den häufigsten Gründen für das Scheitern von Digital Commerce Projekten gefragt. Eines können wir an dieser Stelle bereits verraten: Die Liste ist lang und es gibt keine allgemeingültige Antwort auf diese Frage.
Dennoch haben wir uns Gedanken darüber gemacht und möchten heute den technischen Aspekt dieser Frage genauer beleuchten. Dafür haben wir mit unserem Kollegen Michael Solovev gesprochen, der sich an eine Antwort wagt. Er hat über 15 Jahre Erfahrung im Web Development – vorwiegend im e-Commerce. Dieser Artikel basiert auf seinen Erfahrungen aus dem Projektgeschäft, in dem er seit etlichen Jahren versucht, technische Risiken zu minimieren, Software leichter wartbar, skalierbarer und zuverlässiger zu machen und den Kunden mehr Vertrauen in Ihrer e-Commerce Plattform zu geben. Er möchte dabei die Experimentierfreudigkeit der Kunden fördern und Ihnen stets die beste und schnellste Time-to-Market Lösung liefern.
Doch genug der Vorrede. Lesen Sie nun endlich, warum e-Commerce Projekte scheitern und wie Sie das verhindern.
Mein Name ist Michael. Ich bin seit 2015 als Solution Architekt bei mediawave tätig und bilde in dieser Funktion die Schnittstelle zwischen unseren Entwicklern und unseren Kunden. Ich habe versucht, die (meiner Meinung nach) wichtigsten Methoden und Ansätze zusammenzufassen, die uns dabei helfen, bei der Entwicklung und Integration von komplexen e-Commerce Plattformen für unsere Kunden echte Mehrwerte zu generieren und eine langfristige partnerschaftliche Zusammenarbeit zu etablieren.
Meistens beginnt das Scheitern schon ganz am Anfang des Projekts, mit einem massiven Scope wie diesem:
So entstehen Projektpläne, die von vornherein zum Scheitern verurteilt sind, denn:
Was passiert mit einem so großen und riskanten Projekt? Es wird oft monatelang, manchmal sogar länger als 12 Monate, entwickelt, ohne die Kundenbedürfnisse zu berücksichtigen. Das Budget wird meist signifikant überstiegen und das Entwicklungsteam steht unter großem Druck, was zu massiven Änderungen ohne ausreichend Tests führt. Und das ist schmerzhaft für alle:
Die Entwicklung im Rahmen eines Digital Commerce Projekts unterscheidet sich stark von herkömmlicher Fließbandarbeit. Die Arbeit mit nicht Vorhandenem und Unbekanntem erfordert andere Arbeitsmethoden.
Wenn man 100 Autos eines Modells produziert hat, weiß man, wie viel Zeit gebraucht wird, um ein weiteres zu produzieren und wie man das macht, weil alle Produkte gleich sind. Bei der Projektarbeit hingegen sind es immer andere Situationen und andere Lösungen. Man kann keine genauen Schätzungen abgeben und garantieren, dass die Dinge genau wie bei einem früheren Projekt verlaufen werden.
Wenn man also im Rahmen eines Digital Projekts etwas noch nicht Vorhandenes schaffen möchte, wir sprechen hier von einem sog. Greenfield-Projekt, empfehle ich:
1. Entwickeln Sie zunächst eine Minimal-Version, die verhältnismäßig kosteneffizient und schnell gelauncht werden kann und leicht anzupassen ist.
2. Vertesten Sie das Minimum Viable Product mit einer relevanten Zielgruppe.
3. Beobachten Sie, was gut funktioniert und was nicht.
4. Nehmen Sie Änderungen vor und testen Sie erneut.
In unserer Branche nennen wir eine solche Minimal Version ein "Minimum Viable Product" oder einfach "MVP".
Ich gebe ein Beispiel aus der Stadtarchitektur, das hilft, die Idee des MVPs zu verstehen. Es handelt sich um den Wiederaufbau des Times Square 2010-2017. Was ein MVP in der Praxis bedeutet, sieht man, wenn man das Bild in der Mitte betrachtet. Die Fußgängerzone wurde zunächst als temporärere Lösung eingeführt, um zu beobachten, ob und wie es von der Bevölkerung angenommen wird und wie sie genutzt wird.
Das Projekt ist also klar: Umgestaltung einer stark befahrenen Straße in eine Fußgängerzone. Welche Schritte braucht es hier?
1. Einrichtung von Fußgängerzonen mit einfachen und leicht zu ändernden Lösungen (Verwendung von Farben um bestimmte Zonen zu definieren, Bäume als Abgrenzung etc. in Töpfen, usw.)
2. Beobachten, wie die Menschen diesen neuen Raum nutzen, was sie tun und was anscheinend noch fehlt
3. Ständige Veränderung des Bereichs, um ihn an die Bedürfnisse der Menschen anzupassen
4. Schlussendlich: Einrichtung bzw. Umsetzung permanenter Optimierungsmaßnahmen
Der gleiche Ansatz eignet sich auch für Digital Commerce Projekte:
1. Go-Live mit einem MVP: begrenzter Katalog und Checkout, fast keine Integration zu anderen Systemen, begrenzte Funktionen, einfache und leicht zu ändernde Layouts, keine Datenmigration
2. Erfassen des Nutzerverhaltens: wir wollen sehen, wonach die Leute suchen, welche Produktattribute für sie am wichtigsten sind, was sie auf dem Weg zum Kauf ablenkt oder unterbricht, usw.
3. A/B-Tests durchführen: wir wollen herausfinden, was am besten funktioniert
4. Übernehmen der besten Ergebnisse und Lösungen in die Codebasis
Grundsätzlich verfolgen wir den MVP-Ansatz mit unseren Kunden, weil wir verschiedene Ebenen prüfen wollen:
Zudem ermöglicht dieser Ansatz natürlich einfach Anpassungen vorzunehmen, bevor die Änderungen teuer werden. Die Idee hinter einem MVP ist sehr einfach: Erst testen, dann investieren und somit Investitionen absichern.
Im vorangegangenen Teil habe ich bereits erwähnt, dass Misserfolg oftmals mit einem zu großen, anfänglichen Umfang und somit einer hohen Gesamtkomplexität einhergeht. Was passiert nun normalerweise als Nächstes und führt so zum Scheitern des Projekts?
1. Massiver anfänglicher Umfang mit vielen Funktionen in kurzer Zeit und knappem Budget
2. Permanent steigende Komplexität aufgrund immer mehr Änderungswünsche
3. Fehlerbehebung und keine Zeit für Regressionstests
4. Der Kunde gerät in Stress und verliert das Vertrauen in das Produkt und das Team
5. Vertrauensverlust und als Folge davon -Überkontrolle und Mikromanagement
6. Das Team ist frustriert und verlässt das Projekt
7. Neue Entwickler werden mit altem Code ohne Tests, Dokumentation und mit vielen Fehlern konfrontiert
8. Wechsel der Agentur, Wechsel zu einer anderen e-Commerce-Plattform oder Beendigung des Projektes
Regelmäßig kommen Unternehmen auf uns zu, weil sie schlechte Erfahrungen mit einer anderen Agentur gemacht haben. Manchmal werden Projekte sogar vor dem Launch gestoppt, weil das Budget überschritten wurde oder das gesamte Projekt von der Geschäftsleitung eingestellt wurde. Auch wir haben in der Vergangenheit schon einmal die Fehler gemacht, wodurch gelernt haben, wie man die Dinge richtig macht.
Wir haben gelernt, dass ein Schlüsselfaktor für gute und finanziell erfolgreiche Projekte ein angemessenes Risikomanagement ist. Der richtige Weg eines typischen „gesunden“ Projekts sieht folgendermaßen aus:
1. Reduzieren des Projektumfangs zu Beginn auf das geringstmögliche Maß (MVP)
2. Experimentieren und Ergebnisse beobachten (A/B-Tests und Tracking)
3. Aufbau einer soliden Teambeziehung und vertraut machen mit den Arbeitsabläufen und der Technologie
4. Abdeckung der Code-Änderungen mit automatisierten Tests (Automatisierte Regressionstests)
5. Überprüfen Sie regelmäßig technische Schulden und leiten Sie daraus entsprechende Maßnahmen ab.
Da die Vorteile eines MVPs bereits in den vorangegangenen Teilen diesesArtikels dargelegt wurden und auch A/B-Tests und Tracking klar sind, möchte ich tiefer auf automatisierte Tests und technische Reviews eingehen und warum sieso wichtig sind.
Nehmen wir an, Sie möchten Ihrem Shop ein Banner hinzufügen, den Sie jenach Log-in Status des Nutzers aktivieren oder deaktivieren möchten, da es aufbeispielsweise auf Aktionen hinweist, die nur für eingeloggte Nutzer gelten. Außerdemmöchten Sie festlegen können, in welchen Zeiträumen dieses Banner angezeigtwird:
Hier ein Diagramm der Komplexität der Konfigurationsmöglichkeiten:
Offensichtlich wächst die Komplexität exponentiell mit der Anzahl der Funktionen, die Sie haben:
Nehmen wir an, Sie verbringen 15 Minuten damit, einen Zustand manuell zu testen und die Zeit des manuellen Testings steigt von 30 Minuten für eine Konfiguration auf 2 Stunden 15 Minuten für 3 Konfigurationen.
Gehen wir davon aus, das das Hinzufügen einer dritten Einstellung 1 Stunde Entwicklung in Anspruch nimmt. Der Stundensatz für Ihr Team beträgt 150 Euro pro Stunde. Sie erhalten nun also folgende Zeitbuchungen:
Das bedeutet, dass Sie 1.162,50 Euro ausgegeben haben, von denen nur ca. 13% hochqualifizierte Arbeit sind (Programmierung) und 87% niedrig qualifizierte Arbeit (manuelle Tests). Wenn Sie in automatisierte Tests investieren, sieht das Bild so aus:
Sie geben nun 525 Euro aus, wobei der Anteil der hochqualifizierten Arbeit bei ca. 86% und der Anteil der niedrigqualifizierten Arbeit bei14% liegt, da Sie die Funktionalität der neu hinzugefügten Einstellung noch bestätigen müssen. Der Rest wird automatisch getestet.
13% vs. 86% der hochqualifizierten Arbeit mit 150 Euro pro Stunde = 1.162,50 Euro vs. 525 Euro.
Eine solche Strategie half unseren Kunden, Teile des zuvor geplanten und ungenutzten Budgets in Innovationen und mehr Beratungsleistungen zu investieren.
Wir haben auch einen positiven Nebeneffekt nach der Einführung automatisierter Tests in unserem Lieferprozess festgestellt: Die Entwickler überarbeiten ihren Code dahingehend, um ihn weniger fehleranfällig zu machen. Das Schreiben automatisierter Tests verändert somit nicht nur das Mindset, sondern motiviert die Entwickler, da sie das Gefühl haben, an einem stabilen und gut getesteten System arbeiten. Ein weiterer interessanter und positiver Nebeneffekt ist eine kürzere Einarbeitungszeit für neue Entwickler. Automatisierte Tests helfen dabei, sich mit einem Projekt schneller vertraut zu machen und erfordern weniger Kontrolle, da Fehler, die aufgrund mangelnder Projektkenntnisse entstehen, mit einer sehr hohen Wahrscheinlichkeit durch das automatisierte Testsystem abgefangen werden können.
Adobe Commerce verfügt beispielsweise über ein eigenes Automated Testing Framework, das es von Haus aus erlaubt, folgende Dinge automatisch zu überprüfen:
Anhand des Beispiels des Adobe Commerce Automated Testing Frameworks werden auch Berichte mit den Ergebnissen dieser Tests erstellt, die wie folgt aussehen:
All dies trägt dazu bei, die Markteinführungszeit für neue Funktionen oder Änderungen erheblich zu verkürzen, da signifikante Anteile des Gesamtaufwands häufig auf das Testen entfallen. Ständige Änderungen und Experimente erfordern außerdem eine kontinuierliche Überprüfung technischer Schulden. Manche Dinge werden vielleicht nur für kurze Zeit implementiert, um zu sehen, ob die Kunden sie nutzen. Wenn das Team keine Zeit aufwendet, um den Legacy-Code zu verbessern, werden sich natürlich die Probleme häufen und somit die technischen Schulden schneeballartig zunehmen.
Unsere Lösung bestand in diesem beispielhaften Projekt darin, alle ein bis zwei Monate ein technisches Review vorzunehmen. Das Ziel ist es hierbei, die Logs, die angeschlossenen Dienste und unseren benutzerdefinierten Code zu überprüfen sowie Aktualisierungen der von uns verwendeten Module und neuen Funktionen des Frameworks vorzunehmen. Auch die Erstellung von Folgetickets, um Fehler zu beheben, Funktionalitäten weiterzuentwickeln und Code zu bereinigen gehört dazu. Das alles hilft dabei, die Eigenverantwortung des Entwicklerteams zu stärken und um das Projekt permanent in einem guten Zustand zu halten.
Wenn Sie ein neues Projekt mit neuen Leuten, neuer Technologie und neuen Ideen beginnen, kann vieles schief gehen. Hier sind unsere wichtigsten Erkenntnisse, wie man es richtig macht:
Planen Sie ein Budget, das ausreicht, um mit einem minimalen Satz von Funktionen (MVP) live zu gehen. Lernen Sie dann von Ihren Kunden und beobachten Sie deren Interaktion. Sammeln Sie Feedback, probieren Sie verschiedene Szenarien aus und finden Sie heraus, was Ihnen das beste Ergebnis bringt. So werden Sie auch sehen, wie Ihr neues Team arbeitet und welche Anpassungen es möglicherweise braucht. Außerdem lernen Sie das gewählte e-Commerce System mit seinen Funktionen, Leistung, Stärken und Schwächen kennen.
Nutzen Sie den Vorteil von automatisierten Regressionstests. So können Änderungen häufiger vorgenommen werden und Sie können sicher sein, dass diese nicht in anderen Bereichen des Unternehmens zu Fehlern führen. Investieren Sie nicht in gering-qualifizierte Arbeit –versuchen Sie, die Tests so weit wie möglich zu automatisieren. Das verlängert Ihre Produktlebensdauer, hilft dabei, Entwickler schneller an Bord zu holen. Außerdem wird der Code stabiler und lässt sich leichter ändern. Automatisiertes Testen verbessert die Wartbarkeit und reduziert die Kosten für Weiterentwicklung enorm.
Der Grund dafür ist, dass man Dinge ausprobiert, ohne viel Zeit darauf zu verwenden, sie solide zu machen. Das ist gut so, denn man will erst einmal sehen, ob die Dinge überhaupt funktionieren, bevor man sie perfekt macht. Man muss sich einfach daran gewöhnen, mit technischen Unreinheiten zu arbeiten und seinen Code zu überprüfen, um festzustellen, welche Teile verfeinert oder entfernt werden müssen. Erstellen Sie einfach ein passendes Folgeticket für jedes Ihrer Ergebnisse. Machen Sie die Überprüfung der technischen Schulden einfach zu Ihrer monatlichen Routine.
Irgendwie klingt das Meiste davon ziemlich offensichtlich und einfach, aber es hat Jahre gedauert, diese Erfahrungen zu sammeln, die Nuancen zu verstehen und die Kunden an unsere Arbeitsweise zu gewöhnen.
Sollten Sie ein Replatforming oder ein neues Digital Commerce Projekt planen, freuen wir uns, unsere Erfahrung mit Ihnen zu teilen und Sie auf Ihrem Weg zum digitalen Champion tatkräftig zu unterstützen.
