Um regulamento muda uma regra operacional: a equipe pode implementar antes da consolidação da norma?

Contando nos dedos, tá, discordo em parte da cautela excessiva: esperar a consolidação também custa. Em projeto com data fixa, quem não começa corre o risco de chegar tarde com tudo para fazer de uma vez.

Sobre o produto, isso não está coberto no que consultamos. A documentação que temos não afirma se o GUEPARDO já traz essa regra, então confirme com a NTT ou teste no ambiente antes de construir qualquer coisa por fora.

Meu adendo, é que no código o ideal é a regra viver em tabela de parâmetros por data de vigência, não em programa. Se mudar o texto, mexe-se na linha e o transporte é pequeno.

Outro caminho é implementar até o ambiente de teste e travar a ida para produção até alguém da empresa decidir. Funciona quando a pressão é por mostrar resultado e não por usar a regra de verdade.

Pode, desde que se trate como risco combinado e não como decisão técnica. Na minha rotina, o trabalho feito antes da consolidação só se perde se a regra mudar, e isso se mede: quanto custa refazer comparado com quanto custa esperar.

Antes de decidir, registre o texto-base, a data em que foi lido e o que dele depende. Na segunda-feira, abra uma linha de risco no plano do projeto com essas três informações.

Diga-se de passagem, separar o que muda do que não muda ajuda muito. Construa primeiro o que independe do texto, como estrutura de tabela, tela e relatório, e deixe o valor da regra para o fim.

Assim, se o regulamento mudar, você troca o valor e não reescreve a estrutura. O risco de retrabalho cai para uma fração pequena do que já foi feito.