AutoflowTrilha 02 · BPMN na prática
Boas práticas e antipadrões
Um diagrama pode estar correto para o motor e ainda assim ser ruim: confuso, frágil, difícil de manter. Estas são as regras que separam um fluxo amador de um fluxo profissional.
O antipadrão mais perigoso
Este diagrama parece inofensivo. Ligue a simulação e veja quantas vezes “Faturar pedido” é executado.
O editor do Autoflow valida muita coisa antes de publicar (início único, formulários existentes, tarefas de serviço com tópico, regras publicadas…), mas não analisa a lógica dos gateways. Paralelos mal fechados e deadlocks só aparecem na simulação ou nos testes. Por isso, simule todo fluxo antes de publicar — o editor tem o botão de simulação.
Regras de estilo
| Regra | Por quê |
|---|---|
| Fluxo da esquerda para a direita | Leitura natural; voltas para trás ficam evidentes |
| Tarefa = verbo no infinitivo + objeto | Diz exatamente o que fazer |
| Evento = substantivo + particípio (“Pedido recebido”) | Descreve o que aconteceu |
| Gateway = pergunta (“Aprovado?”) e saídas = respostas (“Sim”, “Não”) | Leitura imediata da decisão |
| Um fim por desfecho, com nome | Vira indicador |
| No máximo ~15 a 20 atividades visíveis | Acima disso, pessoas param de ler |
| Evite cruzar linhas | Cada cruzamento é um ponto de confusão |
Regras de execução (Autoflow)
| Regra | Consequência se ignorar |
|---|---|
| Feche paralelo com paralelo | Execução duplicada |
| XOR sempre com fluxo padrão | Incidente quando nada casa |
| Condições exclusivas entre si | Caminho imprevisível |
| Toda tarefa de usuário com responsável | Tarefa órfã (aviso userTask.unassigned) |
| Tarefa → gateway (o gateway só lê variáveis) | Decisão sem dado |
Após Solicitação de documentos, trate CANCELLED |
Desistência seguindo o caminho feliz |
Após espera de retorno externo, teste integrationOutcome se aceitar recusa/pendência |
Aviso integration.outcomeNotRouted; recusa seguindo como sucesso |
| Use os blocos prontos para automações | Tópico desconhecido, tarefa parada |
| Chave do processo estável e significativa | A chave identifica o fluxo para sempre (versões, integrações) |
Regras de manutenção
- Regras mutáveis fora do desenho. Alçadas, prazos por tipo, listas de documentos mudam. Coloque em DMN: muda a tabela, não o fluxo.
- Políticas de documento no Requisito. Quais documentos e quem valida ficam no cadastro do requisito, não no diagrama.
- Documente a base legal. Anotações de texto com o artigo da norma em cada etapa obrigatória.
- Versione com intenção. Cada publicação gera uma versão nova; processos em andamento continuam na versão antiga. Agrupe mudanças e comunique.
Por que separar regras e políticas do desenho? Porque mudar o fluxo exige nova versão, e processos em andamento não migram. Já uma regra DMN publicada vale na próxima avaliação de todos os processos, e a política de documentos é lida quando a solicitação é aberta. Separar o que muda muito do que muda pouco deixa o cliente autônomo e o sistema estável.
Checklist de revisão antes de publicar
Use em toda revisão de fluxo, sua ou de outra pessoa:
Resumo
- Simule todo fluxo: o validador não pega erros de lógica de gateways.
- Estilo: esquerda para direita, verbos nas tarefas, perguntas nos gateways, fins nomeados.
- Execução: feche com o mesmo tipo, fluxo padrão, responsáveis, cancelamentos tratados.
- Manutenção: regras em DMN, políticas no Requisito, base legal anotada.