As métricas que realmente revelam a saúde da sua equipe de Engenharia
Desde que assumi o papel de Coordenador de equipes multidisciplinares e de senioridades desde Junior a um Senior / Tech Lead, com mentorias desdes mais seniores aos mais juniors, percebi que as métricas ágeis tradicionais (como Velocity e Burndown) contam só uma parte da história.
Medir apenas o output ignora o trabalho “invisível”, punindo o esforço de mentoria e qualidade nas revisões. Para ser mais justo e ter uma visão holística, precisamos de métricas que avaliem a saúde da equipe, olhando o fluxo de entrega e a qualidade técnica
Aqui vai um guia que fui montando e que dependendo da empresa, podemos ter dificuldade em aplicar, mas é super importante para manter o engajamento e a saúde da equipe.
O padrão ouro das entregas: Famosa DORA Metrics
As métricas DORA são fundamentais porque acabam não medindo o quanto trabalhamos, mas sim a nossa capacidade de entregar valor ao cliente, de uma forma rápida e segura.
Lead Time for Changes: O tempo que leva de um commit ser feito até este código estar em produção e nas mãos dos usuários.
- Se o tempo for alto, o problema pode estar no seu processo (testes de desenvolvimento, aprovações, build), não necessariamente no desenvolvedor
Deployment Frequency: Com que frequência é realizado deploy de sucesso.
Menos deploys e maiores, você pode correr mais riscos.
Mais deploys e menores, menos risco e maior agilidade.
CFR (Change Failure Rate): A porcentagem de deploys que resultaram em uma falha e acaba exigindo um hotfix ou até mesmo o próprio rollback.
MTTR (Mean Time To Restore): O tempo médio para recuperar um serviço após alguma falha.
Se o seu Lead Time é baixo mas o seu CFR é alto, você está entregando mais rapidamente mas está sendo descuidado, com menos qualidade. Esse equilibrio entre os números por trás das métricas é o que mostra a maturidade da sua cultura de qualidade.
O Desafio de uma equipe mista: Visibilidade para a mentoria
Em uma equipe de mais senioridades, de Juniores a Seniores, a contribuição de pessoas com Senioridade maior é a mentorização, e não somente a linha de código. Para isso, precisamos de métricas que revelem esse valor:
Métricas de colaboração e fluxo interno
Tempo de Code Review: Quanto tempo que uma PR (Pull Request) fica aberta esperando revisão.
Alerta: Se este tempo for muito alto, os Seniores estão atuando como gargalos.
Ação: O líder precisa intervir para proteger o tempo dos Seniores, deixando blocos e um espaço específico para revisão ou também deixando um espaço para os Plenos ajudarem nessas revisões.
- Uma dica é realizar uma espécie de retrospectiva e entender se as pessoas Seniores estão tendo muita reunião que acaba tomando seu tempo e se essas reuniões podem ser coordenadas de outra maneira ou estão dedicando 100% do seu tempo em codificar.
Distribuição de Revisões: Quem está revisando o código de quem?
- Alerta: Se um Sênior faz 80%+ das revisões, ele pode estar sobrecarregado e pode ser perigoso para o futuro da equipe.
Medindo o crescimento
- Tempo para os primeiros PRs serem mergeados, especialmente para mais Juniors. Essa métrica mede a eficiência das suas PRs e do suporte necessário para que ocorra a evolução delas.
Já vivenciei cenários de Pessoas mais Juniores com dificuldade em entregar PRs por conta de alguns cenários como esses. Ter um plano de carreira bem estruturado também ajuda para poder direcionar as Pessoas do seu time, com exemplo prático do que se espera de cada Senioridade.
A saúde Holística: Falando um pouco sobre a Satisfação e a Eficiência e Fluxo do framework SPACE
Nenhuma métrica de performance fará sentido se a sua equipe estiver exausta. O framework SPACE, traz a dimensão humana, garantindo que o seu foco seja sustentável.
S (Satisfaction): Usar um check-in de saúde rápido, podendo por exemplo, ser dentro da sprint (quinzenal) para medir o nível de motivação, stress e sentimento de pertencimento de um membro da equipe.
- Um exemplo, é perguntar: "Você se sentiu apoiado pela equipe nesta sprint?"
E (Efficiency and Flow): A métrica mais importante aqui é o "Deep Work". Você precisa garantir que sua equipe tenha tempo ininterrupto para programar.
- O Alerta: Se a equipe reporta no Check-in que foi constantemente interrompida (por reuniões, mensagens), o Coordenador precisa instituir dias ou períodos de "Foco Total" (sem reuniões).
Qualidade silenciosa: Evitando retrabalho
Se o código for insustentável, a velocidade da entrega é só uma ilusão!
Taxa de retrabalho: A porcentagem de código que é alterada pouco tempo após a sua implementação, por exemplo, no primeiro mês.
- Alerta: Alto Retrabalho indica falhas no refinamento da história (alerta para o time de Produto) ou que o código original não estava robusto o suficiente.
Cobertura de Testes (em Áreas Críticas): Não fique encanado apenas à porcentagem total. Concentre-se em garantir que as funcionalidades core do seu negócio estejam bem testadas.
Lembre-se: uma métrica nunca deve ser usada para punir um indivíduo.
Concluindo esse post sobre um pouco do que já vivenciei, o papel do coordenador é usar métricas para:
Identificar Gargalos no processo (podemos olhar o DORA).
Valorizar o Trabalho Sênior de mentoria (Colaboração).
Proteger o Tempo da sua equipe (SPACE - Deep Work).
Use estes dados para sentar com o time, apontar o problema no processo (ex: "O Code Review está lento") e encontrar a solução em conjunto.
Uma boa retrospectiva ajuda, mas as métricas servem para serem utilizadas no dia a dia. Se não está funcionando, não espere dias para entender e mudar.
Um papo muito bacana sobre SPACE, que acompanhei esses dias, foi com o Phil Alves, com o Edu Matos:
E por aqui, também falo um pouco sobre Agilidade para maximizar a produtividade
