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.
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
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!
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.
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.
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.
Lesenswert dazu: Feature Priorisierung vs. Business-Value
“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
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.
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.
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.“)
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.
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.
