Gedankentüdelüt (75): Wie man Projekte so richtig in den Sand setzt

Die offizielle Beschreibung meines Berufes lautet aktuell Product Owner (mit ein bisschen fancy Kram davor und danach, aber im Großen und Ganzen kann man es auf diesen Begriff herunterbrechen). Und damit bin ich eigentlich sehr zufrieden, denn das rumtüfteln an Ideen in Verbindung mit diversen Anforderungen und Konzeptionieren des ganzen Schmus in eine Form, die keine Fragen mehr offenlässt – da hab ich Spaß dran.

Woran ich eher weniger Spaß hab: Ressourcen-Planung, Timing-Jonglage und den ganzen Mist, den man eigentlich als Projektmanagement bezeichnen kann. Das ist, soweit ich es mitbekommen habe, immer mit Termindruck und Stress verbunden – dafür muss man geboren sein oder einfach die richtigen Projekte erwischen.

Das Problem, dass ich immer wieder sehe: die Trennung zwischen Produkt- und Projektmanager bekommt nicht jeder hin. Das ist bis zu einem gewissen Grad einigermaßen nachvollziehbar, schließlich kümmert sich der Produktmanager oder auch Product Owner vollumfänglich um sein Produkt, für das er auch die Verantwortung hat – der Ottonormalverbraucher sieht da natürlich auch Timing und Budget.

Für mich hab ich es allerdings immer so definiert (und das kann man auch an diversen Stellen als Bestätigung nachlesen), dass der Produktmanager so rein gar nichts damit zu tun hat, was die aktive Umsetzung seines Produktes angeht. Seine Aufgabe ist viel mehr die Vor- und Nachbereitung. Vorher die Abhängigkeiten klären, vorher das Konzept schreiben, vorher alle offenen Fragen klären und vorher auch alle – ich hasse das Wort – alle Stakeholder ins Boot holen. Ist das Produkt umgesetzt, geht es an die Analyse. Wo sind Fehler, wo muss nachgebessert werden, wo gibt es allgemein Nachbesserungspotential?

Natürlich ist der Produktmanager auch während der Umsetzung gefragt – sämtliche Fragen vorab zu klären, ist immer ein Ding der Unmöglichkeit, gerade wenn die Geschichten komplexer sind. Aber mir als Product Owner ist am Ende des Tages eigentlich vollkommen egal, welcher Entwickler das umsetzt und wie viele dafür gebraucht werden (wobei man das natürlich aus Kostensicht einschränken muss). Mir ist weitestgehend ja sogar egal, wann neue Features oder Produkte kommen – aber wenn sie kommen, dann muss der Schuss sitzen.

Was aber – und da sprech ich aus aktuell eigener Erfahrung – so gar nicht geht: Deadlines definieren, ohne auch nur ansatzweise vorher Anforderungen und Abhängigkeiten zu prüfen. Am besten noch zu einem fest definierten Preis. Es geht ja auch keiner zum Autohändler, haut dem 50€ auf den Tisch und kann dann erwarten, einen Neuwagen hingestellt zu bekommen.

Was dann noch erschwerend hinzukommt: mehrere Projekte hintereinander. Wenn sich das erste Projekt – warum auch immer – nach hinten verschiebt, wäre die logische Konsequenz, dass sich auch die Folgeprojekte nach hinten verschieben.

Wäre, hätte, könnte …

Nun könnte man sagen: Okay, war beim ersten Mal scheiße, machen wir so nicht noch mal.

Aber hätte, wäre, könnte …

Genauso gut könnte man sagen, dass man einfach mehr Leute auf das Projekt schmeißt – viele Hände schaffen viel. Was aber auch nur die Wenigsten auf dem Schirm haben: viele Hände müssen trotzdem erst eingearbeitet werden. Mit fortschreitender Zeit und immer näher rückenden Deadlines ist auch das nur bedingt eine Lösung. Zumal viele Hände durch wenige Hände gesteuert werden müssen.

Und irgendwann merkt man dann, dass man direkt inmitten des Henne-Ei-Problems sitzt.

Was da die Lösung ist? Abgesehen von spontan eintretender Vernunft gibt es vermutlich keine. Aber immerhin werde ich immer wieder aufs Neue bestätigt, dass ich lieber Product Owner als Projektmanager bin. Und das dann aber auch mit Leib und Seele.