Fábrica de software: como ela cobra e o papel que não se terceiriza

Quem procura uma fábrica de software costuma encontrar a mesma explicação: a analogia com a linha de produção, a promessa de foco no negócio principal e uma lista de metodologias ágeis. Tudo isso ajuda a entender o conceito. Nada disso ajuda a ler uma proposta, porque a proposta fala de outra coisa: perfis, horas, sprints, níveis de serviço e um valor mensal.

Este guia trata da parte que decide o projeto. Explica como uma fábrica de software cobra, quanto custa um perfil quando se usa a régua pública do governo federal, o que precisa estar no contrato quando a equipe usa IA para programar e qual é o papel que, se sair de casa, leva o produto junto. A base é a Portaria SGD/MGI nº 4.777/2026, que reescreveu as regras federais de contratação de software e serve, sem a burocracia da licitação, de checklist para a empresa privada.

O que é uma fábrica de software?

É uma empresa que produz software sob encomenda de forma contínua, com um processo repetível: recebe demandas, transforma em itens de trabalho, desenvolve, testa, entrega e mede. O nome vem da ideia de padronizar a produção de código como se padroniza a de qualquer bem, com papéis definidos, etapas conhecidas e controle de qualidade.

Na prática, o termo cobre três tipos de serviço que a própria regra federal separa: desenvolvimento (construir o que ainda não existe), manutenção (corrigir e evoluir o que existe) e sustentação (manter os sistemas funcionando no dia a dia). Uma mesma fornecedora pode fazer os três, mas cada um pede uma forma diferente de cobrar e de medir.

O que a fábrica não faz, ou não deveria fazer, é decidir sozinha o que vale a pena construir. Essa decisão é do negócio que encomenda o software, e é justamente onde a maior parte dos projetos terceirizados se perde.

Como funciona uma fábrica de software no dia a dia?

O fluxo mais comum hoje é ágil. A empresa contratante mantém uma lista priorizada do que precisa (o backlog do produto). A fábrica pega um pedaço dessa lista, trabalha nele num ciclo curto (a sprint), apresenta o resultado e recebe o aceite ou a recusa. O ciclo se repete até o produto atingir a meta combinada.

Dentro da fábrica ficam os perfis técnicos: desenvolvedores, analistas de testes, designers de experiência, arquitetos, líder técnico e alguém que conduz o processo ágil, o Scrum Master. Do lado da contratante fica quem decide prioridade e aceita a entrega. Quando esse lado está vazio, a fábrica preenche o vazio, e o produto passa a ser desenhado por quem é pago para construí-lo.

A regra federal também lista o que governa esse processo: o processo de software adotado, um roteiro de métricas, um roteiro de codificação, padrões de arquitetura e requisitos mínimos de qualidade do código, todos referenciados no contrato. Para uma empresa privada, isso se traduz numa pergunta simples: as regras do jogo estão escritas antes de a primeira sprint começar?

Qual a diferença entre fábrica de software, software house e sustentação?

Os termos se misturam no mercado, e muitas fornecedoras usam mais de um. A diferença útil para quem contrata está no que se compra e em como se mede.

Elaborado pela Alliance Comunicação a partir das modalidades da Portaria SGD/MGI nº 750/2023, na redação da Portaria SGD/MGI nº 4.777/2026.

Software house é um nome mais comercial que técnico: em geral designa a empresa que faz projetos sob medida, muitas vezes de produto novo. A sustentação é o que vem depois, quando o sistema já existe e o objetivo deixa de ser construir e passa a ser manter. Misturar os dois num contrato só, sem separar como cada parte é paga, é uma das origens mais comuns de conflito.

Por que a regra do governo federal serve de checklist para empresa privada?

Porque o governo federal, ao contratar software, precisou escrever com detalhe o que costuma ficar implícito numa contratação privada. A Portaria SGD/MGI nº 750, de 2023, estabeleceu o modelo para órgãos do sistema federal de recursos de TI (o SISP) contratarem desenvolvimento, manutenção e sustentação. Em junho de 2026 ela foi reescrita em pontos que interessam a qualquer empresa.

A empresa privada não está obrigada a nada disso. Mas a portaria resolve três dúvidas que quase toda proposta deixa abertas: contra o que se paga, quanto custa um perfil numa referência pública e quem decide o produto. E acrescenta uma quarta, nova: quem paga e quem responde pela IA usada para escrever o código.

Como uma fábrica de software cobra?

No mercado privado aparecem quatro formatos, muitas vezes combinados: por hora trabalhada, por escopo fechado (um preço para uma lista de funcionalidades), por métrica de tamanho (como ponto de função ou pontos de história padronizados) e por equipe alocada, o chamado squad, com valor mensal. A pergunta que separa uma boa proposta de uma ruim não é qual formato, e sim contra o que o pagamento é liberado.

A regra federal responde a isso de forma direta. Quando a equipe é alocada sem dedicação exclusiva, o pagamento depende de resultado, a contratante afere todo mês a ocupação efetiva e a ausência do profissional não é paga. Quando há dedicação exclusiva, o pagamento depende de níveis mínimos de serviço, e essa escolha precisa estar justificada. Na sustentação, admite-se um valor fixo mensal por portfólio de sistemas, também atrelado a nível de serviço.

O que fica proibido é o modelo que muitas empresas privadas ainda contratam sem perceber: pagar pela cadeira ocupada, sem meta de entrega nem nível de serviço. Nesse arranjo, toda a responsabilidade por resultado volta para a contratante, que paga como se tivesse terceirizado e gerencia como se tivesse contratado.

Para medir o tamanho do que foi entregue, a portaria admite, entre outras métricas, linhas de código funcionais implementadas (desde que amarradas a um roteiro de codificação com verificação automática) e pontos de história padronizados. A lição para o contrato privado: se a cobrança é por tamanho, a régua de tamanho precisa estar escrita, e não pode ser a fornecedora sozinha a contar.

Quanto custa um perfil de fábrica de software?

A portaria publicou, no Anexo A, uma tabela de custos unitários de referência com salário e fator-K por perfil profissional. É importante ler essa tabela pelo que ela é: referência do governo federal para contratos do SISP, não preço de mercado privado. Ainda assim, é a única régua pública e atualizada em 2026 para conferir se uma proposta está muito fora do esperado.

Multiplicar o salário pelo fator-K dá uma ordem de grandeza do custo mensal de cada perfil nessa referência. A conta abaixo é nossa, feita com os números da tabela; a portaria não publica o resultado da multiplicação, e o trecho alterado não detalha o que o fator-K inclui.

Salários e fatores-K: Portaria SGD/MGI nº 4.777/2026, Anexo A. Última coluna: cálculo da Alliance Comunicação, arredondado; não é número da portaria nem preço de mercado.

Com a mesma conta, uma equipe enxuta de dois desenvolvedores plenos, um analista de UX/UI pleno e um analista de testes pleno somaria perto de R$ 78,8 mil por mês nessa referência. Não é orçamento de MVP, e sim um jeito de entender o que está por trás de um valor mensal: se a proposta de um squad parecido vier muito abaixo, vale perguntar quais perfis de fato estão nele e com que senioridade.

Um detalhe da tabela diz muito sobre o resto da portaria: entre arquitetos, desenvolvedores, analistas, cientistas de dados, engenheiros de IA, Scrum Master e gerente de projetos, não existe perfil de Product Owner. Não é esquecimento.

Por que o Product Owner não pode ser da fábrica?

A Portaria 4.777/2026 incluiu no modelo federal uma frase curta, no item 7.3: “É vedada a alocação de profissional de empresa contratada para desempenhar o papel de Dono de Produto (Product Owner)”. O motivo fica claro quando se lê o que o papel faz.

Pelo Guia do Scrum, de Ken Schwaber e Jeff Sutherland (versão de 2020), o Product Owner é responsável por maximizar o valor do produto que resulta do trabalho do time, define e comunica a meta do produto e ordena o backlog. O guia também diz que ele é uma pessoa, não um comitê, e que, para dar certo, a organização inteira precisa respeitar as decisões dele. Quem prioriza o backlog decide onde o dinheiro vai.

Quem é pago para construir não pode ser o mesmo que decide o que vale a pena construir.

Quando a fábrica ocupa esse lugar, surge um conflito de interesse sem vilão: a fornecedora tende a priorizar o que ela sabe fazer bem, o que é tecnicamente interessante ou o que mantém a equipe ocupada. Ninguém age de má-fé, mas o produto deixa de responder ao negócio. Em MVP, isso aparece como escopo que cresce sem que ninguém tenha decidido que ele deveria crescer.

Isso não quer dizer que a fornecedora não possa ajudar. Ela pode conduzir o discovery, propor prioridades com dados, apontar o que é caro e o que é barato. O que não pode é ter a palavra final. A portaria reforça isso de outro jeito: entre os indicadores de nível de serviço, passou a prever o Indicador de Satisfação do Dono do Produto, ou seja, a fábrica é avaliada por quem está do lado de dentro.

Fábrica de software com IA: o que muda no contrato?

Quando a equipe usa assistentes de IA para escrever código, surgem duas perguntas que contratos antigos não respondem: quem paga as ferramentas e o que pode ser enviado a elas. A portaria tratou disso num item novo, o 11.3, voltado ao desenvolvimento de software assistido por IA.

O texto exige que o termo de referência traga as regras, os limites e as responsabilidades desse uso; que atribua de forma clara e objetiva quem arca com os custos das ferramentas de IA; e que os aspectos de privacidade e segurança da informação sejam definidos antes, de forma expressa. Note que a portaria não diz quem deve pagar. Ela diz que o contrato precisa dizer.

Traduzido para uma empresa privada, são quatro cláusulas: se a fornecedora pode usar IA no código do seu produto; quais ferramentas e em que conta (a dela ou a sua); quem paga licenças e consumo; e o que nunca pode sair do ambiente controlado, como dados de clientes, credenciais e trechos de código que você considera segredo do negócio. A titularidade do que for gerado deve seguir a mesma regra do resto do código, e isso também precisa estar escrito, como explicamos no artigo sobre registro de software e quem é o dono do código encomendado.

O que precisa constar no contrato com uma fábrica de software?

Da portaria dá para extrair um roteiro curto, sem a burocracia da licitação. Ele não substitui a revisão de um advogado, mas evita que as decisões importantes fiquem para depois da assinatura.

1. Contra o que cada pagamento é liberado

Escreva se o valor depende de entrega aceita, de nível de serviço ou de tamanho medido. Se for por equipe, diga o que acontece quando um profissional falta ou é trocado no meio do ciclo.

2. Os perfis e a senioridade de cada um

Proposta de squad sem perfil nominal é proposta de preço sem conteúdo. Peça a composição, compare com a tabela de referência e combine prazo para repor alguém que sair.

3. Quem é o dono do produto

Nomeie a pessoa da sua empresa que prioriza o backlog e aceita as entregas, e o tempo semanal que ela vai dedicar. Se ninguém tem esse tempo, o problema não é de fornecedor.

4. Os critérios de aceite e de qualidade

A portaria cita indicadores como qualidade do código e cobertura de testes. No privado, defina pelo menos o que conta como pronto, quais testes são obrigatórios e quem roda a verificação.

5. As regras de uso de IA

Ferramentas permitidas, conta usada, quem paga e o que é proibido enviar. Sem isso, a decisão fica com cada desenvolvedor, todo dia.

6. Titularidade, código-fonte e saída

De quem é o código, onde fica o repositório, quem tem as credenciais e como é a transição se o contrato acabar. É a cláusula que ninguém lê até o dia em que precisa.

7. A separação entre construir e sustentar

Desenvolvimento e sustentação pedem formas diferentes de cobrar. Separe as duas partes no contrato, mesmo que a fornecedora seja a mesma.

Quais os erros mais comuns ao contratar uma fábrica de software?

• Comprar horas e esperar produto. Contratar por tempo sem dizer o que precisa sair no fim de cada ciclo transfere todo o risco para a contratante.
• Deixar o backlog com a fornecedora. É a forma mais rápida de transformar um MVP em um projeto sem fim, porque ninguém de dentro diz o que fica de fora.
• Comparar propostas só pelo valor mensal. Duas propostas de squad com o mesmo preço podem ter senioridades muito diferentes. Sem a composição, a comparação não existe.
• Misturar construção e sustentação. Um valor fixo pensado para manter sistemas não serve para construir um produto novo, e o inverso também não.
• Não falar de IA. Não proibir nem permitir é permitir tudo, inclusive enviar código e dados a ferramentas que você não escolheu.
• Começar a construir sem discovery. A fábrica executa bem o que foi decidido. Se nada foi decidido, ela executa bem a coisa errada.

Como medir se a fábrica de software está entregando?

A portaria organiza a medição por indicadores de nível de serviço, alguns com meta explícita, como qualidade do código igual ou superior a 90%. Para um projeto privado, não é preciso copiar metas de contrato público; é preciso ter algumas medidas combinadas antes e revistas a cada ciclo.

1. Entregas aceitas por sprint, e quantas foram recusadas ou aceitas em parte, com o motivo.
2. Qualidade do código, medida por ferramenta e critério definidos pela contratante, não pela fornecedora.
3. Cobertura de testes nas partes críticas do produto.
4. Rotatividade da equipe: a portaria passou a acompanhar desligamentos nas sprints rejeitadas, porque troca de gente costuma aparecer como queda de entrega.
5. Satisfação do dono do produto, registrada a cada ciclo, de forma simples e comparável.
6. Resultado do produto: no caso de MVP, o sinal de uso real que motivou o projeto. É a única medida que a fábrica não controla sozinha, e por isso é a mais honesta.

Por onde começar quando o projeto é um MVP?

Antes de pedir proposta, decida o que será construído e o que fica de fora. O artigo sobre discovery de produto e o que ele entrega antes do código mostra como chegar a esse escopo, e o texto sobre o critério de parada do produto mínimo viável trata do que combinar para saber quando o MVP terminou.

Depois, nomeie o dono do produto dentro da empresa, escolha o modelo de cobrança pelo tipo de trabalho e escreva as regras de IA antes da primeira sprint. Na Alliance, o desenvolvimento de MVP é organizado por fases com portões de decisão: a empresa investe na validação antes de investir na construção, e a decisão de seguir é sempre dela.

Se o produto faz parte de um plano de crescimento maior, vale olhar o conjunto antes de olhar o código. O diagnóstico de marketing gratuito da Alliance mostra onde estão as lacunas de aquisição, conversão e retenção, e ajuda a decidir se o próximo investimento é mesmo em software.