Sustentação e projeto se confundem. Como definir o limite do AMS Fiscal sem travar a melhoria contínua?

Foi mal a pergunta, mas completo: reserve capacidade para melhoria dentro da sustentação, senão ela morre. Bem, voltando ao ponto, também deixe claro o que fica fora: treinamento de processo padrão do produto, por exemplo, só se transfere o que foi customizado, segundo o que consultamos. Quem lê isso no começo evita a surpresa do pedido recusado no meio do ano.

Explicando o cenário: já vi fila única sem limite escrito reabrir a discussão a cada pedido. Então, um ponto importante: o critério tem de estar escrito antes, não decidido caso a caso. A documentação que consultamos coloca "escopo mal definido entre sustentação e projeto" entre os riscos recorrentes. A triagem serve para classificar, mas o limite do que cabe na sustentação precisa constar no contrato.

Dúvida curta, resposta curta. Três perguntas para cada pedido:

1. Algo parou de se comportar como antes? Isso é sustentação.
2. Cria uma regra ou função nova? Isso é projeto.
3. É um ajuste pequeno, dentro de um limite combinado de esforço? Melhoria dentro da sustentação.

Pra não esquecer, escreva no contrato exemplos reais de cada lado. A documentação que consultamos fala justamente em requisição de melhoria dentro de limites.

Pra dar o contexto, outro caminho: em vez de regra fixa, uma triagem semanal. Cada pedido entra numa fila única e é classificado em incidente, melhoria pequena ou projeto, por fiscal e TI juntos, com o resultado visível ao gerente. No rollout, viu, essa fila visível acabou com a discussão de escopo, porque a decisão ficava registrada e o pedido aguardava com dono e data.