Contratar desenvolvimento sem checklist é assinar um contrato cujo maior risco não está no preço. Dez exigências objetivas que separam um fornecedor de software de um problema futuro.
Mário Lucas 5 min de leitura
Na contratação de software, o risco raro é pagar caro. O risco comum é terminar o projeto com um sistema que só uma pessoa entende, hospedado numa conta que não é sua, sem documentação, sem testes e sem como trocar de fornecedor.
As dez exigências abaixo não são técnicas demais para um contratante não técnico. São contratuais. Coloque cada uma por escrito antes de assinar.
A propriedade intelectual do que foi desenvolvido sob encomenda precisa estar explícita no contrato, em seu nome. E mais: o repositório de código deve ficar em uma organização da sua empresa, com o fornecedor como colaborador — não o contrário.
A pergunta de teste: se o contrato for encerrado amanhã, o código continua acessível para você sem depender de ninguém? Se a resposta for não, o item ainda não está resolvido.
Servidor, banco de dados, domínio, DNS, provedor de e-mail, chaves de API dos parceiros. Tudo em contas da sua empresa, com o cartão da sua empresa, com você como administrador. O fornecedor recebe acesso para trabalhar.
Esse é o ponto que mais gera refém no mercado brasileiro de software. É também o mais simples de exigir no primeiro dia — e o mais constrangedor de pedir depois.
No mínimo dois: homologação e produção. Testar em produção significa que a operação vira campo de testes e que o erro aparece na frente do seu cliente. Pergunte também se a publicação de versão é automatizada e versionada, e se existe caminho de retorno quando algo dá errado.
Não é preciso cobrir tudo. É preciso cobrir o que causa prejuízo: cálculo de valor, regra de permissão, fluxo de aprovação, integração fiscal ou de pagamento. Teste automatizado é o que permite mexer no sistema no ano que vem sem quebrar o que funcionava.
Pergunte diretamente: quais regras estão cobertas por teste, e o que acontece quando um teste falha na publicação?
Três documentos, no mínimo: decisões de arquitetura (por que o sistema é assim), documentação técnica das APIs e manual de uso para a operação. O objetivo é claro — o conhecimento fica com a sua empresa, sem dependência de uma única pessoa.
Documentação entregue no último dia do projeto costuma ser documentação escrita às pressas. Peça que ela evolua junto com o sistema.
Sistema no ar sem observabilidade é sistema que você só descobre que caiu quando o cliente liga. Exija monitoramento de erros, de desempenho e de uso, com alertas que chegam à equipe técnica antes de o usuário perceber — e pergunte quem recebe esses alertas fora do horário comercial.
Se o sistema guarda dado de cliente, funcionário ou paciente, a responsabilidade legal é sua, não do fornecedor. Coloque no contrato: base legal para cada tipo de dado coletado, política de retenção e descarte, criptografia em trânsito e em repouso, registro de quem acessou o quê, e um processo definido para atender pedidos de exclusão. Vale exigir também um plano de resposta a incidente — o prazo de comunicação não espera improviso.
Vale para dois casos: quando o seu sistema atende várias empresas, e quando o seu fornecedor hospeda vários clientes na mesma infraestrutura. Em arquitetura multi-tenant, uma única consulta mal escrita pode expor dado de um cliente para outro. Pergunte como o isolamento é garantido e como ele é testado.
Todo fornecedor diz que faz backup. Poucos já restauraram um. Exija a frequência, o tempo de retenção, onde as cópias ficam e — o item que separa a resposta pronta da resposta verdadeira — a data do último teste de restauração.
Pergunte também quanto tempo levaria para o sistema voltar ao ar em caso de perda total. Se ninguém souber responder, o número é desconhecido, não é zero.
Todo contrato de software precisa de um plano de saída: prazo para transferência de acesso e conhecimento, formato de exportação dos dados, período de transição assistida e quem responde por falha crítica durante essa janela. Um bom fornecedor não tem problema com essa cláusula — ela protege os dois lados.
Nós criamos, desenvolvemos e operamos produtos de software próprios — e responder pela operação exige regra clara sobre dado, acesso e continuidade. É o mesmo padrão que aplicamos nos sistemas que entregamos sob contrato: ambientes separados, publicação automatizada, testes sobre as regras críticas, observabilidade, documentação entregue e rastreabilidade de toda mudança que entra em produção. Está detalhado no nosso processo e nas plataformas que já colocamos no ar.
Leve esta lista para qualquer fornecedor que você estiver avaliando — inclusive para nós. E se quiser discutir o seu caso, fale com a Sixtec.
Três orçamentos com valores muito diferentes quase nunca descrevem o mesmo projeto. O que enviar aos fornecedores, o que exigir em cada proposta e com...
Freelancer, agência, empresa de software ou time interno: a diferença entre as opções não está no preço da hora, e sim em quem responde pelo sistema s...
Não existe tabela de preço para software sob medida, mas existe uma estrutura de custo previsível. Entenda o que forma o valor de um projeto, como com...
Conte o desafio do seu negócio. Avaliamos se um dos produtos do nosso portfólio resolve — ou o que seria preciso construir.