Uma hora de cardio e reflexões sobre métricas no desenvolvimento de software

Retomei os treinos com mais seriedade nos últimos meses. Na rotina, inclui sessões de cardio. Atualmente, 60min diários pelo menos.

O padrão se repete toda sessão: nos primeiros minutos, o corpo resiste. A respiração fica pesada antes de se ajustar, os músculos demandam mais oxigênio do que o sistema cardiovascular consegue fornecer de imediato, e a vontade de parar é forte. Quem treina corrida, sabe bem! Esse desconforto inicial tem explicação fisiológica: ao início do exercício, parte da energia vem de vias anaeróbicas (fosfato de creatina e glicólise, ei nerd!) porque o aumento do débito cardíaco, do fluxo sanguíneo muscular e da ventilação pulmonar leva alguns minutos para se estabelecer. É o que a fisiologia do exercício chama de déficit de oxigênio.

Passados alguns minutos, o corpo encontra o estado estacionário (steady state): a demanda de oxigênio se iguala ao consumo, o metabolismo aeróbico domina, a respiração estabiliza e a vontade de parar simplesmente desaparece. O esforço não diminuiu, foi o sistema que encontrou equilíbrio.

O que me ajuda a atravessar esse período inicial é o monitoramento da frequência cardíaca. Com um intervalo alvo definido de acordo com os meus objetivos, o dado objetivo sobrepõe a percepção subjetiva. A sensação diz para; o monitor diz você está na zona, continua.

Sei que posso estar forçando a barra um pouco, mas consigo ver um paralelo direto com o desenvolvimento de software. Fica comigo!

Times que trabalham sem métricas claras tomam decisões com base em percepções. "Está indo rápido", "a qualidade melhorou", "o time está sobrecarregado". Julgamentos que parecem razoáveis, mas que podem estar tão equivocados quanto a vontade de parar nos primeiros oito minutos do cardio.

O problema não é ter intuição. O problema é confiar somente nela quando o sistema ainda não chegou ao equilíbrio, ou quando as condições mudaram e a percepção ainda não acompanhou. Estimar taxa de entrega, qualidade de código ou impacto de mudanças sem uma referência objetiva é, na melhor das hipóteses, impreciso.

Métricas como as do framework DORA (frequência de deploy, tempo de ciclo, taxa de falha em mudanças e tempo de recuperação) existem exatamente para isso: uma referência que torna as decisões menos dependentes do instinto do momento. O mesmo raciocínio vale para métricas de qualidade de código (cobertura de testes, complexidade ciclomática) ou de experiência do time, como as propostas pelo framework SPACE.

Isso não implica que métricas substituam julgamento. Uma frequência cardíaca alta demais pode indicar treino excessivo ou doença. Por isso, ainda que importante, acompanhar inocentemente somente o número e ignorar o contexto também pode ser prejudicial. Da mesma forma, alta frequência de deploys pode esconder dívida técnica crescente se a taxa de falha não for acompanhada. A métrica informa, mas é a análise do profissional capacitado e experiente que precisa decidir.

Sem uma referência objetiva, a sensação de onde o time está é tão confiável quanto a vontade de parar aos oito minutos de cardio. Às vezes acerta. Com frequência, engana.