Interações com stakeholders

Como BA da Pega, você colabora com um ou mais dos seguintes stakeholders do projeto para garantir que haja um alinhamento constante entre as equipes de projeto de negócios e de TI:

• Product Owner (PO): O Product Owner (PO) é um dos representantes do cliente na equipe de negócios do projeto. O PO é o principal responsável por gerenciar o escopo do projeto e priorizar os requisitos durante todo o processo de desenvolvimento de software. Os BAs da Pega colaboram estreitamente com o PO para garantir que seu aplicativo Pega Platform™ forneça os resultados estratégicos do projeto no cronograma esperado.

• Project Delivery Lead (PDL: O Project Delivery Lead (PDL) da Pega, às vezes conhecido como Project Manager (gerente de projetos), é o principal responsável por liderar a equipe de entrega da Pega, manter a governança do projeto e fazer a ligação com a equipe de liderança do cliente. Os BAs da Pega colaboram estreitamente com o PDL para garantir que o projeto permaneça dentro do prazo, do orçamento e do escopo, de modo que os stakeholders das equipes de negócio e de TI estejam alinhadas em suas expectativas quanto ao prazo e ao custo dos resultados do projeto.

• Scrum Master:  O Scrum Master é responsável por promover e apoiar o Scrum, uma estrutura de entrega de software baseada em Agile. O Scrum Master é responsável por organizar a equipe Scrum, facilitar as cerimônias Scrum, incluindo reuniões de Planejamento de Sprint, Dimensionamento, Refinamento de Backlog e Retrospectiva, e é responsável pelo sucesso da equipe Scrum. 

• System Architects (SAs): Os System Architects (SA) são os desenvolvedores da Pega na equipe do projeto que configuram os aplicativos da Pega. A família de System Architects inclui System Architects (SAs), Senior System Architects (SSAs) e Lead System Architects (LSAs). Os system architects colaboram com os BAs da Pega e os stakeholders de negócios para desenvolver o aplicativo usando o Pega GenAI Blueprint™. Os LSAs são responsáveis por importar o arquivo do Blueprint para o ambiente da Pega Platform e usarão as histórias de usuários criadas pelos BAs do Blueprint e da Pega para configurar os requisitos funcionais e técnicos do aplicativo. Os BAs da Pega traduzem as informações técnicas fornecidas pelos system architects para os stakeholders do negócio para garantir que eles entendam o aplicativo em desenvolvimento e que este atenda aos requisitos deles.

• Quality Analysts (QAs): Os Quality analysts (QAs) garantem que a funcionalidade do aplicativo atenda aos requisitos de negócios documentados. Usando histórias de usuários escritas pelos BAs da Pega como linha de base para seu trabalho, os QAs criam scripts de teste e testes de cenário que confirmam que o aplicativo funciona conforme o esperado. Os QAs também participam de rituais do Scrum, como sessões de refinamento e dimensionamento, para garantir que o tempo e o esforço associados aos testes de aplicativos sejam dimensionados adequadamente.

• Subject Matter Experts (SMEs): Os especialistas no assunto (Subject Matter Experts, SMEs) são representantes da organização do cliente na equipe do projeto que têm profundo conhecimento em primeira mão das etapas necessárias no processo de negócios. Os SMEs fornecem os requisitos operacionais e funcionais específicos associados a essas etapas. Os BAs da Pega colaboram com os SMEs, normalmente em um passo a passo operacional, para observar os usuários finais navegarem pelo processo e pelos aplicativos "como estão". Os BAs da Pega trabalham com os SMEs para entender todo o trabalho (dentro e fora do sistema) que os usuários finais precisam realizar para atender às necessidades do cliente e alcançar o resultado estratégico desejado. 

• Business Analysts: Os Business Analysts (BAs) são representantes da organização do cliente na equipe do projeto. O Business Analyst é responsável principalmente por documentar o processo atual, os requisitos de dados e os requisitos de negócios "como estão". Os BAs da Pega colaboram com os analistas de negócios para reunir e revisar essa documentação e identificar oportunidades de melhoria, incluindo a eliminação de redundâncias e gargalos, recomendando automações de fluxo de trabalho, determinando as necessidades de recursos e definindo detalhes técnicos como dados e requisitos de interface.

• Designers de UX: O Designer de UX (UX Designer) garante que o design do aplicativo atenda às necessidades do usuário final, esteja em conformidade com os padrões de acessibilidade e ofereça uma experiência consistente em todos os canais de fornecimento de aplicativos. Os BAs da Pega colaboram com o Designer de UX para projetar a interface do usuário, alinhando-se aos requisitos de experiência do usuário, maximizando o uso dos recursos prontos para uso da Pega e atendendo aos objetivos estratégicos de negócios.

• Consultor de soluções: O consultor de soluções (Solutions Consultant) trabalha com o cliente durante as fases iniciais do processo de vendas. Em muitos casos, o consultor de soluções projeta o Blueprint em colaboração com os stakeholders do negócio. Se o cliente avançar no processo de vendas, o consultor de soluções fará a transição do Blueprint para os Business Architects e System Architects da Pega responsáveis pela entrega do projeto antes do início do projeto.

O tamanho e a estrutura de uma equipe de projeto variam de projeto para projeto, e é possível que, em projetos menores, alguns membros da equipe desempenhem mais de um papel. Por exemplo, o Business Architect pode ter de atuar como Product Owner do projeto.

Independentemente da combinação exata de stakeholders do seu projeto, é importante que você, como BA da Pega, garanta o alinhamento entre essas áreas de responsabilidade em toda a sua equipe de projeto. Essa é a única maneira de garantir que o processo de negócios transformado atenda aos seus objetivos estratégicos da maneira mais eficiente e econômica possível. 

Na figura a seguir, clique nos ícones+para saber mais sobre como você interage com os participantes do projeto para obter o alinhamento:  

Para apoiar o desenvolvimento de aplicativos de forma eficiente e escalável, a Pega Platform™ oferece ferramentas poderosas para gerenciar colaboração e configuração. Áreas de Trabalho (Workspaces) e Ramificações (Branches) ajudam as equipes a organizar o trabalho, manter o controle das versões e agilizar o ciclo de desenvolvimento.  As áreas de trabalho oferecem ambientes personalizados para diferentes papéis e tarefas dentro do projeto, enquanto as ramificações permitem que os desenvolvedores isolem mudanças antes de mesclá-las no ruleset compartilhado. Juntas, essas funcionalidades garantem que os esforços de desenvolvimento permaneçam alinhados, seguros e adaptáveis às necessidades em evolução do projeto.

Áreas de trabalho

As áreas de trabalho na Pega Platform oferecem um espaço seguro e focado para as partes interessadas envolvidas no desenvolvimento de aplicativos construírem e gerenciarem recursos do aplicativo de forma independente. Cada área de trabalho está vinculada a um operador específico com acesso de desenvolvedor e está exclusivamente associada a um aplicativo.

Dentro de um aplicativo, cada operador tem uma área de trabalho criada por padrão, mas um operador pode criar várias áreas de trabalho dentro desse aplicativo. As mudanças permanecem privadas dentro de uma única área de trabalho até serem compartilhadas com uma ramificação, ajudando a evitar conflitos de regras quando vários desenvolvedores trabalham no mesmo aplicativo.

Cada área de trabalho pertence a um aplicativo e a um operador. Os desenvolvedores podem criar e alternar entre várias áreas de trabalho, que mostram apenas suas próprias mudanças. Alguns tipos de regras podem exigir acesso ao Dev Studio com base nas permissões.

As áreas de trabalho estão disponíveis no App Studio e no Dev Studio, e podem ser ativadas com a configuração EnableWorkspace. 

O seguinte tópico contém informações que são importantes para sua compreensão das áreas de trabalho e para passar no exame de certificação de Arquiteto de Negócios (BA): Desenvolvendo aplicativos em áreas de trabalho.

Ramificações

A Pega Platform™ usa ramificações para ajudar as equipes a gerenciar o desenvolvimento paralelo em ambientes distribuídos. Uma Ramificação é um contêiner para rulesets com registros que passam por mudanças e desenvolvimentos rápidos. 

As ramificações são benéficas tanto para projetos de desenvolvimento em grande escala quanto em pequena escala, onde uma ou várias equipes trabalham simultaneamente nas Regras em um aplicativo. As ramificações também beneficiam o desenvolvimento de recursos quando o tempo para conclusão difere entre os recursos. Uma estratégia comum ao criar um aplicativo na Pega Platform é criar uma ramificação para cada recurso que sua equipe está desenvolvendo. Uma ramificação para cada recurso permite que sua equipe desenvolva um recurso de forma independente em um espaço isolado (a ramificação) sem afetar outras equipes. Por exemplo, sua equipe cria uma ramificação para alterar propriedades em um formulário e outra para alterar uma seção de UI. As mudanças não afetam outras equipes até que as mudanças estejam estáveis, os conflitos sejam resolvidos e a aprovação seja concedida para tornar as mudanças disponíveis para todas as equipes de desenvolvimento.

Como Business Architect da Pega, você é um elo crucial entre os participantes do projeto, trabalhando constantemente para garantir que eles estejam engajados, alinhados e se comunicando de forma eficaz.   

Para enfrentar o desafio de orientar as equipes de negócios e de TI a colaborar, criar soluções inovadoras e alcançar resultados de negócios, você combina sua experiência com o seguinte:

• Habilidades analíticas e de resolução de problemas para decompor processos de negócios complexos e identificar oportunidades de melhoria e simplificação.

• Habilidades de design de processos e conhecimento de design de processos de negócios para inovar novos processos e formas de trabalho a fim de alcançar o resultado de negócio. 

• Conhecimento de design de sistemas, tecnologia Pega e Blueprint para alinhar os requisitos de negócios e as necessidades do usuário final com os recursos prontos para uso da Pega. 

• Habilidades de escuta ativa, comunicação e facilitação para criar uma linguagem e um entendimento comuns da necessidade de negócios e dos recursos da Pega entre a equipe do projeto e outros stakeholders. 

• Conhecimento de mudanças de negócios para ajudar sua equipe de negócios a adotar a nova solução Pega e a se tornar defensora da nova solução em sua organização.