Agile Roadmaps bei der Software-Entwicklung

Article in english ⤴︎

Im Großen und Ganzen benötigt jede Software eine Roadmap – eine Basis für die gezielte Weiterentwicklung und Anpassung an die Bedürfnisse der Anwender über die kommenden Jahre. Egal welche Nische eine Software dabei bedient, sie stellt für ihren Nutzerkreis immer eine Art verlässlichen Standard dar. Funktionalitäten werden deswegen eher selten abgekündigt, da dies mit einem Verlust wahrgenommen wird und damit die Akzeptanz der Anwender beeinflusst.

Die Planung und Vermarktung einer Software obliegt üblicherweise dem Produktmanager. Dieser ist der Produkt-Markt-Experte auf seinem Gebiet. Er entwickelt eine Produktstrategie – die Roadmap. Die Releases einer Software werden üblicherweise in Form eines Projektes mit Hilfe eines Projektmanagers umgesetzt. Dabei können sich Projekt- und Produktmanager gegenseitig entscheidend mit ihrer Erfahrung unterstützen.

Die Produktlebenszeit

Der Businessplan einer Software umfasst also eine Roadmap, die die Vermarktung des Produktes über die kommenden Jahre ermöglicht. Ein wichtiger Aspekt muss dabei berücksichtigt werden: die Produktlebenszeit. Ganz abgesehen von Ideen und Kundenanforderungen an ein Produkt kommt jedes Produkt im Laufe seiner Weiterentwicklung an seine Grenzen. Unsere Erfahrungen zeigen, dass nach etwa sieben Jahren eine Grenze erreicht ist, an der die Weiterentwicklung nicht mehr in einem günstigen Kosten/Nutzen-Verhältnis erfolgen kann. Die Gründe:

  • Die Basis-Technologie ist nicht mehr State-of-the-Art und es fehlen wichtige neue Komponenten von Zulieferern.
  • Die Architektur hat ihre anfangs festgelegten Grenzen erreicht, d.h. die Nutzerzahlen, Datenbankgrößen oder Modularität entspricht nicht mehr den aktuellen Anforderungen.
  • Unzählige Handschriften von Architekten und Entwicklern haben unzählige Kompromisse implementiert, da es mal eben schnell und günstig gehen musste. Als Folge ist der Source-Code kaum noch wartbar.

Die Sicht der Nutzer

Der Anwender möchte für seine aktuellen Probleme die bestmögliche Unterstützung. Darüber hinaus möchte er auch mit neuen Funktionen umworben werden und idealerweise dabei das Gefühl haben, das beste Produkt zu nutzen.

Ein Anwender hat wenig Verständnis für die Aspekte, die die Lebenszeit des Produktes beeinflussen. Er bemerkt das Ende schleichend: Die Software wirkt immer behäbiger und unmoderner. Der Blick nach links und rechts zeigt womöglich bessere Alternativen und diese werden mit der Zeit dann auch ausprobiert, wenn der Produktmanager sich nicht aktiv bemüht, die Lebenszeit des Produktes positiv zu beeinflussen. Neue Funktionalitäten werden gerne und dankbar entgegen genommen aber nur ungern bezahlt. Der Markt ist dabei unerbittlich.

Das Kano-Modell

Das nach Noriaki Kano benannte Modell ermöglicht es, Anforderungen von Kunden und deren Wirkung beim Anwender zu erfassen. Er unterscheidet dabei drei Ebenen, die von Bedeutung sind:

  • Basis-Merkmale: Diese sind für den Nutzer so selbstverständlich, dass er sie nicht extra erwähnt. Fehlen diese, entsteht schnell eine Unzufriedenheit.
    Beispiel Auto: der Airbag
  • Leistungs-Merkmale: Während sie beim Fehlen auch Unzufriedenheit entstehen lassen, können sie bei Erfüllung eine Zufriedenheit erzeugen. Anhand dieser Merkmale differenzieren sich die Wettbewerber und erfolgt die Auswahl durch den Anwender.
    Beispiel Auto: Beschleunigung oder Verbrauch
  • Begeisterungs-Merkmale: Hiermit rechnet der Kunde nicht. Diese Alleinstellungsmerkmale rufen Begeisterung hervor.
    Beispiel Auto: Hybridtechnologie

Es ist offensichtlich, dass ein Produkt nicht ausschließlich auf einer Klasse der Merkmale basieren kann. Es kommt auf die richtige Mischung an.

Die Praxis in der Softwareentwicklung

Die Strategie des Produktmanagers berücksichtigt sowohl den Produktlebenszyklus als auch die Anforderungen der Anwender.

Gehen wir davon aus, dass etwa zwei neue Releases pro Jahr auf dem Markt gebracht werden. Um sie auch gezielt verkaufen zu können, sollte jedes davon eine Geschichte erzählen können. Diese ist idealerweise eine gesunde Mischung aus allen drei Merkmalen.

Gerade die Aspekte rund um die Wartbarkeit von komplexeren und verteilten Anwendungen werden allzu oft vergessen oder gar verdrängt, da der Nutzen sowohl intern als auch extern als schwer zu verkaufen gilt. Dabei wird oft vergessen oder aber falsch eingeschätzt, dass nach etwa sieben Jahren fehlender Modernisierung die Anwendung im Betrieb auch deutlich mehr kosten wird und die Akzeptanz der Benutzer gefährlich sinkt. Wenn die Software die tägliche Arbeit nicht mehr zeitgemäß unterstützt, ergeben sich als Folge weitere, schwer bezifferbare Kosten für den Anwender durch mangelnde Effizienz und Produktivität. Schlimmstenfalls entscheiden sich die Anwender gegen die Anwendung und wechseln den Anbieter.

Die stetige Modernisierung der Anwendung ist das Fundament für einen sanfteren und kostengünstigeren Übergang zu einer neuen Version der Software. Das „Maintenance-Grab“ wird vermieden, welches droht, wenn eine alte Software nicht abgekündigt wird und der Support damit immer teurer zu werden droht.

Die Basis der Roadmap

Unserer Erfahrung nach sollten die Inhalte einer Roadmap immer an Kano angelegt werden und folgendermaßen aufgeteilt sein:

  • Wartbarkeit der Software – Erhaltung der Leistungsfähigkeit und der Performance sowie Reduzierung der Aufwände für Betrieb und Weiterentwicklung
    Die Kosten lassen sich nur über Leasing- oder Support-Modelle vom Kunden bezahlen
    Frei nach Kano: Basis-Merkmale
  • Pflege der vorhandenen Funktionalitäten – Kontinuierliche Verbesserung und Ausrichtung des Produktes. Bestandskunden bemerken die Modellpflege und werden gehalten. Idealerweise werden über Benutzergruppen die Kunden mit einbezogen, so dass die Roadmap teilweise von ihnen mitgestaltet werden kann.
    Die Kosten lassen sich nur über langlaufende und kostenpflichtig an Lizenzen gebundene Module refinanzieren
    Frei nach Kano: Leistungsmerkmale
  • Neue Funktionalitäten – Gezielte Erschließung neuer Märkte durch neue innovative Lösungen. Damit lassen sich Neukunden gewinnen und Bestandskunden auch begeistern.
    Die Entwicklungskosten fließen ebenfalls über neue kostenpflichtige Module zurück
    Frei nach Kano: Begeisterungsmerkmale

Welche konkrete Aufteilung gefunden wird, hängt von vielen Aspekten ab und schwankt natürlich von Release zu Release. – allerdings sollte kein Anteil stark unterrepräsentiert sein, d.h. nicht weniger als 20%.

Wie kommt die Flexibilität in eine Roadmap?

Im Laufe der Produktlebenszeit ergeben sich permanent neue Anforderungen aus dem Markt an die Software. Zu den strategischen Inhalten einer Roadmap kommt die Notwendigkeit, immer flexibel darauf zu reagieren.

Das Fundament für die Flexibilität der Roadmap ist ein agiles Vorgehen bei der Softwareentwicklung. Nur so kann der Produktmanager dann von folgenden Vorteilen profitieren:

  • Featuretausch: Es können sowohl die Inhalte als auch deren Reihenfolge verändert werden.
  • Release-whenever-you-want: Kurze iterative Entwicklungszyklen ermöglichen variable Release-Termine. Man muss nicht zwangsweise eine fertiggestellte Funktionalität zurückhalten, wenn diese bereits fertig entwickelt ist.

Mit diesen Möglichkeiten kann der Kunde schnell auf sich ändernde Marktanforderungen mit einer neuen Roadmap reagieren und sich Vorteile gegenüber der Konkurrenz verschaffen: „time to market“. Der Projektmanager muss im laufenden Projekt in der Lage sein, auf diese Änderungen adäquat zu reagieren.

Fazit

Der Produktmanager kann nur zusammen mit dem Projektmanager eine Agilität seiner Roadmap herbeiführen. Dabei ist dieser auf die Beratung durch den Projektmanager angewiesen, der zusammen mit der technischen Expertise des gesamten Projektteams und der offenen und transparenten Analyse der technischen Abhängigkeiten der Implementierung die Basis für verschiedene Lösungswege legt. Eine konsequente Betrachtung und Bewertung der Einzelfunktionalitäten in Muss-, Soll- und Kann-Eigenschaften ergibt die Basis, eine Funktionalität in eine eigene Roadmap zu zerlegen.

Das Projektmanagement muss auf diese starken Änderungs-Möglichkeiten einer agilen Softwareentwicklung ausgerichtet sein. Ein langfristiger Projektplan ist flexibel aber steuerbar zu gestalten, ohne den Fokus auf die notwendigen Erfordernisse an Leistung, Termine und Kosten zu verlieren. Unsere Projektmanager haben mit den Produktmanagern unserer Kunden mit diesem Vorgehen im agilen Festpreis sehr viele gute Erfahrungen gemacht.

 

Tassilo Kubitz

akquinet tech@spree

(Mitglied der GPM-Fachgruppe Agile Management)

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s