Em algum momento alguém vai te perguntar: "o time está produzindo bem?". Parece uma pergunta simples, até você tentar responder com um número. Quantidade de commits? Cards fechados no Jira? Story points entregues na sprint? Cada um desses números conta uma parte da história e esconde outra. E tem um agravante: muito do que importa no nosso trabalho não dá para pegar na mão, e algumas coisas nem sequer dão o mesmo resultado duas vezes.
Para entender por que isso é tão difícil, fui atrás de estudos que mediram o problema de verdade: uma pesquisa da Microsoft com devs e gestores, um estudo da University College London com mais de 37 mil histórias de usuário, o relatório DORA do Google sobre IA nos times, experimentos controlados da METR e do próprio Google, e trabalhos brasileiros apresentados no SBES e no SBQS, além de um estudo da Zup. Abaixo, o que cada um mostra e o que dá para tirar disso no dia a dia.
Um engenheiro civil consegue medir quanto peso uma viga aguenta. A gente não consegue medir quanto um design de API vai facilitar a vida do próximo dev. O nosso produto é conhecimento virando código, e conhecimento não tem balança.
Por isso quase toda métrica de software é um proxy: uma medida indireta que a gente usa no lugar daquilo que realmente quer saber. Ninguém liga, de verdade, para quantos commits o time fez. O que interessa é se o time entrega coisa útil, com qualidade, sem se matar no processo. O commit só entra na conversa porque é fácil de contar.
Enquanto o proxy e o objetivo andam juntos, tudo certo. O problema é quando eles se separam e ninguém percebe.
Existe um nome para isso: Lei de Goodhart. A versão popular diz que, quando uma medida vira meta, ela deixa de ser uma boa medida. O exemplo clássico é cobrar linhas de código por dia. O número sobe, o código incha e ninguém mais reaproveita nada, porque reaproveitar diminui a contagem.
Um artigo de 2018 publicado no arXiv mostra que esse efeito aparece de jeitos diferentes. Traduzindo para a nossa realidade:
Resumindo: não existe métrica à prova de gambiarra. Existe métrica usada por quem sabe onde ela falha.
Antes de medir produtividade, alguém precisa dizer o que é produtividade. E aí a coisa já começa subjetiva.
Uma pesquisa feita dentro da Microsoft perguntou isso a devs e gestores da mesma empresa. A maioria dos devs respondeu falando de atividade, ou seja, o que fizeram no dia. A maioria dos gestores falou de resultado e qualidade. Mesma empresa, mesma palavra, significados diferentes.
Aqui no Brasil, um estudo apresentado no SBQS 2025 conversou com desenvolvedores de um grande instituto de ciência e tecnologia e chegou a cinco fatores que eles associam a ser produtivo: qualidade, expectativas, prazos, progresso e eficiência. E cada fator muda de peso dependendo se a pessoa está codando, revisando PR ou escrevendo documentação.
Foi justamente para lidar com isso que surgiu o SPACE, um modelo que olha produtividade por cinco lados: satisfação, desempenho, atividade, colaboração e fluxo de trabalho. A ideia principal é simples: nenhum número sozinho dá conta. Os autores ainda recomendam olhar os dados por time, nunca por pessoa, e aceitar que algumas métricas puxem para lados opostos. É de propósito, uma segura a outra.
Scrum e Kanban trouxeram uma coisa boa: o trabalho ficou visível. Tem quadro, tem burndown, tem sprint review a cada duas semanas. Em vez de descobrir no fim do projeto que tudo atrasou, o time vê o problema cedo.
O efeito colateral é que a sensação de produtividade passou a depender muito do que aparece nesses artefatos. Um quadro com tudo em "Done" na sexta-feira parece uma sprint boa, mesmo que metade das entregas volte como bug na semana seguinte. Uma sprint em que o time passou dias investigando um problema de performance parece ruim, porque quase nenhum card andou. O ritual vira o termômetro, e o termômetro mede movimento, não valor.
A velocity é o caso mais claro. Ela nasceu como ferramenta de planejamento interno do time: "costumamos entregar uns 30 pontos, então vamos puxar uns 30". Quando sobe para o relatório da gestão e alguém pergunta por que caiu de 32 para 28, ela vira meta. E aí entra a Lei de Goodhart: os pontos inflam, as tarefas são quebradas para fechar mais cards e o número melhora sem o time entregar mais.
Um estudo de 2024 em uma empresa alemã mostra como isso aparece na prática. Os desenvolvedores consideravam os story points irrelevantes em alguns times, relataram dificuldade com burndown charts e com a própria estimativa, e os product owners reclamaram de falta de transparência e de precisão nas estimativas. A empresa media, mas ninguém confiava muito no que estava medindo.
No Brasil, uma pesquisa apresentada no SBQS 2024 ouviu 145 profissionais que trabalham com agilidade em larga escala, ou seja, vários times trabalhando no mesmo produto. A conclusão dos autores é que não existe pacote pronto: as métricas precisam ser escolhidas para a realidade e o objetivo de cada organização. Copiar o dashboard de outra empresa não resolve.
Quem já participou de planning poker sabe: o 5 de um dev é o 8 de outro, e depois de dez minutos de discussão todo mundo fecha num 5 meio a contragosto. Story point parece objetivo porque é número. Mas é opinião do time convertida em escala.
Um estudo da University College London analisou mais de 37 mil histórias de usuário de 37 projetos open source e comparou os pontos com o tempo real de desenvolvimento. A estimativa errou em 78% dos casos e nem era consistente ao longo do mesmo projeto.
E jogar IA no problema não resolveu tanto. Os mesmos pesquisadores testaram de novo um modelo de deep learning que era considerado o melhor para estimar story points. Em pelo menos metade dos projetos, ele não foi significativamente melhor do que simplesmente chutar a mediana dos pontos.
Isso não quer dizer que estimar é perda de tempo. A conversa do planning ajuda o time a se entender sobre a tarefa. Mas velocity em story points mede, em boa parte, a régua do próprio time. Comparar a velocity de dois times é comparar duas réguas diferentes.
Mesmo os números que parecem mais "duros" têm ruído. Um sistema determinista é aquele que sempre devolve a mesma saída para a mesma entrada. Muita coisa que a gente mede não funciona assim.
O exemplo que todo mundo já viu é o teste flaky: aquele teste que passa, falha, passa de novo, sem ninguém mexer no código. Um estudo com projetos JavaScript mostrou que a maioria desses testes acaba corrigida, mas uma parte é simplesmente pulada, isolada ou apagada. E outra pesquisa de 2024 lembra que muita gente mantém o teste flaky na suíte porque, de vez em quando, ele pega um bug de verdade. Resultado: aquela taxa de sucesso do CI no dashboard já vem com ruído embutido.
Com IA no fluxo de trabalho, isso ficou bem maior. Pesquisadores da University College London pediram ao ChatGPT o mesmo código várias vezes para 829 problemas. Dependendo do conjunto de testes, entre 47% e 76% das tarefas não tiveram duas respostas com o mesmo resultado nos testes. E colocar a temperatura em zero, que muita gente acha que resolve, diminuiu a variação mas não acabou com ela.
Moral da história: rodar um prompt uma vez e anotar "funcionou" não mede a ferramenta. Mede a sorte daquela execução.
Assistentes de código entraram no dia a dia de quase todo time, e com eles veio a pergunta: quanto mais rápido a gente ficou? A resposta honesta é que depende muito de onde você mede.
No nível da pessoa e da tarefa, há ganho em vários estudos. Um experimento controlado do Google com 96 engenheiros mostrou que a IA reduziu em cerca de 21% o tempo de uma tarefa complexa, com a ressalva dos próprios autores de que a margem de erro era grande e o resultado não se aplica automaticamente a outros contextos. Aqui no Brasil, a Zup testou o StackSpot AI, assistente que usa o contexto da própria empresa, com 62 desenvolvedores. O pessoal relatou economia de tempo e acesso mais fácil à documentação e às APIs internas, mas também respostas inconsistentes e dificuldade com código mais complexo.
No nível do time e da entrega, o quadro muda. O relatório DORA 2024, que ouviu milhares de profissionais, encontrou um paradoxo. Cerca de 75% das pessoas disseram que a IA aumentou a própria produtividade. Mas, quando a adoção de IA sobe 25%, o relatório estima queda de 1,5% na vazão de entregas e de 7,2% na estabilidade, além de 2,6% menos tempo em trabalho que a pessoa considera valioso. Uma das explicações levantadas é que, com código ficando mais barato de gerar, as mudanças ficam maiores, e mudança grande é mais arriscada de colocar em produção.
Isso bagunça a análise de desempenho de três jeitos:
A lição dos estudos é que a pergunta "a IA deixou o time mais produtivo?" só tem resposta se você medir o sistema inteiro: do card aberto ao código estável em produção, não só o tempo que o dev levou para escrever.
Quando o dado objetivo é difícil, a saída natural é perguntar para as pessoas. Pesquisa de satisfação é útil, e o próprio SPACE inclui isso. O cuidado é não confundir sensação com resultado.
No começo da pandemia, pesquisadores de várias universidades brasileiras ouviram 413 desenvolvedores do país sobre o trabalho remoto. A produtividade percebida aumentou, principalmente porque havia menos interrupções durante o dia. É um dado valioso sobre como as pessoas se sentiam, e os próprios autores falam em produtividade percebida. Mas é diferente de medir entrega.
O caso mais famoso dessa diferença é o estudo da METR, de 2025. Eles acompanharam 16 devs experientes em 246 tarefas reais de projetos open source grandes, que eles já conheciam bem. Um sorteio definia se cada tarefa podia ou não usar IA. Com IA, as tarefas levaram 19% mais tempo, o contrário do que os próprios participantes e especialistas esperavam.
Os autores deixam claro que é uma foto de um cenário específico (código maduro, gente que conhece o repositório de cor, ferramentas do início de 2025). Não é uma regra, e o estudo do Google mostrou ganho em outro contexto. Mas a lição vale para qualquer time: o que a gente sente sobre a própria produtividade é um dado sobre o sentimento, não sobre a produtividade.
Nada disso é motivo para parar de medir. Sem número nenhum, a decisão fica com quem fala mais alto na reunião. A ideia é medir sabendo o que cada número consegue e não consegue dizer. Algumas dicas práticas:
Medir software sempre vai ter uma dose de julgamento humano. O time que mede bem não é o que eliminou a subjetividade. É o que sabe onde ela entra e deixa isso claro para todo mundo.
Nenhum comentário ainda. Seja o primeiro.
A função list() do PHP é uma forma prática de atribuir múltiplos valores de um array a variáveis individuais. Neste artigo, vamos explorar como essa função funciona, seus usos mais comuns e alternativas modernas…
Iniciantes, Intermediários, php
Ao desenvolver aplicações modernas com PHP, uma das tarefas mais comuns é manipular arrays — filtrando, transformando ou agrupando dados. Embora o PHP nativamente ofereça funções poderosas para isso, como array_map,…
Laravel, php, Tutorial