Man darf sich das mit der Priorisierung von Softwareanpassungen auch nicht so einfach vorstellen. Zunächst unterscheidet man diese üblicherweise kategorisch nach
- Bugfixes: Anpassung zur (Wieder-)herstellung einer bereits ausgelieferten Funktionalität
- Change Request: Veränderung des Umfangs / Verhaltens einer bereites ausgelieferten Funktionalität
- Feature Requests: Hinzufügen einer neuen Funktionalität
- Refactorings: Anpassungen ohne Auswirkungen auf die Funktionalität (z.B. Code-Optimierungen, allgemeine Softwarepflege, damit das Artefakt auch künftig noch wartbar)
Die Kategorie selbst gibt eine gewisse Priorität vor und zusätzlich werden alle Anforderungen innerhalb einer Kategorie zusätzlich priorisiert. Welche Kriterien dabei angesetzt werden, ist höchst unterschiedlich. Auch ist eine Abgrenzung zwischen den Kategorien nicht immer so leicht, weil die Frage „was war eigentlich genau Bestandteil der versprochenen Funktion“ nicht immer eindeutig beantwortet werden kann. Und damit verbunden auch die Frage, ob es sich um eine Fehlerbehebung handelt oder um eine neue Funktion. Prinzipiell sollten Bugfixes immer Vorrang vor neuen Funktionen haben, nach dem Motto: „bring erstmal den versprochenen Sche*ß zum Laufen, ehe du was neues anfängst“. Aber so einfach ist das leider nicht. Da gibt es Vorgaben und Erwartungen vom Management oder anderen Stakeholdern und ehe man sich versieht, hat man für Bugfixes bestenfalls genauso viel Zeit wie für neue Funktionen, für die das Marketing schon die Folien und Presseberichte fertig hat, obwohl die Liste an zu behebenden Fehlern (Backlog) vielleicht deutlich länger ist.
Da braucht es dann ein wirklich gutes Produktmanagement, das auch das Standing hat, sich mal gegenüber der Geschäftsleitung durchsetzen zu können. Dabei dürften auch definierte Kennzahlen (KPIs) eine entscheidende Rolle spielen und das ist dann der Punkt an dem wir Nutzer dann auch indirekt die Möglichkeit haben, etwas zu bewegen. Wenn Ticketaufkommen oder negative Presse sich entsprechend auswirken.
Aber selbst wenn das Management zu Zugeständnissen bereit wäre, die Roadmap aufgrund dringender Bugfixes anzupassen und einzelne Funktionen zu verschieben, ist es mit einem einzelnen fähigen Produktmanager leider nicht getan. Software ist heutzutage oftmals derart komplex, dass Entwicklungen von verschiedenen Teams erledigt werden. Jedes Team mit seinem eigenen Produktverantwortlichen und eigener Priorisierung der Aufgaben. Spannend wird es dann, wenn ein gemeldetes Problem zwischen den Teams herumgereicht wird, weil die Zuständigkeit vielleicht zunächst falsch bewertet wurde oder sich diese nach einer ersten Fehleranalyse anders darstellt. Und noch spannender wird es, wenn die Behebung eines Fehlers nicht innerhalb eines Teams erfolgen kann, sondern verschiedene Teams involviert sind. Da prallen dann direkt die Prioritäten der Beteiligten aneinander und machen eine intensive Abstimmung erforderlich. Besonders herausfordernd ist es dann, wenn es externe Abhängigkeiten gibt, man selbst also keinen Einfluss auf alle relevanten Bestandteile hat. In einem Auto könnte ich mir gut vorstellen, dass eine Firma wie Smart die Software einzelner Steuergeräte nicht selbst verantwortet. Zumindest von deutschen Autobauern wissen wir, dass da auch Zulieferer wie Bosch eine Rolle spielen. Und da wird es dann schon manchmal schwierig. Da ist der Autohersteller dann auch nur Kunde.
Das mal als kleinen Einblick in die Komplexität verteilter Systeme und den damit verbundenen Herausforderungen. Das erklärt dann hoffentlich auch, weshalb zuweilen als unnütz empfundene Funktionen veröffentlicht werden, obwohl es doch eigentlich gerade viel dringendere Baustellen gäbe. Gut möglich, dass das Ticket gerade bei einem anderen Team liegt, der Zulieferer auf sich warten lässt oder Konzernvorgaben die Entscheidung beeinflusst haben. Das muss weder für Smart noch die Automobilbranche als solches zutreffen, aber das sind meine Erfahrungen in 20 Jahren im Bereich der Softwareentwicklung.
