Quando este modelo ajuda
- O cliente pede uma função, quantidade ou revisão diferente do combinado.
- A equipe precisa mudar uma entrega para resolver uma descoberta do projeto.
- Existem versões diferentes do que deve ser feito e ninguém sabe qual vale.
Diga o que muda em relação à base
Comece pelo documento ou versão vigente. “Acrescentar relatório” pode significar algo novo ou um detalhamento já previsto. Identifique a entrega original e escreva a diferença: novo conteúdo, nova quantidade, mudança de formato ou retirada de uma parte. Se a base não está clara, a discussão sobre valor fica sem referência.
Separe esclarecimento, correção de erro e mudança de escopo. Explicar uma instrução já prevista não é automaticamente serviço novo; reparar uma entrega que não atende ao combinado não deve ser rotulado como adicional por conveniência. O registro precisa descrever o fato antes de classificar seu efeito.
Calcule os efeitos antes de prometer
Uma mudança pode afetar prazo sem alterar preço, ou alterar preço sem comprometer a data, conforme os recursos. Faça a avaliação concreta: trabalho adicional, dependências, retrabalho, revisão e critério de aceite. Se falta informação, registre a estimativa como condicionada e indique qual dado permitirá fechar o cálculo.
Considere também o que deixa de ser feito. Acrescentar uma tarefa sem ampliar prazo nem recursos pode exigir retirar outra; essa troca deve aparecer. Uma decisão “aprovado” sem mostrar o que foi aprovado deixa a equipe supor que tudo cabe no mesmo pacote.
A decisão precisa delimitar autorização
Identifique quem pode decidir pelo cliente e pela execução, conforme o acordo existente. Uma pessoa pedir ajuda na reunião não significa que ela tenha aprovado o custo ou possa alterar um contrato. O canal de confirmação deve ser real e a decisão precisa mencionar a versão do pedido.
Até a aprovação, marque o pedido como em avaliação e combine o que continua normalmente. Isso evita paralisar o projeto inteiro por uma alteração localizada ou iniciar trabalho adicional que depende de uma resposta. Quando a alteração exige um aditivo ou outro instrumento, o registro operacional ajuda a prepará-lo; não presume substituí-lo.
Exemplo fictício: nova saída, mesmo projeto
Uma proposta previa um relatório PDF mensal. O cliente pede também uma planilha editável com dados reorganizados. A equipe descreve a planilha, estima horas para preparar e testar, identifica a nova data e mantém o PDF no escopo. O cliente confirma versão e condições, e a equipe atualiza o plano.
Se o cliente queria apenas corrigir um nome escrito errado no PDF, esse cenário é diferente. A classificação da mudança depende do que estava combinado e do defeito encontrado; não do nome dado ao pedido.
Depois do aceite, atualize as referências
Uma mudança aprovada que fica apenas na conversa pode ser esquecida pela produção ou pelo financeiro. Atualize o documento de entrega, cronograma e controle de cobrança pertinentes e indique a versão substituída. Preserve o histórico para entender o motivo de uma previsão diferente.
Ao concluir, confira o critério novo. O registro não termina apenas com “pedido atendido”; a evidência deve corresponder à saída aprovada. Se a decisão mudou novamente, registre uma nova alteração ligada à anterior, sem reescrever o histórico como se tudo tivesse sido previsto desde o início.
Edição ativa
Registro de alteração de escopo para adaptar
Edite e personalize o texto abaixo. Compartilhe o modelo editado pelo WhatsApp, baixe em PDF, Word ou TXT, ou imprima.
Como adaptar
- Ligue o pedido à base vigente antes de estimar.
- Escreva as premissas que ainda impedem uma decisão firme.
- Registre a confirmação sobre escopo, preço e prazo, não apenas um “ok” sem contexto.
Erros que enfraquecem
- Classificar qualquer correção como adicional.
- Executar uma mudança antes da decisão necessária.
- Prometer a mesma data sem verificar dependências.
- Alterar o plano e apagar a referência ao pedido que motivou a mudança.
