Was Product Owner FALSCH machen!

Рет қаралды 11,182

Жыл бұрын

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/profile/David_Ti...
► LinkedIn: / david-tielke-06140912b
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

Пікірлер: 27

@superlive-sh 11 ай бұрын

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!

@Jan_Hille Жыл бұрын

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.

@michaelschmitz3067 Жыл бұрын

Danke für das Video, wie immer lehrreich mit praktischen Einblicken!

@sebastiangrafe459 Жыл бұрын

Beliebter Satz von unserem PO: "Aber der Kunde will das genau so haben." Gegenrede der Entwickler ist nicht erwünscht.

@BinGanzLieb Жыл бұрын

Ja der Kunde zahlt auch dafür

@krccmsitp2884 Жыл бұрын

@@BinGanzLieb Der Kunde mag vielleicht wissen und sagen was er *will*, aber nicht unbedingt das was er *braucht*.

@DerTaran Жыл бұрын

@@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.

@vaxrvaxr Жыл бұрын

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.

@samda7109 6 ай бұрын

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.

@sicilianotube 5 ай бұрын

Sehr gut und anschaulich erklärt! 👍👍👍 Hat mein Interesse für PO geweckt, wusste vorher nicht genau wohin es mich zieht.

@andreweinert8725 Жыл бұрын

Wie immer ein sehr interessantes Video. Es zeigt auch wieviel in einer Firma schief laufen kann.

@eseldu7906 Жыл бұрын

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.

@rohrbold Жыл бұрын

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.

@SUPERSONIC_ARCHERY Жыл бұрын

@@opodendorf Perfekt beschrieben!

@tomdanielsofficial Жыл бұрын

Super Video - hab ein Abo dagelassen ;)

@michaeldornberger5051 Жыл бұрын

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.

@projektingenieur8491 Жыл бұрын

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 🙂

@easypy Жыл бұрын

Stimme dir vollkommen zu!

@user-fw2gm9pv1c 11 ай бұрын

Wenn alle jammern, dass ihre Bedürfnisse nicht ausreichend Berücksichtigung finden ist man wahrscheinlich grade in der goldenen Mitte 😂

@heikokunze5800 Жыл бұрын

Prinzipiell alles richtig, aber da war jetzt wenig neues dabei :-( Leider sind POs meist von sich viel zu sehr überzeugt, um solche Videos anzusehen.

@aggifun4471 11 ай бұрын

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…

@wrappar 11 ай бұрын

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 😉

@Erik_Fa 2 ай бұрын

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.