In dieser Vision mache ich mir Gedanken über die Rolle einer Produktdokumentation, die mit der Methode CARDS+ erstellt und gepflegt wurde, in einem Szenario, in dem ein Auftraggeber eine Individuallösung durch eine Lösung mit einem Standardprodukt ersetzt. Werbeversprechen der Hersteller von Standardprodukten verführen Auftraggeber. Sie erwarten durch den Umstieg auf ein Standardprodukt die Lösung aller Probleme.

03 Vision Standardprodukt

Ausgangssituation

Diese Situation entsteht häufig bei einer Individuallösung, die mehr schlecht als recht gewartet wird. Die Projektmitarbeiter sind kaum mehr motiviert. Das Budget für die Wartung ist beschränkt. Die Kosten für die Wartung steigen jedoch kontinuierlich. Die Gründe sind fehlende Innovationen, immer mehr technische Schulden, Wissensverlust durch Fluktuation oder wachsende Lizenz- oder Betriebskosten.

ktip Standardprodukte sind keine schlechte Sache. Es gibt eine ganze Reihe Individuallösungen in den unterschiedlichsten Branchen, die nicht mehr mit anpassbaren Standardprodukten mithalten können. Als Beispiele fallen mir spontan Web-Shops oder Systeme für Content-Management für KMU ein. Und große Unternehmen setzen lieber auf SAP, statt sich eine mindestens genau so teure eigene Software zu leisten.

Jeder Auftraggeber sollte sich bewusst machen, dass seine individuell entworfene und entwickelte Lösung zum Zeitpunkt der Realisierung gut begründet war. Vielleicht gab es zu diesem Zeitpunkt noch kein passendes Standardprodukt. Oder ein verfügbares Standardprodukt war nicht nutzbar in dem Markt, in dem sich der Auftraggeber bewegt, z.B. rechtliche Vorgaben wurden nicht erfüllt. Auch der Wunsch nach Alleinstellungsmerkmalen könnte der Treiber für eine Individuallösung gewesen sein.

Projektinitialisierung

Der Auftraggeber startet ein Projekt mit dem Ziel, sein Bestandssystem durch ein neues System auf Basis eines Standardproduktes zu ersetzen. Dazu muss ein passendes Standardprodukt ausgewählt werden. Die Anforderungen an das neue System sind nicht wesentlich anders als für das bisher eingesetzte System. Mit anderen Worten: Die Systembeschreibung und das Glossar gelten auch für das neue System. Die Projektmitarbeiter müssen die Lösungen in den Cases an das Standardprodukt anpassen.

  1. Im Idealfall hat das Standardprodukt für jeden Case eine passende Lösung. Die neue Lösung ist dann trivial.
  2. Oft kann ein Case durch indiviuelle Anpassungen am Standardprodukt (englisch: customizing) realisiert werden, was als Lösung im Case dokumentiert wird.
  3. Manchmal gibt es jedoch keine Lösung für einen Case. Und genau das werden wir als “Lösung” im Case beschreiben.

Die Fälle 1 und 2 zeigen, dass das Standardprodukt in der Lage ist, die Individuallösung zu ersetzen. Im Fall 3 muss der Auftraggeber aktiv werden und eine Entscheidung treffen. Er hat mehrere Möglichkeiten:

  • Der Case wird komplett gestrichen und damit der Umfang des neuen Systems reduziert. Dabei kann eine Kosten-Nutzen-Rechnung helfen.
  • Der Case wird durch eine individuell entwickelte Lösung des Herstellers des Standardproduktes realisiert. In manchen Fällen übernimmt der Hersteller diese Lösung sogar in ein zukünftiges Release des Standardproduktes.
  • Der Case wird durch einen neuen Case ersetzt, für den es eine Lösung mit dem Standardprodukt gibt. Der ursprüngliche Case wird ohne Lösung dokumentiert.

Ziel aller drei Ansätze ist es, für jeden Case eine korrekte Lösung zu finden. Wichtig ist, dass kein Case aus der ursprünglichen Systembeschreibung gelöscht wird. Die Systembeschreibung mit den neuen Lösungen zeigt auch, ob das Standardprodukt geeignet ist, die individuelle Lösung zu ersetzen. Viele Cases ohne Lösung sind ein guter Hinweis, dass das gewählte Standardprodukt nicht alle Funktionen hat, um die Anforderungen an das System zu erfüllen.

Schätzung

Der nächste Schritt ist die Überprüfung der Entscheidung für ein Standardprodukt. Dabei spielen Kosten und Termine eine Rolle. Aber auch der Glaube an die Lösung. Eine Systembeschreibung, in der es für alle Cases eine akzeptable Lösung gibt, schafft dieses Vertrauen. Eine grobe Schätzung mit der Methode Usecase-Points läßt sich relativ schnell durchführen. Die Cases sind sehr gut geeignet für die Schätzmethode. Und die drei Fälle bei der Lösungsfindung aus der Projektinitialisierung lassen sich direkt als Komplexität verwenden. Die weiteren Faktoren werden mithilfe des Herstellers des Standardproduktes ermittelt. Das Ergebnis der Schätzung sind gewichtete Personentage. Klingt nicht sehr agil, ist aber beim Projektstart in vielen Situationen hilfreich.

Projektdurchführung

Die neue Systembeschreibung ist gleichzeitig eine gute Grundlage für die Umsetzung. In einem agilen Projekt sind diese Cases gut geeignet für den schnellen Aufbau eines Product-Backlog. Der Vorteil durch die Verwendung einer gut gepflegten Produktdokumentation ist offensichtlich: Viele fachliche Fragen können sofort beantwortet werden. Der Product-Owner kümmert sich von Anfang an um die Erstellung und Priorisierung der User-Stories. Mit dem Einsatz eines Standardproduktes sind auch viele Entscheidungen bezüglich Software-Architektur und Betrieb bereits getroffen. Das cross-funktionale Team konzentriert sich sofort auf die Umsetzung, es braucht keinen Sprint 0. Es kann auch ein Vorteil sein, dass zur Klärung von Fragen das Bestandssystem herangezogen werden kann.

Trotzdem wird das Projekt die Vorteile der agilen Methoden für Anforderungsanalyse und Entwicklung nutzen. Auch die frühzeitige Umsetzung betrieblicher Aspekte des Systems durch DevOps ist möglich – natürlich unter den Rahmenbedingungen des Standardproduktes. Das neue System auf Basis des Standardproduktes wird sich vom Bestandssystem unterscheiden. Jede andere Annahme wäre töricht und würde den Erfolg des Projektes gefährden.

Fazit

Die Methode CARDS+ hilft bei der Wahl des richtigen Standardproduktes. Die Systembeschreibung und das Glossar des Bestandssystems sind die Grundlage. Der Product-Owner und das cross-funktionale Team haben sehr schnell ein gut gepflegtes Product-Backlog. CARDS+ hilft bei der Projektdurchführung, die neue Produktdokumentation laufend in guter Qualität zu aktualisieren. Der Fortschritt in der Umsetzung des neuen Systems spiegelt sich auch im Umfang der Systembeschreibung wider. Der Product-Owner wird im weiteren Verlauf des Projektes entscheiden, ob ein Case oder ein Layout so wie im Bestandssystem umgesetzt wird oder – gut begründet – doch anders. Die Architekturdefinition des Bestandssystems ist der Teil der Produktdokumentation, der nicht für das neue System verwendet wird. Den Verlust können wir jedoch leicht verschmerzen, weil das Standardprodukt eh seine eigene Architekturdefinition mitbringt.