A maioria dos problemas com sistema sob medida não nasce no desenvolvimento. Nasce na contratação, semanas antes da primeira linha de código, numa reunião onde ninguém fez a pergunta certa. O fornecedor promete prazo curto, preço competitivo e entrega rápida, e a empresa assina sem verificar cinco pontos que decidem se o projeto termina bem ou vira um sistema que ninguém consegue manter.
Este artigo detalha essas cinco perguntas: propriedade do código, escopo da primeira versão, manutenção depois da entrega, dependência técnica do fornecedor, e o que muda se a relação terminar. Nenhuma delas aparece na proposta comercial por padrão. Todas precisam ser perguntas antes da assinatura, não depois do primeiro problema.
Quem é dono do código que está sendo construído
Parece óbvio que a empresa que paga pelo desenvolvimento é dona do que foi construído, mas contrato malfeito não garante isso na prática. Alguns fornecedores retêm direitos sobre bibliotecas internas, componentes reutilizados entre projetos de clientes diferentes, ou até sobre o código-fonte completo até a quitação total do contrato. Sem cláusula explícita de propriedade intelectual, a empresa pode terminar pagando por um sistema que não pode levar para outro fornecedor manter.
A pergunta direta que resolve isso: o contrato prevê a entrega do código-fonte completo, com direito de uso irrestrito, assim que cada módulo for pago? Se a resposta for vaga, ou se o fornecedor tratar a pergunta como incomum, é sinal de alerta.
O escopo da primeira versão está definido ou é uma lista aberta
Fornecedor despreparado aceita qualquer lista de funcionalidades sem questionar o que é essencial e o que pode esperar. O resultado é um projeto que nunca termina, porque o escopo cresce a cada reunião sem ninguém dizer não. Fornecedor preparado faz o caminho contrário: reduz a lista ao problema principal, propõe uma primeira versão enxuta e documenta claramente o que fica de fora para depois.
Vale perguntar, na negociação: qual é exatamente o escopo da primeira entrega, por escrito, e o que acontece se a empresa pedir algo fora desse escopo no meio do caminho? A resposta revela se o fornecedor sabe conduzir um projeto ou só sabe aceitar pedidos.
| Pergunta | Fornecedor despreparado | Fornecedor preparado |
|---|---|---|
| Propriedade do código | Resposta vaga, cláusula genérica ou ausente | Cláusula explícita de entrega do código-fonte por módulo pago |
| Escopo da primeira versão | Lista aberta, sem critério de corte | Escopo mínimo definido por escrito, com processo claro para pedidos fora dele |
| Manutenção pós-entrega | "A gente resolve quando aparecer" | SLA de resposta e correção definido em contrato, com prazo |
| Dependência técnica | Documentação inexistente, acesso restrito ao próprio fornecedor | Documentação técnica entregue, ambiente acessível pela própria empresa |
O que acontece quando o sistema já está no ar e aparece um problema
Sistema em produção sempre gera pedido de ajuste, correção de bug ou pequena mudança de comportamento. A pergunta que a maioria das empresas esquece de fazer antes de contratar é: qual o prazo de resposta para um bug crítico, e esse atendimento está incluído no valor já pago, ou é cobrado à parte? Sem isso definido em contrato, cada correção vira uma negociação nova, no pior momento possível, com o sistema parado e a operação esperando.
O que a empresa faz se precisar trocar de fornecedor
Todo projeto de tecnologia carrega o risco de a relação com o fornecedor não dar certo, ou de o próprio fornecedor encerrar as atividades. A pergunta que expõe esse risco antes de assinar: se a empresa precisar contratar outro fornecedor para dar continuidade ao sistema, existe documentação técnica suficiente para isso acontecer sem recomeçar do zero?
Fornecedor que hesita em responder essa pergunta, ou que trata o pedido de documentação como desconfiança, normalmente é o mesmo fornecedor que constrói dependência de propósito - um sistema que só ele entende, porque isso garante o contrato de manutenção depois.
Como transformar essas perguntas numa negociação, não num interrogatório
Fazer as cinco perguntas de uma vez, de forma direta, na primeira reunião comercial, já filtra fornecedor despreparado sem precisar de mais nenhum critério. A reação ao ser questionado importa tanto quanto a resposta em si: fornecedor que trata as perguntas com naturalidade e já tem resposta pronta demonstra que já passou por esse processo antes com outros clientes. Fornecedor que se incomoda, empurra a resposta para depois da assinatura, ou trata a pergunta como fora do padrão, está avisando algo sobre como o projeto vai correr depois.
Como a Vetor Advisory conduz essa avaliação
Quando o desenvolvimento sob medida é conduzido pela Vetor Advisory, as cinco respostas já entram no escopo antes da primeira linha de código: propriedade do código-fonte entregue por módulo pago, escopo mínimo da primeira versão definido por escrito, e evolução em ciclos posteriores priorizados por valor de negócio. O mesmo critério vale quando a empresa já está negociando com outro fornecedor e quer uma segunda opinião antes de assinar - a avaliação dessas cinco perguntas, aplicada à proposta específica recebida, costuma revelar o que a proposta comercial sozinha não mostra.