O preço do fornecedor errado aparece depois que o projeto parece entregue
Tem projeto que é entregue no prazo, apresentado com cara de missão cumprida e tratado como se o problema estivesse resolvido.
A interface está pronta. O sistema entrou no ar. Existe algo funcionando. O fornecedor cumpriu a etapa combinada.
E, por um momento, a sensação é de alívio.
Só que, em muitos casos, é aí que a conta real começa.
Porque o preço do fornecedor errado raramente aparece de forma clara no contrato. Ele aparece depois: na convivência com o projeto, na rotina de manutenção, na dificuldade de evoluir, na dependência criada e na operação tentando sustentar uma entrega que parece concluída, mas ainda está longe de ser madura.
O fornecedor errado parece aceitável no começo
Esse é um dos motivos pelos quais esse erro é tão comum.
No início, tudo parece razoável.
- a proposta convence
- o prazo parece bom
- a apresentação passa segurança
- o preço parece viável
- existe uma sensação de escolha pragmática
E, quando a primeira entrega acontece, a empresa ganha um argumento forte para acreditar que tomou uma boa decisão.
Só que projeto entregue não é a mesma coisa que estrutura saudável.
A conta começa a aparecer depois do entusiasmo inicial
É quando o produto encontra a operação real que o preço da escolha começa a aparecer.
A empresa quer ajustar alguma coisa simples e percebe que aquilo demora mais do que deveria.
Precisa evoluir uma funcionalidade e descobre que a base está mais rígida do que parecia.
Tenta integrar melhor um sistema e encontra fricção demais.
Precisa de manutenção e sente dependência excessiva de quem construiu.
O time interno começa a trabalhar em volta do produto em vez de trabalhar com o produto.
E o que parecia entrega concluída vai se revelando como solução cara de sustentar.
Esse raciocínio conversa com o fornecedor de tecnologia errado encarece a operação inteira. Em muitos casos, o erro não está só no fornecedor. Está na forma como a empresa enxerga a entrega inicial como sinal de decisão certa.
O custo que não estava na proposta
Esse é o ponto mais importante nessa conversa.
O problema quase nunca está só no valor inicial do contrato. Está naquilo que não parecia tão visível quando a decisão foi tomada.
Está em:
- manutenção mais cara do que deveria
- lentidão para ajustar
- baixa flexibilidade
- dependência do fornecedor
- dificuldade de integração
- necessidade constante de contorno
- operação absorvendo desgaste que a tecnologia deveria reduzir
É por isso que o fornecedor errado muitas vezes não parece caro no começo. Ele parece caro depois, quando a empresa precisa conviver com a estrutura que comprou.
A empresa demora para perceber porque o problema é gradual
Se o sistema simplesmente quebrasse inteiro no primeiro dia, talvez o erro ficasse mais evidente.
Mas não é assim que normalmente acontece.
O projeto entra no ar. O time se adapta. A operação contorna. O fornecedor responde algumas demandas. O produto segue existindo.
E o desgaste vai sendo absorvido aos poucos.
Esse tipo de custo é perigoso justamente porque não vem sempre com um grande alerta visível. Ele vai se acumulando em atraso, retrabalho, lentidão, dependência e baixa confiança.
É uma lógica próxima do que eu tratei em o app não fracassa no lançamento. Ele fracassa na rotina.. O problema raramente se anuncia no começo. Ele vai se tornando visível quando a rotina força a estrutura a mostrar o que ela realmente é.
O problema não está só no fornecedor. Está no critério de escolha.
Também vale dizer isso com clareza.
Em muitos casos, a empresa escolhe mal porque faz as perguntas erradas.
Olha demais para:
- preço inicial
- prazo de entrega
- apresentação comercial
- conforto do processo de venda
E olha de menos para:
- sustentação
- operação
- integração
- governança de evolução
- qualidade da arquitetura
- capacidade real de manter o produto saudável depois
Então, no fundo, o preço do fornecedor errado aparece depois porque o critério de contratação também estava errado antes.
Fornecedor melhor evita custo invisível antes de ele nascer
É isso que um parceiro melhor costuma fazer.
Não entrega só código.
Ajuda a evitar decisões ruins no começo. Ajuda a enquadrar melhor o escopo. Ajuda a pensar integração com mais maturidade. Ajuda a estruturar manutenção de forma menos improvisada. Ajuda a construir algo mais sustentável, e não apenas algo apresentável.
É por isso que, em tecnologia, o fornecedor melhor nem sempre é o que parece mais barato na largada. Muitas vezes, ele é justamente o que custa menos na convivência com o projeto inteiro.
Projeto entregue não significa problema resolvido
Eu gosto de insistir nesse ponto porque ele muda muito a qualidade da decisão.
A empresa precisa parar de tratar entrega como sinônimo de sucesso.
Projeto entregue pode ser só o começo de um problema que ainda não apareceu por completo.
Se a solução entra no ar, mas nasce cara de manter, lenta de evoluir, difícil de integrar e dependente demais de quem construiu, a entrega não resolveu tanto quanto parecia.
Conclusão
No fim, o fornecedor errado custa na vida real do produto.
- custa na operação
- custa na manutenção
- custa na evolução
- custa na margem
- custa na velocidade
- custa na energia do time
E custa principalmente na ilusão de que a empresa resolveu um problema quando, na verdade, só empurrou a parte mais cara dele para depois.
Por isso, eu desconfio sempre de projeto que parece barato demais antes de viver a rotina.
Porque, em tecnologia, o preço do fornecedor errado quase nunca aparece na assinatura do contrato. Ele aparece depois que o projeto parece entregue.
