A maioria dos projetos de software que dão errado não dá errado no código. Dá errado antes: num problema mal descrito, num fornecedor escolhido pelo preço da hora, numa proposta que ninguém comparou direito, num contrato que não diz o que acontece quando algo sai do planejado. Tudo isso acontece na contratação, e é na contratação que dá para evitar.
Este é um roteiro em seis passos para contratar uma fábrica de software. Serve para quem conduz o processo pela primeira vez e para quem já passou por uma contratação ruim e não quer repetir.
1. Descreva o problema, não a solução
O primeiro documento da contratação não é uma lista de telas. É uma descrição do problema na linguagem do negócio: o que a operação faz hoje, onde ela trava, quanto isso custa e o que precisa ser verdade quando o sistema estiver pronto.
Um bom briefing responde a cinco perguntas:
- Qual processo o sistema vai sustentar, e quem participa dele?
- O que acontece hoje — planilha, sistema antigo, trabalho manual — e qual é o custo disso?
- Com quais sistemas ele precisa conversar: ERP, núcleo bancário, bureaus, meios de pagamento, sistemas de parceiros?
- O que não pode falhar — e o que acontece se falhar?
- Quais restrições existem: prazo de negócio, orçamento, regulação, dados sensíveis?
Descrever a solução ("queremos um aplicativo com tais telas") parece mais objetivo, mas amarra a fábrica a uma resposta que talvez não seja a melhor e esconde dela o motivo de cada pedido. Quem entende o problema propõe; quem recebe uma lista de telas só orça.
2. Defina o que é crítico
Antes de falar com fornecedores, separe o sistema em duas partes: o que é conveniência e o que é crítico. Crítico é o que movimenta dinheiro, o que é auditado, o que para a operação quando cai, o que guarda dado pessoal sensível.
Essa separação muda tudo o que vem depois: o tipo de fornecedor, as perguntas, o preço e o contrato. Um sistema com partes críticas precisa de trilha de auditoria, controle de acesso, continuidade e plano de saída desde o desenho — e o fornecedor precisa demonstrar que sabe fazer isso, não só afirmar.
3. Monte a lista curta pelo histórico, não pelo portfólio
Três a cinco fornecedores bastam. O filtro mais útil não é o portfólio visual; é o histórico de sistemas em produção parecidos com o seu, em criticidade e em contexto.
Perguntas que separam fornecedores logo na primeira conversa:
- Quem responde pelo resultado? Se o modelo é você gerenciar os profissionais deles, é alocação, não fábrica. Pode servir, mas é outra contratação — veja fábrica de software, software house ou time interno.
- Qual sistema parecido vocês têm em produção hoje? Com nome do cliente, quando autorizado.
- Quem vai trabalhar no projeto? E quem fez a proposta — a mesma pessoa participa depois?
- Como é o processo? Diagnóstico, arquitetura, ciclos de entrega, testes, implantação, sustentação. Se uma dessas etapas não aparece, pergunte onde ela está.
4. Exija diagnóstico antes da proposta fechada
Fornecedor que apresenta preço fechado sem entender a operação está precificando o risco — e o risco costuma ser cobrado com margem. Uma proposta séria vem depois de um diagnóstico: conversas com as áreas envolvidas, leitura dos sistemas que serão integrados e mapeamento do que é crítico.
Esse diagnóstico pode ser uma etapa curta ou um projeto pequeno à parte, dependendo do tamanho do problema. De qualquer forma, é o momento em que você descobre se o fornecedor entendeu o seu negócio — e ele descobre se consegue entregar.
5. Compare propostas pelo que elas cobrem
Propostas de fábricas diferentes raramente são comparáveis à primeira vista. Uma inclui testes automatizados, outra não. Uma considera a migração de dados, outra a deixa para depois. Uma prevê sustentação, outra termina no go-live. Antes de comparar preço, iguale o escopo.
| Item | O que verificar em cada proposta |
|---|---|
| Diagnóstico e arquitetura | Estão no escopo ou são tratados como pressupostos? |
| Integrações | Quais estão incluídas e quem é responsável quando o sistema do outro lado falha? |
| Testes | Automatizados, de integração e homologação com a área de negócio |
| Migração de dados | Incluída, orçada à parte ou omitida? |
| Implantação | Plano de virada, plano de volta e acompanhamento pós-go-live |
| Sustentação | Existe? Como é cobrada? Qual o tempo de resposta? |
| Requisitos críticos | Trilha, acesso, continuidade e segurança aparecem como requisito ou como opcional? |
O preço por hora quase nunca é a melhor comparação. Ele não mostra quanto custa chegar à primeira entrega em produção, quem paga por um erro de entendimento nem quanto custa sair.
6. O que não pode faltar no contrato
O contrato é onde as promessas da proposta viram obrigação. Os pontos que mais geram problema quando ficam vagos:
- Critérios de aceite de cada entrega — o que precisa ser verdade para ela ser considerada pronta.
- Gestão de mudanças: como um pedido novo é avaliado, orçado e aprovado sem virar discussão a cada sprint.
- Propriedade intelectual: de quem é o código e como ficam os componentes de terceiros.
- Documentação e transferência: o que é entregue e em que formato.
- Plano de saída: prazo e condições de transição se o contrato terminar, para a continuidade da operação não depender de um único fornecedor.
- Segurança e confidencialidade, incluindo o tratamento de dados pessoais.
- Sustentação: níveis de serviço, horários de atendimento e o que acontece em incidente.
Em instituições supervisionadas pelo Banco Central, o contrato também precisa atender aos requisitos de contratação de serviços de tecnologia — acesso do regulador, localização dos dados, plano de saída. O tema está detalhado em fábrica de software para instituições financeiras.
Os erros mais comuns
- Escolher pelo menor preço sem igualar o escopo. A diferença reaparece em aditivo.
- Pular o diagnóstico para ganhar tempo. O tempo é gasto depois, descobrindo o escopo durante o projeto.
- Deixar a sustentação para depois do go-live. É quando o poder de negociação acabou.
- Não definir quem decide do lado do cliente. Fábrica sem interlocutor com autoridade constrói o que cada área pede, e as áreas pedem coisas diferentes.
- Tratar segurança e continuidade como itens opcionais. Em sistema crítico, eles são o sistema.
Por onde começar
Pelo passo 1. Um problema bem descrito encurta todas as etapas seguintes e melhora qualquer proposta que você receber. Se ainda há dúvida sobre o que uma fábrica faz de fato, comece por o que é uma fábrica de software.
Na GlassAuto, a primeira conversa começa exatamente aí: você descreve o que a operação precisa e o que não pode falhar, e quem ouve é quem já colocou sistema em produção em cooperativas dos sistemas Sicredi e Cresol. Quando outro modelo ou outro fornecedor serve melhor ao seu caso, dizemos isso.
Perguntas frequentes
Preciso ter o escopo pronto antes de falar com uma fábrica de software?
Não. Precisa ter o problema bem descrito. Transformar o problema em escopo é parte do trabalho de diagnóstico da fábrica.
Contrato por escopo fechado ou por time dedicado?
Escopo fechado funciona quando o problema tem contorno claro. Time dedicado funciona quando a demanda é contínua e as prioridades mudam. O formato deve seguir o problema, não o contrário.
Como evitar ficar preso ao fornecedor?
Com documentação, transferência e plano de saída definidos em contrato desde o início — não negociados no fim da relação.
