SPACE e produtividade

Toda tentativa de medir produtividade de engenharia com um número falha do mesmo jeito: o número sobe e o trabalho não melhora. Linhas de código, commits, story points, PRs por semana — cada um deles é fácil de aumentar sem entregar mais valor, e todos punem exatamente o comportamento que você quer (simplificar, apagar código, ajudar alguém).

O framework SPACE existe para tornar isso explícito: produtividade é multidimensional, e qualquer leitura honesta combina dimensões que se contrabalançam.

As cinco dimensões

Dimensão	O que captura	Exemplo de medida
Satisfaction	Satisfação e bem-estar de quem faz o trabalho	Pesquisa curta, eNPS interno, rotatividade
Performance	Resultado do que foi entregue	Confiabilidade, taxa de falha, impacto no negócio
Activity	Volume de atividade	Deploys, PRs, tickets fechados
Communication	Colaboração e fluxo de informação	Tempo até primeira revisão, qualidade da documentação
Efficiency	Fluxo sem interrupção	Tempo de espera, tempo de foco, lead time

A regra de uso: escolha pelo menos três dimensões, incluindo obrigatoriamente uma de percepção (satisfação). Atividade sozinha é a armadilha mais comum, porque é a mais fácil de extrair de ferramenta.

Por que contar commits é inútil

Porque a métrica vira alvo, e o alvo é fácil de atingir sem produzir valor: commits menores e mais frequentes, PRs fatiados artificialmente, código que ninguém apaga porque apagar “conta negativo”. A pessoa que passou a tarde ajudando outras duas a desbloquear um problema aparece como a menos produtiva da semana — e o time aprende a não fazer isso.

O critério prático para descartar uma métrica: se alguém pudesse melhorá-la deliberadamente sem melhorar o resultado, ela não serve sozinha.

Combinando métricas que se contrabalançam

O valor está nos pares que impedem a distorção:

• Frequência de deploy com taxa de falha em mudanças: entregar mais sem quebrar mais.
• Lead time com satisfação: acelerar sem esgotar as pessoas.
• Vazão de PRs com tempo até primeira revisão: produzir sem criar fila para os outros.
• Cobertura de plantão com acionamentos noturnos: cobrir sem destruir o sono.

Se um número melhora e o par piora, você moveu o problema em vez de resolvê-lo — e essa é justamente a informação útil.

Métrica de time, nunca de indivíduo

Esta é a linha que não deve ser cruzada. Métrica individual extraída de ferramenta de desenvolvimento produz três efeitos previsíveis: as pessoas otimizam o número, param de colaborar (ajudar não conta) e passam a esconder problema.

Para avaliação individual existem caminhos melhores: feedback de pares, avaliação de impacto por quem trabalha junto, conversa de carreira. Nenhum deles sai de um dashboard.

Use SPACE no nível do time e da organização, com o objetivo de encontrar atrito no sistema — e diga isso em voz alta quando apresentar os números, porque a primeira reação de quem é medido é presumir vigilância.

Como coletar sem virar vigilância

Uma pesquisa trimestral curta (cinco a sete perguntas, anônima) responde a maior parte do que ferramenta nenhuma alcança:

1. Consigo levar uma mudança pequena até produção sem depender de aprovação demorada. (1-5)
2. Meu ambiente de desenvolvimento funciona sem eu perder tempo consertando. (1-5)
3. Sei onde procurar quando algo quebra em produção. (1-5)
4. Tenho tempo de foco suficiente na semana. (1-5)
5. O plantão está sustentável para mim. (1-5)
6. Qual é o maior atrito no seu trabalho hoje? (aberta)

A pergunta aberta costuma ser a mais valiosa do conjunto. Combine com dados de sistema (DORA, tempo de build, tempo até primeira revisão) para separar percepção de medida — e quando os dois discordam, investigue: normalmente a percepção está captando algo que a métrica não vê.

Três regras que mantêm a prática saudável: publique o resultado para quem respondeu; aja sobre um ou dois itens e mostre o que mudou; e nunca use o resultado em avaliação individual. Uma pesquisa que não gera mudança visível para de ser respondida na rodada seguinte.

Próximo passo: boa parte do atrito medido vem do desenho dos times. Continue em Team Topologies.