Podcast-Icon (Mikrofon)

Was man als Product Owner:in im Projektgeschäft braucht

Wie sieht der Alltag als Product Owner:in bei Assecor aus? Welche Erfahrungen haben wir mit OKR-Planning gemacht? Ein Gespräch mit zwei Product Owner:innen über das, was wirklich wichtig ist.
Inhaltsverzeichnis

Dieser Artikel ist ein bearbeiteter Auszug aus unserer zweiten Staffel des IT-Podcasts 4x30. Hören könnt ihr die ganze Folge hier

 

Maximilian Lukasczyk: Seit 10 Jahren bei Assecor in verschiedenen Rollen tätig, unter anderem als Product Owner. Neben der über viele Jahren aufgebauten Expertise von Max, hat er in den 10 Jahren auch wichtige Erfahrungen anderer Art auf einer längeren Weltreise und jüngst durch Elternzeit gewonnen.

Veronika Saakova: Seit 10 Monaten bei Assecor tätig in ihrem ersten Projekt, das noch mehrere Jahre andauern wird. Veronika hat seit der zweiten Klasse deutsch gelernt und arbeitet heute in einemdeutschsprachigen Umfeld. Und das dazu noch in einem Beruf, in dem man Talent für Kommunikation braucht.

 

Max, wieviel Projekte hast du bei Assecor schon gestemmt?

 

Max: Wir haben manchmal kleinere Projekte, wir haben auch manchmal größere Projekte. Ich bin jemand, ich mag die größeren Projekte. Deswegen waren es möglicherweise nicht so ganz so viele, aber ich glaube, dass ich die Zahl im zweistelligen Bereich bewegt. Ja, vielleicht zehn. Vielleichtwaren es auch 15.

 

Ihr habt im selben Projekt gearbeitet. Um was geht es denn eigentlich in dem Projekt genau?

 

Veronika: Das Projekt hat mit Finanzen zu tun. Unser Kunde ist ein deutsches Unternehmen für Finanzsoftware und wir sind dafür verantwortlich, dass die digitale Kommunikation mit Banken und Zahlungsdienstleister klappt. In dem Projekt kümmern wir uns konkret darum, dass bestimmte digitale Kommunikationsformate umgestellt werden.

 

Klingt sehr aufwändig.

 

Veronika: Ja, es ist ein großes Projekt. Und das Projekt ist zeitbegrenzt. Es dauert noch eine Weile, bis wir damit fertig sein werden.

 

Wie sieht denn dein Arbeitsalltag aus?

 

Veronika: Immer unterschiedlich, weil immer wieder neue Themen vorkommen. Aber grundsätzlich lässt sich mein Arbeitstag in dreigroße Blöcke einteilen. Der erste ist die Kommunikation mit dem Kunden, hier sammele ich die Anforderungen und Wünsche, die wir umsetzen sollten. Und danach priorisieren wir die.

 

Der zweite Block ist die Kommunikation mit dem Team, bei der sich das Team mit den Anforderungen des Kunden vertraut macht und anhand des Umfangs und Umfangs und der Größe, der Aufgaben und der Priorität entscheidet und sagt, was wir in diesem Monat zu tun haben.

 

Und der dritte Block ist die fachliche Bearbeitung von Fragen, um in Zukunft Vorschläge für den Kunde zu machen.

 

Wie organisiert ihr euch im Team?

 

Veronika: Wir haben eine Kernarbeitszeit von 10 bis16 Uhr, dazwischen teilen wir alles selbst bestimmt ein. Dazu gibt es festgelegte Termine, wie zum Beispiel jeden Tag 15 Minuten Refinement, jede Woche eine Stunde Retrospektive, und jede zwei Wochen zwei Stunden, in denen wir besprechen, was wir in diesem Monat oder in diesen zwei Wochen gut gemacht haben und wo wir uns verbessern können.

 

Max, du bist damals wegen der Elternzeit aus dem Projektraus und hast Veronika eingearbeitet. Wenn du das nun so hörst, hat sich da viel geändert, seit du das Projekt verlassen hast?

 

Max: Nein, eigentlich sind es immer noch die gleichen Themen. Das ist vom Projekt abhängig. Einmal ist der Product Owner stark in der Requirements-Analyse unterwegs. In anderen Projekten ist es so, dass der Kunde die Anforderung schon vorbereitet gesammelt hat und der Product Owner das Ganze nur noch aufbereiten muss. Dann geht er mit dem Team in die entsprechenden Planungstermine und macht die unterbreitet die entsprechenden Vorschläge dem Kunden, in welcher Reihenfolge das ganze abgearbeitet werden sollte. Im Groben und Ganzen sind die Prozesse aber quasi die gleichen. Bei allen Teams.

 

Wie managed ihr das über mehrere Teams verteilt an einem Projekt zu arbeiten?

 

Max: Ja, mit den anderen drei Dienstleisternzusammenzuarbeiten war eine Besonderheit in diesem Projekt. Die Organisationwurde hier durch den Kunden vorgegeben. Es gibt also keinen Generalunternehmer, der die Zusammenarbeit der Teams organisiert, sondern der Kunde hat das übernommen.

 

In diesem Projekt gibt es außerdem, das hat auch der Kundeeingebracht, fachliche Schnitte. Die sogenannten Bounded Contexts. Und für diese Bounded Contexts werden Anwendungskomponenten definiert, die bestimmte Aufgaben übernehmen. Und so hat dann jedes Team ausgewählte Anwendungskomponentenübernommen und erstellt. Die einen zum Beispiel die Kommunikation, die anderen die Weiterverarbeitung und so weiter.

 

Und dazu wird einmal im Monat die neue Methodik von Google eingesetzt: Das OKR-Planning. Hier werden Ziele vorgegeben, die man erreichen möchte, und jedes Team darf oder hat die Möglichkeit selbst zu definieren, durch welche Aktionen oder durch welche Features es diese Ziele erreicht.


Und Veronika, findest du, das klappt gut? Kommst du mit OKR-Planung gut zu Recht?


Veronika
: Ja, ich glaube, das bringt viel Mehrwert, weil wir wissen, welche Ziele wir erreichen sollen. Und wir können selbst, wie schon gesagt, definieren, wie wir diese Ziele erreichen.

Max: Da müssen wir als PO aber genau herausarbeiten, was der Kunde haben will. Und wir befragen die Entwicklenden, welches die besten Technologien sind. Die sind die Fachleute.

 

Veronika: Zum Verständnis: In komplexen Umgebungen ist es kompliziert, im Voraus festzulegen, was eigentlich genau gebraucht wird. Und es kann passieren, dass wir irgendwas für diesen Monat geplant und implementiert haben, und im nächsten Zyklus kommen neue Anforderungen, die dem widersprechen, was bereits in Produktion ist, weil der Kunde erst dann weiß, was er möchte, wenn er sieht, was er in der Produktion bekommt.

 

Max: Das heißt, wir als Product Owner und erst recht der Kunde können gar nicht einschätzen, wie die Lösung am Ende aussehen kann. Sondern der Product Owner und damit auch der Kunde müssen so spezifisch wie möglich Ziele definieren.

Und ich sehe gerade in anderen Projekten so oft, in denen der Kunde agile Vorgehensweisen noch nicht kennt, dass der Kunde da leider gerne wieder das Wasserfall-Prinzip möchte, das heißt eine sehr starke Planung. Und dann kann das Projekt leicht in Schieflage geraten.

 

Dass in dem Projekt, das jetzt Veronika hat, konsequent agil gearbeitet wird, fand ich rückblickend sehr schön.

 

Der Product Owner ist nicht nur die Schnittstelle zum Kunden. Was ist sonst noch als PO wichtig?

 

Max: Dadurch, dass wir Dienstleister sind, gehen wir ganz stark in die Kommunikation zum Kunden. Wir müssen dafür sorgen, dass einerseits das Team ausgelastet ist. Wir brauchen also stets genug Anforderungen, dass das Team weiter arbeiten kann. Das Backlog muss immer gefüllt sein. Ich glaube, Veronika hat einen sehr volles Backlog übernommen und eher wieder Sachen rausgeschmissen, richtig?

 

Veronika (verschmitzt): Ich habe das Backlog erst mal analysiert.

 

Max (lacht): Ja, das ist auch richtig so.

 

Max: Genau, aber das ist, das ist das Ziel. Das Backlog sollte eben immer gefüllt sein. Das klingt so böse, aber das, um eine Perspektive zu haben und bieten zu können. Auch für das Entwicklungsteam. Und das ist so eine Rolle, die ich vielleicht, wenn ich ein Inhouse Product Owner bin, in einem Konzern oder einem anderen Unternehmen möglicherweise nicht habe.

 

Ihr müsst euch in diesem Projekt sicher auch viel Fachwissen aneignen. Veronika, war das für dich am Anfang schwierig?

 

Veronika: Dass das einfach war, kann ich nicht behaupten. Als ich gekommen bin, habe ich sofort erfahren, dass Max in zwei oder drei Monate weg sein wird. Und dann hatte ich nur begrenzt Zeit, in der ich das ganze Projekt übernehmen sollte, wo Max ja schon drei Jahre drin war. Ja, ich war ziemlich nervös.

 

Es ist ja immer beängstigend und schwer, etwas Neues anzufangen. Aber ich muss sagen, ich bin ins Team gekommen und ich muss sagen, dass ich noch nie in einem so eingespielten Team gearbeitet habe! Ich wurde sehr gut aufgenommen. Die Teammitglieder unterstützen sich gegenseitig, kommunizieren offen, helfen und scheuen sich nicht, Fragen zu stellen.

 

Und nachdem ich ganz am Anfang meiner Arbeit in diesem Projekt eine gewisse Sicherheit durch die Team-Atmosphäre erhalten hatte, hatte ich auch keine Angst mehr. Deswegen ja, ich habe sehr viel vom Team gelernt.

 

Auch als Max weg war, habe ich sehr viel vom Team mitgenommen und die haben mich sehr unterstützt. Und dazu gibt es noch andere Product Owner von Kundenseite und Product Owner von anderen Teams. Und natürlich sei hier auch die Dokumentationssoftware erwähnt, in der ich die Informationen über das Projekt nachlesen konnte und mich so Schritt für Schritt einarbeiten konnte – und das mache ich eigentlich immer noch.

 

Das ist auch ein Kompliment an dich Max, dass das Team so gut eingespielt war.

 

Max: Nein, das Lob gehört wirklich dem Team. Es ist eben ein Kernteam. Die Teammitglieder kennen sich schon aus dem Projekt zuvor, indem ich auch drin war - und sogar teilweise noch darüber hinaus. Und auch in dieses Team kamen neue Mitarbeiter hinzu. Wir versuchen natürlich schon, dass die Teammitglieder alle nach der eigenen Facon individuell sind, aber auch irgendwie kompatibel zueinander.

 

Vielen Dank euch beide für das Gespräch!

Ihr wollt diese Folge und weitere unseres Podcasts hören?

Assecor-IT-Podcast 4x30

 

Oder ihr wollt als Product Owner:in Teil des Assecor-Teams werden? Dann bewerbt euch gerne hier.

 

Oder ihr habt erstmal Lust auf einen Kaffee?

by Assecor
Teilen
LinkedIn Logo
LinkedIn Logo
LinkedIn Logo
Assecor Kontakt - IT Dienstleister aus Berlin
Assecor Kontakt - IT Dienstleister aus Berlin
Assecor Linkedin - IT Unternehmen aus Berlin