Melhores práticas essenciais do Pega Express para o Business Architect
Das vinte melhores práticas do Pega Express™, oito são identificadas como partes essenciais de seu trabalho como um Business Architect (BA) da Pega. Essas oito melhores práticas, que são uma combinação de práticas específicas da Pega e padrão do setor, são:
- Pega GenAI Blueprint™
- Resultados de negócios
- Valor do negócio
- Microjourney®
- Minimum Lovable Product
- Directly Capture Objectives (DCO)
- Estratégia de reutilização
- Scrum
Neste tópico, você examinará cada uma dessas oito melhores práticas do Pega Express em mais detalhes.
Pega GenAI Blueprint
O Blueprint é uma experiência interativa que ajuda os stakeholders técnicos e de negócios a colaborar e projetar aplicativos para alcançar seus resultados de negócios. Usando o Blueprint, você define os requisitos da jornada do cliente e, com o poder da IA generativa e dos fluxos de trabalho de melhores práticas, o Blueprint sugere designs de aplicativos que visualizam o design do caso, as etapas (steps) e os estágios (stages), o modelo de dados, os dados em tempo real e as personas.
Para o Business Architect da Pega, o Blueprint agrega valor às atividades de design e desenvolvimento de aplicativos:
- Possibilita a colaboração com os stakeholders do projeto no design do aplicativo, economizando horas em workshops e sessões de design.
- Ajuda a garantir, por meio de sua colaboração, que você está criando o aplicativo certo para atender aos resultados de negócios.
- Fornece uma excelente captura visual do escopo de seus planos, para ajudar nas decisões de governança e na reunião de início do projeto.
- Acelera a configuração de seu aplicativo com pouco código no App Studio importando o arquivo JSON do Blueprint.
- Fornece uma experiência fora da Pega para ajudar a apoiar suas sessões de coleta de requisitos e planejamento de backlog.
- Desenvolve seu plano de prontidão para os negócios, permitindo que os testadores e o suporte à ativação compreendam o design do aplicativo antes do lançamento.
- Preenche rapidamente as ferramentas de estimativa do App Studio com os materiais gerados pelo Blueprint.
O Blueprint agrega valor em todo o processo de design e desenvolvimento de aplicativos, tornando-o uma das principais melhores práticas do Pega Express, na qual todos os Business Architects da Pega devem ser altamente eficientes.
Resultados de negócios
Os resultados de negócios são objetivos de negócios importantes e de alto valor que um aplicativo criado com a Pega Platform™ foi projetado para alcançar. Os resultados de negócios podem incluir, por exemplo:
- um novo objetivo de vendas
- um objetivo de retenção de clientes
- um objetivo de eficiência
Identificar e definir os principais resultados estratégicos de negócios para o aplicativo Pega fornece a direção para o seu programa de transformação de processos de negócios e garante que todos os incrementos contribuam para atender às necessidades da organização do cliente e dos clientes finais.
Valor do negócio
A melhor prática de valor de negócio consiste em garantir que a organização atinja seus resultados estratégicos por meio da cuidadosa preparação de uma justificativa de negócio e de apoio ao caso de negócio.
Para você, como Business Architect da Pega, entender o caso de negócios serve muitos propósitos, incluindo:
- Priorizar o escopo para garantir que a solução proposta atinja o resultado de negócio.
- Estabelecer indicadores-chave de desempenho (KPIs) que a solução da Pega alcança.
- Calcular o ROI (retorno sobre o investimento) usando os modelos de linha de base e de meta.
Estabelecer o valor de negócio para um projeto oferece, como ponte entre o os setores de negócios e TI, pontos de referência para discussões sobre priorização com a equipe de negócios durante todo o projeto.
Aplicação prática dos resultados de negócios e do valor de negócio para o Business Architect da Pega
Como Business Architect da Pega, você trabalha com o Product Owner para entender os principais resultados estratégicos de negócios do projeto, o que fornece a direção para a transformação do processo de negócios. À medida que você avança no projeto, a compreensão do caso de negócios orienta suas discussões com os participantes da equipe de negócios sobre a priorização de recursos com base no valor de negócio que cada recurso oferece.
Verifique seu conhecimento com a seguinte interação:
Microjornadas
O conceito de microjornada é fundamental para a abordagem de entrega do Pega Express. É a nossa maneira de dividir a complexidade das jornadas maiores do cliente em jornadas menores que podem ser entregues mais rapidamente, aumentando a velocidade de obtenção de valor do redesenho do seu processo de negócios.
Para identificar as microjornadas, é necessário considerar a experiência de ponta a ponta dos usuários finais de um aplicativo. Esse exercício identifica partes incrementais de funcionalidade na jornada geral que suas equipes de projeto podem colocar rapidamente em produção, agregando valor imediato para a organização do cliente e do cliente dele.
Por exemplo, a imagem a seguir ilustra uma jornada de serviço automotivo - uma solicitação de assistência na estrada com uma empresa chamada GoGoRoad - que poderia ser dividida em uma microjornada:
Minimum Lovable Product
A abordagem de entrega do Pega Express defende que você agrupe as alterações de aplicativos em uma versão de software chamada de Minimum Lovable Product (MLP). Uma série de uma ou mais versões do MLP em um projeto forma o roadmap de transformação do redesenho do seu processo de negócios.
Cada MLP oferece uma solução que não é apenas viável, mas também desejada e adotada pelos usuários finais. Conforme ilustrado na imagem a seguir, um MLP é empacotado para fornecer rapidamente resultados de negócios de forma a encantar os clientes e facilitar suas vidas, o que acelera o tempo de obtenção do valor de negócio para a organização do cliente:
Aplicação prática de microjornadas e MLP para o Business Architect da Pega
Usando o conceito de microjornada e a estrutura do MLP, como Business Architect, você divide a complexidade do processo de desenvolvimento em entregas incrementais que aumentam a certeza de entrega do aplicativo e o valor associado. Isso torna o processo de entrega de aplicativos gerenciável e responsivo às mudanças. Os stakeholders das equipes de negócios e TI podem então considerar e aplicar os aprendizados e insights obtidos à medida que cada MLP do roadmap é implementado.
Verifique seu conhecimento com a seguinte interação:
Directly Capture Objectives
Directly Capture Objectives (DCO) é a disciplina da Pega de colaboração, iteração e validação contínuas ao longo do arco de um projeto da Pega. O DCO estimula o alinhamento entre os stakeholders e estimula o engajamento de alta qualidade entre as equipes de negócios e TI. Conforme ilustrado na imagem a seguir, o DCO é uma disciplina orientada pela colaboração, iteração e validação contínuas:
As conversas sobre o DCO se concentram em:
- Projeto e desenvolvimento de aplicativos
- Obtenção de resultados de negócios
- Design centrado no ser humano
- Iterações para alcançar os valores de negócios mais rapidamente
Usando as ferramentas de visualização fornecidas pela Pega, o DCO ajuda os stakeholders do negócio a entender o aplicativo a partir de uma perspectiva prática e experimental.
Como Business Architect, incorporar o DCO em seu projeto é fundamental para reduzir mal-entendidos e minimizar o risco de descobrir lacunas nos negócios ou na funcionalidade em um estágio muito avançado do processo de desenvolvimento de aplicativos.
Estratégia de reutilização
A reutilização é a melhor prática estratégica de projetar e configurar aplicativos tendo em mente o roadmap, a escala e as necessidades de longo prazo da empresa.
A reutilização permite a rápida implementação de aplicativos que podem ser ampliados com agilidade para atender a necessidades específicas de negócios e, ao mesmo tempo, incentivar a consistência na experiência dos usuários.
A abordagem da Pega para a reutilização, encapsulada na ideia do Situational Layer Cake, consiste nas seguintes camadas, da mais especializada para a menos especializada:
- Camada de aplicativos de inovação: Mantém regras associadas a aplicativos criados para unidades de negócios específicas ou regiões geográficas localizadas
- Camada de aplicativos de negócios: Mantém as regras associadas às diferentes unidades de negócios de uma organização
- Camada modular de aplicativos: Mantém todas as regras disponíveis para reutilização nos aplicativos de negócios e inovação
- Camada empresarial: Mantém regras comuns a todos os aplicativos da empresa
- Camada da Pega Platform Consiste em todos os pacotes de regras na Pega Platform
Na imagem a seguir, clique nos ícones + para saber mais sobre a abordagem Situational Layer Cake da Pega para reutilização:
Aplicação prática do DCO e estratégia de reutilização para o Business Architect da Pega
Como Business Architect, você utiliza o DCO para estruturar o engajamento de alta qualidade entre os stakeholders das equipes de negócios e TI. Durante as primeiras conversas sobre o design do aplicativo, você começa a definir as camadas da empresa, do módulo e do aplicativo para o projeto. Em seguida, você trabalha com a equipe de TI para arquitetar os ativos reutilizáveis para a organização. O planejamento da reutilização empresarial no início do processo de design gera retornos significativos sobre o investimento para a organização e aumenta a velocidade de obtenção de valor do seu projeto.
Verifique seu conhecimento com a seguinte interação:
Scrum
O Scrum é uma parte fundamental da abordagem de entrega do Pega Express. O Scrum garante que os stakeholders das equipes de negócios e TI trabalhem juntas, de forma colaborativa e transparente, para alcançar os resultados certos para o cliente, garantindo que não haja surpresas indesejadas no momento da implantação.
O Scrum é uma forma de desenvolvimento ágil que define papéis, responsabilidades, eventos, artefatos e processos específicos para o seu projeto. Inclui os principais papéis de liderança, como Product Owner, Scrum Master e Desenvolvedores. Os projetos são divididos em ciclos de desenvolvimento com prazos determinados, conhecidos como sprints. Um backlog do produto, organizado em itens do backlog, como histórias de usuários, serve como repositório central para as tarefas e prioridades do projeto.
Sprints e eventos scrum
Um sprint é um ciclo de trabalho com prazo determinado, com duração de até quatro semanas, no qual a equipe constrói uma entrega. Os sprints são consistentes em termos de duração durante todo o projeto e, quando um sprint termina, o próximo começa, fornecendo um novo incremento. Vários eventos scrum ocorrem em cada sprint. Cada evento scrum ajuda a equipe a inspecionar e adaptar-se ao que foi construído.
Os eventos Scrum incluem:
- Refinamento e estimativa de histórias: fornece tempo para revisar as histórias de usuários quanto ao tamanho e à integridade.
- Planejamento de sprint: permite que o Product Owner priorize as histórias dos usuários no sprint atual.
- Scrum diário: a equipe do projeto se reúne diariamente para planejar e discutir o progresso.
- Análise do sprint: dá a membros específicos da equipe do projeto a chance de revisar o que foi desenvolvido no sprint atual.
- Retrospectiva do sprint: oferece à equipe do projeto a oportunidade de compartilhar feedback sobre o que deve ser alterado no próximo sprint, com base no que deu certo no sprint atual ou no que pode ser melhorado.
Como Business Architect, você participa ativamente de todos os eventos scrum, incluindo, na medida do possível, os scrums diários.
Refinamento e estimativa de histórias
Sessões de refinamento e estimativa de histórias são realizadas com frequência. Durante as reuniões de refinamento e estimativa de histórias, a equipe:
- Confirma que a equipe de TI entende as histórias de usuários que estão prontas para estimativa e que as histórias de usuários atendem à Definição de Pronto (Definition of Ready, DoR), que é o critério que determina se uma história está completa.
- Confirma o esforço necessário para configurar e testar a história do usuário para atender aos critérios estabelecidos na Definição de Pronto (DoD), que é o critério para determinar se uma história está com o desenvolvimento concluído.
- Dimensione a história do usuário atribuindo um valor de Fibonacci (1, 2, 3, 5, 8, 13...) para permitir que o Product Owner priorize e estime o esforço.
Aplicação prática do Scrum para o Business Architect da Pega
Trabalhando na interseção entre as equipes de projeto de negócios e TI, você participa ativamente de muitos eventos Scrum ao longo do seu projeto. As informações comunicadas durante os eventos scrum permitem que você atue, em vários momentos, como um defensor tanto da equipe de negócios quanto da equipe de TI. Por exemplo, você participa ativamente dos eventos scrum de refinamento e estimativa de histórias para finalizar as histórias de usuários que criou como parte das sessões de DCO. Depois que as histórias de usuários forem finalizadas, adicione-as ao backlog do projeto, tornando-as disponíveis para desenvolvimento e teste pela equipe de TI nos próximos sprints.
Verifique seu conhecimento com a seguinte interação:
This Topic is available in the following Module:
Quer nos ajudar a melhorar esse conteúdo?