O framework SPACE e as cinco dimensões da produtividade em engenharia de software

Medir produtividade em engenharia de software é muito difícil. Há anos tentam e há anos falham. Não pela falta de dados ou pela criatividade planilheira de gerentes, mas pelo excesso de dados fáceis de coletar que pouco dizem sobre o que realmente importa. Commits, pull requests abertas ou revisadas, linhas de código: números que aparecem naturalmente nas ferramentas de desenvolvimento e criam a noção errônea de visibilidade.

O desafio real é confundir o que é mensurável com o que é relevante.

Foi para endereçar essa confusão que Nicole Forsgren, coautora do Accelerate e uma das pesquisadoras por trás do framework DORA, publicou em fevereiro de 2021, junto com Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck e Jenna Butler, o paper "The SPACE of Developer Productivity" na ACM Queue. O grupo reunia pesquisadores de Microsoft Research, GitHub e da University of Victoria.

A tese central não é difícil de entender, mas pode ser necessário repensar preincípios para compreender: a produtividade de desenvolvedor não pode ser capturada por uma única métrica, e provavelmente não pode ser capturada só por métricas de atividade.

As métricas de atividade que iludem e não comunicam

Existe uma razão pela qual as mesmas métricas clássicas como commits e pull requests dominam os dashboards de engenharia: são fáceis de coletar automaticamente. Não exigem pesquisa, entrevista ou interpretação. Chegam prontos e geram ferramentas de análise muito bonitas.

O problema é que atividade e produtividade são conceitos distintos. Um desenvolvedor que abre trinta PRs por semana pode estar fragmentando o trabalho intencionalmente para mover a métrica no dashboard. É o que acontece quando passam a perseguir métricas cegamente. Um desenvolvedor sênior que passa dois dias revisando a arquitetura e elimina um módulo inteiro vai aparecer com atividade "negativa" nos contadores de atividade automatizados. E nem vamos falar sobre o token maxxing por aqui.

Como já discutimos no contexto do DORA, a lei de Goodhart é implacável: quando uma medida se torna uma meta, ela deixa de ser uma boa medida. Em contextos de avaliação individual, métricas de atividade são especialmente suscetíveis a esse efeito.

Isso não significa que atividade seja irrelevante. Uma queda brusca nos commits de um desenvolvedor pode sinalizar um bloqueio técnico, sobrecarga ou problema no time. O erro é usar atividade como proxy de valor entregue.

As cinco dimensões do SPACE

O framework organiza produtividade em cinco dimensões. A recomendação central do paper é medir pelo menos três delas simultaneamente, em múltiplos níveis (indivíduo, time e sistema), combinando dados objetivos com dados subjetivos, como pesquisas. Nenhuma dimensão sozinha conta a história completa.

S — Satisfação e bem-estar (Satisfaction and well-being)

Como desenvolvedores se sentem em relação ao trabalho, às ferramentas e à cultura do time. Inclui percepção de propósito, risco de burnout e satisfação com o ambiente de trabalho.

A pesquisa identifica um ciclo que se retroalimenta: desenvolvedores satisfeitos tendem a ser mais produtivos, e produzir bem alimenta a satisfação. Romper esse ciclo tem consequências duradouras. Métricas possíveis: pesquisas de satisfação, eNPS do time, taxas de retenção.

P — Performance

Resultados, não outputs. O código fez o que deveria fazer? Gerou valor?

Essa dimensão olha para impacto: confiabilidade do sistema, taxa de bugs em produção, adoção de features pelos usuários. Existe uma sobreposição intencional com o Change Failure Rate do DORA — ambos interrogam a qualidade do que foi entregue, não o volume. A premissa do paper é simples: estar ocupado não é o mesmo que ser eficaz.

A — Atividade (Activity)

Commits, PRs, code reviews, deploys, contribuições em documentação. A dimensão mais visível e, como discutido, a mais perigosa de ser analisada isoladamente.

O paper não descarta atividade. Reconhece que ela é um sinal útil para identificar padrões e anomalias. O que combate é o uso de atividade como objetivo ou como critério de avaliação individual.

C — Comunicação e colaboração (Communication and collaboration)

Como o time coordena, compartilha conhecimento e resolve dependências. Tempo de resposta em code reviews, qualidade do feedback, documentação, eficácia do onboarding, colaboração entre times.

Essa dimensão captura uma causa raiz frequentemente invisível de gargalos. Um Lead Time alto no DORA pode ter origem não em código lento, mas em revisões que acumulam na fila por falta de disponibilidade ou clareza sobre quem deve revisar o quê.

E — Eficiência e fluxo (Efficiency and flow)

Capacidade de trabalhar com mínima fricção e interrupção. Tempo de foco ininterrupto, velocidade do pipeline CI/CD, número de handoffs, tempo de espera entre etapas.

Há uma sobreposição direta com o Lead Time for Changes do DORA, que mede o tempo desde o commit até o deploy em produção. O SPACE expande essa perspectiva: enquanto o DORA mede o fluxo do sistema, a dimensão E mede o fluxo humano. Quantas vezes um desenvolvedor é interrompido antes de conseguir concluir uma tarefa?

SPACE e DORA: frameworks complementares

Os dois frameworks operam em camadas diferentes e se complementam.

O DORA responde se a entrega de software está saudável: frequência de deploy, tempo de ciclo, taxa de falha em mudanças, tempo de recuperação. São métricas do sistema de entrega.

O SPACE ajuda a entender por que o sistema de entrega está no estado em que está. Se o Lead Time está subindo, as dimensões E (Eficiência) e C (Colaboração) do SPACE dão as pistas: o gargalo está no pipeline CI/CD? Nas revisões que demoram? Na falta de contexto compartilhado entre quem escreve e quem revisa?

Usados em conjunto, o DORA tende a sinalizar enquanto o SPACE tende a disgnosticar.

Por onde começar?

O mesmo conselho que vale para o DORA se aplica aqui: não tente implementar as cinco dimensões de uma vez, com ferramentas e rituais novos, em todos os níveis ao mesmo tempo.

• Comece pela Satisfação: uma pesquisa anônima trimestral com o time já revela muito. Desenvolvedores que não estão satisfeitos com ferramentas, processos ou cultura raramente são o gargalo isolado. São o sintoma de algo maior.
• Separe atividade de performance: estabeleça essa distinção nas conversas de feedback e avaliação. O que foi entregue importa mais do que quanto foi entregue. Uma refatoração que estabilizou o sistema conta mais do que dez PRs de ajuste de indentação.
• Mapeie os pontos de espera: onde o trabalho fica parado? Na fila de revisão? Em aprovações manuais? Em comunicações e reuniões infinitas? Em deploys que dependem de janela específica? Isso é a dimensão E tornada visível, e costuma ser o ganho mais rápido.

O paper original está disponível na Communications of the ACM e vale a leitura direta. A argumentação é densa, mas acessível. Os mitos sobre produtividade que o texto desfaz logo no início já justificam o tempo investido.