Pular para o conteúdo
platform-engineering

SPACE: Produtividade Não É um Número — É um Sistema Humano em Tensão

SPACE não oferece respostas rápidas. Ele oferece fricção intelectual. Entenda por que produtividade em software exige aceitar tensões irresolvíveis.

24 min de leitura

Also in English

Série Por Que Times Produtivos Fracassam
5/8

Depois de olhar para o DORA, fica tentador acreditar que produtividade em software pode ser entendida — e melhorada — observando o pipeline. Em muitos aspectos, isso é verdade. Sistemas previsíveis, com baixo custo de mudança, criam condições reais para que o trabalho avance.

Mas, à medida que organizações amadurecem operacionalmente, um desconforto começa a surgir. Como vimos no Artigo 2, métricas não são neutras. E se o DORA pode ser manipulado — como exploramos no Artigo 4 —, o que acontece quando ampliamos o jogo para cinco dimensões simultâneas?

A lacuna entre números e experiência humana

O que as métricas mostram

  • As métricas estão boas
  • O fluxo está saudável
  • Implantações são frequentes

O que as pessoas sentem

  • Times entregam, mas reclamam de exaustão
  • O sentimento é de urgência constante
  • Viver dentro do sistema é caro

É nesse ponto que o modelo [2] se torna relevante.

Não é correção, é expansão

Não como correção do DORA, mas como expansão do problema. Onde o DORA pergunta “o quão bem o sistema entrega mudanças?”, o SPACE pergunta algo mais incômodo: “o que estamos chamando de produtividade — e quem está pagando o custo dessa definição?”

SPACE oferece fricção intelectual, não respostas

O modelo SPACE surge de pesquisas ligadas ao trabalho de produtividade em engenharia no contexto de grandes organizações de tecnologia, especialmente em iniciativas associadas ao GitHub e à pesquisa acadêmica aplicada. Ele não nasce para gerar métricas prontas, mas para organizar o pensamento. E isso, por si só, já o coloca em uma categoria diferente da maioria dos frameworks populares.

A premissa subversiva

Produtividade em trabalho de conhecimento é inerentemente multidimensional. Qualquer tentativa de reduzi-la a um único indicador inevitavelmente sacrifica aspectos importantes do trabalho. O problema não é apenas técnico. É epistemológico.

Estamos tentando medir algo complexo demais com instrumentos simples demais.

Por isso, o SPACE não começa perguntando o que medir. Ele começa perguntando o que está sendo ignorado.

As cinco dimensões em tensão permanente

O acrônimo representa cinco dimensões que coexistem em tensão permanente: Satisfaction, Performance, Activity, Communication & Collaboration, e Efficiency & Flow. Nenhuma delas, isoladamente, define produtividade. Mas qualquer definição que ignore uma delas cria distorções.

Satisfaction and Well-being: Variável estrutural, não luxo

Como estabelecemos no Artigo 1, Developer Experience não é conforto — é economia cognitiva. No SPACE, satisfação segue a mesma lógica: é variável estrutural do sistema, não bônus emocional.

A conexão entre satisfação e qualidade técnica

Desenvolvedores insatisfeitos não param de entregar. Eles mudam como entregam. Começam a evitar riscos, escolhem soluções seguras em vez de soluções melhores, param de questionar decisões ruins, aceitam débito técnico sem resistência.

Desenvolvedor satisfeito
  • Questiona decisões questionáveis
  • Propõe melhorias proativamente
  • Investe em qualidade de longo prazo
  • Compartilha conhecimento
Desenvolvedor insatisfeito
  • Executa sem questionar
  • Faz o mínimo necessário
  • Aceita atalhos sem resistência
  • Guarda conhecimento para si

O paradoxo é que insatisfação não aparece imediatamente na produtividade. Ela aparece na qualidade das decisões, na disposição para colaborar, na energia disponível para problemas difíceis. O sistema continua produzindo — mas produz pior.

Como medir satisfação (sem pesquisas vazias)

SPACE sugere medir satisfação através de proxies comportamentais:

  • Retenção: Quanto tempo pessoas ficam? Por que saem?
  • Voluntariado: Pessoas se oferecem para projetos difíceis ou evitam?
  • Qualidade das discussões: Debates técnicos são honestos ou políticos?
  • Feedback espontâneo: Pessoas falam sobre problemas ou guardam para si?

O problema das pesquisas

Pesquisas de satisfação capturam o que pessoas dizem sentir. Comportamento captura o que elas realmente sentem. Quando os dois divergem, confie no comportamento.

No SPACE, satisfação funciona como indicador antecedente. Ela sinaliza problemas antes que apareçam em métricas de entrega. Quando satisfação cai, a produtividade ainda pode estar alta — mas está vivendo de reservas que eventualmente acabam.

Organizações que tratam satisfação como “desejável” descobrem tarde demais que ela era estrutural para o funcionamento do sistema.

Performance: Qualidade percebida, não velocidade

Performance, no SPACE, não é sinônimo de velocidade. Ela está ligada à qualidade percebida do trabalho, à capacidade de resolver problemas complexos e de gerar impacto real.

A confusão persiste porque velocidade é fácil de medir (quanto tempo para fechar ticket?) e performance é difícil de definir (quanto tempo para saber se decisão técnica foi boa?). Assimetria temporal cria viés sistemático: o mensurável agora ganha atenção; o que só se revela depois é ignorado.

Velocidade alta
  • Muitos tickets fechados
  • Ciclos curtos de entrega
  • Movimento constante
  • Pipeline fluindo
Performance alta
  • Problemas resolvidos de verdade
  • Código que não volta como bug
  • Decisões técnicas sustentáveis
  • Impacto mensurável no negócio

O que performance realmente captura

No modelo SPACE, performance tenta capturar algo mais próximo de : o trabalho produzido resolve o problema que deveria resolver? O código escrito funciona de forma confiável? As decisões tomadas se sustentam no tempo?

Isso inclui:

  • Qualidade do código: Bugs introduzidos, retrabalho necessário, manutenibilidade
  • Resolução real de problemas: A funcionalidade entregue resolve a necessidade do usuário?
  • Sustentabilidade técnica: As decisões de hoje criam ou reduzem problemas futuros?
  • Impacto no negócio: O trabalho técnico se traduz em valor perceptível?

A pergunta que performance faz

Não é “quanto produzimos?” — é “o que produzimos funciona e importa?”

Por isso, SPACE trata performance como dimensão que exige julgamento qualitativo, não apenas coleta automatizada. Revisões de código, retrospectivas honestas e feedback de usuários são fontes de dados tão válidas quanto métricas de pipeline.

Quando organizações confundem velocidade com performance, elas otimizam o movimento — não o resultado. E sistemas otimizados para movimento podem mover-se muito rápido na direção errada.

Activity: O sinal mais traiçoeiro

Atividade é talvez a dimensão mais traiçoeira. Commits, tickets, PRs, horas conectadas — tudo isso é fácil de contar. E justamente por isso, é perigoso.

Por que atividade é tão sedutora

Atividade é a dimensão que organizações mais gostam de medir — e a que menos deveria ser tratada como indicador principal. A razão é simples: atividade é visível, imediata e inequívoca.

Você pode abrir um painel agora e ver quantos commits foram feitos hoje. Quantos tickets foram movidos. Quantas horas cada pessoa ficou online. Essa visibilidade cria uma ilusão de controle.

A armadilha da visibilidade

Aquilo que é fácil de ver tende a receber mais atenção. Aquilo que recebe mais atenção tende a ser otimizado. Quando atividade é o que mais se vê, atividade é o que se otimiza — mesmo que não seja o que importa.

O que atividade alta realmente significa

Atividade alta pode significar coisas completamente opostas:

Atividade saudável
  • Progresso real em direção a objetivos
  • Trabalho focado e intencional
  • Colaboração produtiva
  • Entregas que resolvem problemas
Atividade patológica
  • Retrabalho disfarçado de progresso
  • Trabalho fragmentado por interrupções
  • Reuniões que geram mais reuniões
  • Entregas que criam novos problemas

Sem contexto, um painel de atividade não distingue entre as duas. Um time que refaz o mesmo trabalho três vezes por falta de clareza mostra três vezes mais atividade que um time que fez certo na primeira. Nos números, o time disfuncional parece mais produtivo.

Quando atividade é útil

SPACE não demoniza atividade. Ela tem valor quando usada corretamente:

  • Como sinal de alerta: Uma queda brusca na atividade pode indicar bloqueios sistêmicos
  • Como contexto para as demais dimensões: Muita atividade + satisfação baixa = sinal de desgaste
  • Como referência individual: Mudanças bruscas no padrão de atividade merecem atenção

O erro não é medir atividade. É tratá-la como indicador principal quando ela deveria ser indicador complementar. Atividade mede quanto o sistema se move. Não mede para onde.

Communication and Collaboration: Fricção social consome energia

Comunicação e colaboração aparecem como um eixo próprio porque trabalho de software raramente é individual. Dependências, alinhamentos, revisões e decisões coletivas fazem parte do custo real de produzir software.

Por que colaboração é dimensão própria

A tentação é tratar colaboração como meio para outras dimensões. “Colaboramos para entregar mais rápido”, “Comunicamos para evitar erros”. Mas SPACE trata colaboração como dimensão autônoma porque seu custo e valor são independentes do resultado final.

Um time pode ter colaboração excelente e ainda assim entregar pouco — porque está resolvendo o problema errado. Outro pode entregar muito com colaboração mínima — e criar silos de conhecimento que fragilizam o sistema.

Colaboração eficiente
  • Informação flui para quem precisa
  • Decisões são tomadas com contexto
  • Dependências são gerenciadas proativamente
  • Conhecimento é distribuído
Colaboração ineficiente
  • Informação fica presa em silos
  • Decisões são tomadas no escuro
  • Dependências viram bloqueios
  • Conhecimento concentrado em indivíduos

O custo cognitivo da coordenação

Coordenar trabalho com outras pessoas consome energia cognitiva. Cada reunião, cada thread de Slack, cada PR review, cada alinhamento de expectativas — tudo isso tem custo. E esse custo raramente aparece em métricas tradicionais.

A matemática oculta

Se um desenvolvedor gasta 2 horas por dia em reuniões, alinhamentos e comunicações, restam 6 horas para trabalho focado. Mas o impacto real é pior: alternância de contexto entre reuniões e código profundo fragmenta ainda mais o tempo útil.

O problema não é que coordenação existe — ela é necessária. O problema é quando o custo de coordenar supera o benefício de colaborar.

Sinais de colaboração disfuncional

Como identificar problemas de colaboração

Sinais de colaboração saudável

  • Reuniões têm propósito claro e terminam com decisão
  • Informações importantes chegam sem precisar perseguir
  • Code reviews são construtivos e rápidos
  • Pessoas sabem quem pode ajudar com o quê

Sinais de colaboração disfuncional

  • Reuniões geram mais reuniões
  • Informação crítica chega tarde ou nunca
  • Code reviews viram gargalo político
  • Ninguém sabe quem decide o quê

A armadilha da colaboração excessiva

Organizações que valorizam colaboração às vezes caem na armadilha oposta: colaboração como fim em si mesma. Tudo precisa ser discutido, alinhado, consensuado. Nenhuma decisão acontece sem reunião. Nenhuma mudança passa sem aprovação múltipla.

Isso cria um sistema onde a fricção de coordenação é tão alta que fazer qualquer coisa se torna exaustivo. Pessoas competentes são forçadas a gastar mais energia navegando o processo do que resolvendo problemas.

Quando colaboração vira obstáculo

Se um desenvolvedor sênior precisa de três reuniões e cinco aprovações para fazer uma mudança que levaria 30 minutos, o problema não é falta de colaboração — é excesso dela. O sistema está otimizado para controle, não para resultado.

Como medir colaboração

Colaboração é difícil de medir diretamente. SPACE sugere proxies:

  • Tempo de espera: Quanto tempo decisões ficam bloqueadas esperando alinhamento?
  • Qualidade das revisões: Revisões de código agregam valor ou são mera formalidade?
  • Distribuição de conhecimento: Quantas pessoas podem resolver problemas críticos?
  • Satisfação com comunicação: Pessoas sentem que têm a informação necessária?

O objetivo não é maximizar colaboração, mas otimizar a relação custo-benefício. Colaboração suficiente para que o trabalho flua; não tanta que o trabalho pare.

Colaboração e estrutura organizacional

A qualidade da colaboração raramente é problema individual. Ela reflete estrutura organizacional. Times mal divididos, responsabilidades mal definidas e incentivos desalinhados criam fricção que nenhuma ferramenta de comunicação resolve.

Lei de Conway invertida

A Lei de Conway[1] sugere que sistemas tendem a refletir a estrutura de comunicação das organizações que os criam. Se a comunicação entre times é difícil, provavelmente a arquitetura do sistema reflete essa dificuldade. Melhorar colaboração às vezes exige redesenhar o sistema — não apenas adicionar mais canais de comunicação.

Efficiency and Flow: Uma dimensão, não o fim em si

Eficiência e fluxo fecham o modelo conectando-o, em parte, com o que o DORA já observa. Aqui entram tempo em espera, interrupções, alternância de contexto e gargalos sistêmicos.

Fluxo no contexto SPACE

No SPACE, fluxo não é tratado como fim em si mesmo. Ele é apenas uma dimensão entre outras. Um fluxo excelente não compensa um sistema que desgasta pessoas. Ele apenas acelera esse desgaste.

O que eficiência realmente significa

Eficiência, no contexto SPACE, não é apenas “fazer mais com menos”. É sobre minimizar desperdício sistêmico: tempo esperando, energia gasta em alternância de contexto, trabalho perdido por falta de clareza.

Eficiência real
  • Menos tempo esperando recursos
  • Menos interrupções desnecessárias
  • Menos retrabalho por falta de clareza
  • Menos energia em tarefas que não agregam
Eficiência aparente
  • Fazer mais coisas por dia
  • Estar sempre ocupado
  • Responder imediatamente a tudo
  • Maximizar utilização de tempo

A confusão entre eficiência real e aparente é comum. Um desenvolvedor que responde Slack imediatamente, participa de todas as reuniões e está sempre “disponível” parece eficiente. Mas se essa disponibilidade constante fragmenta seu trabalho profundo, a eficiência real é baixa.

Fluxo: o estado e o sistema

“Fluxo” tem dois significados relevantes aqui:

  1. Estado psicológico: Concentração profunda onde o trabalho acontece sem fricção
  2. Propriedade sistêmica: Capacidade do sistema de mover trabalho do início ao fim sem bloqueios

Ambos são importantes, e ambos são frágeis.

A fragilidade do fluxo

Entrar em estado de fluxo leva tempo. Uma única interrupção pode custar 20-30 minutos de recuperação. Sistemas que interrompem frequentemente impedem estruturalmente que fluxo aconteça.

Os inimigos do fluxo

Condições sistêmicas para fluxo

O que permite fluxo

  • Blocos de tempo protegidos
  • Clareza sobre o que fazer
  • Ferramentas que funcionam
  • Autonomia para decidir como fazer

O que destrói fluxo

  • Interrupções constantes
  • Ambiguidade sobre prioridades
  • Ferramentas que quebram ou são lentas
  • Microgerenciamento que exige justificativas

Organizações frequentemente sabotam fluxo sem perceber. Políticas de “porta aberta”, cultura de resposta imediata, reuniões mal distribuídas ao longo do dia — tudo isso fragmenta o tempo e impede concentração profunda.

Eficiência vs. Utilização

Um erro conceitual comum é confundir eficiência com utilização. Utilização máxima não é eficiência — é receita para gargalos.

Sistemas operando a 100% de capacidade não têm margem para absorver variação. Qualquer imprevisto — um bug urgente, uma dependência atrasada, uma pessoa doente — cria cascata de atrasos. Paradoxalmente, reduzir utilização pode aumentar vazão.

A lição de teoria de filas

Sistemas de alta utilização têm tempo de espera exponencialmente maior. Um sistema a 90% de utilização tem filas muito maiores que um a 70%. Folga no sistema não é desperdício — é capacidade de resposta.

Gargalos sistêmicos

Eficiência também envolve identificar onde o sistema trava. Não adianta otimizar desenvolvimento se o gargalo está em revisão. Não adianta acelerar revisão se o gargalo está em deploy.

A teoria das restrições é relevante aqui: otimizar qualquer parte do sistema que não seja o gargalo atual não melhora o resultado final. Primeiro, identifique onde o fluxo trava. Depois, otimize ali.

Gargalos comuns
  • Code review lento
  • Deploys manuais e arriscados
  • Aprovações que demoram dias
  • Ambientes de teste indisponíveis
Como identificar
  • Trabalho acumulando antes da revisão
  • Mudanças esperando janela de deploy
  • Decisões em limbo esperando alguém
  • Desenvolvedores esperando ambiente

Eficiência sem burnout

O risco de otimizar eficiência é criar sistemas que extraem máximo de pessoas. Eliminar toda folga, toda pausa, todo momento de respiro pode parecer eficiente no curto prazo — mas cria sistemas frágeis que quebram sob pressão.

Eficiência sustentável

Eficiência real inclui sustentabilidade. Um sistema que opera em máxima eficiência por três meses e depois colapsa é menos eficiente que um que opera em 80% por anos. O horizonte temporal importa.

SPACE trata eficiência como uma dimensão entre outras, não como objetivo supremo. Um sistema pode ser altamente eficiente e ainda assim insustentável, porque ignora satisfação. Pode ter fluxo excelente e ainda assim falhar em performance, porque o trabalho eficiente está indo na direção errada.

Eficiência é necessária, mas não suficiente. E quando tratada como único objetivo, ela se torna destrutiva.

O ponto mais importante: as dimensões entram em conflito

O ponto mais importante — e mais frequentemente ignorado — é que essas dimensões entram em conflito:

Tensões inerentes entre dimensões do SPACE

Otimizações que geram conflito

  • Aumentar atividade
  • Maximizar eficiência
  • Otimizar colaboração

Custos não evidentes

  • Pode reduzir satisfação
  • Pode prejudicar aprendizado
  • Pode diminuir foco individual

O SPACE não tenta resolver essas tensões. Ele as torna explícitas.

A mudança de conversa

Em vez de perguntar “qual métrica está ruim?”, a pergunta passa a ser “qual dimensão estamos sacrificando sem perceber?”. Em vez de buscar um score agregado, o modelo força escolhas conscientes. Toda decisão de otimização tem um custo — e o SPACE exige que esse custo seja visível.

Carregando diagrama...
As 5 dimensões do SPACE. Setas sólidas = Tensão (otimizar uma pode prejudicar outra). Setas tracejadas = Sinergia (dimensões se reforçam mutuamente).

Quem se beneficia da complexidade?

Mas há algo incômodo nessa multidimensionalidade que raramente é discutido: quem se beneficia quando tudo fica complexo demais para ser questionado?

Quando o DORA mostra números ruins, a conversa tende a ser direta: o pipeline está lento, as implantações estão quebrando, precisamos melhorar. É desconfortável, mas decisivo. Há um alvo claro.

Com SPACE, a conversa pode facilmente virar outra coisa.

Exemplo: A reunião que nunca termina

Cenário: Time de engenharia reporta exaustão. Liderança pede análise baseada em SPACE.

  • Satisfaction está baixa? “É cultural, estamos trabalhando nisso.”
  • Performance está ok? “Então o problema não é técnico.”
  • Activity está alta? “Time está produtivo.”
  • Communication poderia melhorar? “Vamos adicionar mais rituais.”
  • Efficiency está razoável? “Fluxo não é o gargalo.”

Resultado: Três meses de conversas. Nenhuma decisão tomada. Time continua exausto. Mas agora há painéis bonitos mostrando “estamos monitorando todas as dimensões”.

Quando complexidade vira desculpa

Organizações que evitam decisões difíceis adoram SPACE. Não porque ele seja inútil — mas porque ele pode ser usado para protelar ação.

  • “Precisamos entender todas as dimensões antes de agir”
  • “Não podemos otimizar uma dimensão sem considerar as outras”
  • “É muito complexo para ter resposta simples”

Tudo verdade. Mas quando essas frases viram padrão, não são mais análise — são paralisia institucionalizada.

Há uma linha tênue entre aceitar a complexidade necessária e usar complexidade como escudo contra responsabilização. SPACE, como qualquer framework sofisticado, pode ser usado de ambas as formas.

A pergunta que incomoda

Quem se beneficia quando a resposta sempre é “depende” e nada nunca muda?

Não são os desenvolvedores quebrando sob pressão. Não são os times de produto lutando com sistemas lentos. São as estruturas organizacionais que conseguem apresentar “pensamento sistêmico” enquanto evitam decisões reais.

SPACE vs DORA: Universal vs Contextual

Esse talvez seja o maior contraste com o DORA. Enquanto o DORA busca identificar padrões universais de alta performance em sistemas de entrega, o SPACE assume que produtividade é contextual.

Contexto importa

O que faz sentido medir em um time de plataforma pode ser inútil — ou destrutivo — em um time de produto. O que funciona em uma organização pode falhar completamente em outra.

Por que SPACE raramente vira dashboard

SPACE raramente vira dashboard. E quando vira, geralmente perde seu valor. Ele não foi feito para monitoramento contínuo, mas para conversas difíceis. Conversas sobre prioridades, trade-offs e consequências humanas de decisões técnicas e organizacionais.

Quando sofisticação vira desculpa

Se o DORA pode ser manipulado, o SPACE pode ser instrumentalizado. E a arma é justamente sua força: a complexidade.

A sofisticação do modelo — com suas cinco dimensões e tensões inevitáveis — deveria proteger contra simplificação destrutiva. Mas em mãos erradas, ela vira ferramenta para obscurecer realidade ao invés de esclarecê-la.

Como o framework pode ser usado ou abusado

Uso legítimo do SPACE

  • Reconhecer trade-offs reais entre dimensões
  • Tornar custos ocultos visíveis
  • Forçar conversas sobre prioridades
  • Questionar otimizações unidimensionais

Instrumentalização do SPACE

  • Usar complexidade para evitar decisão
  • Esconder custos atrás de 'tudo importa'
  • Protelar indefinidamente com 'mais análise'
  • Justificar status quo como 'equilíbrio necessário'

Como reconhecer instrumentalização na prática

Padrão 1: Teatro de produtividade multidimensional

Sintoma: Relatórios trimestrais mostram que a organização “está trabalhando em todas as cinco dimensões” simultaneamente.

Realidade: Nenhuma melhoria significativa em nenhuma dimensão. Recursos fragmentados demais para gerar impacto real. Mas a narrativa é bonita: “Estamos equilibrando tudo.”

O que realmente acontece: A organização conseguiu transformar inação em estratégia documentada.

Padrão 2: ‘Estamos otimizando para o longo prazo’

Sintoma: Problemas concretos (burnout, rotatividade, sistemas quebrando) são respondidos com “não podemos sacrificar outras dimensões por solução rápida.”

Realidade: “Longo prazo” vira desculpa para não agir no curto prazo. Enquanto isso, pessoas queimam, sistemas pioram e dívida técnica cresce.

O que realmente acontece: Linguagem de sofisticação estratégica mascarando incapacidade de priorizar.

Padrão 3: Executivo que descobriu SPACE ontem

Sintoma: Liderança cita SPACE para invalidar pedidos de melhoria com “isso seria otimizar apenas uma dimensão.”

Realidade: Pedidos eram legítimos (ex: reduzir toil, melhorar observabilidade, automatizar processos manuais). SPACE vira escudo retórico contra mudança.

O que realmente acontece: Framework virou ferramenta política, não analítica.

O truque retórico

Quando alguém usa SPACE para dizer que não dá para fazer nada porque “tudo está conectado e complexo”, não está aplicando o framework — está abusando dele.

SPACE existe para tornar trade-offs explícitos e escolhas conscientes. Não para tornar escolhas impossíveis.

O risco do relativismo

Há, claro, um risco aqui. Sem disciplina, o SPACE pode virar relativismo. Se tudo é multidimensional e contextual, nada é comparável, nada é decisivo.

O trade-off do SPACE

O modelo não nega esse risco. Ele apenas assume que simplificação excessiva é um risco maior.

Por que organizações resistem ao SPACE (quando usado honestamente)

Aqui está o paradoxo: as mesmas organizações que instrumentalizam SPACE para evitar decisão também resistem ferozmente a aplicá-lo com honestidade. Por quê?

Porque SPACE aplicado de verdade torna conflitos políticos explícitos.

O desconforto da explicitude

O desconforto da explicitude política

DORA permite

  • Discutir tecnicamente sem tocar em poder
  • Focar em 'eficiência do sistema'
  • Otimizar sem questionar prioridades
  • Narrativa de progresso mensurável

SPACE exige

  • Admitir que estamos sacrificando pessoas
  • Reconhecer que eficiência tem custo humano
  • Expor que prioridades são escolhas políticas
  • Aceitar que nem tudo é mensurável

O DORA é confortável para quem prefere evitar perguntas difíceis: você pode aumentar a frequência de implantações sem questionar por que o time está exausto, reduzir o tempo de entrega sem perguntar se o que está sendo entregue sequer importa. Métricas sobem, problemas reais ficam intocados.

SPACE não oferece esse conforto.

Resistência executiva: Preferência por narrativas simples

Executivos preferem DORA porque ele oferece narrativa linear de progresso: “éramos Low Performers, agora somos Medium, caminhando para High.”

SPACE não permite essa história. Ele força admissão: “Melhoramos eficiência sacrificando satisfação. Aumentamos performance às custas de sustentabilidade.”

Isso não cabe em apresentação de reunião de diretoria.

E assim, SPACE é ignorado ou simplificado até perder significado — porque a alternativa seria explicar trade-offs que revelam decisões políticas.

Resistência gerencial: Medo de conversas difíceis

Gestores intermediários resistem ao SPACE porque ele exige conversas que ninguém sabe ter:

  • “Por que estamos priorizando velocidade sobre bem-estar?”
  • “Quem decidiu que quantidade de atividade vale mais que impacto real?”
  • “Estamos dispostos a desacelerar para reduzir carga cognitiva?”

Essas perguntas não têm resposta técnica. Têm resposta organizacional e política. E fazer essas perguntas em voz alta expõe fragilidade das decisões atuais.

Resistência estrutural: Sistemas de incentivo incompatíveis

A resistência mais profunda ao SPACE não é ideológica — é estrutural.

Se seus sistemas de promoção recompensam volume de atividade (commits, tickets fechados), você não pode aplicar honestamente um framework que trata atividade como indicador pouco confiável de produtividade real.

Se suas métricas de sucesso ignoram satisfação e bem-estar, você não pode aplicar SPACE que trata essas dimensões como estruturais.

O sistema já escolheu. SPACE apenas tornaria essa escolha desconfortavelmente explícita.

SPACE tensiona DORA, não o substitui

SPACE não substitui DORA. Ele o tensiona. Ele lembra que sistemas eficientes podem ser desumanos, e que produtividade não é apenas quanto passa pelo sistema, mas como esse sistema é vivido por quem trabalha nele.

A diferença fundamental entre os frameworks

DORA pergunta

  • Nosso sistema de entrega funciona?

SPACE pergunta

  • A que custo?

E essa pergunta não pode ser respondida com um número. Ela exige escuta, interpretação e escolhas conscientes.

A ponte entre sistema e humano

É por isso que, nesta série, o SPACE aparece exatamente aqui. Depois que o fluxo foi entendido, mas antes que a experiência seja explorada em profundidade. Ele faz a ponte entre sistema e humano, entre métrica e significado, entre eficiência e sustentabilidade.

E ao fazer essa ponte, SPACE revela algo fundamental: produtividade não é neutra, e complexidade não é desculpa.

Duas verdades simultâneas

Primeira verdade: Produtividade é genuinamente multidimensional. Reduzi-la a um número sempre sacrifica algo importante.

Segunda verdade: Essa complexidade pode ser instrumentalizada. Usada para evitar decisão, protelar ação, e manter status quo destrutivo sob verniz de “pensamento sistêmico”.

Ambas são verdade. Aceitar apenas a primeira torna você ingênuo. Aceitar apenas a segunda torna você cínico. A postura madura é aceitar as duas e ainda assim agir.

Mas se complexidade não é desculpa e trade-offs precisam ser explícitos, uma pergunta se impõe: como é viver esses trade-offs no dia a dia?

SPACE torna tensões visíveis. Mas visibilidade não é vivência. Saber que satisfação e eficiência entram em conflito é uma coisa. Sentir esse conflito no corpo, no código, e nas decisões cotidianas é outra completamente diferente.


Notas de Rodape

  1. [1]

    A Lei de Conway, formulada por Melvin Conway em 1967, afirma que “organizações que projetam sistemas são constrangidas a produzir designs que são cópias das estruturas de comunicação dessas organizações”. Em outras palavras: a arquitetura do software tende a espelhar a estrutura organizacional. Se dois times não se comunicam bem, os módulos que desenvolvem provavelmente também não se integrarão bem.

  2. [2]

    Forsgren, Nicole; Storey, Margaret-Anne; Maddila, Chandra; Zimmermann, Thomas; Houck, Brian; Butler, Jenna. The SPACE of Developer Productivity. ACM Queue, 2021. O paper introduz cinco dimensões para medir produtividade de desenvolvedores: Satisfaction, Performance, Activity, Communication & Collaboration, e Efficiency & Flow.

Posts Relacionados

Comentários 💬