Outcomes & Outputs
O que Stanford está falando sobre produtividade real?
Um React sobre o Estudo de Stanford sobre Produtividade de Software
Recentemente, um estudo da Stanford trouxe à tona questões vitais sobre como medimos produtividade em engenharia de software — e se realmente estamos capturando o valor que importa. Muitas métricas comuns hoje (linhas de código, número de commits, story points, autoavaliações) foram analisadas criticamente, mostrando que têm problemas relevantes de comparabilidade, incentivos adversos e falha em representar outcomes e valor de negócio.
Principais insights do estudo:
Output vs Outcome: O estudo diferencia claramente “output” (o que se constrói) de “outcome” (o que muda de fato para os usuários/negócio). Times podem gerar muito output, mas entregar pouco resultado.
Métricas Tradicionais têm Limites:
Lines of Code, Commits e Pull Requests são ruído — mais código ou mais commits nem sempre significam mais produtividade ou valor.
Story Points são subjetivos, difíceis de comparar entre equipes, suscetíveis a inflar.
Self-assessments: engenheiros subestimam ou superestimam sua produtividade — desvio médio ~30 pontos percentuais.
Métricas DORA também têm suas falhas: métricas como Deployment Frequency, Lead Time for Changes etc. são úteis, mas nem sempre aplicáveis, especialmente em domínios com restrições regulatórias, aprovações de loja de apps ou arquiteturas que não permitem releases frequentes.
Uma nova proposta: O estudo apresenta uma métrica chamada Output Units, que combina mudanças de código, metadados de commits e outras dimensões (complexidade, acoplamento, coesão) para gerar uma métrica que correlaciona bem com avaliação humana especializada.
Casos de benchmark internos:
Times com produção alta vs times com custo menor por unidade de output;
Impacto de crescimento rápido (ex: triplicação de equipe) na produtividade por pessoa;
Métricas tradicionais nem sempre capturam eficiência/custo real. dpe.org
Com base nesses Insights, algumas implicações estratégicas para quem implementa agilismo ou opera times de tecnologia:
O que muda na prática?
Foco em outcomes, não só output: priorizar valor para o usuário, impacto de negócio e resultado real em vez de só quantidade de entregas ou código.
Métricas contextualizadas: precisamos escolher métricas que façam sentido no contexto (tipo de produto, canal, restrições externas).
Evitar incentivos perversos: se alta quantidade de commits for recompensada, pode gerar código redundante ou trabalho de baixa qualidade. É necessário equilibrar incentivos.
Métricas mais sofisticadas e híbridas: combinar métricas tradicionais com métricas como Output Units, com dashboards e modelos de comparação interna, benchmarks.
Transparência e diálogo: discutir com equipes o que mediremos, por que mediremos, quais consequências queremos evitar, garantir que métricas sejam usadas para melhoria, não punição.
Esse estudo confirma algo que muitos agilistas já observavam: métricas medem muito, mas nem sempre mede o que importa. É preciso evoluir de medir output para medir impacto, de métricas superficiais para métricas que revelem eficiência, valor e custo.
Times e organizações que seguirem essa rota tendem a ganhar: maior previsibilidade, melhor uso dos recursos, decisões mais alinhadas, motivação maior no time, porque haverá clareza sobre o que significa sucesso.
Takeaways
Ao definir métricas, pergunte sempre: isso mede output ou outcome? E será que será gamificado ou distorcido?
Use métricas híbridas — mesclar métricas de fluxo, qualidade, custo e impacto.
Realize pilotos antes de institucionalizar métricas novas, validando se elas realmente trazem insights úteis.
Estabeleça conversas regulares sobre métricas com equipes (review de fluxo, check-ins), não apenas relatórios.
Atualize métricas com evolução do time/produto; o que funciona no início pode deixar de funcionar à medida que o contexto muda.