Ao negociar projetos de software personalizado, a unidade mais comummente alinhada entre as partes A e B é o «homem‑dia» : quantos engenheiros, por quantos dias, e qual o preço unitário. Esse modelo funciona bem quando os requisitos são estáveis e os limites de entrega estão claros; porém, assim que as regras no local mudam frequentemente, as ferramentas de IA elevam a eficiência da codificação, e a parte A continua a avaliar com base na «soma de cabeças», as contradições acabam surgindo — a parte B sente que os requisitos se expandem, enquanto a parte A acha que «não aumentou o número de pessoas, mas não há mais resultados».
Sinal político: do vender cabeças ao vender resultados
Em setembro de 2026, o Ministério da Indústria e Tecnologia da Informação publicou o «Plano de Implementação da Campanha Especial “IA + Software”», que menciona diversas vezes a promoção da transformação dos modelos de produção de software, o desenvolvimento de «Modelo como Serviço» e «Agente como Serviço», além de estabelecer claramente que, até 2028, serão criadas aplicações‑referência de software baseadas em agentes nos setores-chave. O documento não descarta o desenvolvimento sob medida, mas transmite uma direção clara: para avaliar o valor do software, cada vez mais se considera a eficácia real, e não apenas o número de homens‑dias investidos .
Para empresas que estão implementando ERP, MES, CRM ou sistemas de gestão setorial, isso significa que, se o contrato ainda especificar apenas «XX pessoas × XX dias», após a implantação será fácil cair na disputa de «o código foi concluído, mas o negócio não consegue utilizá‑lo». Uma forma mais sustentável de redigir é dividir a entrega em resultados operacionais verificáveis .
Lógica de negócio: os marcos devem ser mais específicos do que os homens‑dias
Ao atualizar o projeto de «pagamento por etapa» para «pagamento por marco», cada marco deve atender simultaneamente a quatro condições:
- Cenário de negócios : quem está utilizando e que operação está resolvendo (por exemplo, «o controlador de estoque escaneia para entrada no estoque» em vez de «concluir o módulo de entrada no estoque»).
- Escala de dados : quais dados mestres, campos de status e escopos de permissão estão envolvidos, e quais são as regras de amostragem.
- Roteiro de aceitação : com dados de teste fornecidos, quais processos devem ser executados e quais documentos ou relatórios devem ser gerados.
- Tratamento de exceções : como o sistema informa em caso de falha, quem tem autorização para fazer alterações e se há registro de mudanças.
Os marcos não devem exceder 2–4 semanas cada um; se forem muito longos, voltaremos ao «desenvolvimento em caixa‑preta». Exemplo típico de divisão: dados mestres e permissões → ciclo fechado de documentos essenciais → relatórios e reconciliação → interfaces e mudança de produção.
Lógica de design: escopo, mudanças e «assistência inteligente» devem constar do contrato
A codificação assistida por IA, a geração automática de casos de teste e a complementação inteligente de documentos alteram o consumo de homens‑dias para a mesma funcionalidade, mas não modificam automaticamente a complexidade do negócio . Recomenda‑se incluir separadamente no contrato e nas especificações de requisitos:
- Linha de base do escopo (Baseline) : lista de funcionalidades + lista do que está fora do escopo (Out of Scope); qualquer mudança deve ser registrada em formulário de alteração.
- Regras de precificação de mudanças : novos marcos devem ser avaliados com base em «cenário + roteiro de aceitação», em vez de adicionar homens‑dias de forma improvisada.
- Limites da assistência inteligente : em quais etapas a IA pode melhorar a eficiência (geração de código, rascunhos de documentos), e em quais é necessário assinatura humana (segurança, conformidade, compromissos externos).
- Propriedade do conhecimento acumulado : quem detém os documentos do processo, as configurações e os scripts, evitando lacunas na manutenção após a entrega.
Implementação do desenvolvimento: automação e observabilidade na aceitação
Para tornar a «orientação por resultados» viável, o lado técnico deve colaborar em três pontos:
- Inclusão de casos de aceitação no banco de dados : cada marco corresponde a um conjunto de casos automatizados ou semi‑automatizados, permitindo repetição dos testes.
- Isolamento de ambiente e dados : os dados do ambiente UAT podem ser redefinidos, evitando que «apenas funcione no ambiente de demonstração».
- Logs observáveis : operações-chave possuem registros de auditoria, permitindo rastrear quem alterou o quê em caso de controvérsia.
Se o projeto inclui agentes ou motores de regras, a aceitação deve acrescentar um mecanismo de inspeção aleatória : inserir casos de limite aleatoriamente, verificar se a recusa de resposta, a escalada para humanos e o bloqueio de permissões estão de acordo com o design, em vez de apenas verificar se «consegue conversar».
Três tipos comuns de controvérsias e suas prevenções
Controvérsia nº 1: «Todas as funcionalidades foram feitas, por que o negócio não usa?» — Prevenção: vincular os marcos às operações de cargo e aos registros de treinamento; durante a aceitação, realizar visitas in loco, não apenas apresentar PPT.
Controvérsia nº 2: «Por que cobrar extra por uma pequena demanda adicional?» — Prevenção: registrar no formulário de alteração os marcos afetados, os roteiros e o prazo, e só iniciar o desenvolvimento após ambas as partes assinarem.
Controvérsia nº 3: «A IA aumentou a eficiência, podemos reduzir os homens‑dias?» — Prevenção: o contrato distingue entre «custo de implementação» e «complexidade do negócio»; os ganhos de eficiência podem ser refletidos no preço total ou no período, mas os padrões de aceitação não devem ser reduzidos.
Recomendação piloto: começar com um módulo em ciclo fechado
Não é preciso esperar que todo o sistema reescreva o contrato. Escolher um módulo que possa fechar o ciclo em 2–3 semanas (como entrada e saída de estoque, registro de trabalho ou aprovação de despesas), usar um novo modelo para assinar um acordo complementar: listar cenários, roteiros, exceções e etapas de pagamento. Depois de testar, expandir para todo o projeto. Para avaliar o sucesso, observar se o número de casos de alteração diminuiu, reduzindo o tempo de discussão , e se a taxa de aprovação única do UAT aumentou , em vez de contar quantos homens‑dias a parte B deixou de reportar. Se o módulo piloto for bem escolhido, a reformulação do contrato para todo o projeto terá maior credibilidade. Os homens‑dias não desaparecem da noite para o dia, mas estão passando de «única unidade de precificação» para «referência de estimativa de custos». Incluir marcos e roteiros de aceitação no contrato é o básico para que o software personalizado continue a entregar resultados confiáveis no contexto de «IA + Software».
Os homens‑dias não desaparecem da noite para o dia, mas estão passando de «única unidade de precificação» para «referência de estimativa de custos». Incluir marcos e roteiros de aceitação no contrato é o básico para que o software personalizado continue a entregar resultados confiáveis no contexto de «IA + Software».
Compatibilidade com preço fixo e iteração ágil
A aceitação por marco não exclui a agilidade: cada Sprint ainda pode entregar incrementos demonstráveis, mas o pagamento e a aceitação formal ficam vinculados a um marco maior. Nos contratos de preço fixo, é especialmente importante especificar o «ponto de congelamento do escopo» — após qual revisão as novas demandas devem seguir o formulário de alteração, evitando adições verbais de funcionalidades. Para módulos que incluem agentes, recomenda‑se realizar a aceitação por marco separadamente, avaliando a «versão das regras + taxa de aprovação da inspeção», sem vincular tudo à implantação geral do site.
Dados setoriais mostram que cerca de um terço dos projetos de software falham devido à falta de clareza nos requisitos e na escala de aceitação, e não propriamente pela execução técnica. Primeiro escrever no contrato «o que significa estar concluído» é mais valioso do que discutir se a IA substituiu alguns programadores. Na próxima revisão de projeto, pode‑se começar perguntando: se amanhã toda a equipe da parte B tirar férias, poderemos, com base no roteiro, determinar se o marco atual atingiu os padrões — se não for possível responder, significa que a aceitação ainda não está clara. Incluir marcos no contrato não é dificultar a parte B, mas permitir que ambas as partes discutam na mesma página se «está concluído ou não». Quanto mais evidente for a eficiência da IA no projeto, mais importante é esclarecer isso desde o início.