Was einen guten Product Owner wie Roland ausmacht? Geschäftsprozesse in Softwareprogrammen und Apps so abzubilden, dass sie zweckdienlich sind und es Spaß macht, damit zu arbeiten.
Roland ist seit einiger Zeit Teil des wachsenden Software-Teams bei REISSWOLF Systems. Während andere Kolleginnen und Kollegen quer über Deutschland verteilt größtenteils remote arbeiten, ist er meistens direkt vor Ort in Glinde. Wenn man ihn fragt, wie zufrieden er bei REISSWOLF ist, so lautet die Antwort: „Es ist super hier. Leute cool, Umgebung cool. Art und Weise des Umgangs cool. Ich bin sehr begeistert!“
Roland hat sehr schön erläutert, was die Arbeit bei der REISSWOLF Systems von den anderen unterscheidet: Während wir im Lager, der Produktion, dem Marketing und Vertrieb und den vielen anderen Bereichen Software als Werkzeug und Hilfsmittel für unsere tägliche Arbeit nutzen, sind sie in der virtuellen Software-Welt beheimatet, d.h. sie schreiben Konzepte (Stories), Programm-Code und Dokumentation. So bestehen unsere eigens entwickelten Software-Programme REISSWOLF dok. suite. und REISSWOLF archiv. manager. aus rund 250.000 Zeilen Programm-Code. Das sind, je nach Schriftgröße und Norm, rund 5.000 DIN A4-Seiten oder 3x die Herr-der-Ringe-Trilogie.
Seine Rolle als Product Owner fordert ihn auf mehreren Ebenen. Die Kernkompetenz eines Product Owners ist es, die Probleme aus Sicht eines Auftraggebers zu verstehen und sie so zu beschreiben, dass ein oder mehrere Entwickler in der Lage sind, ein Stück Software zu bauen, die den Auftraggeber zufriedenstellt und einem Anwender die Arbeit erleichtert.
Ein zweiter wichtige Part, den ein Product Owner zu leisten hat, ist die Wirtschaftlichkeit eines Projekts zu gewährleisten. Denn was nützt eine theoretisch großartige Software, die aufwendig und kostenintensiv in der Entwicklung ist, wenn sie später in der Praxis nur wenig Mehrwert bietet? Roland spricht oft vom Paretoprinzip, auch 80-zu-20-Regel genannt: 80 % der Ergebnisse werden mit 20 % des Gesamtaufwandes erreicht. Die verbleibenden 20 % der Ergebnisse erfordern mit 80 % des Gesamtaufwandes die meiste Arbeit.
Eine weitere Herausforderung liegt in der Komplexität der Systeme. Kundenindividuelle Einstellungen und Programmierungen liegen oft unsichtbar im Hintergrund und treten erst in Erscheinung, wenn an dem System etwas geändert wird. Stellt Euch vor Ihr spielt Mikado und wollt ein Stäbchen entfernen, ohne, dass andere sich bewegen. Das beschreibt das Problem sehr gut. Wenn ein User beispielsweise aus Bulgarien ein Problem hat und wir dies lösen wollen, darf das nicht dazu führen, dass wir eine andere wichtige Funktion für einen User aus Frankreich dadurch verschlechtern.
Zudem müssen neue Funktionen, Apps und Anpassungen immer wieder an gesetzliche Veränderungen (z.B. DSGVO, NetzDG, GoB, ISO 9001, ISO27001) angepasst werden. Außerdem sind regelmäßig Updates erforderlich, weil sich Betriebssysteme, Browser und Datenbank-Systeme verändern und aktualisiert werden wollen. All dies muss gemacht und finanziert werden.
Das ist bei Funktionen, die wir für einen Partner oder Kunden entwickeln natürlich anders. Der Partner oder Kunde, der eine individuelle Anpassung benötigt, muss auch die Entwicklungskosten tragen. Dabei dreht sich die Diskussion schnell zur Prozess- und Unternehmensberatung. Welche Kosten werden mit der Funktion eingespart und wo ist der Break-even-Point? Was darf die Entwicklung also kosten? Bei einem Feature, das, ein wenig verändert, plötzlich für viele Anwender einen Mehrwert bringt, können die Entwicklungskosten auf mehrere Schultern verteilt werden und tragen so zum allgemeinen Funktionsumfang bei, ohne dass ein einzelner Kunde dafür aufkommen muss.
Am meisten Spaß an der Arbeit hat Roland bei der „Übersetzung“, die ein Product Owner erbringen muss. Denn oftmals ist es so, dass das, was sich Menschen, Gesetzgeber oder Auftraggeber wünschen, nicht das ist, was sie brauchen, um ihre Ziele zu erreichen. Das gilt auch im Falle der Software-Entwicklung. Vielleicht sogar ganz besonders in diesem Fall. Als Product Owner nimmt man die funktionalen Anforderungen auf, übersetzt sie zunächst in eine Business-Logik und diese übersetzt man dann nochmals für die Entwickler in einzelne Funktionen bzw. Stories. Diese werden dann regelmäßig mit den Software-Architekten diskutiert und ggf. gekürzt, denn nicht alles, was sich ein Product Owner wünscht, ist auch technisch machbar oder sinnvoll. Hier gilt es einen Spagat zwischen Wunsch und Wirklichkeit hinzubekommen. Die Summe aller Stories wird dann zu einem neuen Release bzw. einer neuen Version.
Die Priorisierung aller Anforderungen, ist dann die nächste Hürde, denn alle Anforderungen und Wünsche können nur sehr selten erfüllt werden. Welches Problem oder welcher Kunde ist wichtiger als ein anderer und wie erkläre ich es dem letzten in der Reihe, der es nicht mehr in das Release geschafft hat? Wenn es einen Punkt gibt, der Roland bei der Softwareentwicklung manchmal stört, dann ist es das Problem, dass gute Ideen auf der Strecke bleiben, weil die Bereitschaft oder die Möglichkeit fehlt, das benötigte Geld zu investieren.