8 Fehler im Anforderungsmanagement von E-Commerce-Systemen

Professionelles Anforderungsmanagement ist kein Nice-to-have, sondern für den Erfolg von E-Commerce-Projekten entscheidend. Wir zeigen typische Stolpersteine und helfen, diese zu umgehen.

Das Anforderungsmanagement (Requirements Engineering) entscheidet wesentlich über den Erfolg (oder Misserfolg) von E-Commerce-Projekten – egal ob ein Software-System neu aufgebaut oder ein bestehendes transformiert werden soll. Das gilt auch und besonders für komplexe Projekte, bei denen es um die grundlegende Umstellung der Systemplattform (Replatforming) geht.

Professionelles Anforderungsmanagement ist kein Nice-to-have

Es gibt unzählige Gründe für das Scheitern von Softwareprojekten, aber schlecht erhobene, dokumentierte, validierte und gemanagte Anforderungen tragen in hohem Maße zum Scheitern von Softwareprojekten bei. Die Folge sind explodierende Kosten, Verzögerungen in der Umsetzung und nicht zuletzt Frust bei allen Beteiligten – abgesehen von Langzeitfolgen durch gravierende Planungsfehler.

Grund genug für Sie, dem Thema Anforderungsmanagement eine besondere Bedeutung beizumessen und eigene Strukturen und Prozesse zu professionalisieren. Um Sie dabei zu unterstützen hat eCube eine Reihe von Leitfäden für Projektverantwortliche veröffentlicht, in denen verschiedene erfolgskritische Aspekte von Replatforming-Projekten beleuchtet werden. Von Praktikern für Praktiker.

Leseempfehlung: Komplexe Replatforming-Projekte im B2B erfolgreich managen

Aus Fehlern im Anforderungsmanagement lernen

Im Folgenden soll es um typische Fehler im Anforderungsmanagement gehen, die wir alle schon gemacht haben und aus denen wir lernen sollten, um kleine und große Projektkatastrophen künftig zu vermeiden. Wir sprechen hier aus eigener Erfahrung aus unzähligen Projekten!

Fail #1: Plausibilität nicht geprüft

Die Plausibilitätsprüfung ist eine Methode, bei der ein zu erwartendes Ergebnis daraufhin überprüft wird, ob es überhaupt plausibel, d.h. nachvollziehbar und akzeptabel, sein kann oder nicht. Findet diese Prüfung insbesondere mit dem Entwicklungsteam nicht statt, besteht die Gefahr, dass der Projekt-Backlog mit mehr oder weniger “wertlosen” Anforderungen geflutet wird, die Ressourcen binden und den Blick für das Wesentliche vernebeln.

Learnings & Empfehlungen
  • Keine Anforderung wird ohne systematische Plausibilitätsprüfung angenommen
  • Das Entwicklungsteam wird stets in die Prüfung eingebunden

Fail #2: Andere Abteilungen nicht eingebunden

Softwareanforderungen werden beispielsweise mithilfe von Interviews, Feldbeobachtungen oder Workshops mit potentiellen Nutzern aufgenommen. Diese Nutzer sind – neben den wirklichen Nutzern eines Onlineshops, den Kunden – häufig Mitarbeitende aus IT-Abteilungen und nicht-IT-Abteilungen. Diese Nutzer haben einen subjektiven Blickwinkel auf Anforderungen und deren Wert. Um eine 360° Betrachtung zu gewährleisten und damit vollständig und objektiv Anforderungen aufzunehmen, sollten diese durch weitere Abteilungen verifiziert bzw. vervollständigt werden. Andernfalls ist der wirkliche Wert von Requirements am Ende unklar.

Learnings & Empfehlungen
  • Unterschiedliche wertvolle Perspektiven aus Nicht-IT-Abteilungen einbeziehen
  • Ergebnisse aus Interviews transparent machen und damit den Dialog ermöglichen

Fail #3: Ohne Value und Aufwand planen

Der Wert eines Ergebnisses (Value) und der Aufwand, um dieses Ergebnis zu erzielen, sind zentrale Kriterien für die Bewertung und Priorisierung von Anforderungen an ein Software-System. Werden Anforderungen ohne Value und Aufwand geplant, übernehmen Bauchgefühl und Geschmacksfragen das Regiment und die Entwicklung geht ins Blaue. Das ist auch der Fall, wenn beispielsweise nicht zwischen Minimalanforderungen und Nice-to-haves unterschieden wird.

Learnings & Empfehlungen
  • Value und Aufwand für jede Anforderung in die Plausibilitätsprüfung einbeziehen
  • Nach Minimalanforderungen und Nice-to-haves unterscheiden

Lesenswert dazu: Feature Priorisierung vs. Business-Value

Fail #4: Anforderungsmanagement ohne geeignete Tools

“A Fool with a Tool is still a Fool” – dieses Zitat von Grady Booch, einem legendären amerikanischen Software-Ingenieur und Erfinder der Unified Modeling Language (UML), gilt auch im Anforderungsmanagement. Dennoch gibt es eine Vielzahl digitaler Werkzeuge und Methoden, die das Erheben, Dokumentieren, Validieren und Managen von Anforderungen deutlich vereinfacht – und vor allem verbessert. Ein gutes Beispiel ist Jira, ein bewährtes Tool für agiles Projektmanagement.

Quelle: Atlassian. Pty Ltd

Learnings & Empfehlungen
  • Tools nutzen, die einfach zu bedienen sind und schnell helfen, das Anforderungsmanagement effizienter und besser zu machen – Beispiel Jira
  • Anzahl Tools auf die wesentlichen Bereiche beschränken – kein Werkzeug-Overload!

Fail #5: Lastenheft statt Backlog

Fast wie aus der Zeit gefallen, zeugt das Lastenheft in vielen Projekten vom klassischen Erfassen und Dokumentieren von Anforderungen. Alle Anforderungen – in vielen Fällen, alles was technisch irgendwie denkbar ist – werden vor Beginn der Entwicklung aufgenommen und damit nicht selten “in Stein gemeißelt”. Die Prioritäten, wenn sie denn definiert sind, ergeben sich aus der inhaltlichen Reihenfolge. Das Gegenteil vom agilen Backlog, der jederzeit eine flexible Anpassung und Repriorisierung des Anforderungskatalogs ermöglicht.

Learnings & Empfehlungen
  • Weg von der vollständigen Erhebung von Anforderungen im Voraus, hin zum agilen Backlog
  • Anforderungen erst dann im Detail klären, wenn sie kurz vor ihrer Umsetzung stehen

Fail #6: Architektur und Prozesse vermischen

Grafiken und Diagramme vereinfachen die Darstellung von komplexen Zusammenhängen und erleichtern so, ein gemeinsames Verständnis bei allen Projektbeteiligten herzustellen. Nicht selten werden jedoch unterschiedliche fachliche Dimensionen – Zustände, Prozesse und Funktionen – in einer grafischen Darstellung vermischt, obwohl diese um der Klarheit Willen strikt getrennt werden sollten. Entweder skizziere ich einen Prozess, ODER eine Architektur, nicht beides zusammen.

Learnings & Empfehlungen
  • Zustände, Prozesse und Funktionen getrennt voneinander visualisieren
  • Etablierte Standards, wie UML oder BPMN verwenden

Fail #7: User Stories um jeden Preis

Eine User Story ist eine informelle, allgemeine Erklärung eines Software-Features, die aus der Sicht des Endbenutzers verfasst wurde. Das macht Sinn, um zu formulieren, wie Features dem Kunden einen bestimmten Wert liefern. Das macht jedoch keinen, um zu formulieren, wie ein Feature einem System einen bestimmten Wert liefert. Ein System ist kein Nutzer im Sinne einer User Story, auch wenn in User Stories gerne stellvertretend ein Auftraggeber genannt wird. (“Als Abteilungsleiter brauche ich einen Linux-Server, der zum Staging verwendet werden kann.“)

Learnings & Empfehlungen
  • User Stories ausschließlich für Anforderungen verwenden, die sich unmittelbar auf Ergebnisse für den Nutzer beziehen
  • Andere Templates für beispielsweise NFRs oder Randbedingungen verwenden

Fail #8: Anforderungsmanagement in falschen Händen

Zu viele Köche verderben den Brei, die falschen sowieso – das gilt auch und besonders im Anforderungsmanagement, wo es darauf ankommt, dass Anforderungen an einem Ort und von einer Person verwaltet werden, die nicht unmittelbar Teil des Entwicklungsteams ist. Das Anforderungsmanagement als quasi “neutrale” Instanz hat den Vorteil, dass das Erheben, Dokumentieren, Validieren und Managen von Anforderungen nicht technisch “gefärbt” ist und die Zuständigkeit eindeutig einer Person zugeordnet ist, statt sich beispielsweise im Team zu verlieren.

Learnings & Empfehlungen
  • Anforderungen werden von einer einzelnen qualifizierten Person gemanagt
  • Anforderungsmanagement und Entwicklung werden personell getrennt

Fazit: Anforderungen professionell managen!

Professionelles Anforderungsmanagement ist kein Nice-to-have, sondern sollte in jedem Projekt verantwortungsvoll und systematisch betrieben werden. Und zwar ohne Ausnahme, denn auch kleine Projekte, die auf den ersten Blick unscheinbar und risikoarm erscheinen, können scheitern, wenn Anforderungen nicht von Beginn mithilfe neuester Methoden und bewährter Tools erhoben, dokumentiert, validiert und gemanagt werden. eCube unterstützt Sie dabei, das optimale Setting für Ihr Projekt zu finden – besonders wenn es um komplexe Replatforming-Vorhaben geht.

img
Sie suchen das richtige Setting
für Ihr Replatforming-Projekt?
Sprechen Sie mit unserem Experten Tino!

Termin vereinbaren

Artikel teilen

Auch interessant

Projektmanagement Skills im E-Commerce
Die 5 wichtigsten Projektmanagement-Skills im E-Commerce

Der Erfolg von Software-Projekten steht und fällt mit speziellen persönlichen Fähigkeiten im Projektmanagement, die über rein fachliche Skills hinausgehen. Erfahren Sie hier mehr darüber.

Post-it Wand mit vielen Zetteln
Feature Priorisierung vs. Business-Value

Im IT-Projektmanagement gibt es viele spannende Rollen für jemanden wie mich. Der Spaß bleibt aber nur so lange erhalten, wie ich das Wichtigste im Griff behalte: Meine Stakeholderinnen auf dem Laufenden zu halten.