Was ist eigentlich ein Product Owner?
Ab einem gewissen Alter ist es bei sozialen Treffen üblich, dass man seine/n Gesprächspartner/in nach dem Beruf fragt. Es hat quasi jeder einen Beruf und damit ist einfach ein Gesprächsthema für den Einstieg gefunden.
Bei vielen Berufen hat man eine grobe Vorstellung, die einem hilft Fragen und Meinungen auszutauschen. Ein Augenarzt ist für die Augengesundheit da, ein Dachdecker deckt Dächer, ein KFZ-Mechatroniker repariert Autos. Und dann komme ich: Ich bin Product Owner. Ein Jobtitel, den außerhalb der IT quasi keiner kennt, und selbst in der IT können sich viele unter dem Beruf nichts vorstellen.
Ein Grund für mich, einfach mal zu beschreiben, was ein Product Owner, kurz PO, eigentlich macht. Dabei habe ich selbst die Suchmaschine der Wahl bemüht und mir die Definitionen im Internet angesehen. Und genau wie ich haben diese Schwierigkeiten, die Rolle des Product Owners in wenigen Worten zu beschreiben. Ich versuche es trotzdem:
Ausführlicher ist es nicht so leicht. Als Produkt Owner bekommt man von Unternehmen zuerst ein oder mehrere Produkte zugewiesen. Dabei kann das Produkt eine Software (beispielsweise eine Office Suite), ein Teil einer Software (die Textverarbeitung Word) oder ein Unternehmensteil sein. Bei mir sind die Produkte im Wareneingang der Logistik angesiedelt und umfassen jeweils einen Teil des Wareneingangsprozesses. Die Annahme, die Warenprüfung, der interne Transport, und so weiter. Da kein Unternehmensteil heutzutage ohne IT funktioniert braucht es auch jemanden, der alle anfallenden IT-Themen dieser Teile koordiniert.
Dabei geht der Auftrag zur Koordination sehr weit. Ein Product Owner ist recht nahe an der Geschäftsführung angesiedelt und ist bewusst keiner Fachabteilung zugeordnet. Damit ist die Fachabteilung gegenüber dem PO nicht weisungsbefugt. Das ist auch wichtig für eine seiner wichtigsten Tätigkeiten: Die offenen Entwicklungsthemen genannt Backlog inhaltlich zu prüfen, zu bewerten und zu priorisieren. Ein PO entscheidet darüber ob und wann ein Projekt von den Entwicklern umgesetzt wird. Natürlich immer mit dem Ziel die vorhandenen Entwicklungsressourcen so gewinnbringend wie möglich einzusetzen. Die Unternehmensziele und abgestimmte Produktziele sind dabei die Orientierungshilfe und Richtungsgeber.
Alle weiteren Aufgaben leiten sich quasi aus der Prüfung und Priorisierung ab. Das Entwicklungsteam muss immer ausreichend ausgearbeitete Arbeitspakete zur Verfügung haben, die Anforderer wollen über den aktuellen Status ihrer Themen auf dem Laufenden gehalten werden und häufig braucht es Informationen oder Zuarbeiten aus anderen Bereichen, die beschafft werden müssen. Und natürlich kümmert sich der Produkt Owner auch aktiv um die Weiterentwicklung seiner Produkte, indem er selbst notwendige Projekte einbringt und ausarbeitet.
Man sieht, der Job hat viel mit Kommunikation und Planung zu tun. Dabei ist Planung nicht im Sinne von festen Zeitplänen zu verstehen. Das steht dem agilen Manifest in der IT entgegen, welches flexible Reaktionsmöglichkeiten auf sich ändernde Bedingungen propagiert. Die grösste Schwierigkeit als Product Owner ist es, zumindest für mich, in der Kommunikation und der Koordination nicht nur planen und gestalten zu können, sondern auch regelmässig auf neue Anforderungen und Bedürfnisse reagieren zu können.
Ich bin mir noch immer nicht sicher, ob meine Arbeit mit dem Text halbwegs verständlich und kompakt zusammengefasst ist. Gerade die Schwierigkeit des Berufs ist schwer zu beschreiben. Trotzdem hoffe ich, dass ihr damit einen groben Einblick in die Tätigkeit des Product Owners bekommen habt.