Interactions avec les parties prenantes

En tant que BA Pega, vous collaborez avec une ou plusieurs des parties prenantes suivantes pour garantir un alignement constant entre les équipes projet métier et IT :

• Product Owner (PO) : le Product Owner (PO) est l’un des représentants du client au sein de l’équipe métier du projet. Le PO est principalement chargé de gérer la portée du projet et de définir la priorité des exigences tout au long du processus de développement logiciel. Les BA Pega collaborent étroitement avec le PO pour s’assurer que leur application Pega Platform™ produit les résultats stratégiques du projet dans les délais prévus.

• Project Delivery Lead (PDL) : le Project Delivery Lead Pega, parfois appelé chef de projet (Project Manager), est principalement chargé de diriger l’équipe delivery Pega, d’assurer la gouvernance du projet et de faire le lien avec l’équipe de direction du client. Les BA Pega collaborent étroitement avec le PDL pour s’assurer que le projet respecte les délais, le budget et la portée, afin que les attentes des parties prenantes des équipes métier et IT soient alignées au niveau du calendrier et du coût des livrables du projet.

• Scrum Master :  le Scrum Master est responsable de la promotion et de la prise en charge de Scrum, un framework de delivery de logiciels basé sur l'approche Agile. Le Scrum Master est chargé d’organiser l’équipe Scrum, d’animer les cérémonies Scrum, y compris la planification des sprints, le dimensionnement, l’affinement du backlog et les réunions rétrospectives, et assume la responsabilité de la réussite de l’équipe Scrum. 

• System Architects (SA) : les System Architects sont les développeurs Pega de l’équipe projet, qui configurent les applications Pega. La famille des System Architects comprend les System Architects (SA), les Senior System Architects (SSA) et les Lead System Architects (LSA). Les System Architects collaborent avec les BA Pega et les parties prenantes métier pour développer l’application en utilisant Pega GenAI Blueprint™. Les LSA sont responsables de l'importation du fichier Blueprint dans l'environnement Pega Platform et utiliseront les user stories créés à la fois par Blueprint et les BA Pega pour configurer les exigences fonctionnelles et techniques de l'application. Les BA Pega traduisent les informations techniques fournies par les System Architects aux parties prenantes métier afin de s’assurer qu’elles comprennent l’application en cours de développement et que celle-ci répond à leurs exigences.

• Quality Analysts (QA) : les Quality Analysts s’assurent que les fonctionnalités de l’application répondent aux exigences métier documentées. En utilisant les user stories écrites par les BA Pega comme base de référence pour leur travail, les QA créent des scripts de test et des tests de scénarios qui confirment que l’application fonctionne comme prévu. Les QA participent également à des rituels Scrum tels que des sessions d’affinement (Refinement) et de dimensionnement (Sizing) pour s’assurer que le temps et les efforts associés aux tests de l’application sont dimensionnés de manière appropriée.

• Subject Matter Experts (SME) : les Subject Matter Experts sont des représentants de l'organisation cliente au sein de l’équipe projet qui connaissent parfaitement les étapes requises dans le processus métier. Les SME fournissent les exigences opérationnelles et fonctionnelles spécifiques associées à ces étapes. Les BA Pega collaborent avec les SME, généralement dans le cadre d’une revue opérationnelle (operational walkthrough), pour observer les utilisateurs finaux naviguer dans le processus et les applications existants (« as-is »). Les BA Pega travaillent avec les SME pour comprendre tout ce que les utilisateurs finaux doivent faire (à l’intérieur et à l’extérieur du système) pour répondre aux besoins du client et au résultat stratégique souhaité. 

• Business Analysts : les Business Analysts sont les représentants de l'organisation cliente au sein de l’équipe projet. Le Business Analyst est principalement chargé de documenter le processus actuel « as-is », les exigences relatives aux données et les exigences métier. Les BA Pega collaborent avec les Business Analysts pour rassembler et examiner cette documentation afin d’identifier les axes d’amélioration, notamment en éliminant les redondances et les goulots d’étranglement, en recommandant des automatisations des workflows, en déterminant les besoins en ressources et en définissant des détails techniques tels que les exigences relatives aux données et à l’interface.

• UX Designers : l’UX Designer garantit que la conception de l’application répond aux besoins de l’utilisateur final, est conforme aux normes d’accessibilité et offre une expérience cohérente sur tous les canaux (Channel) de livraison de l’application. Les BA Pega collaborent avec l’UX Designer pour concevoir l’interface utilisateur de manière à ce qu’elle corresponde aux exigences en matière d’expérience utilisateur, optimiser l’utilisation des fonctionnalités prêtes à l’emploi de Pega et répondre aux objectifs métier stratégiques.

• Solutions Consultant : Le Solutions Consultant travaille avec le client durant les phases initiales du processus de vente. Dans de nombreux cas, il conçoit le Blueprint en collaboration avec les parties prenantes métier. Si le client avance dans le processus de vente, le Solutions Consultant passera le Blueprint aux Business Architects et System Architects Pega responsables de la livraison du projet avant qu’il ne démarre.

La taille et la structure d’une équipe projet varient d’un projet à l’autre. Sur les petits projets, il est possible que certains membres de l’équipe assument plusieurs rôles. Par exemple, il peut arriver que le Business Architect soit également le Product Owner du projet.

Quelle que soit la composition exacte des parties prenantes de votre projet, il est important pour vous, en tant que BA Pega, de veiller à l’alignement de ces domaines de responsabilité au sein de votre équipe projet. C’est la seule façon de vous assurer que le processus métier transformé atteint ses objectifs stratégiques de la manière la plus efficace et la plus économique possible. 

Dans la figure suivante, cliquez sur les icônes + pour en savoir plus sur le mode d’interaction avec les parties prenantes du projet pour parvenir à un alignement :  

Pour favoriser un développement applicatif efficace et évolutif, Pega Platform™ propose des outils puissants qui facilitent la collaboration et la configuration. Les espaces de travail (Workspaces) et les branches (Branching) aident les équipes à organiser leur travail, à assurer le contrôle des versions et à rationaliser le cycle de vie du développement.  Ces espaces de travail fournissent des environnements adaptés à différents rôles et tâches au sein du projet, tandis que la création de branches permet aux développeurs d’isoler leurs changements avant de les fusionner dans le Ruleset partagé. Ensemble, ces fonctionnalités garantissent que les efforts de développement restent alignés, sécurisés et adaptables en cas d’évolution des besoins du projet.

Espaces de travail

Les espaces de travail (Workspaces) de Pega Platform offrent un espace sécurisé et dédié aux parties prenantes impliquées dans le développement d’applications, afin de développer et de gérer les fonctionnalités des applications de manière indépendante. Chaque espace de travail est lié à un opérateur spécifique disposant d’un accès développeur et est exclusivement associé à une application.

Dans une application, chaque opérateur dispose d’un espace de travail créé par défaut, mais il peut en créer d’autres au sein de cette application. Les modifications restent privées au sein d’un même espace de travail, jusqu’à ce qu’elles soient partagées avec une branche (Branch), ce qui permet d’éviter les conflits de règles lorsque plusieurs développeurs travaillent sur la même application.

Chaque espace de travail appartient à une application et à un seul opérateur. Les développeurs peuvent créer plusieurs espaces de travail et passer de l’un à l’autre, chacun affichant uniquement les modifications qu’ils ont apportées. Certains types de règles (Rules) peuvent nécessiter un accès à Dev Studio en fonction des autorisations.

Les espaces de travail sont disponibles dans App Studio et Dev Studio, et peuvent être activés avec le paramètre EnableWorkspace. 

La rubrique suivante contient des informations importantes pour comprendre les espaces de travail et réussir l’examen de certification Business Architect : Développer des applications dans les espaces de travail.

Branches

Pega Platform™ utilise des Branches pour aider les équipes à gérer le développement parallèle dans des environnements distribués. Une Branche est un conteneur pour des Rulesets ayant des enregistrements qui subissent des changements et des développements rapides. 

Les Branches sont utiles pour les projets de développement à grande et à petite échelle, où une ou plusieurs équipes travaillent simultanément sur les règles (Rules) d’une application. Les Branches sont également utiles pour le développement de fonctionnalités lorsque le temps nécessaire à leur réalisation varie d’une fonctionnalité à l’autre. Une stratégie courante lors de la création d’une application Pega Platform consiste à créer une Branche pour chaque fonctionnalité développée par votre équipe. Votre équipe peut ainsi développer indépendamment une fonctionnalité dans un espace isolé (la branche) sans affecter les autres équipes. Par exemple, votre équipe crée une Branche pour modifier les propriétés d’un formulaire et une autre pour modifier une section de l’interface utilisateur. Les modifications n’affectent pas les autres équipes. Pour que les autres équipes de développement y accèdent, les modifications doivent être d’abord stabilisées, les conflits résolus et les validations accordées.

En tant que Business Architect Pega, vous êtes un lien essentiel entre les parties prenantes du projet, en veillant constamment à ce qu’elles soient impliquées, alignées et qu’elles communiquent efficacement.   

Pour aider les équipes métier et IT à collaborer, créer des solutions innovantes et atteindre les résultats métier, vous combinez votre expérience avec les compétences suivantes :

• Compétences analytiques et de résolution de problèmes pour décomposer les processus métier complexes et identifier les opportunités d’amélioration et de simplification.

• Compétences en conception de processus et connaissance de la conception de processus métier pour imaginer de nouveaux processus et de nouvelles méthodes de travail afin d’atteindre le résultat métier. 

• Connaissance de la conception de systèmes, de la technologie Pega et de Blueprint pour aligner les exigences métier et les besoins des utilisateurs finaux sur les fonctionnalités prêtes à l’emploi de Pega. 

• Compétences d’écoute active, de communication et d’animation pour créer un langage commun et une compréhension des besoins métier et des fonctionnalités de Pega entre l’équipe projet et les autres parties prenantes. 

• Connaissance des changements métier pour aider votre équipe métier à adopter la nouvelle solution Pega et à la promouvoir au sein de son entreprise.