Design de caso

A primeira etapa da atividade de design de caso na fase Preparação (Prepare) é analisar o tipo de caso Backlog e criar o tipo de caso para cada Microjourney^™ que foi priorizada para o Minimum Lovable Product (MLP). Isso é importante para garantir que seu plano de construção faça sentido.

O objetivo da atividade de design de caso é:

• Criar os tipos de caso básicos e as associações entre eles em preparação para a fase Construção (Build).
• Validar o escopo funcional da Microjornada com o proprietário do produto
• Garantir que o design de caso adote as melhores práticas desde o começo

Ao usar o Directly Capture Objectives (DCO), o arquiteto de negócios (business architect), o arquiteto de sistemas (system architect) e o proprietário do produto (product owner) atuam em colaboração para modelar o tipo de caso em estágios e etapas. Essa atividade divide o tipo de caso em componentes.

Após as etapas e estágios tiverem sido acordados com o proprietário do produto, outras discussões vão definir as personas envolvidas no tipo de caso, bem como os objetos de dados necessários para você concluir o processamento. Ao final das sessões de DCO, você tem uma representação visual do tipo de caso a ser validado pelo proprietário do produto.

Para garantir que as melhores práticas do design do caso sejam adotadas desde o começo, o system architect (SA) conduz os aspectos técnicos do design do tipo de caso em uma sessão de DCO.

O SA se certifica de que o design do caso considere:

• Fluxo de trabalho
• Personas e canais
• Dados
• Reutilização
• Escala

Na imagem seguinte, clique em + para saber mais sobre estágios e etapas do design do caso.

A combinação de estágios e etapas determina o fluxo de trabalho do caso. Na maioria das empresas, há várias combinações de trabalho:

• Alguns trabalhos podem ser executados em sequência.
• Alguns trabalhos podem ser conduzidos em paralelo.
• Alguns trabalhos podem ser opcionais, aplicáveis apenas em condições específicas.  

No começo do projeto, os diferentes tipos de trabalho influenciam o design do seu caso. Com base nas descobertas feitas em oficinas com o proprietário de produto, o lead system architect (LSA) considera a prática técnica recomendada. Quando adequado, ele pode decidir criar tipos de caso adicionais (por exemplo, habilitar um trabalho paralelo por meio de casos secundários).

Outra consideração de design de caso é a alocação de trabalho, que é discutida e acordada logo no começo do projeto. A alocação de trabalho define a forma como o trabalho é direcionado para as personas que estão vinculadas com o tipo de caso. Definir o modelo de alocação de trabalho exige a compreensão do modelo de operação do negócio.

Há dois modelos de alocação de trabalho:

• Modelo push: em um modelo “push”, o sistema ou um gerente de equipe atribui trabalho ao usuário apropriado.
• Modelo pull: em um modelo “pull”, o usuário é atribuído automaticamente a um trabalho com base em um conjunto de regras de negócio.

Usando a abordagem do Pega Express^™, as personas são associadas a estágios em um tipo de caso para representar a interação da persona durante o caso. As personas também são associadas a canais para indicar como a persona pode acessar o aplicativo (por exemplo, por e-mail ou usando uma página web de autoatendimento). 

Como a Pega Platform pode associar uma persona a um canal, você pode personalizar a interface de usuário (IU) e os processos de um canal específico para criar uma experiência de usuário que seja adequada a uma situação particular.

Como parte das sessões de DCO executadas durante a fase Preparação (Prepare), o proprietário do produto e o business architect (BA) mapeiam as personas aos estágios para garantir que os cenários da empresa estejam dentro do escopo do tipo de caso. Como parte dessas discussões, é importante entender que tipo de interação pode ser realizada pela persona em um canal específico. Por exemplo, talvez seja possível criar uma reivindicação em um canal de autoatendimento, mas não por e-mail. 

Segurança por persona e canal

Os direitos de acesso a dados e processos também são definidos para o tipo de caso. Os direitos de acesso podem impactar o design do tipo de caso de várias formas, por exemplo:

• Excluir trabalho/dados de canais específicos
• Trabalho separado em estágios diferentes dentro do tipo de caso
• Criar um tipo de caso totalmente novo  

Com base nos requisitos de segurança, o SA deve decidir sobre o design do tipo de caso para atender às necessidades de segurança.

No início do projeto, você precisa de um entendimento de alto nível sobre os objetos de dados vinculados ao tipo de caso para garantir que o design atenda às necessidades dos dados. 

Para cada objeto de dados, o arquiteto de sistemas deve compreender o seguinte:

• Disponibilidade e pontualidade
• Retenção e arquivamento 

A disponibilidade dos dados refere-se à origem dos dados. Alguns dados podem estar disponíveis em sistemas externos. Os usuários podem capturar diretamente outros dados, e alguns dados podem não estar disponíveis; eles devem ser criados durante a progressão do caso. A pontualidade dos dados se refere a quão rápido os dados podem ser obtidos de outros sistemas e com que frequência os dados mudam.

Com a conscientização cada vez maior sobre os requisitos de privacidade de dados, as regras de retenção de dados do cliente influenciam diretamente a atividade de modelagem de dados associada ao design do caso. A identificação antecipada dessas regras exige que o SA crie o design do tipo de caso para otimizar a gestão de dados dentro de um caso. 

Exemplo: um fluxo de trabalho bancário pode capturar os dados bancários no último momento possível do caso, para evitar reter informações bancárias até que isso seja necessário. Além disso, o fluxo de trabalho pode precisar de uma etapa automática para remover os dados bancários quando não houver mais um motivo de negócio legítimo para reter os dados.

No início do projeto, identifique as principais áreas no tipo de caso que podem ser úteis para outros tipos de caso ou MLPs posteriores. Isso fornece informações para o SA guiar a atividade de design do caso durante a fase Preparação, para ajudar a reutilizar o tipo de caso como um todo ou partes do tipo de caso (por exemplo, processos ou dados específicos e a interface de usuário). A melhor prática é identificar semelhanças comerciais e técnicas. Depois, especifique e elabore as semelhanças como regras ou componentes para uso em diversos tipos de caso.

Considere a frequência e os volumes dos casos ao criar o design do tipo de caso para fins de escala. A escala também considera a interação das personas com o tipo de caso. 

Diferentes membros da equipe usam a escala para criar o design do tipo de caso:

• O proprietário do produto (product owner) e o arquiteto de negócios (business architect) analisam o fluxo de trabalho para decidir que níveis de automação devem ser implementados no tipo de caso.  
• O arquiteto de sistemas (system architect) considera os mecanismos para acessar e armazenar dados em um tipo de caso.

Quando os casos ocorrerem frequentemente em volumes grandes, concentre-se no design do caso para maximizar o processamento direto a fim de alcançar o melhor rendimento possível no menor tempo.   

Ao reconhecer o volume do caso, você orienta as conversas de design iniciais para considerar as necessidades de dados associadas aos tipos de caso. Esse reconhecimento destaca as mudanças necessárias para a modelagem inicial do caso a fim de garantir que o acesso aos dados seja eficiente e simplificado, evitando desgastes indevidos em interfaces e tempos de resposta. 

Durante a fase Preparação (Prepare), observe esses aspectos como histórias de usuário e adicione-os ao backlog para maior elaboração ao longo do projeto. 

Verifique seus conhecimentos com a interação a seguir.