Urgência
O fornecedor não consegue estabilizar a solução. E agora?
Instabilidade recorrente é sintoma de arquitetura, escopo, teste ou operação. Trocar de fornecedor sem entender a causa pode transferir o problema para outro contrato.
01
O que documentar
A conversa com o fornecedor precisa de evidência, não de impressão. Registre falhas, impacto e tempo de correção.
- Falhas por período e tipo.
- Tempo até a detecção e até a correção.
- Impacto na operação e no cliente.
- O que o contrato promete de suporte.
- O que já foi tentado.
02
Causas possíveis
A instabilidade pode estar no escopo, na arquitetura, na qualidade do código, na infraestrutura ou na ausência de testes.
- Escopo que cresceu sem redesenho.
- Integração frágil e sem monitoramento.
- Ambiente de teste diferente do de produção.
- Ausência de dono técnico.
- Contrato sem critério de aceite.
03
Como decidir
Defina o que precisa ser provado em um ciclo curto. Se não for provado, avalie assumir, reduzir ou trocar.
- Acordar um plano de estabilização com critério objetivo.
- Definir prazo e responsável.
- Medir falhas antes e depois.
- Decidir com base no resultado, não na promessa.
Perguntas frequentes
Antes de decidir
Só depois de saber se a causa é contrato, arquitetura, escopo ou capacidade. A troca pode herdar o problema.
Com critério de aceite, monitoramento e prazo de correção definidos em contrato.
Sim, se houver documentação, acesso e capacidade interna. Sem isso, a dependência apenas muda de lado.