A impossibilidade de medir a produtividade da IA

Este é longo, desculpa. Já escrevi antes que tendo a escrever quando estou a tentar perceber uma coisa. Esta pergunta anda a chatear-me há algum tempo, e de cada vez que achei que lhe tinha respondido, encontrei mais um defeito na resposta.

Na Flowstate, perguntam-nos com regularidade como medir o retorno do investimento em IA. Umas vezes querem saber se as equipas estão mais produtivas. Outras vezes só precisam de algo credível para mostrar à administração quando ela pergunta pela fatura. Compreensível.

O meu interesse vai além de ter uma empresa que precisa de responder à pergunta. Acredito que a IA pode tornar as pessoas muito mais capazes, e gostava que fosse isso que estivéssemos a construir. Que os agentes tratem da porcaria repetitiva. Que as pessoas tenham mais tempo para o trabalho que realmente querem fazer, incluindo coisas que antes não podiam dar-se ao luxo de tentar.

É em boa parte esse o raciocínio por trás da Flowstate. Mas não posso presumir que está a acontecer só porque gosto da ideia.

Tenho andado a ler a The Humanist Review e, porra, há lá muito boa escrita. A sério, vai ver. O ensaio de Daron Acemoglu sobre a IA e o trabalho merece ser lido por inteiro, mas esta frase sobre o setor empresarial ficou-me na cabeça:¹

It will demand more pro-worker tools when it focuses on increasing productivity and innovation, rather than only labor cost-saving.

Acho que ele tem razão. Se defendo a IA só em termos dos salários que poderia substituir, não me posso admirar quando a conversa vira para cortar empregos. Preferia poder explicar o que a equipa consegue fazer agora e antes não conseguia. Ou se livrar-nos de um processo maçador melhorou mesmo o dia de trabalho de alguém.

O problema é demonstrá-lo. Alguém dizer que poupa uma hora por dia é interessante, mas eu continuo a querer saber o que mudou. Fez-se mais? Houve finalmente tempo para pensar em algo a sério? Talvez a ferramenta tenha poupado uma hora a uma pessoa e dado a outra uma hora de verificações.

Por isso comecei a procurar uma forma de comparar o trabalho que uma empresa faz com o que gasta a fazê-lo. Idealmente, algo útil entre equipas diferentes, quer o trabalho fosse feito por funcionários, prestadores, um fornecedor de serviços ou agentes. Não esperava que todos os departamentos tivessem a mesma ideia de sucesso. Esperava, isso sim, que nos pudéssemos entender sobre parte da contabilidade.

Acabei com uma abordagem que acho que vale a pena testar, e não com uma resposta que recomendaria a toda a gente. Várias das minhas primeiras ideias estavam erradas. Deixei lá os erros úteis, porque explicar porque falharam é provavelmente mais útil do que fingir que cheguei à versão atual por previsão excecional.

O primeiro problema é fácil de demonstrar: dá-se a um agente as perguntas de suporte mais simples, e as pessoas que ficam com as difíceis podem de repente parecer piores no que fazem.

Aparentemente, ajudar a equipa piorou tudo

Imagina uma equipa de suporte que trata 800 casos fáceis e 200 difíceis por mês. Um caso fácil exige seis minutos de tratamento humano. Um difícil exige trinta. Todos são resolvidos com o mesmo padrão.

São números inventados.

Antes da IA, esta equipa hipotética precisava de 180 horas de tratamento para os seus 1 000 casos. São 5,56 casos por hora.

Agora um agente trata 600 dos casos fáceis. As pessoas ficam com 200 fáceis e 200 difíceis: 120 horas para 400 casos, ou 3,33 por hora.

O dashboard mostra uma queda de 40% na taxa da equipa humana. O tempo médio de tratamento passa de 10,8 minutos para 18.

Ninguém ficou mais lento. As pessoas têm os casos mais difíceis. Os fáceis diluíam a média, e agora desapareceram.

A empresa continua a ter os 1 000 casos resolvidos e precisa de sessenta horas a menos de tratamento humano. Volto ao valor dessas horas mais à frente. Por agora, pedir à equipa que recupere a média antiga seria uma resposta bastante estúpida a uma mudança que fizemos de propósito.

Passa os casos fáceis a um agente

i

Fáceis, pessoasDifíceis, pessoasFáceis, agente

Casos fáceis que o agente resolve por mês600 de 800

Casos por hora humana

5,56 → 3,33

Horas humanas de tratamento

180 → 120

Entrega reconhecida

$7200 → $7200

Custo imputado ao tratamento

$7200 → $5280

Despesa real, folha de salários inalterada

$7200 → $7680

Os casos por hora humana descem 40%. Os mesmos 1000 casos continuam a ser resolvidos, e ficam 60 horas de tratamento livres para outra coisa.

Isto já acontecia antes dos chatbots. O Remote Encoding Center do Serviço Postal dos EUA trata imagens de moradas que as máquinas não conseguem decifrar. Um relato de 2022 descreve máquinas a ficar com as imagens mais fáceis e a deixar às pessoas as que demoravam mais a interpretar.² O vídeo do Tom Scott no centro continua a ser um dos meus exemplos preferidos de um sistema automatizado a mudar um processo de negócio, anos antes de alguém lhe chamar IA. A Intercom faz a mesma observação sobre a carga de casos humanos que sobra depois da automação do suporte.³

Há também boa investigação que usa precisamente a taxa que acabei de criticar. Em Generative AI at Work, Erik Brynjolfsson, Danielle Li e Lindsey Raymond reportam um aumento médio de 15% nos problemas resolvidos por hora. O assistente de IA deles ajudava as pessoas que atendiam clientes. Não ficava com uma fila separada de casos fáceis. Examinaram também a qualidade e a experiência de trabalhar assim.⁴

Não discordo de contar casos nesse cenário. Discordo de presumir que continuam comparáveis depois de mudar os casos que as pessoas recebem. «Casos por hora» pode ser útil. Precisa de uma descrição dos casos.

E mesmo no meu exemplo arrumadinho, um dia com menos perguntas fáceis pode ser um dia mais exigente. Nada na tabela nos diz se o trabalho melhorou.

O que estamos realmente a perguntar?

Entregámos mais? Gastámos menos recursos? O trabalho alcançou algo útil? As pessoas que o fizeram tiveram um dia melhor?

São perguntas diferentes. Fui culpado de tratar «produtividade» como se respondesse às quatro.

As contagens dizem-nos o volume. Os custos dizem-nos o que pusemos lá. O lead time diz-nos quanto tempo alguém esperou. A receita e a margem importam, mas não nos dizem o que aconteceu dentro de cada equipa. Nem um inquérito a perguntar às pessoas se se sentem mais rápidas.

A experiência da METR com programadores, no início de 2025, ilustra bem este último ponto, e de forma dolorosa. Programadores experientes, a trabalhar em repositórios open source que conheciam, demoraram 19% mais com as ferramentas de IA disponíveis. Depois, continuaram a estimar que as ferramentas os tinham tornado 20% mais rápidos.⁵ É um resultado daqueles programadores e daquelas ferramentas, não um veredicto sobre os agentes de programação em 2026. A atualização da METR de fevereiro de 2026 diz que as ferramentas mais recentes provavelmente ajudam mais, ao mesmo tempo que explica porque é que os efeitos de seleção tornam essa melhoria difícil de estimar.⁶

Há, inevitavelmente, um inquérito da McKinsey. Nos resultados de agosto de 2026, 80% dos inquiridos disseram que a IA melhorou a sua própria produtividade. Só 37% lhe atribuíram algum impacto nos lucros da empresa.⁷ Uma diferença útil para uma consultora ter encontrado. São também duas perguntas autorreportadas diferentes, por isso não podemos subtrair uma percentagem à outra e declarar o benefício em falta como roubado.

O framework SPACE ajudou-me a pôr uma fronteira na pergunta. Nicole Forsgren, Margaret-Anne Storey e os coautores defendem que a produtividade dos programadores não se deixa captar por uma única métrica ou dimensão.⁸ Concordo. Uma medida da eficiência da entrega ainda pode ser útil. Só tem de deixar de afirmar que descreve tudo o resto.

Vou chamar à proposta um índice de entrega uniformizado. Trata do trabalho entregue e dos recursos por trás dele. O resultado para o negócio e a experiência de fazer o trabalho precisam de evidência própria.

Experimentei os números que já tínhamos

Cada um parecia razoável até lhe dar um exemplo incómodo.

As tabelas não são razão para deitar fora todas as medidas existentes. Precisei de partes de várias. O que falhava sempre era o pressuposto de que uma só conseguia fazer o trabalho todo.

Testei os candidatos contra onze casos inventados, incluindo um agente a ficar com o trabalho fácil e uma equipa a dividir-se em duas. As minhas notas de trabalho têm os casos, os dados fictícios e os cálculos. Trata-as como um registo de como a ideia mudou, e não como onze testes a provar que a versão final funciona numa empresa.

Trabalho não é um ticket

A minha primeira definição era agradavelmente arrumada: contar o trabalho que alguém pediu e aceitou.

Infelizmente, a empresa que eu tinha descrito não existia.

Na Flowstate, o nosso Linear está quase sempre atrás do trabalho que realmente se faz. Não preciso de um estudo histórico sobre gestores de issues para reconhecer esse problema.

Um engenheiro repara em algo, discute, corrige e cria um ticket algures pelo caminho. Um cliente abre uma conversa na Intercom. Chega uma fatura. Um advogado dá aconselhamento numa chamada. O engenheiro de piquete investiga porque manter o serviço a funcionar já é responsabilidade dele.

Não tornamos o trabalho legítimo por o pôr atrás de um botão de aprovação. A pessoa que cria o registo também não é necessariamente quem precisava do trabalho.

O que tento contar é um entregável de negócio ou um serviço com um propósito, um âmbito e uma condição de conclusão que consigamos explicar. Um pedido pode estabelecer essas coisas. Um objetivo acordado, um problema de um cliente ou uma responsabilidade permanente também. Um engenheiro não devia precisar de outro departamento para encomendar a correção de uma vulnerabilidade antes de ela contar.

As definições vão diferir por função. Não vejo maneira de contornar isso.

Não são nomes alternativos para linhas numa base de dados. Uma alteração integrada pode estar incompleta. Uma fatura marcada como paga pode estar errada. Um cliente silencioso pode estar satisfeito ou completamente farto.

A evidência anda espalhada. Um incidente pode deixar uma conversa de suporte, uma issue de engenharia, três pull requests e um email de seguimento. Contar seis registos não estabelece seis produções. O process mining centrado em objetos é útil aqui porque representa eventos ligados a vários objetos de negócio.⁹ Ajuda a juntar os registos. Não decide como o incidente deve contar.

Se as empresas partilharão o contexto relevante, e se a IA o consegue interpretar de forma fiável, são problemas à parte. Deixo-os fora deste texto. Para a contabilidade, assume que conseguimos estabelecer um relato suficientemente bom do trabalho e dos seus custos, por revisão humana, por automação ou por ambas.

Mesmo assim fica uma pergunta difícil: dada a evidência, o que contamos? A falta de evidência deve deixar o trabalho por resolver, e não declará-lo sem valor. Caso contrário, estou a construir uma medida de quem escreve as notas de conclusão mais entusiasmadas.

Os contabilistas já passaram por aqui

O exemplo do suporte precisa de uma forma de distinguir seis minutos de trabalho de trinta. Esta parte, pelo menos, não é nova.

A ACCA descreve as horas padrão como uma forma de combinar produtos diferentes numa só medida de produção. Separa quanto se produziu, quanto da capacidade disponível se usou e com que eficiência.¹⁰ O ONS usa índices de atividade ponderados pelo custo para grande parte da produção dos serviços públicos.¹¹

Estou a pedir emprestada essa estrutura: contar as produções por tipo e depois usar pesos de referência estáveis para as somar. Dá-nos uma escala sem exigir que cada serviço interno tenha um preço de venda.

O ONS também serve de teste à minha ambição. Cerca de um terço da produção dos serviços públicos abrangida pela sua metodologia ainda usa uma convenção em que os recursos gastos são iguais à produção, o que torna a produtividade constante nessa parte.¹¹ Existir medição ponderada pelo custo não significa que alguém já tenha descoberto como medir todos os serviços.

Voltemos ao suporte. A uma taxa de trabalho de referência de $40 por hora, uma resolução fácil leva um peso de $4 e uma difícil leva $20. Multiplica cada contagem pelo seu peso e soma:

D = 800 × 4 + 200 × 20 = 7 200

(1)

Temos $7 200 antes do agente e $7 200 depois. O negócio recebeu as mesmas 800 resoluções fáceis e 200 difíceis. Torná-las mais baratas, 600 delas, não as faz desaparecer da produção.

Escrito em geral, fica assim:

D_t = Σ_k n_k,t s_k,b

(2)

D é a produção entregue, em dólares de custo de referência. n é a contagem de cada tipo e s é o seu custo de referência de ponta a ponta. t identifica o período que estamos a medir e b identifica o período de referência. A soma percorre os tipos de trabalho.

Esses dólares não são receita nem poupança. Servem para comparar quantidades de trabalho diferente com um único conjunto declarado de pesos.

Inicialmente tentei justificar o peso argumentando que o custo histórico era um piso para o valor. Uma empresa certamente não pagaria quatro horas por trabalho que vale menos de quatro horas?

Uma avaliação extremamente generosa da tomada de decisões nas empresas. As empresas compram o que não deviam, e investimentos sensatos podem falhar. O custo antigo diz-nos alguma coisa sobre a produção. Não prova quanto valia o resultado.

Num negócio real, o padrão abrangeria a mistura relevante de pessoas, ferramentas, agentes e serviços comprados. Onde tivermos estimativas de esforço por função que sejam credíveis, taxas de referência fixas evitam que o mesmo trabalho ganhe um peso maior só porque o fez uma pessoa mais cara. Um serviço comprado pode precisar, em vez disso, de um preço de referência comparável.

Os salários e as faturas reais pertencem ao lado do custo. O mesmo entregável delimitado devia ter o mesmo peso de produção em Londres e em Lisboa. Mudar de fornecedor também não o devia alterar.

As horas padrão podem funcionar onde fazem sentido. Mas um índice que cubra trabalho automatizado precisa de mais do que as horas humanas restantes, ou os seus pesos podem aproximar-se de zero à medida que a automação tem sucesso. Os custos de recursos de referência dão-nos uma base mais ampla.

E o período de referência não tem de ser anterior à IA. Tem de ter evidência utilizável. «Antes de alguém usar o ChatGPT» não vai continuar a ser uma data útil para sempre.

Isto não são só story points em dólares?

Pode ser. Primeiro, uma correção que já vi engenheiros, com razão, ficarem irritados por ter de fazer: story points não são horas. Destinavam-se a dimensionar o trabalho em relação a outro trabalho, por complexidade e incerteza, e é por isso que tantas equipas usam uma escala tipo Fibonacci. Os intervalos alargam à medida que a confiança desce. Converter pontos em horas nunca foi o objetivo.

O risco aqui é outro. Pegar nas estimativas da equipa, convertê-las em dólares e chamar objetivo ao resultado seria o mesmo palpite com melhor marca financeira.

O pedido de desculpa de Ron Jeffries por ter possivelmente inventado os story points tem graça, mas não responde a esta objeção.¹² Gergely Orosz descreve um programador a inflacionar estimativas quando a equipa começou a tratar os pontos do sprint como um teste de sucesso.¹³ Um sistema de custo de referência oferece a mesma tentação. Põe-se um peso maior no trabalho e a pontuação melhora.

O que quero é um padrão para uma classe de trabalho entregue, e não uma estimativa corrente de quão difícil esta tentativa em particular parece. Uma estimativa de planeamento pode subir quando encontramos um problema. O peso da produção não devia subir só porque demorámos mais. Se o âmbito mudou, temos de dizer o que mudou.

Construiria o padrão a partir de exemplos revistos de trabalho comparável e testá-lo-ia noutros exemplos. Fixa os pesos para a comparação. Regista as alterações, para que nem a equipa nem o seu gestor possam melhorar um resultado reportado aumentando-os depois.

Continua a haver juízo nisto. Que trabalhos pertencem ao mesmo grupo? O caso caro é um tipo de trabalho diferente, ou uma tentativa cara da mesma coisa? Um revisor tem de poder contestar tanto a categoria como o peso.

Até escolher a média importa. Uma mediana descreve um caso típico. Multiplicada pelo volume, não reproduz em geral o uso total de recursos numa carga de trabalho com cauda longa. Para um peso esperado de custo de recursos, começaria normalmente por uma média para uma classe bem definida e mostraria a dispersão. Não escolheria a estatística que desse melhor aspeto ao índice.

A IA poderia ajudar a sugerir pesos. O trabalho da Anthropic sobre a estimativa da duração de tarefas encontrou informação útil de ordenação, mas o Claude sobrestimava as tarefas curtas de software e subestimava as longas.¹⁴ Pôr os trabalhos mais ou menos na ordem certa não chega quando os seus pesos relativos determinam o resultado.

Um sistema de pontos poderia adotar controlos semelhantes. Não posso reclamar vitória por mudar o nome. O teste é se outra equipa consegue aplicar as definições e se um desacordo razoável muda a conclusão.

Se isso não se verificar, então sim, reinventei os story points em dólares.

Terminámos, ou só deixámos de falar nisso?

A Fin dá-nos um exemplo concreto útil. A Intercom conta as resoluções confirmadas e as presumidas, aquelas em que o cliente sai depois de uma resposta sem pedir mais ajuda. A documentação diz também que o valor cobrado é revertido se o cliente voltar à mesma conversa a pedir mais assistência.¹⁵

É uma regra de faturação clara. Deixa uma pergunta sobre os clientes silenciosos, mas é injusto discuti-la sem a regra da reversão. E as conversas encerradas por humanos merecem o mesmo escrutínio.

Para este índice, especificaria o que conta como conclusão para cada tipo de trabalho. Por vezes há uma aceitação explícita. Por vezes há um teste, um registo de pagamento ou prova de entrega. Por vezes só temos sinais indiretos e precisamos de mostrar essa incerteza. «Fechado» não pode resolver todos os casos.

O retrabalho também não é simples. Uma conversa reaberta pode ser uma resposta falhada ou uma pergunta nova. Uma reversão de código pode corrigir um defeito ou refletir uma decisão de produto que mudou. Uma disputa posterior não invalida automaticamente o aconselhamento jurídico que a precedeu.

Precisamos de uma regra para saber que correções revertem a produção anterior, em quanto, e quais pertencem a um âmbito novo. Usa-a para pessoas e agentes por igual. Compara trabalho que teve a mesma oportunidade de revelar defeitos, e revê o período original quando o crédito anterior já não se sustenta. Uma fila recém-fechada não devia parecer melhor só porque ninguém teve ainda tempo de se queixar.

A verificação também consome recursos. Os cenários de revisão e refação do GDPval mostram quanto a vantagem de custo aparente pode mudar quando se inclui a revisão por peritos. São cenários modelados, não poupanças observadas em empresas, e o artigo refere que não inclui custos equivalentes de revisão e falha para a referência humana.¹⁶ Queria ver o fluxo de trabalho inteiro com custos nos dois lados.

O planeamento expôs um erro diferente na minha versão anterior. Sugeri não dar crédito a um ciclo de previsão se os ajustes do planeador o piorassem. Isso confundia concluir o trabalho com obter um resultado favorável.

O forecast value added é útil para avaliar ajustes sobre observações comparáveis.¹⁷ Não é um interruptor universal que diga se o planeamento aconteceu. Uma previsão sólida pode cumprir o que lhe foi pedido e mesmo assim sair errada. Um bom aconselhamento jurídico pode travar um negócio. Uma experiência pode ser útil precisamente porque nos diz para abandonar o projeto.

Se a medida só reconhece boas notícias, vai deixar passar algum bom trabalho.

Quarenta rascunhos de quê?

Agora dá ao índice algum trabalho de marketing.

Uma equipa produzia quatro variantes de anúncio por semana. Cada uma levava duas horas, o que dá a cada uma um peso de referência de $80 à nossa taxa ilustrativa. A produção da semana era de $320.

Com IA produz quarenta. Aplica o peso a cada ficheiro gerado e a produção passa a $3 200, enquanto os resultados da campanha mal se mexem.

Inicialmente tratei isso como prova de que a medida estava estragada. Pode estar, mas não pela razão que pensei. Quarenta entregáveis distintos e comparáveis podem ser dez vezes a produção sem serem dez vezes mais úteis. Eu já tinha dito que não estava a medir valor, e depois esperei que o número o fizesse na mesma.

A outra pergunta é se aqueles quarenta ficheiros eram quarenta entregáveis. Podiam ser rascunhos usados para escolher o que entra numa experiência.

Para este exemplo, supõe que o serviço é uma experiência de campanha para um público especificado, com uma pergunta de teste definida e requisitos de reporte. Eu contaria essa experiência. Gerar quatro rascunhos ou quarenta não muda a unidade. A sua produção e seleção fazem parte do custo.

Se a equipa fizer outra experiência genuinamente distinta e de âmbito comparável, isso é mais produção. Chamar a dez variações do mesmo teste dez experiências não é. Precisaríamos da definição antes de ver o resultado, e não de uma explicação inventiva depois.

Noutro fluxo de trabalho, produzir variantes prontas a usar pode ser, em si, o serviço. Então as variantes individuais podem ser a unidade certa. É uma fronteira de reporte diferente, e eu não alternaria entre as duas consoante a que desse o número maior.

Tom Cunningham e Parker Whitfill, da METR, ajudaram a esclarecer porque é que a questão do valor continua separada. Distinguem o efeito da IA na mistura antiga de tarefas, na mistura nova e no valor produzido. Tornar algo barato muda aquilo que as pessoas escolhem tentar, além da rapidez com que acabam a carga de trabalho de ontem.¹⁸

Concordo em separar essas perguntas. Uma contagem de produção não se torna uma medida de valor só porque o trabalho era caro antes. Nem a aprovação de um gestor faz quarenta variantes quarenta vezes mais úteis do que uma.

O que acontece quando um passo desaparece?

O software quebra a contagem no sentido oposto.

Supõe que uma funcionalidade precisava de uma especificação de três horas, dez horas de implementação e duas horas de revisão. A $40 por hora, o custo de referência é $600.

Agora um agente consegue construir a mesma funcionalidade a partir do contexto já disponível. A utilização custa $25. A revisão humana demora três horas, o que representa $120 de esforço à nossa taxa. Os recursos modelados usados somam $145. Assume que a funcionalidade cumpre os mesmos requisitos e verificações de qualidade.

Se contar os passos do processo antigo, perco a especificação. A implementação e a revisão que sobrevivem têm pesos antigos que somam $480. Mas o negócio recebeu a funcionalidade inteira.

Contar passos perde 20% da produção porque um documento se tornou desnecessário. Contar a funcionalidade inteira mantém a comparação intacta.

Isto só funciona se o passo era mesmo desnecessário. Remover uma verificação de segurança ou largar um requisito mudaria o que foi entregue. «A mesma funcionalidade, com o mesmo padrão» está a fazer trabalho importante nessa frase.

«A funcionalidade inteira» também. Não pode significar tudo o que por acaso se chama pedido. Se dividires uma funcionalidade em três tickets, ela não devia receber três pesos de funcionalidade. Se juntares três funcionalidades genuínas num épico, duas não devem desaparecer.

Depois há os pais e os filhos. Se a funcionalidade de ponta a ponta já inclui design e revisão, não posso somar o peso da funcionalidade ao mesmo trabalho contado outra vez por essas equipas. Podemos atribuir contribuições dentro do total. Não podemos criar produção extra da empresa a passá-la de um departamento para outro.

Experimenta reorganizar o mesmo trabalho sem mudar o que se entrega. O total da empresa devia ficar onde está. Experimenta subcontratar parte dele. Mesmo teste.

Os projetos longos também exigem cuidado com o momento. Eu usaria comparações cumulativas ou marcos independentemente úteis cujos pesos somem o âmbito acordado. Caso contrário, meses de custo levam a um único pico enorme de conclusão, e um dashboard mensal passa a maior parte do ano a enganar.

Certo. O que conta como a mesma funcionalidade?

Fui bastante generoso comigo com aquela funcionalidade de quinze horas. Uma correção ortográfica e um sistema de faturação podem ambos chamar-se funcionalidade. Pô-los na mesma categoria levar-nos-ia de volta ao problema do suporte.

Escolhamos algo mais específico: uma exportação CSV do histórico de auditoria de um cliente. Um administrador de conta autorizado precisa de exportar oito campos especificados para um intervalo de datas escolhido. O briefing define os limites de volume e de tempo de resposta, os requisitos de exatidão e os controlos de acesso. Tem de funcionar no produto em produção.

Contaria uma capacidade de exportação entregue, desse âmbito. Não o botão, o endpoint, os testes e a documentação em separado. Nem contaria de cada vez que alguém descarregasse o ficheiro. Aqui estamos a medir a entrega de uma alteração, e não o funcionamento do produto depois.

Nesta empresa fictícia, suponhamos que encontramos cinco alterações anteriores de exportação de relatórios com âmbito de dados, comportamento de utilizador, limites de operação e requisitos de garantia comparáveis. Na mesma base de preços de referência, os seus custos de ponta a ponta foram $480, $560, $600, $640 e $720. A média é $600.

É assim que poderíamos construir o peso. Cinco números convenientes não provam que seja bom. O revisor tem de verificar o que tornava aqueles trabalhos comparáveis, em vez de simplesmente procurar a palavra «exportação». Depois testaríamos a classe e o seu peso noutro trabalho.

Agora temos uma definição com que discutir:

Repara que a classe não depende da implementação escolhida, do número de pull requests nem do salário do engenheiro. Estes podem afetar o custo sem mudar o que o negócio recebeu.

O fluxo de eventos é diferente. Muda o comportamento exigido. Precisaríamos de uma classe de referência adequada ou de outro tratamento explícito para esse âmbito, aplicado de forma consistente ao trabalho anterior e posterior. Não podemos inventar uma categoria «exportação muito complexa» depois de uma construção cara e atribuir-lhe mais produção.

E uma nova plataforma de reporte sem precedente credível? Não a forçaria nesta classe. Descreveria o seu âmbito, custos e marcos úteis, e mantê-la-ia fora desta série comparável até termos uma base para a incluir.

O custo dela tem de continuar visível. O relatório precisa de reconciliar o serviço medido com o trabalho não associado e o resto da despesa. Caso contrário, estaria a escolher os sucessos fáceis de classificar e a deixar todo o investimento incómodo noutro lado.

Esta é a parte mais difícil da proposta. Outro revisor pode rejeitar a classe de exportação ou o seu peso de $600. Pelo menos podemos localizar o desacordo e ver se outra escolha razoável muda a resposta.

Parte do trabalho de engenharia pode sustentar classes como esta. Parte pode não sustentar. Descobri-lo seria um resultado útil, mesmo que arruíne a minha esperança de um total para a empresa inteira.

As sessenta horas não saíram da folha de salários

Voltando ao suporte, e à poupança que fiquei tentado a reportar.

Originalmente, 180 horas de tratamento a $40 davam $7 200. Depois, 120 horas dão $4 800. Soma uma taxa ilustrativa do agente de $0,80 por cada uma das suas 600 resoluções e o custo de tratamento imputado é $5 280.

São menos $1 920. Só que as pessoas continuam empregadas nas mesmas condições.

Supõe que a folha de salários neste exemplo simplificado se mantém em $7 200. Soma a fatura do agente de $480 e a empresa gasta $7 680. A necessidade de tratamento desceu. A fatura subiu.

Robert Kaplan e Steven Anderson fazem esta distinção no seu trabalho sobre custeio baseado em atividades orientado pelo tempo: a capacidade por usar oferece oportunidades de poupança ou de crescimento.¹⁹ Concordo, e isso muda a regra aqui. As horas libertadas vão para uma linha de capacidade. As poupanças precisam de evidência de despesa reduzida ou de um relato credível de despesa evitada.

As sessenta horas podiam servir mais clientes sem outra contratação. Podiam reduzir horas extraordinárias, absorver picos ou tornar o trabalho menos frenético. Também podiam ficar por usar. Não quero que a contabilidade escolha um resultado antes de a empresa ter feito alguma coisa com o tempo.

Para o principal índice de eficiência de custo, usaria o custo de fornecer o serviço medido, incluindo trabalho falhado e capacidade deixada por usar. Compara o crescimento da entrega com o crescimento do custo:

E_t = 100 × D_t / D_bC_t / C_b

(3)

D é o total da entrega. C é o custo dentro da mesma fronteira de reporte. E começa em 100, por isso 100 significa nenhuma mudança na eficiência de custo.

No exemplo do suporte, a entrega fica em $7 200 enquanto a despesa sobe de $7 200 para $7 680. O índice é 93,8: a eficiência de custo caiu 6,25% nesse mês.

Usa o modelo separado de tratamento imputado e o rácio é 136,4. É a melhoria nos recursos necessários para o fluxo de trabalho, não um ganho financeiro concretizado. Ambos os números são úteis depois de rotulados. Pôr «poupanças de IA» por cima de qualquer um deles pouparia muita explicação e criaria um problema muito maior.

Para uma conta de custos real, inclui folha de salários e encargos, prestadores, serviços comprados, licenças, utilização de agentes e infraestrutura. A revisão, a manutenção e a medição também consomem recursos. Não contes duas vezes o trabalho de revisão se já está no total da folha de salários.

A fatura de um fornecedor entra na conta uma única vez, a par da nossa própria supervisão. Não inventamos também a folha de salários interna dele nem os custos de tokens. A subcontratação não devia fazer desaparecer o custo da compra, nem contá-lo duas vezes.

Precisamos também de uma base consistente ao longo do tempo. Despesas do período não são pagamentos em dinheiro. Uma construção paga neste trimestre pode servir vários anos. Escolhe e divulga o tratamento. Não lances a construção como despesa numa comparação e a repartas por vários anos noutra. O exemplo do suporte assume que a despesa e o pagamento coincidem.

Os preços também importam. Tokens mais baratos melhoram a economia mesmo que nada mude no fluxo de trabalho. Um aumento salarial faz o contrário. Onde as quantidades e a qualidade dos recursos se podem comparar, uma visão a preços constantes ajuda a separar as mudanças de preço do uso de recursos. Sem essa evidência, mostra o resultado de custo nominal e explica os seus limites.

Por fim, sessenta horas de tratamento a menos não provam que um posto inteiro possa sair. A equipa ainda tem de cobrir o trabalho quando ele chega. A pergunta seguinte é sobre a procura e os compromissos de serviço, não sobre dividir por um número conveniente de horas.

O erro que pensei que se anulava

Eu tinha escrito que um peso errado se anularia quando comparássemos uma equipa consigo própria. O mesmo erro aparece dos dois lados, por isso estamos safos, certo?

Não. Não quando a mistura se move.

Toma dois tipos de trabalho. Para este exemplo, estipula que os seus pesos de referência corretos são $1 para o trabalho simples e $10 para o complexo. No primeiro trimestre, a equipa conclui noventa unidades simples e uma complexa. No segundo, dez simples e nove complexas. A produção corretamente ponderada é $100 nos dois trimestres. Mantém também os recursos totais inalterados.

Agora dá ao trabalho complexo um peso incorreto de $20.

Reportamos um crescimento de 72,7% onde não houve nenhum na medida corretamente ponderada. O erro manteve-se fixo. Fizemos mais do trabalho que tínhamos sobrevalorizado.

Um peso errado pode fabricar crescimento

i

Crescimento real 0,0%. O índice diz +72,7%. O mesmo trabalho, outra mistura.

Quão errado está o peso do trabalho complexo?+100%

Unidades complexas no trimestre 29

Errar também o peso do trabalho simples no mesmo valor

A relação é esta:

ĜG = 1 + ē_t1 + ē_b,ē_t = Σ_k w_k,t e_k

(4)

G é o rácio de crescimento com os pesos corretos no exemplo. Ĝ usa os nossos pesos estimados. e é o erro proporcional do peso de cada tipo e w é a sua quota da produção corretamente ponderada. ē é o erro médio depois de ponderado por essas quotas.

Os erros anulam-se quando essa média é a mesma nos dois períodos. Uma mistura de trabalho inalterada fá-lo-ia. Errar todos os pesos na mesma proporção também. Outras combinações também podem anular-se. Essas duas não são as únicas possibilidades.

A verificação prática é olhar para o que ganhou quota. Se a melhoria aparente vem de uma categoria cujo peso mal merece confiança, experimenta alternativas plausíveis. O ganho sobrevive? Os resultados por tipo devem estar ao lado do total, e não exigir um pedido especial de quem duvida.

As categorias podem esconder outra mudança. Se o agente ficar com o mais fácil dos «casos fáceis», até o meu modelo de suporte com duas categorias pode ajustar-se pouco. Temos de verificar também o que mudou dentro de cada categoria.

Também podemos melhorar a ver o trabalho

Mesmo com pesos perfeitos, os registos podem enganar-nos.

Supõe que a produção real cresce 10%. Captamos 80% da produção corretamente ponderada no primeiro período e 84% no segundo. A comparação observada fica:

D̂_tD̂_b = 1,10 × 0,840,80 = 1,155

(5)

O dashboard reporta 15,5% de crescimento. Quatro pontos percentuais de melhor cobertura acrescentaram 5,5 pontos percentuais ao crescimento aparente. Sem crescimento real, essa mesma mudança de cobertura fabricaria 5%.

Um agente pode deixar um registo exaustivo de trabalho que uma pessoa teria concluído numa conversa. Melhores registos seriam bem-vindos. Não seriam, por si só, mais produção.

«Cobertura» nessa equação significa a quota de produção captada, ponderada na mesma base de referência. Não significa a percentagem da folha de salários associada a uma integração, os lugares ligados ou a despesa visível.

Saber para onde foram 80% do dinheiro não nos diz que encontrámos 80% do trabalho. Isso só se segue com mais pressupostos sobre o trabalho observado e o que falta. Mantém a cobertura da despesa como uma verificação financeira útil. Não a ponhas na equação da produção só porque é mais fácil de obter.

É por isso que mantive o exemplo da cobertura, apesar de deixar o sistema de recolha de evidência fora do texto. Uma mudança no que conseguimos ver altera a medição, seja qual for a forma como recolhemos os registos.

Mais registos não resolvem isto automaticamente. O volume pode reduzir o ruído aleatório. Um viés consistente pode ficar. Quatro trimestres de dados também não reduzem automaticamente a incerteza a metade. Erros partilhados entre trimestres não se comportam como erros independentes.

Preferia publicar uma série mais estreita que observamos de forma consistente a fazer uma afirmação sobre a empresa inteira com uma cobertura que não conseguimos defender. Precisa de uma fronteira clara, das mesmas janelas de seguimento e de verificações de mudanças no registo. O trabalho fora dessa fronteira continua visível como trabalho não medido.

Simulações anteriores ajudaram-me a explorar estes erros. Não guardei as suas bandas numéricas como evidência da exatidão que o método teria. Isso exige a implementação e os pressupostos publicados, e depois verificados contra trabalho real. Os exemplos aqui estabelecem os modos de falha sem fingir saber com que frequência ocorrerá cada um.

Eventualmente, até a base de comparação se torna um problema

Não podemos congelar um conjunto de pesos para sempre e assumir que o negócio vai, obsequioso, manter-se comparável. Os serviços mudam. Alguns desaparecem, e os novos não vêm com um preço antigo.

Uma opção é atualizar os pesos periodicamente, comparando cada par de períodos adjacentes com os mesmos pesos. Uma ligação anual que use os pesos do ano anterior é:

L_t = Σ_k n_k,t s_k,t−1Σ_k n_k,t−1 s_k,t−1

(6)

O numerador conta a produção deste ano com os pesos do ano passado. O denominador conta a produção do ano passado com esses mesmos pesos. Multiplica as ligações para um índice de maior duração.

Isto evita chamar mudança na produção a uma mudança de pesos. Tem também um senão: componentes encadeados em separado geralmente não somam o total encadeado. O BEA avisa expressamente contra tratar componentes em dólares encadeados como aditivos.²⁰

Por isso, constrói a série da empresa a partir do seu próprio conjunto de produções sem sobreposição. Não somes dashboards de equipa desenhados de forma independente na esperança de que meçam coisas compatíveis. Algum trabalho interno pode ser útil numa vista por função e já estar incluído no entregável de ponta a ponta da empresa.

Uma classificação alterada também precisa de uma ponte: um período de sobreposição, uma reconstrução credível da série anterior ou uma rutura divulgada. O encadeamento não repara uma má definição de serviço nem trabalho em falta que acabámos de encontrar.

Isto pode deixar-nos com comparações úteis ao nível da função e sem um total defensável para a empresa. Eu aceitaria. Seria melhor do que inventar um total porque o pedido original o exigia.

Por vezes o bom trabalho faz a contagem diminuir

Supõe que a engenharia corrige o defeito por trás de mil conversas de suporte. O nosso índice de casos de suporte reporta menos casos tratados.

É o que deve acontecer. Houve menos casos. O erro seria concluir que a empresa ficou menos produtiva.

Numa fronteira mais ampla, estamos a tentar ajudar os clientes a usar o produto com sucesso. Manter ou melhorar esse serviço com menos contactos evitáveis pode ser um ganho substancial. A contagem estreita de casos precisa da definição de serviço mais ampla ou das medidas de resultado a seu lado.

A fiabilidade e a prevenção têm o mesmo problema. Uma semana tranquila de piquete pode ser uma boa semana. Uma intervenção de conformidade útil pode impedir que um caso chegue sequer a existir.

Para essas funções, testaria unidades baseadas no serviço mantido durante um período: o que se manteve a funcionar, para quem, sob que carga e risco, e com que padrão. Uma entrada na escala não basta. Também não transformaria a produção de um mês em zero por falhar um limiar. O ajuste de qualidade tem de refletir a falha, e não fazer tudo depender de um único interruptor.

Estas unidades são mais difíceis de definir. Isso faz parte do problema que estou a tentar compreender, e não algo que uma contagem de tickets nos deixe evitar.

E o trabalho que não conseguíamos fazer antes?

Uma equipa de auditoria que fazia amostragem de transações pode agora examiná-las todas. Põe o antigo custo humano hipotético contra cada verificação adicional e a alegação de produção torna-se enorme.

Mas ninguém ia necessariamente comprar aquele processo manual. Mais verificações também não significam um aumento proporcional da garantia.

Se o novo serviço é comparável a algo que já medimos, podemos tratar a mudança de âmbito ou de qualidade nessa base. Se não é, reportaria a capacidade, o seu custo e o que esperamos que alcance em separado, enquanto estabelecemos uma definição útil.

Estou a chamar a isto um registo de capacidades. Não quer dizer que a despesa se qualifique para capitalização. Não quer dizer que possamos esconder trabalho caro sob «inovação» sempre que o rácio de eficiência desiludir. A conta tem de continuar a reconciliar com as finanças.

Quando o serviço se torna repetível e definível, pode juntar-se ao índice de entrega ao abrigo de uma regra de introdução explícita. Ser possibilitado pela IA não o devia manter de fora para sempre.

É aqui que volta o ponto de Acemoglu sobre a procura das empresas. Se as empresas só recompensam poupanças de custo de trabalho, só vão comprar ferramentas que substituam pessoas.¹ Um registo de capacidades é uma forma de recompensar o outro tipo.

O meu contributo aqui é mais estreito. Dar à empresa um sítio onde explicar o que o investimento torna possível, em vez de pedir a cada projeto que se justifique como trabalho antigo mais barato. Um responsável, evidência e uma data de revisão seriam um bom início. «É IA» não é um caso de investimento.

Acemoglu defende também que se combatam as distorções fiscais que favorecem o capital em detrimento do trabalho, com base em trabalho feito com Andrea Manera e Pascual Restrepo.¹²¹ Concordo em remover uma preferência artificial pela substituição. Mas, para este texto, a decisão está dentro do orçamento: quanto custa agora o serviço existente, e o que conseguimos fazer que antes não conseguíamos?

O registo não vai tomar essa decisão por nós. Devia tornar mais difícil evitá-la.

Poria isto à frente de um CFO?

Sim, mas a par do resto da conta, e não como uma pontuação para a empresa.

Kent Beck e Gergely Orosz apresentam um argumento forte contra metas de esforço e de produção na sua resposta à McKinsey. A propósito das métricas personalizadas da consultora, escrevem: “Customers don’t care. Executives don’t care. Investors don’t care.”²²

Acho que essa rejeição vai longe demais. Um CFO pode perguntar, com razão, se conseguimos entregar o mesmo serviço de processamento salarial, com o mesmo padrão, com menos recursos. Não devíamos ter de esperar por um movimento no lucro da empresa para investigar porque ficou mais caro.

O argumento deles é mais matizado do que essa frase. Reconhecem também a utilidade do esforço e da produção para diagnosticar problemas, e os perigos de julgar as pessoas só pelos resultados.¹³ Na secção final, Orosz recomenda usar o esforço e a produção para investigar problemas, e não torná-los as medidas públicas de sucesso.

Esse é o desacordo mais estreito que vale a pena ter. Acho que uma comparação reportada com regularidade da produção e do custo de um serviço definido pode ajudar, a par dos resultados. Tem de justificar o seu custo e o seu efeito no comportamento. Um dashboard lindo que transforma a equipa em melhoradores de dashboards a tempo inteiro falhou.

É mais ou menos isto que eu queria ver:

As medidas de resultado devem diferir por função. Os bookings pertencem a uma conversa de vendas. Não são um teste de aceitação sensato para aconselhamento jurídico. Prefiro mostrar essas diferenças a escondê-las dentro de um «multiplicador de impacto».

Ao nível da empresa, a conta financeira tem de refletir também como comprámos o trabalho. A receita por funcionário pode subir depois de subcontratar, mesmo que o custo total de entrega suba. Soma os serviços comprados relevantes e os custos de IA antes de decidir que o negócio ficou mais eficiente. A receita tem ainda outros motores, por isso esse rácio não vai atribuir a mudança à IA.

Eu não usaria o índice de entrega para classificar indivíduos. Os seus pesos descrevem classes de trabalho, não a contribuição completa de uma pessoa. Orientar, ser interrompido e ajudar outra pessoa a acabar um trabalho não cabem na contagem de produção individual. Se ligares o salário ao índice, damos às pessoas uma razão para pedirem pesos maiores e mais trabalho contável.

Até comparar trabalho assistido por IA com trabalho só humano exige o mesmo cuidado do exemplo de abertura. As atribuições podem diferir dentro de uma categoria. Saber que um agente esteve envolvido não prova que causou a melhoria.

E um artefacto concluído não prova que a pessoa responsável o compreendeu. Isso é outro problema, em particular se afirmamos que o objetivo é tornar as pessoas mais capazes.

O teste que ainda não fiz

Mostrei como se comportam alguns cálculos com entradas que escolhi. Pedi emprestados métodos de contabilidade e aprendi com as objeções dos outros. Nada disso me diz se duas equipas conseguem usar esta proposta em trabalho real e chegar a um resultado útil.

Esse é o próximo teste.

Começaria por três contextos: um fluxo de casos ou transações repetível, um fluxo de projeto e um serviço contínuo. Para cada um, escreve a unidade, o âmbito e a fronteira de reporte antes de ver os resultados. Acrescenta a regra de conclusão, o tratamento da qualidade, os pesos de referência e a base de custo. Diz o que acontece ao trabalho não associado e às correções posteriores.

Depois dá a outra equipa competente a mesma evidência. Consegue reproduzir o cálculo? Onde discorda sobre o que lá pertence?

A aritmética deve ser fácil de acordar. O exemplo da exportação mostra onde estará o verdadeiro debate. Se duas escolhas razoáveis de categoria invertem o resultado principal, o relatório precisa de o mostrar, em vez de resolver o desacordo com uma casa decimal.

Escolhe classes de referência e estima os seus pesos com um conjunto de trabalho, e depois testa-as noutro. Inclui na revisão os registos excluídos e o trabalho fora do principal sistema de acompanhamento. Não redesenhes as categorias até o histórico parecer convincente.

Repete os testes de ticket dividido, ticket fundido, reorganização e subcontratação. Verifica as mudanças no registo. O total da empresa não devia mexer-se quando só mudámos a forma de descrever ou comprar o mesmo trabalho.

Testa primeiro esta contabilidade com um relato do trabalho estabelecido de forma independente. Se uma máquina consegue recuperar esse relato a partir dos sistemas disponíveis é um teste de implementação para mais tarde. Se humanos com evidência adequada não se entendem sobre as unidades, um classificador melhor não vai salvar a definição.

Testar se a IA causou uma melhoria é outro trabalho. O acesso aleatório pode ajudar onde for viável, tal como uma implantação faseada bem desenhada com um grupo de comparação credível. A aprendizagem, os efeitos de contágio, a seleção de tarefas e um seguimento de qualidade equivalente importam todos. Adotantes entusiastas e relutantes não são automaticamente comparáveis só porque partilham um cargo.

Que exatidão precisa a medida de ter? Depende da decisão. Um sinal aproximado sobre onde investigar tem um ónus diferente de evidência usada para cortar pessoal ou reportar poupanças. O erro aceitável devia seguir essa decisão, e não um tamanho universal de amostra de auditoria.

Publica as definições, o cálculo e a política de revisão com o resultado. A minha fasquia é que outra equipa consiga aplicar o método, contestar as suas escolhas e ver se a conclusão sobrevive. O reconhecimento de um contabilista ou uma equação de aspeto impressionante não bastaria.

Agora tenho uma pergunta melhor

Comecei com «a IA tornou-nos mais produtivos?». Agora quero saber que serviço mudou, se estamos a contar a mesma coisa e para onde foi a capacidade libertada. Estas perguntas são menos convenientes num slide. São muito mais úteis quando alguém pergunta o que devemos fazer a seguir.

Isto importa para a Flowstate porque ligar o trabalho aos recursos por trás dele é o problema que tentamos resolver. Não quero que o produto dependa de defender uma fórmula por que me afeiçoei enquanto escrevia um post de blogue. Se o trabalho real quebrar o modelo, o modelo tem de mudar.

Continuo a querer que os agentes tirem o trabalho repetitivo do dia das pessoas. Quero que uma empresa reconheça o benefício quando alguém ganha tempo para pensar, ajuda um colega ou tenta algo novo, em vez de exigir mais tickets para provar que a compra do software funcionou.

Não sei quanto disso cabe num só índice. Talvez menos do que esperava. Um resultado útil pode ser um conjunto de comparações em que confiamos, com as lacunas deixadas bem à vista.

Quando o agente fica com os casos fáceis, as pessoas que sobram não deviam precisar de fabricar atividade para se defender. Quando alguém alega uma poupança, devíamos poder perguntar para onde foi. E quando o número proposto não responde à pergunta, devíamos dizê-lo antes de se tornar a meta de alguém.

Fui à procura de uma medida. Acabei com um método que testaria e uma lista bastante longa de razões para ter cuidado. Dado de onde parti, acho que isso é progresso.

Notas técnicas

Estes são os cálculos por trás dos exemplos. Os pressupostos importam: uma identidade pode ser exata sem nos dizer com que exatidão conseguimos estimar as suas entradas numa empresa. Os rácios abaixo assumem pesos de referência positivos e denominadores diferentes de zero.

A identidade do erro de peso

Seja o peso de referência correto estipulado para o tipo k igual a s, e seja o peso estimado:

ŝ_k = s_k(1 + e_k)

(7)

Para uma produção contada com exatidão, define o total corretamente ponderado e a quota de cada tipo como:

D_t = Σ_k n_k,t s_k,w_k,t = n_k,t s_kD_t

(8)

Então:

D̂_t = Σ_k n_k,t s_k(1 + e_k) = D_t(1 + ē_t)

(9)

Tomar o rácio entre períodos dá a identidade usada acima. Assume erros de peso proporcionais fixos por tipo, quantidades exatas e uma definição de produção comum. Não modela trabalho omitido, classificações em mudança nem fronteiras incertas dos entregáveis.

Para erros pequenos, o erro relativo no rácio de crescimento é aproximadamente:

ĜG − 1 ≈ Σ_k (w_k,t − w_k,b) e_k

(10)

Se, além disso, os erros por tipo forem variáveis aleatórias independentes, de média zero e com o mesmo desvio-padrão, o desvio-padrão de primeira ordem desse erro do rácio de crescimento é:

σ_G ≈ σ_e √Σ_k (w_k,t − w_k,b)²

(11)

Sob esses pressupostos específicos, transferir vinte pontos percentuais de quota de produção entre dois tipos e fixar o desvio-padrão do erro em 20% dá aproximadamente 5,66% de erro relativo no rácio de crescimento, um desvio-padrão. Não é uma banda de erro estabelecida empiricamente, e em geral não é o mesmo número de pontos percentuais de crescimento reportado. Padrões correlacionados ou sistematicamente enviesados exigem um cálculo diferente.

A cobertura é um conceito de produção na identidade

No exemplo só de cobertura, seja c a quota da produção corretamente ponderada visível nos registos, sem falsos positivos e sem outros erros. Então a produção observada é c vezes a produção completa, pelo que:

D̂_t / D̂_bD_t / D_b = c_tc_b

(12)

A equação é exata sob essas definições. Estimar c é a parte difícil. Um rácio entre despesa ligada e despesa total é outra estatística e não se pode substituir sem um modelo explícito que ligue a cobertura de recursos à cobertura da produção.

A fronteira contabilística também importa aqui. Observar parte da produção usando a base de custo inteira não estima o mesmo objeto que medir produção e custo para um serviço deliberadamente restrito e observado de forma consistente. Nenhum dos dois deve ser renomeado como eficiência da empresa inteira sem justificação.

Porque é que a exatidão global de um classificador não chega

Para um problema simples de reconhecimento binário, com pesos fixos atribuídos corretamente, define os totais de verdadeiros positivos, falsos positivos e falsos negativos usando esses pesos e não contagens de itens. A precisão ponderada é o peso dos verdadeiros positivos a dividir por todo o peso reconhecido. A abrangência ponderada é o peso dos verdadeiros positivos a dividir por todo o peso elegível. Onde os denominadores são diferentes de zero:

peso reconhecidopeso elegível = abrangência ponderadaprecisão ponderada

(13)

A precisão e a abrangência habituais, baseadas em contagens, não dão essa identidade para um índice ponderado pelo custo. Uma classificação errada que altere o peso de um item reconhecido exige tratamento adicional. O mesmo vale para candidatos que nunca foram encontrados e para relações incertas entre registos pai e filho. Combinar estes erros numa só equação multiplicativa exige definições compatíveis. Não se justifica só porque cada termo tem um nome plausível.

O reconhecimento probabilístico é possível, mas um estimador proposto tem de manter as classificações mutuamente exclusivas e evitar contar entregáveis sobrepostos. Um conjunto de tickets pontuados de forma independente não satisfaz automaticamente essas condições. As probabilidades calibradas tratam da incerteza nos candidatos observados, não do trabalho que falta por completo no conjunto de candidatos.

O que uma amostra de auditoria consegue estabelecer

A conhecida estimativa de 385 observações vem de um cálculo particular: uma amostra aleatória simples de uma proporção binária independente, um intervalo de 95% por aproximação normal, uma proporção no pior caso de metade e uma margem de cinco pontos percentuais. A dimensão da amostra sem arredondar é:

n ≈ 1,96² × 0,5 × 0,50,05² = 384,16

(14)

Não estabelece que 385 registos vão calibrar os custos de referência, validar todos os tipos de trabalho ou resolver uma pequena mudança entre períodos. A estratificação, o agrupamento, os pesos desiguais, os casos raros de custo elevado e a discordância entre revisores mudam o desenho necessário. O planeamento da auditoria devia partir do erro que poderia mudar a decisão de negócio, e não de um número redondo familiar.

Reprodutibilidade e interpretação

Os exemplos trabalhados usam as entradas indicadas. Não são estimativas do desempenho típico de uma empresa. As bandas de erro numéricas de Monte Carlo também exigiriam a implementação, as distribuições dos parâmetros, os pressupostos de dependência e as sementes aleatórias publicadas. Teríamos depois de estabelecer que pressupostos se ajustam ao trabalho observado antes de interpretar as bandas como exatidão esperada.

A soma da entrega tem unidades de moeda de custo de referência. Um índice de apresentação pode normalizar essa soma para 100 no período base. O índice de eficiência de custo já usa essa normalização. Nenhum dos dois mede valor económico, impacto causal da IA nem o valor de um funcionário.

Will Hackett é cofundador e CTO da Flowstate.

Footnotes

1. Daron Acemoglu, Will AI Replace Workers? Not If We Build It Right., The Humanist Review of AI, 15 July 2026. Defende ferramentas que complementem os trabalhadores e uma procura empresarial centrada na produtividade e na inovação, e não só na poupança de custos de trabalho. A ligação ao desenho de reporte aqui apresentado é uma inferência minha, não um método proposto nesse ensaio. Source. ↩ ↩² ↩³

2. National Association of Letter Carriers, The Remote Encoding Center: Where bad addresses go to get better, The Postal Record, July 2022, pp. 34 and 35. O relato descreve máquinas a ficar com as imagens de moradas mais fáceis e a deixar as mais difíceis para os digitadores humanos. Source. ↩

3. Intercom, How Fin AI Agent and Copilot Cut Handle Time and Boost Agent Productivity. A discussão sobre a carga de casos humanos que sobra é um comentário do fornecedor que apoia o mecanismo da mistura de trabalho, não evidência independente da dimensão de um ganho de produtividade. Source. ↩

4. Erik Brynjolfsson, Danielle Li and Lindsey Raymond, Generative AI at Work, The Quarterly Journal of Economics 140(2), 2025, pp. 889 to 942. O estudo publicado reporta um aumento médio de 15% nos problemas resolvidos por hora no seu contexto de suporte ao cliente, com efeitos diferentes na rapidez e na qualidade consoante os trabalhadores. Published article. Authors’ summary. ↩

5. Joel Becker, Nate Rush, Beth Barnes and David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 July 2025. O resultado diz respeito aos programadores experientes participantes, aos seus repositórios e às ferramentas disponíveis nessa experiência. Source. ↩

6. Joel Becker and colleagues, We are Changing our Developer Productivity Experiment Design, METR, 24 February 2026. O seguimento discute a seleção de participantes, a seleção de tarefas e as dificuldades em medir o tempo com agentes em simultâneo. Source. ↩

7. McKinsey, The state of AI in 2026: On the road to ROI, 25 August 2026. As respostas ao inquérito foram recolhidas junto de 1 719 participantes entre 4 de maio e 8 de junho de 2026. Os valores reportados de 80% de produtividade individual e 37% de impacto no EBIT respondem a perguntas diferentes. Source. ↩

8. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler, The SPACE of Developer Productivity: There’s more to it than you think, ACM Queue 19(1), 2021. Defende que a produtividade dos programadores não se deixa captar por uma única métrica ou dimensão. O índice de entrega delimitado aqui proposto não é apresentado como substituto desse framework. Source. ↩

9. Alessandro Berti and colleagues, OCEL (Object-Centric Event Log) 2.0 Specification, arXiv:2403.01975, submitted 4 March 2024. A especificação suporta eventos e relações que envolvem vários objetos de negócio. É um padrão de representação, não uma métrica de produtividade. Source. ↩

10. ACCA, The standard hour in performance measurement. As horas padrão fornecem uma medida de atividade comum para produtos heterogéneos e sustentam rácios separados de volume, utilização e eficiência. Source. ↩

11. Office for National Statistics, Public service productivity estimates: sources and methods, revised 1 May 2026, especially section 1 on output, inputs and index numbers. A metodologia usa medidas de atividade ponderadas pelo custo para grande parte, mas não para toda, a produção dos serviços públicos. Source. ↩ ↩²

12. Ron Jeffries, Story Points Revisited, 23 May 2019. O seu pedido de desculpa condicionado por ter possivelmente inventado os story points é a referência aqui, não evidência contra todas as formas de estimativa relativa. Source. ↩

13. Gergely Orosz and Kent Beck, Measuring developer productivity? A response to McKinsey, Part 2, The Pragmatic Engineer, 31 August 2023. A discussão conjunta trata dos incentivos baseados só em resultados. A secção final, identificada em separado, é de Orosz e inclui o exemplo da inflação de estimativas e a recomendação de usar o esforço e a produção para diagnosticar problemas, e não como medidas públicas de sucesso. Source. ↩ ↩²

14. Alex Tamkin and Peter McCrory, Estimating AI productivity gains from Claude conversations, Anthropic, 25 November 2025. A verificação em tarefas de software reporta correlações de Spearman de 0,44 para o Claude e 0,50 para os programadores, a par de estimativas do modelo comprimidas. O desempenho na ordenação não estabelece calibração em horas. Source. ↩

15. Intercom, Fin AI Agent outcomes, documentation checked 7 October 2026. Ver “Resolution definition” e a explicação de que pedidos posteriores de mais assistência na mesma conversa revertem a cobrança da resolução. Os exemplos trabalhados neste texto não usam os preços reais da Fin. Source. ↩

16. Tejal Patwardhan and colleagues, GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks, 2025, appendix A.2.1 and table 2. Os cenários de revisão e refação usam pressupostos especificados e omitem um tratamento comparável de revisão e falha para a referência humana. Não devem ser lidos como estimativas gerais de poupança no local de trabalho. Source. ↩

17. Ralf Seifert, Richard Markoff and Matthew Spooner, How a new approach to demand planning can redefine success, I by IMD, 5 August 2024. Discute o forecast value added e a possibilidade de uma melhor base de comparação reduzir a contribuição incremental dos ajustes humanos. Source. ↩

18. Tom Cunningham and Parker Whitfill, Task Substitution and Uplift, METR, 8 May 2026. Distingue o ganho nas tarefas antigas, nas novas e no valor, com relações derivadas sob pressupostos explícitos. Source. ↩

19. Robert S. Kaplan and Steven R. Anderson, Rethinking Activity-Based Costing, Harvard Business School Working Knowledge, 24 January 2005. Distingue a capacidade fornecida da capacidade consumida e discute as oportunidades que surgem da capacidade por usar. Source. ↩

20. US Bureau of Economic Analysis, Chained-dollar estimates. Nota a não aditividade fora do ano de referência e avisa contra usar os componentes como se fossem valores em dólares aditivos comuns. Source. ↩

21. Daron Acemoglu, Andrea Manera and Pascual Restrepo, Does the U.S. Tax Code Favor Automation?, Brookings Papers on Economic Activity, Spring 2020. Analisa o tratamento fiscal que favorece o investimento em equipamento e software em detrimento do trabalho. As estimativas históricas desse artigo não são um cálculo do tratamento fiscal atual de nenhuma empresa em particular. Source. ↩

22. Gergely Orosz and Kent Beck, Measuring developer productivity? A response to McKinsey, The Pragmatic Engineer, 29 August 2023, especially section 4. A rejeição citada diz respeito às métricas personalizadas de esforço e de produção da McKinsey, não a todas as formas possíveis de medição operacional. Source. ↩