Na era da IA, o desafio não é só escolher a métrica. É garantir uma unidade comum para comparar produtividade, custo e valor no software.
Um quilômetro é um quilômetro.
Não importa se você percorreu de carro, moto, bicicleta ou a pé. Não importa quanto tempo levou, quanto combustível gastou ou quão boa era a estrada.
A distância continua sendo um quilômetro.
E é justamente porque concordamos sobre essa unidade que conseguimos fazer outras perguntas.
Quantos quilômetros percorremos por hora? Quanto gastamos por quilômetro? Quanto combustível consumimos?
O quilômetro não mede velocidade, eficiência ou valor.
Ele oferece uma referência estável para que essas relações possam ser construídas.
Talvez esteja faltando algo parecido em parte da discussão sobre produtividade no desenvolvimento de software.
E a Inteligência Artificial está tornando essa falta cada vez mais evidente.
A IA aumentou a produtividade. Mas aumentou em relação a quê?
Estamos cercados por números sobre os ganhos proporcionados pela IA: 20%, 30%, duas vezes, cinco vezes.
Mas existe uma pergunta anterior:
mais do quê?
Mais linhas de código? Mais commits? Mais tickets? Mais histórias? Mais Story Points?
Uma pessoa usando IA pode escrever muito mais código. Isso significa necessariamente produzir mais software?
Um time pode fechar mais histórias porque passou a quebrá-las em partes menores. Isso prova aumento de produtividade?
E 100 Story Points de um time dificilmente significam exatamente o mesmo que 100 Story Points de outro.
Se não temos uma unidade suficientemente estável para representar aquilo que foi entregue, fica difícil até afirmar que ficamos mais produtivos.
Talvez tenhamos passado tempo demais procurando amétricaperfeita, quando existe uma pergunta mais básica:
qualéa nossa régua?
A régua não precisa explicar tudo
Ao longo do tempo usamos horas, linhas de código, Function Points, Story Points, throughput, lead time, métricas DORA (DevOps Research and Assessment), defeitos e inúmeras outras formas de observar software.
Precisamos de muitas delas.
O problema aparece quando esperamos que uma única medida responda perguntas diferentes.
DORA ajuda a entender o sistema de entrega. Lead time ajuda a observar fluxo.
Defeitos ajudam a avaliar qualidade.
Custo ajuda a entender eficiência econômica.
Outcomes ajudam a avaliar resultado.
Mas antes de relacionar todas essas dimensões, existe uma pergunta importante:
quanto de software, ou de complexidade funcional, atravessou esse sistema?
Sem algum denominador comum, podemos acabar comparando números que parecem equivalentes, mas representam coisas diferentes.
É como comparar o consumo de dois carros sabendo quantos litros cada um gastou, mas sem saber quantos quilômetros percorreram.
Falta a régua.
A régua não precisa medir produtividade
Essa distinção, para mim, é central.
A régua não precisa medir produtividade. Ela precisa permitir que produtividade seja medida.
Um quilômetro não mede velocidade.
Mas quilômetros divididos por horas permitem calcular velocidade.
Da mesma forma, uma unidade consistente de tamanho ou complexidade do software pode permitir relações como:
unidades / tempo → produtividade ou capacidade custo / unidade → eficiência econômica
defeitos / unidade → qualidade normalizada esforço humano / unidade → alavancagem humana custo de IA / unidade → eficiência da automação resultado / unidade → efetividade
A discussão deixa de ser encontrar uma métrica capaz de explicar tudo.
Passa a ser construir um sistema de métricas sobre uma referência comum.
E a IA torna isso ainda mais importante
Imagine uma demanda que hoje exige cinco pessoas durante duas semanas.
Algum tempo depois, usando copilots, automações e agentes, a mesma demanda pode ser resolvida por duas pessoas em poucos dias.
Mudaram o esforço, o tempo, o custo e a composição do sistema de produção.
Mas o tamanho do problema não deveria mudar simplesmente porque encontramos uma maneira melhor de resolvê-lo.
Em um exemplo hipotético, se antes tínhamos:
100 unidades → 1.000 horas humanas
e depois:
100 unidades → 350 horas humanas + IA
agora temos uma base muito mais consistente para discutir produtividade. A entrega permaneceu comparável.
O sistema que a produziu é que mudou.
Quanto mais variável se torna a forma de produzir software, mais importante se torna alguma estabilidade na forma de medir aquilo que foi produzido.
Então qual régua usar?
É aí que surgem Function Points, COSMIC, Business Complexity Points (BCP) e outras abordagens.
Antes de seguir, vale uma transparência.
Minha relação com o BCP começou antes de eu fazer parte da CI&T. Tive contato com a abordagem há muitos anos e, hoje, acompanho mais de perto sua evolução.
E talvez justamente por isso eu considere importante não começar pela pergunta “por que usar BCP?”.
Minha proximidade com a abordagem poderia me levar a escrever um artigo defendendo sua utilização. Mas acho que existe uma discussão anterior, e mais importante:
por que precisamos de uma unidade comum de medida e como decidir qual régua faz sentido para cada contexto?
Function Points traz décadas de utilização, padronização e uma base relevante de benchmark.
COSMIC oferece uma abordagem funcional bastante aderente a arquiteturas modernas e também possui padronização internacional.
BCP foi concebido buscando aproximar a medição da linguagem de negócio e do fluxo cotidiano de desenvolvimento e, hoje, traz uma característica particularmente relevante para esta discussão: a possibilidade de automatizar sua medição a partir do backlog.
São propostas diferentes, com vantagens, limitações, níveis de maturidade e custos distintos.
Por isso, talvez a pergunta não deva ser:
qual é a melhor régua?
Mas:
quais propriedades essa régua precisa ter para o problema que queremos resolver?
O que uma boa unidade de medida de software deveria oferecer?
Para funcionar como referência, uma unidade deveria ser, no mínimo:
Consistente.A mesma coisa medida novamente deveria produzir resultados suficientemente próximos.
Comparável.Deveria permitir observar períodos, times e, quando fizer sentido, fornecedores diferentes.
Independente de quem executa. A complexidade da demanda não deveria mudar porque foi executada por três pessoas, uma pessoa com copilots ou um conjunto de agentes.
Poucodependentedatecnologia.Mudar linguagem, framework ou arquitetura não deveria destruir a série histórica.
Auditável.Precisamos conseguir compreender por que determinada entrega recebeu aquela medida.
Simples o suficiente para ser usada.
E hoje acrescentaria uma característica que ganha muito mais importância com IA:
Automatizável.
Porque uma metodologia pode ser tecnicamente excelente, mas, se medir custa tanto que ninguém mede, dificilmente se tornará uma boa régua organizacional.
A própria IA pode reduzir o custo da régua
Existe uma ironia interessante nisso.
A mesma IA que torna urgente rever como medimos software também começa a reduzir o custo dessa medição.
BCP já possui automação baseada em IA. No caso do COSMIC, também existem iniciativas de automação com LLMs capazes de estimar o tamanho funcional a partir de requisitos em linguagem natural. Outras metodologias, como Function Points, também vêm sendo exploradas em processos de automação, mas o nível de maturidade e implementação varia.
Isso nos permite imaginar um fluxo bastante diferente do processo tradicional: Uma história entra no backlog.
Um agente interpreta seu conteúdo. Propõe uma medida.
Apresenta sua decomposição e seu nível de confiança. Casos mais simples seguem automaticamente.
Casos ambíguos passam por revisão humana.
E aquela unidade acompanha a demanda durante seu ciclo de vida.
Nesse cenário, medir deixa de ser uma atividade paralela feita de tempos em tempos.
A régua pode passar a fazer parte da própria telemetria da engenharia.
Talvez isso mude significativamente a viabilidade de algo que durante anos foi visto como burocrático ou caro demais para ser aplicado continuamente.
Mas existe um custo da régua
E ele também precisa fazer parte da decisão. Não apenas o preço de uma licença.
Existe um custo total de manter a medição funcionando: infraestrutura, consumo de IA, integração, qualidade dos requisitos, especialistas, revisão humana, governança e manutenção da própria metodologia.
Uma régua extremamente sofisticada, mas cara e lenta para utilizar, pode acabar produzindo menos valor do que outra suficientemente boa e aplicada consistentemente em milhares de entregas.
Por isso, talvez uma das perguntas mais pragmáticas seja:
qual régua conseguimos sustentar ao longo do tempo?
Escolher importa. Manter a escolha importa ainda mais.
Não acredito que todas as organizações precisem adotar a mesma unidade. Software não é uma distância física.
Uma empresa pode escolher Function Points. Outra pode optar por COSMIC.
Outra pode encontrar maior aderência em BCP.
A decisão pode depender de arquitetura, governança, necessidade de benchmark, modelo contratual, maturidade dos dados, custo de medição e objetivo de negócio.
O ponto central começa depois da escolha.
Se queremos comparar evolução, precisamos preservar a referência.
Não faz sentido mudar a unidade quando muda o resultado que queremos demonstrar. Não faz sentido comparar fornecedores usando réguas diferentes.
E não faz sentido anunciar ganho de produtividade provocado por IA se a definição do que chamamos de “entrega” também mudou no caminho.
Talvez essa seja uma discussão econômica, não apenas técnica
Durante muito tempo conseguimos conviver com uma aproximação razoável entre pessoas, esforço e produção.
Contratávamos FTEs. Estimávamos horas. Organizávamos capacidade.
Mesmo conhecendo as limitações, havia alguma relação entre quantidade de pessoas, tempo disponível e capacidade produtiva.
A IA começa a desmontar essa aproximação.
Quando pessoas, copilots e agentes passam a produzir juntos, o esforço humano deixa progressivamente de representar capacidade produtiva.
E então surgem perguntas maiores:
Como comparar fornecedores? Como demonstrar o retorno da IA?
Como sair de modelos baseados em hora ou FTE? Como saber se um time realmente ficou mais eficiente?
Como definir preço quando trabalho humano deixa de ser a principal variável de produção?
Para responder, precisaremos continuar olhando para fluxo, qualidade, custo e valor. Mas talvez precisemos, antes de tudo, de algo surpreendentemente simples:
uma régua.
Não necessariamente universal.
Não necessariamente a mais sofisticada. Muito menos perfeita.
Uma régua adequada ao contexto, suficientemente estável, comparável e economicamente viável para ser usada de forma consistente.
Porque, antes de afirmar que estamos 30%maisrápidos,duasvezesmaiseficientes ou cinco vezes mais produtivos, existe uma pergunta que precisamos conseguir responder:
estamos comparando usando a mesma régua?
Talvez não precisemos da régua perfeita.
Precisamos escolher uma. E continuar medindo com ela.
Referências para aprofundamento
- Métricas DORA (DevOps Research and Assessment) : https://dora.dev/guides/dora-metrics
- Function Points: https://ifpug.org/ifpug-standards/fpa
- COSMIC: https://cosmic-sizing.org/publications/measurement-manual-v4-0-2/? | https://cosmic-sizing.org/2026/04/30/31737/
- BCP (Business Complexity Points): https://ciandt.com/us/en-us/complexitypoints | https://ciandt.com/us/en-us/business-complexity-points-ciandt-itau| https://github.com/flow-ciandt/bcp-agent | https://itforum.com.br/noticias/cit-e-itau-lancam-software-ia/
