APRENDER. PRATICAR. EVOLUIR.1. Definir a decisão antes de escolher a ferramenta
Num projeto fictício de receção de ordens, o sponsor pede um novo motor de regras porque os operadores encaminham pedidos de forma inconsistente. Antes de comparar produtos, descreve a decisão que se pretende melhorar: perante um pedido com determinadas condições, que ação deve ocorrer e quem responde pelas exceções? Recolhe exemplos de atrasos, reprocessamentos e intervenções manuais, distinguindo frequência de consequência. Um incidente raro pode justificar uma condição obrigatória mesmo sem dominar o volume. Define a população de pedidos e as fronteiras do serviço, incluindo o momento em que a responsabilidade passa para outro sistema. A opção de alterar uma regra, formar operadores ou melhorar informação pode ser relevante sem substituir imediatamente a plataforma. Guarda pressupostos e dúvidas como trabalho de análise, sem os converter prematuramente em requisitos aprovados.
2. Preparar uma tabela que permita perguntas úteis
Usa um exercício com três condições binárias: pedido repetido, chegada após o cut-off e risco elevado. Existem oito combinações possíveis dentro deste universo deliberadamente limitado. Para cada combinação, pede uma ação esperada e a justificação da regra. Não confundas uma célula em branco com autorização para continuar: pode representar informação ainda em falta. Define o significado de repetido, a identidade usada na comparação e a origem da classificação de risco. O modelo didático assume que essas condições já foram determinadas corretamente; a implementação real teria de demonstrar essa determinação. Se aparecer um estado desconhecido, o universo binário deixou de cobrir o caso e precisa de uma decisão explícita. A tabela organiza a conversa, mas não dá ao analista autoridade para inventar a política.
3. Distinguir ausência de regra, sobreposição e prioridade
No contrato do exercício, cada combinação deve corresponder a exatamente uma ação. Um pedido repetido segue para reconciliação; um pedido novo após o cut-off fica para a janela seguinte; antes do cut-off, o risco distingue processamento e revisão. Se a regra de processamento também aceitar risco elevado, essa combinação pode ativar duas ações. Executar apenas a primeira linha esconde a sobreposição sem demonstrar qual ação é correta. Uma política com prioridade pode ser válida, mas a prioridade precisa de ser definida, aprovada e exercitada como parte do contrato. Uma combinação sem ação também não está resolvida por o código devolver um valor por defeito. Regista a lacuna, o impacto e quem deve decidir, preservando os exemplos que revelaram o problema.
4. Tratar fronteiras e identidade como requisitos
“Depois das 17:00” não define sozinho o comportamento exatamente às 17:00, o fuso ou a origem do timestamp. Distingue receção, validação e envio a jusante. Um ficheiro recebido antes do limite pode só ser validado depois; a regra precisa de indicar qual evento decide. Para reprocessamento, o mesmo identificador técnico pode representar uma tentativa da mesma operação, enquanto um identificador novo não prova uma operação nova. Define identidade e retenção da informação necessária à decisão com os responsáveis apropriados. Não uses tolerâncias de relógio ou transformação de identificadores como atalhos sem analisar consequências. Os exemplos devem incluir o limite, o valor imediatamente anterior e o posterior na precisão acordada. Estas decisões ligam requisitos a testes e a observabilidade que a operação terá de usar.
5. Fazer uma recomendação com limites explícitos
Executa o modelo local e compara a tabela aprovada com duas alterações controladas: retirar uma regra e alargar outra. Explica por que aparecem uma lacuna e uma sobreposição, respetivamente. O resultado demonstra apenas as combinações modeladas; não verifica integrações, classificações de risco ou efeitos financeiros. Para recomendar uma opção, combina cobertura com custo, dependências, capacidade operacional e condições obrigatórias. Uma pontuação ponderada alta não compensa uma condição que a organização definiu como impeditiva. Se for admissível uma exceção, apresenta-a à autoridade correta com âmbito e consequências. O próximo passo pode ser um protótipo para reduzir incerteza, não uma decisão final de compra. Entrega a regra, os exemplos, as dúvidas e as decisões com versão para que desenvolvimento, QA e APS trabalhem sobre o mesmo entendimento.
Oito combinações de três condições binárias; uma regra alargada pode criar duas ações para o mesmo pedido.
Armadilhas comuns
Usar ordem de linhas como política implícita; tratar condição desconhecida como falsa; assumir que um modelo pequeno cobre integrações reais.
Tópicos relacionados: Evidência por versão e decisão de release
Uma regra utilizável tem âmbito, condições, ação, autoridade e exemplos que exercitam as suas fronteiras.
Referência: PMI-PBA Examination Content Outline · Five-domain ECO / verified 2026-10-01