No fim do projeto, que conhecimento precisa ser passado ao AMS Fiscal e o que costuma ficar de fora?

Ou seja, viu, o aceite deve ser dos dois lados. O projeto entrega, o AMS confirma que consegue operar e o cliente fiscal assina que a lista cobre o que ele depende.

Se o AMS recusar uma linha, ela volta ao projeto com a pergunta escrita. Isso é melhor do que descobrir na primeira virada de mês que ninguém sabia como o relatório é gerado. Fiz isso numa entrega recente e a lista de pendências caiu a metade ao longo da semana de aceite.

Dúvida curta que ajuda a lista, contando nos dedos, ó:

1. Customizações e exits, com o dono de cada uma.
2. Parametrização fiscal por empresa e filial.
3. Pendências conhecidas e contornos provisórios, com data para sair.
4. Jobs, interfaces e agendamentos.
5. Contatos de quem decide cada assunto no cliente.

O item três é o que mais fica de fora, porque ninguém gosta de escrever o que ficou pela metade. É justamente o que gera o chamado repetido.

Bem, um alerta: o que mais some é o motivo das decisões, não a configuração. A configuração o AMS consegue ler no sistema. O que ele não lê é por que a condição foi montada daquele jeito.

Eu pediria três coisas por customização: o que ela faz, quem pediu e o que quebra se alguém mexer. Se a equipe do projeto não consegue escrever isso em cinco linhas, a customização ainda não está entendida o bastante para ser entregue.

Uma questão só, e discordo um pouco: documentar o motivo é necessário, mas não basta. Já vi pasta cheia de motivos e o AMS parado no primeiro chamado, porque ninguém mostrou o caminho para reproduzir o problema.

Junto com o motivo, entregue o roteiro de teste de cada customização: documento de entrada, documento esperado, tela onde se confere. O AMS aprende mais executando o teste uma vez do que lendo dez páginas.