Welche Rolle/Verantwortung hat der Product Owner bei einem Proof of Concept mit einem externen Anbieter?

Die Rolle des Product Owners, wie sie im Scrum Guide definiert ist , sagt nichts über die Zusammenarbeit mit einem Anbieter aus.

Gibt es weitere Verantwortlichkeiten, die dieser PO in dieser Situation übernehmen sollte?

Das hängt von einer Reihe von Faktoren ab, darunter:

• Die Fähigkeiten des Product Owners
• Wie viel Zeit sie zur Verfügung haben
• Ob sie interessiert sind und sich an nicht-traditionellen Product-Owner-Aktivitäten beteiligen möchten
• Die Fähigkeiten anderer Teammitglieder

Oder gehört dieser Teil dem Produktmanager oder Scrum Master?

Auch hier sagt die im Scrum Guide definierte Rolle des Scrum Masters nichts über die Zusammenarbeit mit einem Anbieter aus.

Mein Vorschlag wäre wie folgt:

• Der Product Owner übt weiterhin seine definierte Rolle aus, es sei denn, er möchte sich ausdrücklich in die Zusammenarbeit mit dem Anbieter einbringen
• Der Scrum Master erfüllt seine übliche Rolle im Team: Er unterstützt den Scrum-Prozess und hilft bei der Beseitigung von Hindernissen
• Das Entwicklungsteam übernimmt die Verantwortung für den Umgang mit dem Anbieter

Wenn das Entwicklungsteam nicht über die erforderlichen Fähigkeiten verfügt, um mit dem Anbieter zusammenzuarbeiten, kann es sich lohnen, ein Teammitglied mit den erforderlichen Fähigkeiten hinzuzufügen. Ich habe mit Scrum-Teams gearbeitet, in denen jemand mit einem Hintergrund im Projektmanagement war, und sie waren oft diejenigen, die sich mit Anbietern/Kunden befassten.

In einem POC sollte der Product Owner der Entscheidungsträger sein, die Person, die die Eignung des zu bewertenden Produkts beurteilt und den Kauf tätigt oder empfiehlt – oder jemand, der von dem/den Entscheidungsträger(n) nominiert wird. Es ist äußerst wichtig, dass sie den Fokus des Teams darauf richten, die erforderlichen Beweise zu demonstrieren oder die Lektionen zu lernen, für die der POC bestimmt ist.

Ich würde auch vorschlagen, dass Scrum möglicherweise nicht die beste Wahl für einen POC ist, es sei denn, die erwartete Dauer beträgt mehr als beispielsweise einen Monat. Für eine kürzere Arbeit kann Kanban besser geeignet sein. Die Natur eines POC ist, dass es um Entdeckung, Lernen und kontinuierliche Anpassung geht, während Sie fortfahren. Bei Scrum dreht sich alles um iterative Lieferung, Kadenz und funktioniert nur dann gut, wenn das Ergebnis jedes Sprints während der Sprintplanung definiert werden kann - bei einem kurzen POC schwer zu erreichen, hätte ich gedacht.

PO scheint die richtige Person für die Beziehung zum Anbieter zu sein. Zusammenarbeit und Anpassungsfähigkeit sind normalerweise wertvoller als Planung, aber das kann von der Art der Arbeit und der Beziehung zum Anbieter abhängen. Kein Projektmanager in Scrum, da der PO für die Festlegung des Umfangs und der Prioritäten verantwortlich ist und das Team als Ganzes für die Planung verantwortlich ist.

Ein Proof of Concept (POC) kann nicht in Bezug auf Story Points, Stunden oder eine von Ihnen verwendete Dimensionierung geschätzt werden, da es darum geht, zu beweisen, ob ein vorgeschlagenes Modell funktioniert oder nicht. Aus diesem Grund kann es nicht in einen Sprint aufgenommen werden.

Soweit ich weiß, ergibt sich die Notwendigkeit, es in die Sprints aufzunehmen, aus folgenden Gründen:

1. Einige der Entwickler im Scrum-Team werden an diesem POC arbeiten
2. Das Ergebnis des POC sind Epics, Stories und/oder Tasks für das Scrum Team

Sie sollten diesen POC genauso angehen, wie Sie einen Fehler aus der Produktionsumgebung angehen; Haben Sie ein Kanban-Board für diese Art von Aktivitäten und fügen Sie dort den POC hinzu. In Bezug auf die Arbeitsbelastung der Scrum Team-Mitglieder können Sie dasselbe Modell verwenden, das Sie verwenden, wenn ein Mitglied bezahlte Freizeit (Urlaub) in Anspruch nimmt.

Ich würde empfehlen, dass der PO die Kommunikation zwischen den externen und internen Teams übernimmt, da der POC hauptsächlich für den PO durchgeführt wird; die Ergebnisse davon definieren, was getan werden muss. Während der PO die Kommunikation übernimmt, kann er die Planung vornehmen, um schneller zu handeln.

Erstens würde ich argumentieren, dass es so etwas wie einen POC in einer agilen Organisation nicht gibt. Sie erstellen lediglich eine Iteration des Produkts mit der Lösung des Anbieters. Wenn Ihnen die Ergebnisse dann nicht gefallen, zieht die nächste Iteration diese Lösung heraus.

Die Kontaktaufnahme ist einfach. Der PO und das Team erstellen gemeinsam nur die User Stories für ihren Teil des Prozesses – Erstellen von Spezifikationen für den Anbieter, Bewerten der Ergebnisse, nachdem die Lösung verfügbar ist – und legen Hindernisse („Blocker“) an diejenigen, die sie nicht können tun, bis der Verkäufer etwas liefert. Jedes Teammitglied kann die Rolle der Beantwortung von Anbieterfragen übernehmen; Die Logik legt nahe, dass es sich um die Person mit dem relevantesten technischen Wissen handelt. Konzentrieren Sie sich dann auf andere Dinge, bis der Anbieter etwas liefert, und beseitigen Sie die Blocker in den Post-Delivery-Storys.

Das Manifest gibt einige Antworten in den Zeilen „Individuen und Interaktionen…“ und „Kundenzusammenarbeit…“. Es braucht keinen "Plan", und es spielt keine Rolle, welche Berufsbezeichnung was bewirkt. Sie müssen den Datenzuordnungsprozess Ihrerseits nur in ausreichend kleine Storys aufteilen, damit Sie einen Teil innerhalb eines Sprints liefern können, und wenn Sie gezwungen sind, Punkte zu sammeln, nur für diese eine Story schätzen. (Allerdings fehlt Ihrem Unternehmen der Point of Points, wenn es den Zeitaufwand in die Betrachtung einbezieht. Aber dann habe ich vor Jahren aufgehört, Punkte zu verwenden!)

Schließlich ist es nicht die Aufgabe des PO, die Lösung zu bewerten. Teams verwalten sich selbst, was bedeutet, dass es der Ruf des Teams ist. Die PO ist nur eine gleichberechtigte Stimme in dieser Diskussion.

Ein Proof of Concept (PoC) ist eine Demonstration der grundsätzlichen Machbarkeit eines IT-basierten Projekts für einen oder mehrere repräsentative Anwendungsfälle. Ein gut geplanter und gut ausgeführter PoC stellt sicher, dass die technische Funktionalität einer neuen IT-Lösung wie erwartet funktioniert. Die Blutlinie eines Produkts und Kern der Produktführerschaft ist der Product Owner. Der PO hat die Macht über die Art der zu erstellenden Features und Funktionen sowie über die Reihenfolge, in der sie erstellt werden sollten. Der PO ist auch dafür verantwortlich, dem Team eine klare Vision zu geben.

Der PO ist allein verantwortlich für den Gesamterfolg der Lösung, die als Product Owner erstellt oder gewartet wird. Ob es sich um ein externes Produkt oder eine interne Anwendung handelt, der Fokus ist derselbe. Dennoch ist der Product Owner dafür verantwortlich, dass stets die größtmögliche, auch technisch fokussierte Arbeit erledigt wird. Der Product Owner arbeitet mit dem Scrum Master und dem Entwicklungsteam zusammen, um sicherzustellen, dass das, was das Team entwickelt, den Anforderungen entspricht.

Im Scrum-Framework wird nicht erwähnt, dass der Product Owner mit dem Anbieter zusammenarbeitet, aber das bedeutet nicht, dass er dies nicht tun sollte, wenn der Product Owner über die erforderlichen Fähigkeiten verfügt.

Zu den Verantwortlichkeiten eines Product Owners gehören unter anderem: Teilnahme an der Planung, Verwaltung der Wirtschaftlichkeit, Pflege des Backlogs, Zusammenarbeit mit dem Entwicklungsteam, Zusammenarbeit mit den Stakeholdern, Übermittlung der Vision an das Team und Führung des Teams, Priorisierung der Arbeit basierend auf dem Geschäft Wert verhandelt der Product Owner mit dem Team.etc. (Grund für meinen Kommentar oben)

Andererseits ergänzen sich der Software Engineer und der Projektmanager in ihren Fähigkeiten und arbeiten gemeinsam an gemeinsamen Aufgaben. Die organisatorische Zusammenarbeit, das Personalmanagement sowie die Projektüberwachung und -steuerung sind die drei Hauptaufgaben des Projektmanagers.

Die Rolle des Projektmanagers als Vermittler zwischen dem technischen Team und nichttechnischen Agenten wird im Abschnitt „Verbindung“ des Projektmanagements (wie Projektsponsoren, Benutzer, IS-Management, Lieferanten usw.) erörtert.

Einige Personen mögen argumentieren, dass der Produkteigentümer nichts mit dem Anbieter zu tun hat, sondern ein Projektmanager der beste Grund ist, weil: Der Projektmanager (und SE) erstellt ein Dokument zur Angebotsabgabe (RFP), um Angebote von möglichen Anbietern zu erhalten . Sobald ein Anbieter ausgewählt wurde, muss ein Vertrag ausgehandelt werden. Verhandlungen können mit dem Vermarkter, aber auch mit einem Finanzvertreter oder dem Manager des Vermarkters geführt werden. Ebenso kann der Projektleiter die Verhandlungen ganz oder teilweise mit Hilfe eines Finanzexperten oder seines Vorgesetzten führen.