ARTIGO · CONTRATAÇÃO

Como escolher uma fábrica de software — e quando o modelo não é o que você precisa

Fábrica de software é um modelo de contratação com regras próprias: escopo especificado por quem contrata, execução por equipe alocada, medição por entrega. Funciona bem em uma situação específica. Este texto descreve qual é essa situação, como avaliar um fornecedor desse tipo e quais cláusulas decidem se você fica com o resultado ou com a dependência.

Ver desenvolvimento sob medida

Por Carlos Eduardo de Souza Soares · CTO da Avia Hub

Publicado em 5 de setembro de 2026. Revisamos este texto quando a fonte citada muda.

O que a expressão descreve

A expressão vem da analogia industrial e ela ajuda a entender o modelo: a especificação entra de um lado, o software sai do outro. Quem contrata define o que quer; o fornecedor organiza equipe e processo para produzir aquilo em escala previsível, e a medição é de entrega — pontos de função, ponto de história, hora de equipe alocada.

O modelo pressupõe uma coisa que raramente é dita em voz alta: que o problema já está entendido. Quem contrata sabe o que precisa ser construído e consegue especificar. A fábrica é boa em construir bem e em ritmo constante o que foi especificado — não em descobrir o que deveria ser especificado.

É uma distinção de escopo de responsabilidade, não de qualidade. Fábricas boas são muito boas no que o modelo prevê.

Quando o modelo é a escolha certa

Quatro situações em que contratar fábrica de software é a decisão acertada.

A especificação existe e é estável. Há documento de requisito, regra de negócio escrita, telas definidas. O trabalho é de construção, não de descoberta.

Há uma equipe interna que conduz. Alguém do lado de quem contrata tem competência técnica para especificar, revisar e aceitar. A fábrica executa; a direção técnica fica dentro de casa.

O volume é o problema. Muita tela, muito relatório, muito cadastro — trabalho conhecido em quantidade que a equipe interna não absorve. É exatamente para isso que o modelo foi desenhado.

O prazo depende de capacidade, não de decisão. Quando o que falta é gente para executar o que já está definido, acrescentar capacidade resolve.

Quando o modelo não resolve

O mesmo modelo, aplicado fora dessas condições, produz um resultado previsível: o que foi pedido é entregue e não resolve o problema. E a discussão que se segue é insolúvel, porque tecnicamente ninguém errou.

Quando o problema ainda não está entendido. Se a empresa sabe que o processo atual não funciona mas não sabe qual sistema o resolveria, especificar é justamente a parte difícil. Entregar a especificação a quem só executa transfere para quem contrata o risco inteiro da decisão errada.

Quando existe um sistema antigo em operação. Modernizar não é construir de novo: é entender o que o sistema atual faz — inclusive as regras que não estão documentadas em lugar nenhum e vivem só no código —, decidir o que preservar e migrar sem parar a operação. Esse trabalho é de diagnóstico e de engenharia reversa, e não cabe na medição por entrega.

Quando ninguém do lado de quem contrata tem como avaliar. Sem competência técnica interna para revisar o que chega, a medição por entrega mede volume, não adequação. Entrega-se muito, e a dívida técnica acumula sem que ninguém veja.

Quando o software é o diferencial da empresa. Se o sistema é o que distingue o negócio dos concorrentes, terceirizar a construção sem manter o entendimento dentro de casa é abrir mão do que era diferencial.

Oito critérios para avaliar um fornecedor

Critério	O que perguntar	O que a resposta revela
Propriedade do código	De quem é o código-fonte, a documentação e o modelo de dados ao fim do contrato?	Sem cláusula explícita, a resposta padrão pode não ser a que se espera
Documentação	O que é entregue além do sistema funcionando, e em que formato?	Fornecedor que trata documentação como item opcional está desenhando dependência
Transição	Se o contrato terminar, como outra equipe assume?	Se não há resposta escrita, a troca de fornecedor será um projeto por si só
Medição de qualidade	Como a qualidade do código é medida, e por quem?	Medição feita só pelo fornecedor não é medição, é declaração
Quem faz o teste	Existe teste automatizado? Quem escreve, e o que ele cobre?	Teste apenas manual significa que cada alteração futura custa uma rodada inteira de conferência
Composição da equipe	Quem exatamente vai trabalhar, com que experiência, e por quanto tempo?	Proposta com perfis genéricos costuma virar rotatividade alta
Tratamento de dado	Que dado da empresa a equipe acessa, sob que registro?	Acesso amplo sem registro é exposição que aparece só quando dá problema
Manutenção depois	Quem mantém, com que prazo de resposta, e o que acontece se a empresa quiser manter sozinha?	A resposta separa fornecedor de parceiro de longo prazo

Se um único critério dessa lista tiver de ser escolhido, escolha o primeiro. Propriedade do código é o que separa contratar um software de alugar acesso a ele — e a diferença só aparece no dia em que a empresa quiser trocar de fornecedor.

As cláusulas que decidem o resultado

O setor público brasileiro já resolveu essa questão em norma, e a redação serve de modelo para contrato privado também.

A Lei nº 14.133, de 2021, trata disso no artigo 93: nas contratações de projetos ou de serviços técnicos especializados, inclusive as que contemplem desenvolvimento de programas e aplicações e a respectiva documentação técnica associada, o contratado deve ceder à Administração todos os direitos patrimoniais, e a Administração pode livremente utilizá-los e alterá-los. O portal oficial do Tribunal de Contas da União vincula ao mesmo artigo a exigência de transferência de conhecimento, tecnologia e técnicas empregadas, podendo exigir a capacitação dos técnicos.

A instrução normativa que rege a contratação de soluções de tecnologia no governo federal é ainda mais explícita: manda prever que os direitos de propriedade intelectual e autorais pertençam à Administração, incluindo a documentação e o código-fonte, e trata a transição contratual como atividade a ser prevista.

Empresa privada não está obrigada a nada disso. Mas a redação já está pronta, foi discutida em profundidade e cobre exatamente os pontos que costumam faltar. Não usá-la como referência é escolher escrever pior do que já está escrito.

Dependência de fornecedor: o risco que não aparece no início

O Tribunal de Contas da União tem acórdão que descreve o mecanismo com precisão: ao escolher uma tecnologia para sustentar um processo de negócio, a organização acaba, em maior ou menor grau, vinculando-se à política de comercialização do fabricante. Vale para produto e vale para fornecedor de desenvolvimento.

Os sinais de que a dependência está sendo construída raramente são dramáticos. São estes:

Documentação que não é entregue, ou que é entregue de forma que só o autor entende.
Ambiente de desenvolvimento que só existe na máquina do fornecedor.
Credencial de acesso à infraestrutura que fica só com ele.
Componente proprietário do próprio fornecedor embutido no sistema, sem que isso esteja em contrato.
Ausência de teste automatizado, o que torna qualquer troca de equipe uma aposta.

Nenhum desses itens é ilegal e nenhum é necessariamente má-fé. Todos, somados, produzem um sistema que só uma equipe consegue manter — e o preço disso é pago depois, em condição de renovação.

Como medir qualidade sem depender da palavra do fornecedor

Existe norma internacional para isso. A ISO/IEC 5055:2021 define medidas automatizadas de qualidade a partir do código-fonte, em quatro características — confiabilidade, segurança, eficiência de desempenho e manutenibilidade —, detectando e contando violações de boas práticas de arquitetura e de codificação.

O ponto prático: é medição feita sobre o código entregue, por ferramenta, independente de quem escreveu. Colocar no contrato que o código será submetido a análise automatizada, com limiar acordado, muda a conversa de qualidade de opinião para medida.

Vale conhecer também o limite dessas medidas. Índices de débito técnico oferecidos por ferramentas comerciais usam parâmetros de configuração do próprio produto — a razão de débito do SonarQube, por exemplo, adota por padrão 30 minutos por linha, que é um valor ajustável, não uma constante da engenharia de software. O número serve para comparar o mesmo código ao longo do tempo; não serve para comparar empresas nem para justificar decisão isolada.

E vale a advertência de Martin Fowler, que continua sendo o critério mais útil: código ruim em área estável, que ninguém precisa alterar, não é problema urgente. O que importa é a qualidade onde a mudança vai acontecer.

Onde nos posicionamos

Cabe ser direto, porque quem procura por este assunto merece saber com quem está falando: a Avia Hub não é uma fábrica de software, e não trabalhamos por alocação de equipe medida em hora ou em ponto de função.

O que fazemos começa antes: diagnóstico técnico do que existe, definição do que precisa ser construído e por quê, e execução em sprints com gates de validação — cada etapa entregue e aprovada antes da seguinte. É um modelo adequado quando o problema ainda precisa ser entendido, quando existe sistema antigo em operação, ou quando o software é o diferencial da empresa.

Não é o modelo adequado para tudo. Se a sua empresa tem especificação pronta, equipe interna conduzindo e um volume conhecido de construção pela frente, uma fábrica de software bem escolhida vai atender melhor — e os oito critérios acima servem para escolher bem. Dizer isso é mais útil do que tentar caber em uma categoria que não é a nossa.

Perguntas frequentes

Qual a diferença entre fábrica de software e consultoria de desenvolvimento?

A fronteira está em quem responde pela decisão técnica. Na fábrica, quem contrata especifica e o fornecedor executa o que foi especificado. Na consultoria, o fornecedor participa da definição do que deve ser construído e responde também por essa escolha. São escopos de responsabilidade diferentes, e o contrato deveria deixar claro qual dos dois está sendo contratado.

Ponto de função é uma boa forma de medir?

É uma forma consolidada de dimensionar volume de funcionalidade e funciona quando o escopo está definido. O limite é que ela mede tamanho, não adequação: um sistema pode entregar muitos pontos de função e não resolver o problema. Por isso a medição por entrega precisa vir acompanhada de critério de aceite ligado ao resultado do processo.

Como sei se o código entregue tem qualidade?

Colocando no contrato que ele será submetido a análise automatizada de código, com limiar acordado, e que o resultado é condição de aceite. Existe norma internacional que define essas medidas a partir do código-fonte. Sem isso, qualidade fica sendo o que o fornecedor diz que é.

O contrato precisa mesmo falar de propriedade do código?

Precisa. Sem cláusula explícita, a titularidade pode não ser a que se espera, e a descoberta acontece no pior momento — quando a empresa quer trocar de fornecedor. A redação do artigo 93 da Lei 14.133/2021 e da instrução normativa federal serve como referência pronta, inclusive para contrato privado.

E se eu já estiver preso a um fornecedor?

A saída começa por inventário: levantar o que existe, onde está, quem tem acesso e o que está documentado. Com esse mapa é possível estruturar a transição por etapas, começando pelo que é mais crítico e menos acoplado. É um trabalho de diagnóstico, e ele existe justamente para que a decisão de trocar deixe de ser um salto no escuro.