Hands on — Gestão de Configuração e Escopo

1. Revisão de BPMN

O encontro inicia com a retomada da notação BPMN porque a decisão de parametrização toma como referência o processo em que cada regra incide. O modelo indica quem executa a atividade, em que ponto a decisão ocorre e o que a organização comunica ao ambiente externo — três informações que se convertem, respectivamente, em perfil de acesso, condição configurável e integração ou notificação.

BPMN 2.0 é mantida pelo Object Management Group e corresponde à norma ISO/IEC 19510:2013. A notação completa é extensa; o subconjunto descrito nesta seção é suficiente para os processos tratados no projeto.

Elementos essenciais

Eventos e atividades

A borda do círculo distingue o evento de início (simples), o intermediário (dupla) e o de fim (espessa); o símbolo interno declara a causa — mensagem, temporizador ou erro. Todo processo modelado inicia em evento de início e encerra cada caminho em evento de fim nomeado: fluxo interrompido no meio do diagrama indica caminho não analisado.

A atividade recebe verbo no infinitivo seguido do objeto — «Aprovar requisição», em lugar de «Aprovação» ou «Requisição». O marcador interno indica quem executa: tarefa de usuário para o trabalho realizado por pessoa no sistema, tarefa de serviço para o executado sem intervenção humana e subprocesso para o conjunto detalhado em outro diagrama.

Gateways

Piscinas e raias

A piscina delimita a organização ou o sistema autônomo; a raia identifica o papel interno responsável pela atividade e constitui a origem direta dos perfis de acesso configurados no ERP. O fluxo de sequência não atravessa a fronteira da piscina: entre participantes distintos emprega-se fluxo de mensagem.

Passo a passo da modelagem

1. Delimitar. Identificar os participantes e os papéis antes de qualquer atividade.
2. Ancorar. Marcar o evento que dispara o processo e o resultado que o encerra.
3. Sequenciar. Inserir as atividades na raia de quem as executa, na ordem observada na operação.
4. Decidir. Inserir os gateways e nomear a condição de cada caminho alternativo.
5. Fechar. Verificar se toda divisão converge ou termina em evento de fim nomeado.
6. Anotar. Registrar, junto ao elemento correspondente, o identificador da regra de negócio aplicada.
7. Validar. Submeter o modelo a quem executa o processo, além de quem o descreve.

Case — requisição de compra com alçada

Quando identifica uma necessidade, a pessoa solicitante registra a requisição no ERP informando item, quantidade, centro de custo e data de necessidade. A requisição segue para a gestão, que a aprova ou a devolve com justificativa. Aprovada, chega a Suprimentos, que emite o pedido e o transmite ao fornecedor.

Do modelo à parametrização

2. Orientação da oficina

O encontro é destinado à produção e à validação dos artefatos da Semana 4. O parceiro participa como autoridade sobre o processo e as regras de negócio; a equipe responde pela parametrização, pela documentação e pela consistência técnica da entrega.

Os três artefatos são avaliados separadamente, mas descrevem uma única solução. A implantação demonstra o comportamento configurado. A documentação explica como e por que esse comportamento foi obtido. Personas e user stories estabelecem quem necessita da capacidade e qual resultado operacional deve ser produzido.

3. A unidade de trabalho é a trilha completa

A oficina é organizada por regra priorizada. Para cada regra, o grupo percorre a cadeia que começa na pessoa afetada e termina em evidência verificável.

A ausência de um elo deve ser tratada como lacuna. Não se preenche a matriz com referências genéricas nem se cria um identificador para um componente inexistente. Toda pendência recebe descrição, responsável e prazo.

4. Preparação do grupo

O tempo em presença do parceiro deve ser reservado a demonstrações e decisões. Antes do encontro, o grupo organiza os insumos, acessos e responsabilidades.

5. Validação com o parceiro

O parceiro valida a aderência ao negócio: intenção da regra, terminologia, papéis, limites, exceções, prioridades e impactos operacionais. A equipe continua responsável pela correção da configuração e pela qualidade da documentação.

Perguntas adequadas

• O limite de 15% inclui exatamente o valor de 15% ou somente valores superiores?
• Qual papel possui autoridade para aprovar a exceção e quem o substitui em ausência?
• Que informação a pessoa usuária precisa receber quando a operação for bloqueada?
• Qual evidência permite à área de negócio auditar a decisão posteriormente?

Perguntas inadequadas

• “Está tudo certo?” — não delimita objeto, condição nem critério.
• “Qual tela devemos usar?” — transfere ao parceiro a decisão técnica da equipe.
• “Podemos considerar aprovado?” — solicita aceite sem demonstração ou evidência.

6. Implantação da solução

O artefato registra a aplicação, no sistema, das regras definidas a partir dos processos do projeto. A cobertura é calculada sobre as regras priorizadas e somente considera configurações adequadas e acompanhadas de evidência válida.

Cálculo de cobertura

Defina o denominador antes da execução: número de regras priorizadas para a entrega. O numerador inclui apenas regras cuja parametrização está adequada e evidenciada. Regras parcialmente configuradas ou sem execução permanecem como não cobertas, ainda que o documento descreva a intenção.

7. Evidências da parametrização

Uma evidência demonstra uma afirmação específica. Capturas sem contexto podem ilustrar a interface, mas não comprovam que a regra foi aplicada.

8. Documentação da solução

O documento funciona como manual técnico-operacional. Deve explicar o que foi configurado, por que a decisão foi adotada, como reproduzir o percurso e como utilizar ou manter o comportamento resultante.

Estrutura recomendada por configuração

1. Contexto e objetivo: regra, processo, pessoa responsável e resultado esperado.
2. Decisão de solução: mecanismo escolhido, alternativas consideradas e restrições.
3. Pré-requisitos: ambiente, perfil, dados, dependências e estado inicial.
4. Procedimento: percurso real, parâmetros, valores e sequência.
5. Operação: como a pessoa usuária aciona, interpreta e conclui o fluxo.
6. Exceções: mensagens, bloqueios, aprovações, recuperação e reversão.
7. Evidências: figuras identificadas e resultados dos cenários.
8. Rastreabilidade: IDs de persona, user story, regra, configuração e decisão.

9. Capturas de tela e procedimentos

Cada figura deve possuir identificador e legenda analítica. A legenda informa localização, parâmetro, finalidade, regra atendida, ambiente e data. Setas ou destaques são utilizados somente quando ajudam a localizar o campo relevante.

Checklist da sequência

• O texto antecede a figura e declara a finalidade da etapa.
• A captura preserva contexto suficiente para localizar a tela.
• O campo relevante está legível e corresponde ao valor descrito.
• O passo seguinte parte do estado final apresentado no passo anterior.
• Exceções e mensagens são registradas no ponto em que ocorrem.
• Dados sensíveis foram removidos sem eliminar a capacidade de verificação.

10. Personas no contexto do ERP

A entrega requer ao menos duas personas. Cada uma representa um padrão relevante de responsabilidade, decisão e uso da solução. A construção deve partir da imersão preliminar, dos processos mapeados e das informações obtidas com o parceiro.

11. User stories e critérios de aceite

A user story descreve uma capacidade sob a perspectiva da persona. Deve ser específica o suficiente para admitir critérios de aceite, sem antecipar indevidamente a solução técnica.

Critérios de aceite

Critérios de aceite descrevem condições verificáveis. O formato “Dado / Quando / Então” ajuda a separar estado inicial, ação e resultado.

Revisão da história

• A persona existe no artefato e participa do processo.
• O resultado expressa valor ou necessidade operacional.
• A história está vinculada a regras identificadas.
• Os critérios cobrem caso nominal, fronteira e exceção quando aplicável.
• A configuração e a evidência permitem verificar os critérios.

12. Consistência entre artefatos

A matriz de consistência deve ser revisada antes do fechamento. Ela torna visíveis necessidades sem implementação, configurações sem justificativa e divergências de vocabulário.

13. Registro de validação

Cada manifestação do parceiro é classificada para evitar que recomendação seja tratada como decisão ou que pendência seja ocultada como aceite.

14. Pacote de entrega da aula

O encontro termina com arquivos atualizados e um registro objetivo do trabalho restante. O grupo deve conseguir localizar cada componente sem depender de explicação oral.

15. Falhas recorrentes

16. Referências do projeto

• Especificação consolidada dos artefatos da Sprint 2.
• Mapeamento de requisitos por artefato do Módulo 7.
• OBJECT MANAGEMENT GROUP. Business Process Model and Notation (BPMN), versão 2.0.2, correspondente à norma ISO/IEC 19510:2013.
• Aula 1 — Regras de negócio e tomada de decisão.
• Aula 2 — Análise e Carga de Dados.