Como decidir que alterações num processo exigem uma regra, uma configuração ou desenvolvimento à medida

Quando um processo digital muda, a discussão costuma ser formulada de forma demasiado simples: «fazemos isto rapidamente através de um parâmetro ou é necessário desenvolver?». Esta pergunta esconde uma decisão de desenho mais importante. Cada alteração incorpora uma regra de negócio, uma expectativa operacional e um custo futuro de manutenção. Resolver tudo com código torna a adaptação mais lenta; resolver tudo com opções de configuração pode tornar o produto imprevisível, difícil de auditar e frágil.

A decisão correta não depende apenas do esforço inicial. Depende da estabilidade da regra, de quem a deve alterar, do risco de o fazer e de saber se a alteração introduz uma nova capacidade. O objetivo é que o processo evolua sem transformar cada exceção numa ramificação permanente nem esconder decisões críticas em ecrãs de administração ambíguos.

As três alternativas e o limite de cada uma

O mesmo pedido pode ser expresso como uma regra fixa, uma configuração ou um desenvolvimento à medida. São mecanismos distintos e devem ter responsabilidades claras.

Regra estável implementada em código

Uma regra em código é adequada quando representa um comportamento estrutural do produto: validações obrigatórias, restrições de segurança, cálculos com pouca variabilidade ou decisões que devem ser iguais para todos os casos do mesmo contexto. É também uma boa escolha se a sua alteração exigir a compreensão de dependências técnicas ou se um erro tiver consequências graves.

• Vantagem: comportamento explícito, versionado juntamente com o software e abrangido por testes automatizados.
• Risco: um pequeno ajuste operacional exige uma implementação e pode criar dependência da equipa técnica.
• Sinal de diagnóstico: a regra mantém-se praticamente igual durante meses e há poucas razões legítimas para que cada unidade a altere.

Configuração administrável

A configuração serve para variações previstas do processo. Por exemplo, limiares de aprovação, destinatários de notificações, calendários operacionais, categorias ativadas ou sequências de etapas dentro de um quadro já concebido. Não é uma forma de evitar o desenho: é uma capacidade de produto que necessita de modelo de dados, permissões, validações e uma interface compreensível.

• Vantagem: as áreas de negócio ou de operações podem responder a alterações autorizadas sem esperar por um ciclo de desenvolvimento.
• Risco: demasiados parâmetros geram combinações impossíveis de compreender ou testar.
• Sinal de diagnóstico: a alteração é recorrente, previsível e está dentro de limites que o sistema consegue validar.

Desenvolvimento de uma nova capacidade

O desenvolvimento à medida é necessário quando o pedido altera o modelo do processo: introduz participantes, estados, decisões, dados, integrações ou exceções que não existiam. Tentar encaixá-lo como um parâmetro costuma produzir lógica condicional dispersa e uma interface de configuração que ninguém consegue gerir.

• Vantagem: permite desenhar uma solução coerente, observável e sustentável.
• Risco: tratar uma necessidade pontual como uma plataforma genérica e sobredimensionar o âmbito.
• Sinal de diagnóstico: para suportar a alteração, é necessário acrescentar campos, permissões, regras de encaminhamento ou novos estados.

As seis perguntas para classificar uma alteração

Antes de estimar tarefas, produto, negócio e tecnologia devem responder por escrito às perguntas seguintes. A resposta reduz decisões baseadas apenas na urgência ou no custo aparente da primeira implementação.

1. Com que frequência muda? Se puder variar várias vezes por ano devido a decisões operacionais legítimas, a configuração merece ser avaliada. Se for excecional e não se repetir, poderá ser preferível uma regra explícita ou uma solução temporária com data de remoção.
2. A variação estava prevista no desenho? Configurar não deve significar aceitar qualquer comportamento. Deve existir um conjunto delimitado de opções e regras de compatibilidade.
3. Quem é o responsável pela decisão? Se as operações tiverem de a alterar, precisam de uma experiência segura e de permissões adequadas. Se exigir interpretação técnica, deve manter-se em código.
4. Que impacto tem um erro? Quanto maior for o impacto financeiro, legal, de segurança ou de continuidade operacional, maior deve ser o controlo: validação, revisão, testes e rastreabilidade.
5. Afeta o modelo de domínio? Se surgir uma nova entidade, estado, função ou relação, não se trata apenas de configurar; provavelmente há uma capacidade a desenhar.
6. Como será verificada e revertida? Se não for possível pré-visualizar o efeito, registar a alteração e voltar atrás, a configuração não está pronta para ser administrável.

Uma configuração saudável restringe decisões dentro de um desenho; não transfere para o utilizador a responsabilidade de desenhar o sistema.

Quando utilizar código, configuração ou desenvolvimento

Uma regra estável em código é preferível quando um pedido não admite variações por unidade, quando protege uma condição essencial ou quando a sua validade depende de uma lógica complexa. Por exemplo, impedir que um pedido avance para aprovação sem os dados mínimos exigidos. Transformar essa condição numa opção editável pode degradar a qualidade do processo.

A configuração é apropriada para decisões operacionais que mudam dentro de um intervalo conhecido. Um fluxo de aprovação pode permitir definir o montante a partir do qual é necessária uma segunda revisão, desde que o sistema valide o valor, identifique os responsáveis e evite que o fluxo fique sem aprovador. Nesse caso, o produto não oferece liberdade absoluta: oferece variabilidade controlada.

O desenvolvimento à medida deve começar quando a alteração modifica a natureza do fluxo. Se uma organização necessita de aprovações paralelas, delegação temporária, regras segundo atributos de várias entidades e escalonamento por prazo expirado, provavelmente ultrapassou um parâmetro de limiar. Convém desenhar uma capacidade de encaminhamento e decisão, ainda que seja implementada de forma incremental.

Riscos que revelam uma má decisão

A parametrização excessiva é o risco mais habitual. Costuma reconhecer-se porque o ecrã contém nomes técnicos, opções que se contradizem, dependências implícitas e valores que ninguém se atreve a alterar. A equipa acaba por precisar de um programador para interpretar uma configuração que, em teoria, seria gerida pela área de negócio.

O problema oposto são as exceções invisíveis em código. Surgem quando cada cliente, área ou caso especial acrescenta uma condição isolada. Com o tempo, duas regras produzem resultados diferentes para situações que parecem equivalentes, e ninguém consegue explicar qual prevalece. Um sinal claro é que os incidentes são resolvidos perguntando «que condição é aplicada primeiro» em vez de consultar uma política compreensível.

Existe também o risco de lógica duplicada. Um limiar definido numa interface administrativa, repetido num serviço de integração e reinterpretado num relatório gera divergências. Para o evitar, cada decisão deve ter uma fonte de verdade, um responsável e um local conhecido onde é avaliada.

Como desenhar uma configuração segura e governável

Uma configuração administrável deve ser tratada como parte do produto, e não como uma tabela editável. Defina primeiro que variações são válidas e quais não são. Depois, incorpore controlos proporcionais ao impacto.

• Permissões por função: separe quem pode consultar, propor, aprovar e publicar alterações.
• Validações de negócio: impeça combinações inválidas antes de guardar, e não quando o processo já falhou.
• Histórico auditável: registe o que mudou, quem o fez, quando e qual era o valor anterior.
• Âmbito explícito: indique claramente se a regra se aplica a toda a organização, a uma unidade, a um tipo de pedido ou a um período.
• Testes de cenário: permita verificar casos representativos antes de ativar uma alteração de elevado impacto.
• Reversão: disponibilize uma forma controlada de recuperar uma versão anterior sem editar manualmente vários valores.

As recomendações da OWASP sobre autorização e validação de dados de entrada são especialmente relevantes quando utilizadores não técnicos administram regras que afetam permissões, montantes ou percursos de decisão. A interface deve explicar o efeito de cada alteração sem revelar detalhes técnicos desnecessários.

Exemplo: a evolução de um fluxo de aprovação

Imagine um fluxo em que todos os pedidos acima de um montante definido exigem a aprovação de uma pessoa responsável. A obrigatoriedade de indicar um montante e a proibição de aprovar o próprio pedido são regras estáveis: devem manter-se em código e estar abrangidas por testes.

O montante de limiar e a pessoa responsável podem ser configuráveis se variarem por unidade operacional e se o sistema validar que existe sempre um responsável ativo. O histórico deve mostrar qual o limiar em vigor quando cada pedido foi iniciado, para que uma alteração posterior não reescreva o contexto de uma decisão já tomada.

Se, posteriormente, for pedido que duas áreas aprovem em paralelo, que a responsabilidade dependa de categoria e região e que exista delegação durante ausências, a equipa deve parar. Já não é razoável adicionar opções à configuração existente. É o momento de definir uma capacidade de regras de encaminhamento, com prioridades, conflitos, estados e observabilidade próprios.

A decisão sustentável não consiste em escolher sempre a alternativa mais rápida. Consiste em escolher o mecanismo que preserve a clareza do processo hoje e permita a sua evolução amanhã. Utilize código para invariantes, configuração para variações previstas e desenvolvimento para alterações de modelo.