Produktmanagement bei der Projektron GmbH

Die Entwicklung unserer Software Projektron BCS läuft seit 2001. Es gibt sogar jetzt noch zwei Kunden aus dem ersten Jahr mit einer aktuellen Version. Beide Kunden haben uns auf der Reise begleitet, von einer Software für technikbegeisterte Innovatoren zu einer bei Fachleuten bekannten und geschätzten Software im Projektmanagement. Die ersten Anwender haben über viele Fehler und fehlende Dokumentation hinweggesehen, die Kunden der letzten Jahre schätzen die hervorragende Dokumentation und die tiefgreifenden Funktionen.

In den ersten Jahren war die Einzigartigkeit ein wichtiges Argument für den Kauf von Innovatoren und frühzeitigen Anwendern. Später waren Themen wie Schnittstellen, Performance, Sicherheit und auch Referenzen wichtig und die frühe Mehrheit derer zu gewinnen, die ihr Projektmanagement webbasiert vorantreiben wollten. Jetzt spielen auch Kosten und die Verfügbarkeit in der Cloud eine stärkere Rolle. Im Gegensatz zu vielen anderen Systemen werden wir aber auch langfristig eine On-Premises-Lösung unterstützen.

Die Ressourcen für gutes Produktmanagement sind für ein Produkt mit 10.000 Funktionspunkten geringer als für fünf Produkte mit je 2.000 Funktionspunkten. Während ersteres Ressourcen spart, würde letzteres ermöglichen, einzelne Module anders zu bewerben. Mit einem Produkt "Zeiterfassung" zum Beispiel würden wir sicher bei mehr Suchen, die nur zu diesem Thema erfolgen, gefunden werden. 

Trotzdem ist allein das Wissen um den aktuellen Funktionsumfang und die Wünsche und Erwartungen des Marktes für unser Produkt Projektron BCS schon lange nicht mehr von einer einzelnen Person zu leisten.

Als Ergebnis des Wachstums der Software und des Wechsels auf die Entwicklungsmethode Scrum haben wir nun zwei Chief Product Owner (CPO) und einen Technischen CPO (TCPO). Dazu sechs Domain Product Owner (DPO) die einen relativ großen Funktionsumfang betreuen sowie weitere zwanzig DPOs, die nur für ihr Spezialgebiet, zum Beispiel die Einbindung von Jira oder MS 365, zuständig sind.

Die Einführung von Scrum hatte nicht nur positive Auswirkungen in Bezug auf die klare Verteilung der fachlichen Verantwortung durch DPOs. Für Projektron hatte Scrum auch zu einer höheren Zufriedenheit der Entwickler geführt - ihnen wird jetzt bei jeder User Story erklärt, welchen Nutzen diese beim Auftraggeber stiftet. Durch dieses Verständnis waren alternative Lösungsvorschläge möglich und die Qualität der Aufwandsschätzungen verbesserte sich deutlich. 

Wir versuchen möglichst die Leute einzubeziehen, die die Probleme aus der eigenen Praxis kennen. Deshalb hat bei Projektron die Leiterin Finanzen die Verantwortung für die Funktionen in der Rechnungsstellung, die Leiterin Personalmanagement die Verantwortung für die Abbildung von Arbeitszeitmodellen und Fähigkeiten der Mitarbeiter und zwei Berater verantworten die Entwicklung des BPMN-Moduls.

Die Verantwortung für Teile des Produktmanagements an Spezialisten abzugeben, ist aber nur möglich, weil wir in allen Bereichen, die sich anbieten, Projektron BCS nutzen. Die DPOs achten dann bei der Abbildung der Kundenwünsche darauf, dass möglichst auch eigene Anforderungen erfüllt werden.

Der Anteil der Funktionen, die durch Anforderungen von Anwendern in das Produkt kam, ist sicher höher als bei anderer Software. Der Grund ist, dass die Projektron GmbH es sich erst nach zehn Jahren erlauben konnte, fachliche Anforderungen zu spezifizieren, die nicht von Kunden beauftragt worden waren. Das hatte Vor- und Nachteile.

Der Vorteil war, dass es in dieser Zeit für jede Funktion einen sehr motivierten externen Tester gab. Der Nachteil war, dass wir keinen großen fachlichen Wurf machen konnten. Wir haben zum Beispiel den kritischen Pfad, ein zentrales Element der Projektplanung, erst nach sieben Jahren im Produkt realisiert, da es vorher keinen Kunden gab, der diese Erweiterung mittrug.

Wir haben in den letzten 15 Jahren den Anteil der kundenspezifischen Erweiterungen zurückgefahren. Die Erweiterungen, die die Kunden beauftragen, spielen nur noch einen kleinen Teil der Entwicklungskosten ein. In den letzten fünf Jahren lag der Umsatz durch kundenspezifische Erweiterungen immer um 2,5 Prozent des Gesamtumsatzes. Die Ressourcen in der Entwicklung für fachliche Erweiterungen waren damit aber trotzdem ungefähr zur Hälfte belegt. Ein Grund ist das intensivere Testen als früher und dass wir dafür sorgen, dass Erweiterungen durch Konfigurationsmöglichkeiten immer einem möglichst großen Kundenkreis zugutekommen können.