Problemas de contratação de software na AP (referência) (S)

Nas instituições públicas, o problema central não é apenas “desenvolver software”, mas contratar, governar e medir software sob amarras de orçamento anual, alta rotatividade de gestores, rigidez procedimental, dependência de fornecedores e forte controle externo. No âmbito do SISP, o modelo hoje obrigatório para desenvolvimento, manutenção e sustentação de software é o da Portaria SGD/MGI nº 750/2023, já alterada em 2024 e 2025, e ele admite quatro modalidades padronizadas de remuneração: Pontos de Função + Horas de Serviço Técnico, valor fixo por sprint executada, alocação de profissionais de TI e valor fixo mensal por portfólio de softwares, com preferência por métodos ágeis e exigência de medição por resultados e níveis mínimos de serviço. A IN SGD/ME nº 94/2022, por sua vez, reforça que o pagamento deve estar ligado a resultados e produtos entregues, e não ao simples rol de atividades executadas. (Serviços e Informações do Brasil — Governo Digital)

Em termos práticos, as formas mais comuns dos últimos anos podem ser agrupadas assim:

Fábrica de software / métrica funcional: historicamente muito usada para desenvolvimento evolutivo e manutenção.
Esquadrões ou times ágeis remunerados por sprint: cresceu com a adoção de métodos ágeis.
Alocação de perfis profissionais: analista, desenvolvedor, arquiteto, tester, UX etc., em arranjos próximos de squad.
Sustentação por valor fixo mensal: mais usada quando já existe parque de sistemas e a demanda é continuidade, correção, ajustes e operação funcional. Isso está alinhado ao modelo padronizado vigente do SISP. (Serviços e Informações do Brasil — Governo Digital)

O histórico de fiscalização do TCU mostra que a APF já enfrentava problemas recorrentes justamente na eficácia e eficiência do modelo de contratação de desenvolvimento e manutenção de sistemas informatizados. Em outras palavras: o problema é estrutural e antigo, não pontual. (Portal TCU — Contratação de sistemas informatizados é fiscalizada pelo TCU)

1) Problemas típicos da contratação por fábrica de software / Pontos de Função

Problema: o contrato mede “tamanho funcional”, mas a necessidade real do órgão costuma envolver também arquitetura, UX, segurança, integração, DevOps, automação de testes, refatoração e sustentação contínua. Isso cria distorção: o fornecedor tende a otimizar o que é medido, e não necessariamente o que gera valor público.

Causas conhecidas:

escopo mal levantado no ETP/TR;
baixa maturidade do órgão em métricas funcionais;
conflito sobre contagem e glosas;
foco excessivo em volume produzido, com menor peso para qualidade;
dificuldade de adaptar PF a contextos muito ágeis, APIs, microsserviços e modernização arquitetural. A própria Portaria 750/2023 reconhece a necessidade de complementar PF com HST e de vincular remuneração a resultados e NMS. (Serviços e Informações do Brasil — Governo Digital)

Efeitos mais comuns:

discussões intermináveis sobre medição;
judicialização ou conflito administrativo sobre glosas;
entrega funcionalmente “contável”, mas tecnicamente fraca;
incentivo a aumentar contagem em vez de simplificar solução;
backlog cresce, mas dívida técnica também.

Mitigação adequada:

usar PF apenas onde a métrica realmente faz sentido;
complementar com HST para itens técnicos não capturados pela métrica;
definir NMS de qualidade, prazo, produtividade e desempenho do produto;
automatizar a evidência de qualidade com ferramenta sob controle do órgão, não da contratada;
usar auditoria de medição independente em amostras críticas. A Portaria 750 exige que os indicadores sejam objetivos, preferencialmente automatizados, e veda aferição baseada exclusivamente em dados fornecidos pela própria contratada. (Serviços e Informações do Brasil — Governo Digital)

Custo típico de mitigação:

baixo a médio: cerca de 1% a 3% do valor anual do contrato em ferramenta, calibração e amostragem independente;
médio: mais 1 a 2 perfis internos ou de apoio para gestão de backlog, aceitação e medição;
quando a casa não tem histórico nem método, o custo inicial pode subir para 3% a 6% no primeiro ciclo.

2) Problemas típicos da contratação por sprint

Problema: o contrato usa linguagem ágil, mas o órgão continua operando com lógica documental, aprovação em cascata e baixa disponibilidade do demandante. Resultado: a sprint vira apenas “lote quinzenal de tarefas”, sem real agilidade.

Causas conhecidas:

backlog mal formado;
Product Owner fraco ou inexistente;
ausência de visão de produto;
planejamento insuficiente antes de iniciar o projeto;
critérios de aceite subjetivos;
pressão para contratar “velocidade” sem contratar capacidade de decisão do lado do órgão. A Portaria 750 exige fase inicial de planejamento do produto, backlog do produto, critérios objetivos de aceitação/rejeição e desestimula sprints artificiais que sejam meros checkpoints. (Serviços e Informações do Brasil — Governo Digital)

Efeitos mais comuns:

sprint aceita sem valor real entregue;
retrabalho alto;
oscilação grande de produtividade;
discussões sobre o que estava ou não “dentro” da sprint;
projeto parece andar, mas o produto não amadurece.

Mitigação adequada:

discovery inicial obrigatório;
backlog priorizado por valor e risco;
Definition of Ready e Definition of Done contratuais;
aceite com indicadores objetivos: cobertura funcional, testes automatizados, qualidade de código, aderência arquitetural e segurança;
ferramenta única de gestão sob domínio do contratante. A Portaria 750 traz exatamente esses eixos de medição. (Serviços e Informações do Brasil — Governo Digital)

Custo típico de mitigação:

2% a 5% do contrato em governança de produto, ferramentas e ritos;
necessidade de 1 PO forte, 1 líder técnico/arquitetural e apoio de fiscalização;
em órgãos muito imaturos, a mitigação pode custar 5% a 8% no primeiro ano, porque exige mudança de processo, não só de contrato.

3) Problemas típicos da alocação de profissionais / squads por perfil

Problema: esse modelo resolve parte da flexibilidade, mas aproxima perigosamente o contrato de terceirização de mão de obra, com risco de subordinação, pessoalização e confusão entre gestão contratual e gestão de equipe.

Causas conhecidas:

o órgão quer “ter pessoas” e não “receber resultados”;
ordens diretas a terceirizados;
escolha nominal de profissionais;
dependência de pessoas-chave;
retenção de conhecimento fora da instituição. A Portaria 750 é explícita ao vedar ingerência, subordinação, direcionamento de pessoas e desvio de função, embora permita fiscalização e intercâmbio de informações. (Serviços e Informações do Brasil — Governo Digital)

Efeitos mais comuns:

passivo trabalhista indireto/riscos de irregularidade;
baixa substituibilidade;
contrato gira em torno de pessoas específicas;
quando alguém sai, o serviço degrada fortemente;
o órgão perde autonomia tecnológica.

Mitigação adequada:

separar claramente gestão do contrato e gestão da equipe;
ordenar serviços por OS, metas e indicadores, nunca por comando pessoal;
exigir documentação viva, repositórios, padrões, pipeline e transferência contínua de conhecimento;
avaliar mensalmente profissionais por indicadores objetivos, não por afinidade;
prever substituição, carência e absorção controlada. A própria Portaria 750 recomenda avaliação objetiva e admite redimensionamento com base em produtividade e níveis mínimos de serviço. (Serviços e Informações do Brasil — Governo Digital)

Custo típico de mitigação:

3% a 7% do contrato em governança, documentação e transição;
custo indireto relevante de servidor/especialista interno para liderança técnica e fiscalização;
se o órgão hoje depende de pessoas “insubstituíveis”, o saneamento pode custar 6% a 10% no primeiro ano.

4) Problemas típicos da sustentação por valor fixo mensal

Problema: o contrato dá previsibilidade financeira, mas pode esconder baixa produtividade, fila opaca e mistura de sustentação com evolução. O órgão paga mensalmente e passa a ter dificuldade de provar se houve entrega proporcional.

Causas conhecidas:

catálogo de serviços fraco;
portfólio de sistemas mal inventariado;
mistura de corretiva, adaptativa, evolutiva e apoio operacional;
ausência de baseline de volume;
NMS pobres ou pouco auditáveis. A Portaria 750 determina que o órgão defina claramente o que está incluído no valor fixo mensal e que o adicional fora desse escopo seja remunerado por outra modalidade. (Serviços e Informações do Brasil — Governo Digital)

Efeitos mais comuns:

sensação permanente de backlog represado;
fornecedor prioriza “apagar incêndio”;
evolução estrutural nunca acontece;
o contrato fica barato no papel e caro na prática.

Mitigação adequada:

inventário e classificação do parque de sistemas;
catálogo e taxonomia de demandas;
separar sustentação de evolução relevante;
usar indicadores de prazo, reincidência, disponibilidade, defeito reaberto e satisfação do usuário;
prever revisão periódica do portfólio e faixas de complexidade.

Custo típico de mitigação:

1,5% a 4% do contrato em inventário, observabilidade e governança;
em parques muito desorganizados, há custo inicial de saneamento de 3% a 8%.

5) Problemas transversais, independentemente do modelo

a) Planejamento deficiente do ETP/TR
O contrato nasce ruim quando a necessidade não foi decomposta em produto, serviço, sustentação, integração, dados, segurança e operação. A IN 94/2022 e o modelo da Portaria 750 empurram a administração para planejar melhor, mapear riscos e alinhar pagamento a resultados. (Serviços e Informações do Brasil — IN 94/2022)

b) Fiscalização fraca
Sem ferramenta, linha de base e indicadores auditáveis, o órgão não consegue comprovar baixa performance nem defender glosas. A Portaria 750 recomenda automação da aferição e veda depender apenas de dados da contratada. (Serviços e Informações do Brasil — Governo Digital)

c) Dependência excessiva do fornecedor
Código, arquitetura, esteiras, documentação, segredos operacionais e conhecimento funcional ficam concentrados fora do órgão. Isso eleva custo de troca e enfraquece o poder de negociação.

d) Contratação sem capacidade interna mínima
Órgão sem PO, arquiteto, gestor técnico ou fiscal capacitado transfere a decisão material para o fornecedor. A norma já pressupõe participação qualificada do contratante no planejamento e na gestão do produto. (Serviços e Informações do Brasil — Governo Digital)

e) Confusão entre desenvolver software e contratar pessoas
Esse é um dos erros mais caros. Em software público, normalmente o problema não é falta de horas; é falta de direção, priorização e aceite técnico.

6) Causas-raiz mais frequentes

As causas mais recorrentes podem ser resumidas em oito grupos:

governança fraca do demandante;
baixa maturidade de requisitos e produto;
métrica de pagamento mal escolhida;
NMS e aceite subjetivos;
fiscalização sem automação nem histórico;
dependência técnica e documental do fornecedor;
mistura entre sustentação, evolução e operação;
pressão por contratar rápido sem preparar a gestão do contrato.

Isso é coerente com a lógica da IN 94/2022, com o desenho de gestão da Portaria 750/2023 e com a própria preocupação histórica do TCU com a eficácia e eficiência dessas contratações. (Serviços e Informações do Brasil — IN 94/2022)

7) Métodos de mitigação que mais funcionam

Os métodos que mais reduzem problema, na prática, são estes:

1. Escolher a modalidade certa para cada tipo de demanda
Não usar um único modelo para tudo. PF para tudo gera distorção. Sprint para tudo gera teatralização ágil. Alocação para tudo gera risco de subordinação. Sustentação fixa para tudo gera opacidade. A própria Portaria 750 admite combinar modalidades. (gov.br — Portaria 750/2023)

2. Estruturar uma célula mínima do lado do órgão
Normalmente: PO/negócio, liderança técnica/arquitetural, gestão contratual/fiscalização e apoio de segurança/qualidade quando necessário.

3. Medir resultado, não presença
Prazo, aceite, defeito reaberto, cobertura de testes, qualidade de código, disponibilidade, desempenho e aderência arquitetural. Isso está alinhado ao modelo de NMS da Portaria 750. (Serviços e Informações do Brasil — Governo Digital)

4. Automatizar evidências
Boards, pipeline, repositório, análise estática, testes, observabilidade e trilha de auditoria. Sem isso, o contrato vira narrativa.

5. Exigir transferência contínua de conhecimento
Não só ao final. Documentação viva, repositório institucional, padrões e shadowing reverso.

6. Fazer saneamento inicial do parque
Inventário de sistemas, criticidade, dívida técnica, integrações e passivos ocultos antes de dimensionar sustentação ou evolução.

8) Quanto custa mitigar de forma séria

Aqui não há valor normativo fixado em lei. O que existe são faixas gerenciais típicas. Em contratos de software público, uma mitigação séria costuma consumir algo assim:

Governança mínima do contrato: 2% a 4% do valor anual.
Ferramentas de gestão, qualidade e evidência: 0,5% a 2,5%.
Discovery, saneamento inicial e inventário: 2% a 8% no início.
Auditoria de medição/qualidade independente: 0,5% a 2%.
Transição e transferência de conhecimento: 1% a 4%.

Em contratos desorganizados, o custo total de mitigação no primeiro ano pode chegar a 6% a 12% do valor contratual. Parece alto, mas normalmente é menor que o custo de retrabalho, glosa litigiosa, atraso de entrega, dependência tecnológica e necessidade de relicitar sob crise.

9) Síntese objetiva

Se eu resumisse em uma frase: o fracasso mais comum não decorre da falta de contratação, mas da contratação de uma métrica inadequada sem capacidade interna de governá-la.

Em regra:

PF/fábrica falha quando mede volume e não valor.
Sprint falha quando há discurso ágil sem gestão de produto.
Alocação de perfis falha quando vira terceirização de mão de obra disfarçada.
Sustentação fixa falha quando o portfólio e o catálogo são opacos.

A melhor saída costuma ser um arranjo híbrido: produto e evolução por sprint ou combinação sprint + métricas objetivas, itens técnicos específicos por HST, e sustentação estável por valor fixo mensal com catálogo e NMS fortes. Isso é, inclusive, compatível com o desenho normativo atualmente adotado pelo SISP. (Serviços e Informações do Brasil — Governo Digital)

Voltar: Introdução ao framework