Ob durch steigende Kundenerwartungen oder komplexer werdende technische Anforderungen – monolithische E-Commerce-Systeme stoßen immer öfter an ihre Grenzen. Wenn Sie aktuell über einen Shop-Relaunch samt Plattformwechsel nachdenken, bietet sich Composable Commerce an. Worauf Sie im Hinblick auf eine erfolgreiche Umstellung und die richtige Vorgehensweise bei ihrer Einführung achten sollten, haben wir für Sie kurz zusammengefasst.

1. Kühlen Kopf bewahren und den Status checken

Bevor Sie in die Relaunch-Planung Ihres Shops einsteigen, erfassen Sie zunächst den Ist-Zustand Ihres Alt-Systems. Ermitteln Sie, ob wirklich handfeste Gründe für einen Shop-Relaunch vorliegen. Kriterien hierfür können Anforderungen Ihrer Kunden, aber auch zu erwartende Aufwände für den Support, die Erweiterung um neue Funktionalitäten, Schnelligkeit und Wartung sein. Gleichen Sie diese Faktoren mit den Aufwänden ab, die Ihnen der Umstieg auf eine Composable Commerce Architektur bietet.

2. Klarheit finden und eine Vision entwickeln

Es geht nicht um „nice-to-have“, sondern um eine Ablösung oder Umstellung mit Mehrwerten. Identifizieren Sie deshalb die gewünschten zentralen Funktionen, Randbedingungen und Kontexte Ihrer zukünftigen Plattform. Auf eine Wunschliste späterer Funktionen kann verzichtet werden. Anstelle dessen sollten auf Business Values basierende User Stories entscheiden, wie die zukünftige Funktionen Ihres Shops aussehen sollen. Überprüfen Sie deren Machbarkeit und erstellen Sie eine Roadmap für die Umsetzung. Beachten Sie dabei unbedingt Abhängigkeiten zu Drittsystemen und die Sicherstellung ihrer Kompatibilität.

3. Strangler: Einfach, aber mit dem höchsten Nutzen einsteigen

First things first. Nutzen Sie die Erkenntnisse des Strangler Pattern, das sich mit der sinnvollen Migration von monolithischen Systemen auf Microservices befasst. Es geht davon aus, dass man sich bei einem Systemwechsel zunächst darauf konzentriert, wichtige Funktionalitäten mit geringer Komplexität oder höchstem Nutzen zuerst zu ersetzen, um Instant Value zu schaffen. Ähnlich wie bei der Vorgehensweise des Minimum Viable Product (MVP) geht es darum, in der Entwicklung, möglichst frühzeitig Werte in Ihrem Projekt zu schaffen und aus den vielleicht noch nicht optimalen Prozessen zu lernen.

4. Laufen lassen, weiterentwickeln und abschalten

Warten Sie nicht den Big Bang ab, sondern gehen Sie routiniert und konsequent vor. Bringen Sie zunächst und im laufenden Betrieb einzelne gewünschte Funktionen live. Gewinnen Sie durch Tests bei Ihren Kunden Vertrauen und gleichen Sie Ihre KPIs ab. Ist die Stabilität der Funktionalitäten und Services erreicht, können Sie den alten Code abschalten. 

5. Standards zuerst, Schnittstellen später

Der Vergleich mit der Musik hinkt nicht. Composable kommt von „Komponieren“. Komponieren Sie Ihr zukünftiges System anfänglich am besten mit den verfügbaren Standardfunktionen. Ob Kundendaten- oder Produktdaten- oder Category Management – viele Funktionalitäten können bereits durch Cloud-Anbieter vollständig gecovered werden und müssen nicht komplett neugebaut werden. Bevor Sie also individuelle Extensions/Customizations nutzen, die in der Regel selbst zu betreiben und zu warten sind, prüfen Sie verfügbare Cloud-Angebote. Wenden Sie sich in der Folge den Schnittstellen zu Drittsystemen für die Datensynchronisation zu.

6. Sauber bleiben beim Frontend und der Business Logik

Achten Sie bei der Weiterentwicklung Ihres Shops darauf, die Anforderungen Ihrer Kundinnen und Kunden nicht mit den Anforderungen des Systems zu vermischen. Die Business-Logik sollte entsprechend ihres Kontextes in den Backend-Services zu „verpackt“ sein. Das Frontend sollte strikt nur für die Darstellung genutzt werden. Hier können Sie eventuell auch Micro-Frontends einsetzen, die sich nach User Journeys aufsplitten. Betrachten Sie das Frontend als „Schaufenster“ Ihres Shops und das Backend als die „Logistik dahinter“. Beide haben unterschiedliche Anforderungen, die gut getrennt und separat gemanaged gehören.

7. Funktionen zentralisieren und standardisieren

Verteilen Sie nicht zu viel. Ob bei der Administration generell, oder auch im Detail zum Beispiel bei der Verwaltung von Zugriffsrechten, sollten Sie darauf achten, Querschnittsfunktionen zu zentralisieren oder durch standardisierte Software-Komponenten abzudecken. Das sorgt für Ordnung, eine geringere Komplexität in der Administration oder eine bessere Systemhandhabung. Plus: standardisierte Tools bieten Ihnen insgesamt eine höhere Sicherheit, eine bessere Wartbarkeit und sind oftmals schneller zu skalieren.

Fazit: Gut vorbereiten – besser aufsetzen

So gelingt der Shop-Relaunch

Composable Commerce bietet eine Vielzahl von Vorteilen gegenüber den hergebrachten, monolithischen Systemen. Insbesondere die modulare Integration spezialisierter Softwaredienste sorgt für mehr Flexibilität und eine schnelle Anpassungsfähigkeit Ihres Angebot. Nehmen Sie sich für Ihr Replatforming die notwendige Zeit. eCube hat für Sie eine Whitepaper-Reihe zu dem Thema erstellt und bietet Ihnen auf Wunsch ein kostenloses Webinar on demand zum Thema Composable Commerce an. Gerne stehen wir Ihnen auch direkt mit Informationen und Services für Ihren erfolgreichen Shop-Relaunch zur Verfügung. Sprechen Sie uns an.

Was Sie erwartet:

Kein Commerce-System bietet alles. Sei es im Hinblick auf Funktionalitäten, sei es im Hinblick auf den Workflow im Backend oder die angebotenen Möglichkeiten für die jeweilige Customer Journey. Setzte man früher monolithische Systeme ein, deren Anforderungen man sich eben anpasste, zeigt der Composable Commerce Ansatz eine neue Strategie auf: die Kombination der besten Lösungen in einen hochgradig anpassungsfähigen Technologie-Stack.

Im dritten Teil unserer Whitepaper-Reihe skizzieren wir für Sie beispielhaft den Prozess der technischen Implementierung und Migration zu einer Composable Commerce Architektur, geben Einblicke in mögliche Projektabläufe sowie Tipps für die Umsetzung.

Wenn Sie sich für eine greifbare Schritt-für-Schritt Anleitung interessieren, in der ein starres System durch ein modernes Frontend und eine Composable Commerce Architektur abgelöst wird, lesen Sie dieses Whitepaper.

Spannend dazu: Plattformwechsel im E-Commerce erfolgreich managen (Teil 1)

Auch spannend: im zweiten Teil unserer Whitepaper-Reihe haben wir wertvolle Fakten und Tipps zum Thema „Agile Projektplanung und Teamwork“ zusammengetragen.

Vorschau anzeigen

Veraltet, kompliziert, unflexibel – wenn monolithische Shopsysteme an ihre Grenzen stoßen, ist eine technologische Neuausrichtung nötig. Erfahren Sie hier, worauf es dabei ankommt und wie ein Onlinehändler diese Herausforderung erfolgreich gemeistert hat.

Der Online-Shop ist heute nur einer von vielen Kanälen für den digitalen Verkauf. Mit der zunehmenden Diversifizierung der Touchpoints verändern sich auch Digital Commerce Systeme grundlegend. Die Tage des klassischen One-Size-Fits-All-Systems dürften gezählt sein. Gefragt sind heute Omnichannel-Plattformen, die sich flexibel anpassen und mit neuen Anforderungen erweitern lassen. Das Konzept der Service-basierten Software-Architektur hat dafür den Weg geebnet.

Die Zeichen der Zeit stehen auf modulare Commerce-Systeme, bei denen Datenhaltung und Geschäftslogik (Backend) vom Verkaufskanal (Frontend) technisch voneinander getrennt sind. Dadurch unterscheiden Sie sich von monolithischen Shopsystemen – um maximale Flexibilität und Skalierbarkeit für beide Bereiche zu gewährleisten. Man spricht hier von „Headless Commerce“. Anbieter wie commercetools, Shopify, emporix und andere sind im Begriff, die Technologie-Landschaft im Digital Commerce aufzurollen.

Es lohnt sich, diese Entwicklung zu verfolgen. Nicht nur, wenn Sie als Händler planen, neu in den Online-Verkauf einzusteigen oder sich technologisch neu aufzustellen.

Herausforderung: Monolithische Shopsysteme stoßen an an Grenze

Händler, die schon einige Jahre online verkaufen und noch ihre ursprüngliche Shop-Lösung betreiben, kommen früher oder später zu der Erkenntnis, dass ihr System an Grenzen stößt und nicht mehr den Anforderungen des modernen Online-Geschäfts genügt.

Woran erkennt man, dass es Zeit für eine technologische Neuausrichtung ist? Hier einige typische Symptome:

• Die Wartung und Instandhaltung Ihres Systems kostet zunehmend mehr Zeit und Geld.
• Funktionen in Front- und Backend lassen sich nicht “mal eben” erneuern oder ergänzen.
• Die Performance lässt zu wünschen übrig, Verkäufe gehen zurück, Kunden wandern ab.

Dies sind drei ernstzunehmende Hinweise dafür, dass grundlegende Veränderungen nötig sind. Nur so kann das Online-Geschäft weiterhin wirtschaftlich und wettbewerbsfähig betrieben werden. Je eher systematische Defizite erkannt werden und entschieden wird, etwas zu ändern, desto wirtschaftlicher und flexibler gestaltet sich eine technologische Neuausrichtung.

Komplett neu bauen oder im laufenden Betrieb transformieren?

Eine gewisse Schonhaltung im Umgang mit den Defiziten monolithischer Shopsysteme, führt nicht selten dazu, dass Händler den richtigen Zeitpunkt für Veränderung verpassen. Sie werden oft erst dann aktiv, wenn ihr altes System durch unzählige individuelle Anpassungen so starr und unflexibel geworden ist, dass ein wirtschaftlicher Betrieb nahezu unmöglich ist. In dieser Situation muss schnell, aber dennoch mit strategischem Weitblick analysiert und gehandelt werden:

Beiden Ansätzen ist gemeinsam, dass die Transformation nach leanen Prinzipien schrittweise erfolgt. Die Reihenfolge der einzelnen Entwicklungsschritte orientiert sich daran, welche Maßnahmen nötig und sinnvoll sind, schnell und mit geringem Risiko maximalen Geschäftswert zu schaffen.

Die Herausforderung besteht darin, zu analysieren, welcher Ansatz besser geeignet ist. Wie bringe ich kurzfristige Projektziele wie Aufwand, Qualität und Dauer der Umsetzung (Time-to-market) bestmöglich mit strategischen Commerce-Zielen in Einklang. Wir unterstützen unsere Kunden beispielsweise in Analyse-Workshops dabei, die richtige Entscheidung zu treffen.

Fallbeispiel: Schrittweise Neuentwicklung bei HENKA

HENKA ist ein mittelständisches Unternehmen im technischen B2B-Handel, das sich auf den Vertrieb von Werkzeugen und Werkzeugmaschinen spezialisiert hat.

Die Herausforderung bei HENKA bestand darin, das bestehende monolithische Shopsystem durch eine neue flexiblere Plattform mit individuellen Such- und Bestellprozessen, sowie smarten Services zur automatisierten Analyse und Aufbereitung von Produktdaten von verschiedenen Zulieferern zu ersetzen.

Auf Basis einer umfassenden Analyse der bestehenden Strukturen und Verkaufsziele, entwickelte eCube eine Headless-Commerce-Plattform. Diese kann flexibel mit dem Online-Geschäft von HENKA wachsen und jederzeit an neue Anforderungen angepasst werden kann.

Das Besondere an diesem Projekt – Mehrwert für HENKA:

• eCube hat nicht einfach Anforderungen gemäß Lastenheft umgesetzt, sondern HENKA proaktiv dabei unterstützt, Ziele und Maßnahmen nach ihrem Beitrag zum Verkaufserfolg zu bewerten und für die schrittweise Umsetzung zu priorisieren.
• Agile Prinzipien bei der Planung und Umsetzung machten es möglich, nach nur 3 Monaten mit einem funktionsfähigen Prototypen (Minimum Viable Product) der Commerce-Plattform zu starten und im Testbetrieb schrittweise und zielgerichtet weiterzuentwickeln.
• Ein eigens entwickelter Service ermöglicht es dem Produktdaten-Team bei HENKA, Daten aus unterschiedlichen Quellen, die regelmäßig in unterschiedlicher Qualität angeliefert werden, automatisiert zu konsolidieren und die Qualität der Daten laufend zu verbessern.

Fordern Sie hier die entsprechende Case Study als PDF an: Neuentwicklung bei HENKA

Produktdaten nie wieder manuell aufbereiten: Erfahren Sie hier, wie Sie Ihre Produktdaten mit unserem Tool Chioro automatisiert analysieren, aufbereiten und die Qualität nachhaltig steigern.

Andere unserer Kunden unterstützen wir je nach strategischer Zielsetzung dabei, ihre Commerce-Systeme schrittweise zu transformieren, um die solide Basis für eine flexible und sichere Weiterentwicklung in der Zukunft zu schaffen. Entscheidend ist, welcher Ansatz möglichst schnell und mit möglichst geringem Risiko zu einem nachhaltigen System für den digitalen Verkauf führt.

Fazit: Verschiedene Wege führen zum Ziel

Die Frage „neu bauen oder schrittweise transformieren?“ lässt sich im Einzelfall nur auf Basis einer fundierten Analyse des Status Quo vorhandener Technologielandschaften und der konkreten Geschäftsziele beantworten. Jede technologische Neuausrichtung sollte nach leanen bzw. agilen Prinzipien schrittweise erfolgen. Jeder Entwicklungsschritt soll sich daran orientieren, was den größtmöglichen Wertbeitrag zum Unternehmenserfolg schafft. Ziel ist es, vorhandene Systeme nicht nur zu ersetzen, sondern die Basis für flexibles und nachhaltiges Wachstum zu schaffen. Headless Commerce-Architekturen können hier einen entscheidenden Beitrag leisten.

Gerne beraten wir Sie bei Ihrer Entscheidung.

Was Sie erwartet:

Passend dazu: Plattformwechsel im E-Commerce erfolgreich managen (Teil 3)

Jetzt anmelden

Vorschau anzeigen

Im IT-Projektmanagement gibt es viele spannende Rollen für jemanden wie mich. Entwickler-Background, Wissenskommunikation irgendwann mal studiert und wie verrückt an Organisationsmethodik interessiert.

Dadurch machen mir so ziemlich alle Rollen in diesem Umfeld riesigen Spaß – vom Agile Coach, bis zum Projektmanager im klassisch-sequentiellen Umfeld. Der Spaß bleibt aber nur so lange erhalten, wie ich das Wichtigste im Griff behalte: Meine Stakeholderinnen auf dem Laufenden zu halten. Das bedeutet vor allem, dass ich es schaffe, dass sich ihre Erwartungen und ihr Know-How parallel zum Projekt mit entwickeln. Das geht nicht von allein und ist als Projektmanager oder Product Owner selbstverständlich zu 100% meine Verantwortung.

Für ein gesundes Erwartungs- und Wissensmanagement in IT-Projekten ist es meiner Meinung nach am aller wichtigsten, dass die Prioritäten in meinen Projekten transparent und verständlich sind. Allen muss klar sein, woran gearbeitet wird bzw. woran nicht gearbeitet wird. Es muss auch klar sein, warum. Und damit bin ich mitten im Thema.

Der Grundsatz

Ob Review im Scrum-Kontext oder Statusmeeting im Lenkungsausschuss, wenn meine Kolleginnen nicht nachvollziehen können, warum das Eine vor dem Anderen erledigt wird, werde ich über kurz oder lang Frust kreieren. Das ist vor allem dann der Fall, wenn iterativ entwickelt wird und ich Stakeholderinnen mit unterschiedlichen Interessen habe. Sprich: Ihre Anforderungen konkurrieren miteinander und wollen von meinem Team umgesetzt werden.

Das führt früher oder später zu einer Situation, die Sie sicher kennen: Sie sprechen mit Ihrer Sponsorin und diese fragt Sie, weshalb Ihr Team Feature A zuerst umgesetzt hat, wo doch klar kommuniziert worden war, dass Feature B das erste sein sollte. Sie hatten gute Gründe für den Wechsel der Prioritäten aber in dieser Situation ist das Kind bereits in den Brunnen gefallen. Wie Sie diesen Case vermeiden können, lesen Sie im kommenden Absatz.

Die Methodik im Projektmanagement

Was ich niemals mache, ist, Features zu dokumentieren und anhand welcher Kriterien auch immer in einer Liste zu priorisieren. Das geht, je nach Ansicht Ihrer Stakeholderinnen, in die Hose. Denn auch eine Beurteilung von Features aus nackter monetärer Sicht kann über Strategie-Gedanken, operative Kosten auf Zeitebene oder irgendeine andere Art und Weise umgedreht werden. Es kommt halt darauf an…

Stattdessen formuliere ich die Anforderungen meiner zu entwickelnden Softwareprodukte in User Stories und lasse diese auf neutrale Weise gegen einander antreten. Sie werden auf zwei Arten miteinander verglichen:

1. Business-Value
2. Story-Points

Je höher der Business-Value, desto wertvoller ist die User Story, also die Anforderung. Je niedriger die Story-Points sind, desto leichter ist sie umzusetzen. Wenn ich beide Werte miteinander korreliere, versetzt mich das schließlich in die Lage, ganz neutral entscheiden zu können, was jetzt umgesetzt wird und was nicht. Damit jeder immer in der Lage ist, diese Einschätzung nachzuvollziehen, mache ich das für alle Projektteilnehmenden und -interessierte mittels Aufwand-Nutzen-Matrix transparent. Einfach jeder hat Zugriff. Wie das aussieht, sehen Sie hier:

Im Beispiel sehen Sie ganz deutlich die logische Reihenfolge, der umzusetzenden Anforderungen. Diejenigen, die wertvoll sind und mit wenig Aufwand umsetzbar (im grünen Bereich), werden zuerst eingeplant. Was sich im roten Bereich befindet, hat schlechte Karten. So sieht die Reihenfolge in der Matrix in Reihe aus, wenn sich in den kommenden Wochen nichts daran ändert:

1. Anforderung 1
2. Anforderung 5
3. Anforderung 2
4. Anforderung 4
5. Anforderung 3

Story-Points im Projektmanagement

Story-Points sind ein abstrakter Wert, der vom Entwicklungsteam vergeben wird. Das Team schätzt (in der Regel mithilfe eines Planning-Pokers) die Komplexität oder den Aufwand der Anforderungen ein und vergibt Story-Points, die durch Fibonacci-Zahlen repräsentiert werden:

• 1
• 2
• 3
• 5
• 8
• 13
• 21
• 34
• 55
• 89

Das Verwenden vom Fibonacci-Zahlen soll davor schützen, dass sich Ihr Team darüber streitet, ob eine Anforderung eher eine 55 oder eine 57 ist. Denn das Ziel der Story-Points ist, die Anforderungen in Größenordnungen einzuteilen, nicht sie kleinteilig miteinander zu challengen.

Business-Value im Projektmanagement

Auch den Business-Value kann man mithilfe einer Pokerrunde, dem sogenannten Business-Value-Poker, durch Stakeholderinnen ermitteln lassen. Das hat die Vorteile, dass es schnell geht und durch alle relevanten Stakeholderinnen abgesegnet wird. Zudem lernen alle Beteiligten ungemein viel über die Anforderungen anderer Stakeholderinnen. Ein Nachteil ist, dass die Runde vollständig sein muss, damit es später keinen Ärger über zu gering oder zu groß geschätzte Anforderungen gibt. Zudem können Bias die Schätzungen beeinflussen und unrealistisch machen.

Ich versuche gerne den Business-Value der Anforderungen meiner Stakeholderinnen so gut wie möglich auszurechnen, damit sie neutral und ohne subjektive Schätzungen miteinander verglichen werden können. Meine Stakeholderinnen helfen mir in der Regel dabei. Dazu sind allerdings Referenz-Anforderungen beziehungsweise Referenz-Values notwendig. Sie ermöglichen eine Vergleichbarkeit der unterschiedlichen möglichen Outcomes von Anforderungen. Denn manche Anforderungen sind wertvoll, weil sie Prozesse verschlanken. Andere stärken das Marketing und damit die Kundenakquise. Diese miteinander auf Basis ihres Wertes zu vergleichen ist schwierig. Wie dieses Dilemma mithilfe von Referenz-Values gelöst werden kann, zeigt das folgende Beispiel:

Fazit

Mein Tipp an Sie ist: Verwenden Sie Business-Values, um Ihre Anforderungen miteinander neutral vergleichbar zu machen. Nehmen Sie Story-Points zur Hilfe, um eine aussagekräftige Matrix aufbauen zu können, die den Wert und den Aufwand zeigt. Machen Sie Ihre Priorisierung damit transparent und verzichten Sie lieber auf Feature-Listen, die von Ihren Stakeholderinnen falsch interpretiert werden können.

So machen Sie vollständig und ganz neutral nachvollziehbar, was wann warum an der Reihe ist. Ihre Stakeholderinnen werden es Ihnen danken und mit den richtigen Erwartungen in die Planung gehen. Das Beste daran: Sie haben – so wie auch ich – Spaß im IT-Projektmanagement!

Passend dazu: Komplexe Replatforming-Projekte im B2B erfolgreich managen

Was Sie erwartet

Je komplexer ein IT-Projekt, desto größer ist das Risiko für Projektverantwortliche, die gesteckten Ziele zu verfehlen. Und das, obwohl das Projektmanagement sich in den letzten Jahrzehnten durch wachsendes Erfahrungswissen, bessere Ausbildung und smarte Softwareunterstützung immer weiter professionalisiert hat. Der Erfolg (oder Misserfolg) von Projekten bleibt in vielen Unternehmen ein Rätsel und lässt Projektverantwortliche schlecht schlafen. Untersuchungen der Boston Consulting Group kommen zu dem Ergebnis, dass 70 Prozent der digitalen Transformationsprojekte ihre Ziele nicht erreichen. In ähnlicher Weise ergab der 2020 Global Application Modernization Business Barometer Report, dass 74 Prozent der Unternehmen, die ein Projekt zur Modernisierung von Altsystemen begonnen hatten, dieses nicht erfolgreich abschließen konnten. Dieser erschreckend hohe Wert deckt sich etwa mit der Misserfolgsrate von 70 Prozent, die McKinsey & Co. vor einigen Jahren ermittelte.

Mit unserer Erfahrung aus vielen IT-Projekten im Bereich Digital Commerce können wir vereinfachend sagen, dass Projekte besonders dann schieflaufen oder scheitern, wenn Projektziele, Erwartungen und Anforderungen nicht klar definiert bzw. intern unzureichend kommuniziert werden. Ein weiterer Stolperstein lauert in schwammig definierten Rollen und Zuständigkeiten im Projekt-Team – nicht selten fehlt ein Product Owner, der das undurchsichtige Gewirr an Fäden in komplexen Projekten zusammenhält. In unserer Reihe „Plattformwechsel im E‑Commerce erfolgreich managen“ zeigen wir Ihnen in Leitfäden und Fachartikeln, wie Sie als Projektverantwortlicher sämtliche Herausforderungen und Risiken jederzeit im Blick behalten und geben Ihnen ein Rezept an die Hand, mit dem Sie erfolgreich zum Ziel gelangen.

Im ersten Teil, den Sie nun vor sich sehen, erläutern wir ausführlich, wie Sie in Ihr Projekt starten und was Sie von Beginn an beachten sollten.

Passend dazu: Plattformwechsel im E-Commerce erfolgreich managen (Teil 2)

Passend dazu: Plattformwechsel im E-Commerce erfolgreich managen (Teil 3)

Jetzt anmelden

Vorschau anzeigen

Projektmanagement – In unserer Branche wird die Mehrheit aller Produktentwicklungen mittels agiler Vorgehensweisen, wie etwa Scrum, Extreme Programming, Feature Driven Development oder Kanban durchgeführt. Das hat gute Gründe, die altbekannt sind. Wenn wir uns beispielsweise auf Scrum beziehen, sind das vor allem diese:

• höhere Flexibilität
• Fokus auf Wertschöpfung
• Orientierung direkt am Kunden
• höhere Transparenz, schnelles Feedback
• schneller Start in die Entwicklung

Wo ist Licht ist, da ist auch Schatten

Agile Methoden wie Scrum haben leider auch eine Reihe von Schwächen, die vor allem Auftragnehmer in der Phase der Auftragsentstehung unruhig schlafen lassen. Die Größten davon kann man folgendermaßen zusammenfassen:

• Schwierigkeiten bei der Planung (Fertigstellung, Kosten etc.)
• häufig fehlender Überblick über das Gesamtprodukt und die kommenden Projektphasen
• Abhängigkeiten zu externen Ressourcen und Plänen sind komplex
• Bei Produkten mit simplem Umfang ist der Overhead zu groß
• Integration in große Unternehmensstrukturen unter Umständen schwierig
• Dokumentation wird häufig vernachlässigt

Unser Lesetipp: Anforderungen von E-Commerce Plattformen richtig in den ersten vier Tagen dokumentieren und kommunizieren

Also doch lieber klassisches Projektmanagement?

Aufgrund der schwerwiegenden Vorteile agiler Softwareentwicklung empfehlen wir in unseren Projekten in der Regel, diese zu verwenden. Unserer Erfahrung nach ist die Flexibilität von Scrum und anderen Methoden unbezahlbar, wenn wir sie mit dem starren Versuch der Erfüllung eines Pflichtenheftes vergleichen.

Es kann ggf. ratsam sein, darüber nachzudenken, ob ein klassisch sequenzielles Vorgehen (zum Beispiel mittels V-Modell, Spiralmodell oder Wasserfall) nicht doch die bessere Wahl ist. Folgende Faktoren sollten dabei untersucht werden:

• Die Umgebung des Entwicklungsteams
• Der Aufbau des Entwicklungsteams
• Die Komplexität des Produktes
• Die Unsicherheiten vor Beginn der Entwicklung

Passend dazu: Unser Whitepaper “Komplexe Replatforming-Projekte im B2B richtig managen”

Unser Modell

Im Laufe der letzten drei Jahrzehnte wurde eine Reihe von Modellen entwickelt, die dabei helfen sollen, die richtige Methodik für Ihre Produktentwicklung zu wählen. Die Meisten legen dabei allerdings ausschließlich den Fokus auf die zu entwickelnde Software. eCube hat ein Modell entwickelt, das die Umstände der Entwicklung mit betrachtet. Sie sind wichtige Faktoren, um festzustellen, in welchen Situationen man sich für ein sequenzielles Vorgehen entscheiden könnte.

Im gezeigten Modell werden acht typische Faktoren bewertet, die Ihnen helfen, Sicherheit bei der Auswahl der richtigen Herangehensweise zu treffen. Im Beispiel sehen Sie einen üblichen Graphen, der entsteht, wenn Sie sie Ihre Situation nüchtern bewerten und die Werte auf den Skalen miteinander verbinden.

Quelle: Eigene Darstellung.

Haben Sie die Fragen mittels Skala beantwortet und so Ihren Graphen erstellt, können Sie einfacher entscheiden. Folgende Eigenschaften sollte die Kurve zeigen, wenn Sie über ein klassisch sequentielles Vorgehen beispielsweise via Wasserfall nachdenken:

• mindestens einer der Werte liegt bei -4
• der Durchschnitt Ihrer Werte liegt unter 0
• es liegt kein Wert bei 4

Sobald alle drei Bedingungen erfüllt sind, kann es sich lohnen von einem iterativen Modell abzusehen und über die Softwareentwicklung sequentieller Natur nachzudenken. Ein Graph, der sich streng in der Mitte bewegt, kann Sie darüber hinaus zum Entschluss bringen ein Hybridmodell zu verwenden oder einen völlig neuen Ansatz auszuprobieren. In jedem Fall werden Sie damit transparent machen, ob Ihr Vorgehen perfekt für die agile Welt oder die klassische Welt geeignet sein wird oder nicht. Konsultieren Sie uns im Zweifelsfall! Wir stehen Ihnen mit unserer Erfahrung gerne zur Seite.

In der Berufswelt stoßen Sie häufig auf diese beiden Typen von Mensch: Dem einen fällt es schwer anzufangen, dem anderen fällt es schwer aufzuhören. Als gute Product Ownerin sollten Sie keines von beiden sein. Haben Sie (noch) kein Standardvorgehen für das Management Ihrer Anforderungen, könnte das ein Hemmnis für einen schnellen Start sein. Wir helfen Ihnen aus dieser Situation heraus. In diesem Blogartikel haben wir den typischen Start und ein paar Kniffe bei der Dokumentation und Kommunikation von Anforderungen skizziert.

Um dieses Thema für Sie greifbar zu machen, haben wir uns ein Beispiel herausgesucht, mit dem wir uns gut auskennen: Das Entwickeln von E-Commerce Plattformen. Damit nehmen wir Sie mit auf die Reise der ersten vier Tage eines üblichen Anforderungsmanagements im Scrum-Kontext.
Sie werden ca. 10 Minuten für das Lesen benötigen.

Voraussetzungen

Damit die Viertage-Journey erfolgreich ist, setzen wir einige Parameter voraus:

• Sie haben bereits ein Scrum Team
• Ihre Stakeholderinnen bzw. WissensträgerInnen sind Ihnen bekannt.
• Sie haben die Zeit und die Ressourcen, um Anforderungen ohne Probleme aufnehmen zu können.

Anforderungen richtig dokumentieren
– Tag 1

Quelle: Eigene Darstellung.

Nach dem Workshop machen Sie ein Fotoprotokoll aller Ergebnisse, das Sie umgehend an alle TeilnehmerInnen des Workshops via E-Mail senden. Zusätzlich legen Sie es in Ihrem hausinternen kollaborativen Wissensmanagementsystem für alle erreichbar ab. Dort dokumentieren Sie am besten alles, was Sie an Wissen zum Produkt erhalten.

Quelle: Eigene Darstellung.

Sie beginnen anschließend damit die Vision der neuen E-Commerce Plattform zu kreieren. Die Vision wird das Leitbild Ihrer Produktentwicklung sein und soll das Ergebnis der Arbeit der kommenden Monate abstrahieren. Dafür verwenden Sie die Metapher des 90er-Jahre-Software-Pappkartons. Dieser landet in Ihrem hausinternen Wissensmanagementtool und nicht in E-Mails oder Netzwerkshares. Auf diesem Karton stehen die wichtigsten Features des neuen Shops.

Was machen Sie damit, wenn dieser fertig ist? Genau! Ihren Stakeholderinnen und Ihrer SponsorIn zur Validierung vorlegen. Ist das geschehen, kann kaum noch etwas schief gehen – zumindest bis zum Feierabend.

Anforderungen richtig dokumentieren
– Tag 2

Nachdem Sie Ihren ersten Kaffee getrunken haben, machen Sie sich ans Werk. Sie beginnen damit, User Stories aus den wichtigsten Features zu formulieren, die Sie im gestrigen Workshop erarbeitet haben. Gönnen Sie sich dabei zwischendurch eine Pause. Das Formulieren guter User Stories ist kein Pappenstiel! Bitte kreieren Sie deshalb Ihre Stories mithilfe Ihres hausinternen und kollaborativen Anforderungsmanagementsystems und nicht mit Office Tools, wie etwa Numbers oder Excel.

Bis zum Mittagessen haben sie die ersten vier wichtigen funktionalen Anforderungen beieinander. Das ist ein guter Start! Diese lassen Sie sich sofort mit Hilfe Ihres Anforderungsmanagementsystems von Ihren Stakeholderinnen validieren. Sie sollen einen Eindruck davon bekommen, was Sie umsetzen werden und Ihnen ihr Okay dafür geben.

12:47 Uhr beenden Sie Ihre Mittagspause und melden sich bei Ihrer Scrum Masterin. Sie bitten Sie, Ihr Developmentteam darauf vorzubereiten, dass es in zwei Tagen losgehen kann. Denn die Vision und die ersten User Stories sind bereits innerhalb Ihres Unternehmens abgestimmt. Morgen soll bereits ein erstes kleines Refinement Meeting von 3-4 User Stories stattfinden. Diese Meetings sind vor Beginn der Entwicklung leider noch ungeplant.

Nun fehlt nur noch eine wichtige Sache, damit der Start Ihrer Produktentwicklung gut verläuft. Sie müssen unbedingt rechtzeitig die Randbedingungen und Qualitätsanforderungen für Ihr neues Produkt in Erfahrung bringen! Ohne diese werden Sie wichtige Fragen Ihres Entwicklungsteams nicht beantworten können. Zu diesem Zweck interviewen Sie Ihre horizontalen Stakeholderinnen, also Fachpersonal, das Ihnen die wirklich wichtigen Fragen, wie beispielsweise die nach technischen Restriktionen, beantworten kann. Am besten aus den folgenden Abteilungen jeweils eine relevante Person: IT-Infrastruktur, Content Management, Datenschutz, Customer Service und Produktmanagement.

Passend dazu

Unser neues Whitepaper: Komplexe Replatforming-Projekte im B2B richtig managen (Teil 1)

Anforderungen richtig dokumentieren
– Tag 3

Ihre Scrum Masterin versteht ihren Job und hat bereits alles für einen guten Start in die Produktentwicklung in die Wege geleitet. Morgen findet das erste Sprint Planning statt. Wie aufregend!

Das kurze Refinement-Meeting wurde heute auf 14:00 Uhr angesetzt. Damit Ihr Development-Team Ihnen nicht ihre ersten Anforderungen um die Ohren haut, schneiden Sie die ersten User Stories so klein wie möglich. Sie erstellen zusätzlich einen Haufen SMARTer Aktzeptanzkriterien für Ihre Stories.

So sichern sie sich vor einem Show-Stopper im ersten Sprint-Planning ab!

Beispiel einer User Story:

Als Kundin des neuen Onlineshops möchte ich meine Wunschzettel an meine Freunde senden können, damit ich bequem meine Geschenke selber aussuchen kann und meine Freunde sich einfach nur eines der Produkte aussuchen müssen.

Akzeptanzkriterien

• Jede eingeloggte Kundin kann mehrere Wunschzettel anlegen.
• Beim Einkaufen können Artikel in die Wunschzettel eingefügt werden.
• Wunschzettel können auf einen Blick eingesehen werden.
• Wunschzettel können via E-Mail versandt werden.
• Wenn ein Produkt auf einem Wunschzettel von der Kundin oder einer Bekanntschaft gekauft wird, wird das auf dem Wunschzettel der Kunden und den versendeten Wunschzetteln markiert.
• Die Preise der Artikel sind auf den Wunschzetteln zu sehen.
• Bekanntschaften können vom Wunschzettel in ihrer Mail aus sofort bezahlen und müssen keinen Umweg über unseren Shop gehen.

Sie sortieren Ihr Backlog bis zum Ende des Arbeitstages nach der Priorität der Anforderungen, damit Ihr Team und Ihre Stakeholderinnen schon jetzt sehen können, in welcher Reihenfolge die kommenden Anforderungen wahrscheinlich umgesetzt werden.

Quelle: Eigene Darstellung.

Anforderungen richtig dokumentieren
– Tag 4

Sie haben in der vergangenen Nacht nicht gut geschlafen. Allerdings ist das vor dem ersten Sprint ganz normal! Erst um 10:00 Uhr findet das erste Sprint-Planning statt, weil Ihre Entwicklerinnen vor 10:00 Uhr noch nicht so richtig aufnahmefähig sind. Sie starten das vierstündige Meeting mit der Vorstellung der Vision der zu entwickelnden E-Commerce Plattform. Nach etwa einer Stunde sind die groben Fragen geklärt, die Sie klären konnten. Den Rest haben Sie sauber in Ihrem Planning-Protokoll notiert.

Zunächst erläutern Sie die Randbedingungen des Shops. Ihr Team wird es Ihnen danken! An der Umsetzung dieser speziellen Anforderungen werden sie nämlich als erstes arbeiten wollen. Damit aber am Ende des ersten Sprints auch ein potentiell nützlicher Teil des Produktes produziert worden ist, stellen Sie nach dem Mittagessen die ersten kleinen aber wichtigen User Stories vor. Ihr Team wird sich auf die Umsetzung aller Stories committen, die sie glauben, vollständig verstanden zu haben, technisch umsetzen zu können und zeitlich schaffen zu können.

Damit Ihre Stakeholderinnen die richtigen Erwartungen von Ihrem ersten Sprint haben, senden Sie ihnen Ihr Planning-Protokoll zu. Das enthält die aktuellen offenen Fragen und den Umfang des nun laufenden Sprints.

Danach

Anschließend beginnt die Produktentwicklung nach Scrum und Sie werden jeden Tag die Anforderungen Ihrer neuen E-Commerce Plattform managen.

Sie möchten wissen, wie es weitergeht?
Dann schauen Sie gern unsere Aufzeichnung des ECC-Webtalks “Wasserfall, agil oder beides? Das Geheimnis erfolgreicher Digital-Commerce-Projekte” an!
“Egal – was zählt, ist das Ergebnis”, sagen Tino Müller von eCube und Stefan Schmidt von emporix, die als Product Owner seit vielen Jahren strategische Digital-Commerce-Projekte steuern. Die Herausforderung besteht darin, die richtigen Projektmanagement-Methodiken und -Tools zu identifizieren und gegebenenfalls passend zu den spezifischen Rahmenbedingungen, Anforderungen und Erwartungen im konkreten Fall zu kombinieren. Wie dies in der Praxis gelingt und wann es sich lohnt, Ansätze aus beiden Welten – Wasserfall und Agile – zu verknüpfen, erfahren E-Commerce-Verantwortliche in diesem kurzweiligen Vortrag.