Interaktionen mit Stakeholdern

Als Pega BA arbeiten Sie mit einem oder mehreren der folgenden Projekt-Stakeholder zusammen, um eine ständige Abstimmung zwischen den Business- und IT-Projektteams sicherzustellen:

• Product Owner (PO): Der Product Owner ist ein Vertreter des Kunden im Business-Team des Projekts. Der PO ist in erster Linie für das Management des Projektumfangs und die Priorisierung der Anforderungen während des gesamten Software-Entwicklungsprozesses zuständig. Pega BAs arbeiten eng mit dem PO zusammen, um sicherzustellen, dass ihre Pega-Plattform-Anwendung die strategischen Ergebnisse des Projekts im erwarteten Zeitrahmen liefert.

• Project Delivery Lead (PDL): Der PDL leitet die Projektbereitstellung und wird manchmal auch als Projektmanager bezeichnet. Er ist in erster Linie für die Leitung des Pega-Bereitstellungsteams, die Aufrechterhaltung der Projekt-Governance und die Zusammenarbeit mit dem leitenden Management des Kunden zuständig. Pega BAs arbeiten eng mit dem Project Delivery Lead (PDL) zusammen, um sicherzustellen, dass das Projekt im Zeit-, Budget- und Projektumfang bleibt. So werden die Erwartungen der Stakeholder aus dem Business- und IT-Team hinsichtlich der zeitlichen Planung und der Kosten der Projektergebnisse abgestimmt.

• Scrum Master:  Der Scrum Master ist für die Förderung und Unterstützung von Scrum zuständig, einem Agile-basierten Framework für die Softwarebereitstellung. Außerdem ist der Scrum Master für die Organisation des Scrum-Teams, die Durchführung von Scrum-Zeremonien wie die Sprint-Planung, die Dimensionierung, die Backlog-Optimierung, rückblickende Besprechungen (so genannte „Retrospective Meetings“) und für den Erfolg des Scrum-Teams verantwortlich. 

• System Architects (SAs): Systemarchitekten sind die Pega-Entwickler im Projektteam, die die Pega-Anwendungen konfigurieren. Die Systemarchitektenfamilie umfasst System Architects (SAs), Senior System Architects (SSAs) und Lead System Architects (LSAs). Systemarchitekten arbeiten mit Pega-BAs und Stakeholdern aus dem Unternehmen zusammen, um die Anwendung mit Pega GenAI Blueprint™ zu entwickeln. LSAs sind für den Import der Blueprint-Datei in die Pega-Plattform verantwortlich und verwenden die von Blueprint und Pega BAs erstellten User Stories, um sowohl die funktionalen als auch die technischen Anforderungen der Anwendung zu konfigurieren. Pega-BAs übersetzen technische Informationen, die die Systemarchitekten für Beteiligte des Unternehmens bereitstellen, und sorgen so dafür, dass die Stakeholder die Anwendung bereits in der Entwicklungsphase verstehen und dass die Anwendung und ihre Anforderungen erfüllt.

• Quality Analysts (QAs): Qualitätsanalysten stellen sicher, dass die Anwendungsfunktionalität die dokumentierten Geschäftsanforderungen erfüllt. Anhand der von Pega BAs erarbeiteten User Stories erstellen QAs Testskripte und Szenariotests, die bestätigen, dass die Anwendung wie erwartet funktioniert. QAs nehmen auch an Scrum-Ritualen wie Refinement- und Sizing-Sessions zur Optimierung und Dimensionierung teil. Das gewährleistet, dass der mit Anwendungstests verbundene Zeit- und Arbeitsaufwand angemessen dimensioniert wird.

• Subject Matter Experts (SMEs): Diese Fachexperten sind Vertreter der Kundenorganisation im Projektteam. Sie besitzen fundierte Kenntnisse der Steps, die ein Geschäftsprozess umfasst. SMEs geben die spezifischen betrieblichen und funktionalen Anforderungen vor, die mit diesen Schritten verbunden sind. In der Regel arbeiten Pega BAs mit den SMEs bei operativen Walkthroughs zusammen, um die Endbenutzer dabei zu beobachten, wie sie sich im bisherigen Prozess und in den vorhandenen Anwendungen zurechtfinden. Durch die Zusammenarbeit mit den SMEs lernt der Pega BA alle Aufgaben von Endbenutzern kennen (sowohl innerhalb als auch außerhalb des Systems), die zur Erfüllung der Kundenanforderungen und des gewünschten strategischen Ergebnisses notwendig sind. 

• Business Analysts: Business Analysts sind Vertreter der Kundenorganisation im Projektteam. Ein Business Analyst ist in erster Linie für die Dokumentation des bestehenden Prozesses sowie der Daten- und Geschäftsanforderungen zuständig. Pega BAs arbeiten mit Business Analysts zusammen, um diese Dokumentation zusammenzustellen und auf Verbesserungsmöglichkeiten zu überprüfen. Dazu gehören u. a. die Beseitigung von Redundanzen und Engpässen, die Empfehlung von Workflow-Automatisierungen, die Bestimmung des Ressourcenbedarfs und die Definition technischer Details wie Daten- und Schnittstellenanforderungen.

• UX-Designer: UX-Designer stellen sicher, dass das Design der Anwendung die Anforderungen der Endbenutzer erfüllt, den Standards für Barrierefreiheit entspricht und eine einheitliche User Experience in allen Channels bietet, über die die Anwendung bereitgestellt wird. Pega BAs arbeiten mit dem UX-Designer zusammen, um die Benutzeroberfläche so zu gestalten, dass sie auf die User-Experience-Anforderungen abgestimmt ist, strategische Geschäftsziele erfüllt und möglichst oft die Pega-Standard-Features verwendet.

• Solutions Consultant: Der Solutions Consultant arbeitet mit dem Kunden in den Anfangsphasen des Verkaufsprozesses zusammen. In vielen Cases entwirft der Solutions Consultant den Blueprint in Zusammenarbeit mit Beteiligten aus dem Unternehmen. Wenn der Kunde im Verkaufsprozess weiter voranschreitet, wird der Solutions Consultant den Entwurf vor Projektbeginn an die für die Bereitstellung des Projekts zuständigen Pega Business Architects and System Architects übergeben.

Die Größe und Struktur eines Projektteams variiert von Projekt zu Projekt. Bei kleineren Projekten übernehmen einige Teammitglieder möglicherweise mehrere Rollen, z. B. muss der Business Architect auch als Product Owner des Projekts fungieren.

Unabhängig von der jeweiligen Zusammensetzung der Stakeholder in Ihrem Projekt ist es für Sie als Pega BA wichtig, für die Abstimmung zwischen diesen Zuständigkeitsbereichen im gesamten Projektteam zu sorgen. Nur so stellen Sie sicher, dass der transformierte Business-Prozess die strategischen Ziele möglichst effizient und kostengünstig umsetzt. 

Klicken Sie in der folgenden Abbildung auf die Pluszeichen (+), um mehr darüber zu erfahren, wie Sie zur Abstimmung mit den Projekt-Stakeholdern interagieren:  

Zur Unterstützung einer effizienten und skalierbaren Anwendungsentwicklung bietet die Pega-Plattform leistungsstarke Tools für eine koordinierte Zusammenarbeit und das Konfigurationsmanagement. Arbeitsbereiche und Zweigeunterstützen Teams dabei, ihre Arbeit zu organisieren, die Versionskontrolle zu pflegen und den Entwicklungslebenszyklus zu optimieren.  Arbeitsbereiche bieten maßgeschneiderte Umgebungen für verschiedene Projekt-Rollen und -Aufgaben. Zweige sind dagegen für Entwickler praktisch, weil sie damit Änderungen umsetzen können, bevor sie in das gemeinsame Ruleset integriert werden. Zusammen sorgen diese Features dafür, dass die Entwicklung abgestimmt, sicher und an wechselnde Projektanforderungen anpassbar bleibt.

Arbeitsbereiche

Die Arbeitsbereiche der Pega-Plattform bieten eine sichere, fokussierte Umgebung für alle an der Anwendungsentwicklung Beteiligten, in der sie Anwendungs-Features unabhängig voneinander erstellen und verwalten können. Jeder Arbeitsbereich ist an einen bestimmten Bearbeiter mit Entwicklerzugang gebunden und immer nur einer Anwendung zugewiesen.

Innerhalb einer Anwendung verfügt jeder Bearbeiter standardmäßig über einen Arbeitsbereich. Ein Bearbeiter kann aber innerhalb dieser Anwendung mehrere Arbeitsbereiche erstellen. Änderungen bleiben innerhalb eines einzelnen Arbeitsbereichs privat, bis sie für eine Zweig freigegeben werden. So lassen sich Regelkonflikte vermeiden, wenn mehrere Entwickler an derselben App arbeiten.

Jeder Arbeitsbereich ist einer einzigen Anwendung und einem einzigen Bearbeiter zugeordnet. Entwickler können mehrere Arbeitsbereiche erstellen, in denen ausschließlich ihre eigenen Änderungen angezeigt werden, und auch zwischen diesen Arbeitsbereichen wechseln. Einige Regeltypen können Berechtigungen für den Zugriff auf Dev Studio erfordern.

Arbeitsbereiche sind in App Studio und Dev Studio verfügbar und können mit der Einstellung EnableWorkspace aktiviert werden. 

Das folgende Thema enthält wichtige Informationen zum Verständnis von Arbeitsbereichen, die Sie für die Zertifizierungsprüfung zum Business Architect benötigen: Anwendungen in Arbeitsbereichen entwickeln.

Zweige

Die Pega-Plattform nutzt Zweige, um Teams bei der Verwaltung paralleler Entwicklungen in verteilten Umgebungen zu unterstützen. Ein Zweig ist ein Container für Rulesets mit Datensätzen, die schnellen Veränderungen und Entwicklungen unterliegen. 

Zweige sind sowohl für große als auch für kleine Entwicklungsprojekte von Vorteil, bei denen ein oder mehrere Teams gleichzeitig an den Regeln in einer Anwendung arbeiten. Zweige sind zudem praktisch für die Entwicklung von Features, deren Fertigstellung unterschiedlich lange dauert. Eine gängige Strategie bei der Erstellung einer Pega-Plattform-Anwendung besteht darin, für jedes Feature, das Ihr Team entwickelt, einen eigenen Zweig anzulegen. Ein Zweig für jedes Feature ermöglicht es Ihrem Team, ein Feature unabhängig in einem isolierten Bereich (dem Zweig) zu entwickeln, ohne die Arbeit der anderen Teams zu beeinträchtigen. Beispielsweise erstellt Ihr Team einen Zweig, um Eigenschaften in einem Formular zu ändern, und einen weiteren Zweig zur Überarbeitung eines UI-Bereichs. Änderungen wirken sich erst dann auf andere Teams aus, wenn die Änderungen stabil sind, Konflikte gelöst wurden und die Genehmigung vorliegt, die Änderungen allen Entwicklungsteams bereitzustellen.

Als Pega Business Architect sind Sie ein wichtiger Vermittler zwischen den Projekt-Stakeholdern und achten ständig darauf, dass alle einbezogen werden, an den gleichen Zielen arbeiten und effektiv kommunizieren.   

Damit die Anleitung von Business- und IT-Teams bei der Zusammenarbeit, der Entwicklung innovativer Lösungen und dem Erreichen von Geschäftsergebnissen ein Erfolg wird, kombinieren Sie Ihre Erfahrung mit folgenden Skills:

• Analytische Fähigkeiten und Problemlösungskompetenz zur Aufschlüsselung komplexer Business-Prozesse und Identifizierung von Möglichkeiten zur Verbesserung und Vereinfachung

• Prozessdesign-Fähigkeiten und Kenntnisse zur Gestaltung von Business-Prozessen zur Entwicklung neuer Prozesse und Arbeitsweisen, um das Geschäftsergebnis zu erreichen 

• Kenntnisse im Systemdesign, der Pega-Technologie und Blueprint zur Erfüllung der Business- und Endbenutzer-Anforderungen mit den Pega-Standard-Features 

• Aktives Zuhören, Kommunikation und Moderationsfähigkeiten zur Schaffung einer gemeinsamen Verständigungsebene sowie eines gemeinsamen Verständnisses der geschäftlichen Anforderungen und Pega-Funktionen für das Projektteam und andere Stakeholder 

• Wissen über geschäftliche Veränderungen zur Unterstützung Ihres Business-Teams dabei, die neue Pega-Lösung zu begrüßen, anzunehmen und als Fürsprecher im Unternehmen dafür zu werben