Stakeholder

Stakeholder sind alle von einem System betroffenen Personen und Personengruppen, sowie alle direkt am Produkt Interessierten oder Beteiligten. Stakeholder werden auf allen Ebenen in die Reviews eingeladen und können optional in Backlog-Refinement-Meetings eingeladen werden, um ihre Anforderungen zu erläutern.

Um Stakeholder zu identifizieren verwendet das P4-Framework zwei unterschiedliche Lebenszyklen als gedankliche Leitfäden. Dies sind

  • der Produktlebenszyplus (von der Idee bis zum Ende der Produktpflege) und
  • der Einzelstücklebenszyklus (vom Einkauf des Rohmaterials bis zum Recycling)

Für jedes Produkt oder System lassen sich an diesen die unterschiedlichen Stakeholder (=Intressengruppen) identifizieren.

Produktlebenszyklus

Einzelstücklebenszyklus

Im P4-Framework werden drei Gruppen von Stakeholder unterschieden, die den drei Bereichen zugeordnet werden

Weitere Stakeholder

Im Anforderungsmanagement werden neben den „direkten“ Stakeholdern auch meist weitere, „allgemeinere“ Stakeholder definiert. Dies sind z.B.

  • die Gesellschaft, bestehend aus den öffentlichen und staatlichen Organisationen
  • die Umwelt (meist betroffen durch Emissionen und Abfälle)
  • Mitbewerber und Konkurrenten

Diese Stakeholder werden im P4-Framework nicht durch Stakeholder-Needs repräsentiert, sondern durch spezielle Ziele (z.B. zur Beschreibung der Wettbewerbssituation) oder sie werden durch Normen und Standards im Bereich Qualitätsattribute und Einschränkungen (QA&C).

Stakeholder-Map

Eine Stakeholder-Map zeigt die verschiedenen Stakeholder mit ihren Bedürfnissen und der Stärke der Einflüsse auf das System.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Backlog-Refinement

Team-Review

.

Cluster-Backlog-Refinement

Cluster-Review

.

Portfolio-Refinement

Portfolio-Review

Team-Product-Owner

.

Cluster-Product-Owner

.

Portfolio-Owner

Team-Product-Owner-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisationsmodellierung

In der Organisationsmodellierung wird die konkrete Organisation durch die verschiedenen P4-Elemente modelliert, d.h. die Teams, Gruppen und Cluster werden durch Informations- und Arbeitsflüsse (Workflows) dargestellt.

Innerhalb des Organisationsmodells können nun die Prozesse dargestellt werden, wobei dies durch Definition und Dokumentation der entsprechenden Inputs, Verantwortlichkeiten, Aktionen und Outputs geschieht. Jede Organisationseinheit wird gemäß der SIPOC-Methode definiert in Supplier – Inputs – Process – Outputs – Customers.

Verantwortung von Technologie und Architektur durch die Systemingenieure

Das P4-Framework gliedert seine Organisations- und Managementstruktur der Produktentwicklung in drei Bereiche:

Technologie und Architektur

Die technischen Rollen der verschiedenen Ebenen tragen die Verantwortung für die eingesetzten und neue Technologien, sowie der Architektur der entwickelten Systeme, also der Zerlegung in Funktionen, Module, Komponenten und Schnittstellen. Dabei kommunizieren sie mit den Stakeholdern dieses Bereichs: Lieferanten, der Supply-Chain und der Produktion.

Die Rolle des Team-System-Engineer

Innerhalb des Working-Teams hat der Team-System-Engineer die Rolle, technische Entscheidungen zu moderieren und zu treiben und im Zweifelsfall Entscheidungen zu treffen. Er steht dabei nicht „über“ dem Working-Team, sondern ist sozusagen der „Erste unter Gleichen“ (Primus inter paris).

Der Team-System-Engineer eines Teams vertritt die technische Expertise und Verantwortung seines Teams in Gruppen und Gremien, sowie bei der Abstimmung zwischen den Teams. Als Verterer seines Working-Teams schätzt es z.B. die Cluster-Backlog-Einträge zusammen mit den Team-System-Engineers der anderen Teams im Cluster.

Die Rolle des Cluster-System-Engineer

Innerhalb der Team-System-Engineer-Gruppe hat der Cluster-System-Engineer die Rolle, technische Entscheidungen zu moderieren und zu treiben und im Zweifelsfall Entscheidungen zu treffen. Er steht dabei nicht „über“ der Team-System-Engineer-Gruppe, sondern ist sozusagen der „Erste unter Gleichen“ (Primus inter paris).

Der Cluster-System-Engineer eines Clusters vertritt die technische Expertise und Verantwortung seines Clusters, in Gruppen und Gremien, sowie bei der Abstimmung zwischen den Clustern. Als Verterer seiner Team-System-Engineer-Gruppe schätzt es z.B. die Portfolio-Backlog-Einträge zusammen mit den Cluster-System-Engineers der anderen Cluster.

Die Rolle des Portfolio-Architekt

Innerhalb der Cluster-System-Engineer-Gruppe hat der Portfolio-Architect die Rolle, technische Entscheidungen zu moderieren und zu treiben und im Zweifelsfall Entscheidungen zu treffen. Er steht dabei nicht „über“ der Cluster-System-Engineer-Gruppe, sondern ist sozusagen der „Erste unter Gleichen“ (Primus inter paris).

Der Portfolio-Architekt vertritt die technische Expertise und Verantwortung der Organisation im Organisations-Management-Kreis gegenüber der Portfolio-Owner und dem Organisations-Scrum-Master, um eine globale Balance zwischen den Themen zu erreichen.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

.

Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

.

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Working-Team

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

Team-Product-Owner

Der Team-Product-Owner priorisiert das Team-Backlog und nimmt die Ergebnisse des Working-Teams ab. Im Team-Backlog können mehrere Produktentwicklungen oder Teile davon enthalten sein. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)

Je nach Art und Verantwortungsbereich des Teams (Team-Flavor) sind die Ergebnisse bzw. „Produkte“ der Teams sehr unterschiedlich. Daher können die Team-Product-Owner in P4 verschiedene Bezeichnungen haben:

Service-Owner

Service-Owner sind die fachlichen Leiter von Teams, die eine Expertise oder Kompetenz verantworten. Oft sind Mitglieder solcher Service-Teams zu speziell oder zu wenige, dass sie ständig in interdisziplinären Teams mitarbeiten könnten. Ein anderer Grund für ein Service-Team ist, das es eine spezielle Infrastruktur betreibt, z.B. ein Labor. Diese Teams sind häufig eine Art interner Dienstleiter innerhalb der Organisation (Service-Provider) und werden meist von anderen Teams aufgesucht oder zu ihnen eingeladen.

Der Service-Owner ist dafür verantwortlich, die Dienstleistungsaufträge seines Teams zu priorisieren. Im einfachsten Fall wendet er und sein Team ein Kanban-Board mit einem First-come-first-serve-Prinzip an (FIFO). Der Service-Owner kann aber auch das Dienstleistungsangebot seines Teams in Klassen einteilen, z.B. mittels unterschiedlichen Service-Level-Agreements zu unterschiedlichen Kosten.

Um einen optimalen Fluss der Systementwicklung zu erreichen, übernimmt der Service-Owner im einfachsten Fall die Prioritäten aus dem Portfolio-Backlog bzw. dem Cluster-Backlog. Zusätzlich stimmt er sich regelmäßig mit den anderen Team-Product-Ownern innerhalb der Team-Product-Owner-Gruppe (TPOG) ab.

Module-Owner

Bei der Entwicklung komplexer Systeme wird es häufig Subsysteme oder Module geben, um die Komplexität beherrschbarer zu machen (Module kapseln Komplexität) oder um mittels eines Plattform- bzw. Baukastenkonzepts die Wiederverwendung von Modulen und Komponenten zu ermöglichen.

Ein Modul-Owner ist daher der fachliche Manager, der dafür sorgt, dass die passenden Module für die Applikations- und Systementwicklung zur Verfügung stehen. Andererseits ist er dafür verantwortlich, dass die Module wiederverwendbar sind. Dabei kommt es im besonderen Maße auf stabile Schnittstellen für ein Plattform- bzw. Baukastensystem an.

Feature-Owner und Application-Owner

Feature-Owner sind die Team-Product-Owner von interdisziplinären Teams, die ein oder mehrere Funktionen (Features) einer Systemvarianten (=Applikationen) entwickeln und verantworten, sowie diese für Anwender zur Verfügung stellen. Der Feature-Owner ist dabei mit den anderen Feature-Ownern und dem Application-Owner für die Verbesserung des Kundennutzens des Produkts seines Application-Teams verantwortlich. Der Application-Owner stellt die direkte Schnittstelle zu den Anwendern der Applikation dar, um über Anforderungen und Änderungen der Applikation zu entscheiden.

Application-Owner sind die Team-Product-Owner der interdisziplinären Teams, die komplette Systemvarianten (=Applikationen) entwickeln und verantworten, sowie diese für Anwender zur Verfügung stellen. Der Application-Owner ist dabei für die Verbesserung des Kundennutzens des Produkts seines Application-Teams verantwortlich. Der Application-Owner stellt die direkte Schnittstelle zu den Anwendern der Applikation dar, um über Anforderungen und Änderungen der Applikation zu entscheiden. Je nach Organisation gibt es noch einen getrennten Liefer- und Betriebsbereich (Operations. Siehe p4-ops.com). Für manche Organisationen macht es Sinn, die Bereiche Entwicklung und Betrieb zusammenzulegen (DevOps), um Synergien durch direkteres und schnelleres Feedback zu erzielen.

Das Application-Team mit dem Application-Owner stellt den Auftraggeber der Modul- und Dienstleistungs-Teams dar. Applikation-Teams integrieren die von den Modul-Teams zur Verfügung gestellten Module mit Hilfe der Dienste der Service-Teams.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

.

Portfolio-Owner

Working-Team

.

Team-Product-Owner-Gruppe

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog