Was Product Owner FALSCH machen!
HTML-код
- Опубликовано: 29 авг 2024
- Innerhalb der Softwareentwicklung kommt dem Product Owner eine große Verantwortung zu: Er koordiniert und steuert das Entwicklungsprojekt. Dabei passiert es jedoch oft, das die Product Owner einen entscheidenden Fehler machen der auf lange Sicht gesehen dazu führt, dass ein Softwareprojekt in große Schwierigkeiten kommen kann. In dieser Episode schauen wir uns an, welche Fehler das sind und wie genau das ganze umgangen werden kann - Viel Spaß!
▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬
Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)
▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬
Wie viel Softwarequalität Ihr braucht - • Architekturen - Von Mo...
Warum Software unwartbar wird - • Warum Software unwartb...
Architektur - Modularisierung - • Architektur - Modulari...
Was ist Architektur - • Was ist Architektur?
Warum Architektur - • Warum Architektur für ...
▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬
Abonniere meinen Kanal: / @davidtielke
Alle Videos: / @davidtielke
▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
► Twitter: / davidtielke
► Xing: www.xing.com/p...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
![Scrum - Von A bis Z [Mit Profi-Tipps]](http://i.ytimg.com/vi/QtTH3m8GfN0/mqdefault.jpg)
![Scrum - Von A bis Z [Mit Profi-Tipps]](/img/tr.png)
Beliebter Satz von unserem PO: "Aber der Kunde will das genau so haben." Gegenrede der Entwickler ist nicht erwünscht.
Ja der Kunde zahlt auch dafür
@@BinGanzLieb Der Kunde mag vielleicht wissen und sagen was er *will*, aber nicht unbedingt das was er *braucht*.
@@krccmsitp2884 Wenn der Kunde nicht bekommt was er will, sondern nur das, was die Developer denken was er braucht, dann kauft er nicht und das Produkt wird eingestampft.
IT hat oft das Gefühl besser zu wissen, was die Fachabteilung will als die Anwender selber. Millionen von Data Warehouse Projekte sind so grandios gescheitert.
Ihr Spezialisten. Dafür macht man mit dem Kunden iterative Requirements-Analyse. Um zwischen dem was der Kunde will und dem was er braucht eine Überschneidung herzustellen. Da wird die Freude aber groß, wenn das gekaufte Produkt sich tatsächlich bewährt.
Diese Erfahrung mache ich mit meinen Projektleitern auch jeden Tag. Ungenügende Kommunikationsfähigkeit um dem Kunden die Augen zu öffnen was er wirklich braucht aber oft nicht mal das Hirn sich einen Kollegen vom Vertrieb zu holen um im Kunden die Bedürfnisse in machbare Bahnen zu lenken. 😅
Klar geht das nicht immer aber es klappt zumindest wenn man auf Standards hinwirken möchte um die fehlerträchtige Extravaganz zu bendigen und Supportkosten im Zaun zu halten.
Ist immer ein Problem, wenn ein Product Owner Projektmanagement und Projektlebenszyklen wenig kennt oder sogar bewusst nicht beachtet. Meine Hypothese: Viele PO's mit denen ich zusammenarbeite denken häufig, dass es jetzt nicht mehr um Projekte geht sondern um Produkte. Anstatt zu verstehen, dass es darum geht innerhalb eines Projektes ein Produkt zu entwickeln 🙂
Und dann versteht man einfach nicht mehr, dass es eigentlich nicht darum geht Stakeholder zu verteufeln, sondern genau darum Stakeholder auch wirklich abzuholen bzw. zu integrieren in den Entwicklungsprozess.
Danke für deinen Impuls das hier zu teilen!
Das sehe ich jetzt durchaus differenzierter. POs tragen die maßgebliche Verantwortung gegenüber dem Auftraggeber, was auch die Qualitätsattribute betrifft, die im überwiegenden Teil von den Entwicklern verantwortet werden. Er befindet sich häufig in einer undankbaren Rolle zwischen vielen verschiedenen Stakeholdern und kann es selten allen Recht machen. Von der einen Seite kommen unrealistische Forderungen bezüglich Featureumfang, Kostenersparnis und Zeitplanung; von der anderen Seite kriegt er zu hören, was alles Probleme bereitet, welche technischen Schulden abzubauen wären, dass die Zeitpläne unrealistisch sind etc.
Wichtig ist doch, dass der PO immer noch Teil des Entwicklungsteams ist. Und so muss man von einem PO auch erwarten, dass er in kontinuierlichem Austausch mit seinen Entwicklern (und Architekten und QA etc.) ist. Natürlich funktioniert das Konstrukt nicht, wenn es hier keinen engen Austausch gibt, denn ein PO muss auch für das Team einstehen. Das sehe ich als das zentrale Versäumnis in den genannten Beispielen dieses Videos.
Und auf der anderen Seite hat der PO auch nur einen Job, der ihm von jemand anderem anvertraut wurde, der wiederum hinter Features und schneller Markteinführung her ist. Es ist ja nur menschlich und verständlich, wenn der PO dann auch um seiner selbst willen dem Druck nicht immer standhalten kann.
Aus meiner Sicht macht man es sich zu einfach, wenn man es auf "den PO" schiebt, wenn die Entwicklung nicht wie gewünscht verläuft. Die Welt ist da doch etwas komplexer.
@@opodendorf Perfekt beschrieben!
Sehr gut und anschaulich erklärt! 👍👍👍
Hat mein Interesse für PO geweckt, wusste vorher nicht genau wohin es mich zieht.
Ich würd sagen dass PO, Architekt UND andere Schlüsselpersonen (Abteilungsleiter , Systemingenieure, Programleiter, …) als Team arbeiten müssen um solche komplexen Sachverhalte langfristig zu bewerkstelligen. Für mich ist es nicht in Ordnung, die Schuld bei 1 oder 2 Rollen zu suchen - zumindest in den Umgebungen in denen ich bisher tätig war.
Hey, sehr schön erklärt. Ich beschäftige mich aktuell auch mit dem Thema bezüglich einer Produktionsmaschine. Deine Videos sind sehr hilfreich und haben mir noch einige neue Aspekte eröffnet.
David du bist nicht nur Technik verliebt sondern hast auch immer ein Blick für Farben und Beleuchtung. Deine Videos geben uns neben dem super Content auch noch was fürs Auge ❤
Ich sage immer bunte Bilder macht die Leute glücklich 🙂
Gebe dir völlig recht. Ist aber nicht auch der Architekt dafür verantwortlich dem PO z.B. fehlende oder unzureichende Qualitätsaspekte zu melden und mit ihm zu "verhandeln"? PO und SA sollten da aus meiner Sicht an der Stelle enger zusammenarbeiten. Das fehlt aber häufig.
Danke für das Video, wie immer lehrreich mit praktischen Einblicken!
Wie immer ein sehr interessantes Video. Es zeigt auch wieviel in einer Firma schief laufen kann.
Wenn alle jammern, dass ihre Bedürfnisse nicht ausreichend Berücksichtigung finden ist man wahrscheinlich grade in der goldenen Mitte 😂
Die Rolle des Product Owners - so wie Du sie beschreibst - hatte anscheinend konkrete Personen vor Augen - nicht nur eine Rolle.
Meine Erfahrungen deuten darauf hin, dass es zu massiven Problemen kommt, wenn diese Rolle durch eine einzelne Person wahrgenommen werden soll. Das ging bislang immer schief. Ich versuche gerade diese Rolle auf ein Team aus Marketing, Designer, IT und Support aufzuteilen - ganz bewusst hat der Vertrieb dort nichts zu suchen, da er immer ausschliesslich projektbezogen denken würde, er kommuniziert aber regelmässig mit dem Marketing.
Ich bin gespannt, wie weit wir mit diesem Ansatz kommen…
Spannender Ansatz einen Stakeholder auszuschließen. Das Vertriebler meistens die lauteren sind und ihre Anforderungen hierdurch überbewertet werden, sollte man meiner Meinung nach bei der Priorisierung in den Vordergrund rücken.
Ich kritisiere gerade, dass bei uns die Rollen durch mehrere Personen besetzt werden, da jede Partei ihre eigenen Ziele verfolgt und für das Ganze übernimmt keiner die Verantwortung. Ist ein totales Chaos.
Natürlich steht und fällt die Qualität des Produktes mit der Qualität der Product Owners, aber Verantwortung teilen, sehe ich als das größere Übel an.
Drück dir die Daumen, dass es bei euch funktioniert! Jedes Team ist individuell 😉
Wie sind den bis jetzt deine Erfahrungen mit dem PO Komitee? Deine beschriebene Vorgehensweise ist entgegen des Scrum Guides. In meinen Augen ist das Marketing und der Support Stakeholder, der Designer Teammitglied und die IT wenn sie DevOps macht ebenfalls Team, sonst auch Stakeholder. Ich frage deswegen, weil ich schon häufig gelesen habe, das es ein Fehler ist und zu Schwierigkeiten kommen kann, wenn der PO durch mehrere Personen vertreten wird.
Stimme dir vollkommen zu!
Super Video - hab ein Abo dagelassen ;)
Prinzipiell alles richtig, aber da war jetzt wenig neues dabei :-( Leider sind POs meist von sich viel zu sehr überzeugt, um solche Videos anzusehen.
Die Ursache aller Schwierigkeiten ist die Illusion das Neuentwicklungen planbar seien!
Ich könnte einiges auf Product Owner schieben. Aber unfähige Projektleiter sind das eigentliche Problem.
Noch Happy mit dem Surface Book?