6 erros comuns ao aplicar métricas em times de desenvolvimento — e como evitá-los — Rodrigo Miguel e Cleiton “Caco” Mafra
Não é necessário ser líder no papel, no cargo, para se importar com a performance, reputação e eficiência do nosso time de desenvolvimento, certo? Cada membro do time, e principalmente seu líder, é pressionado para gerar e demonstrar evolução do desempenho do time.
Aqui na Resultados Digitais, por termos como cultura a orientação a métricas, passamos nos últimos anos pelos mesmos dilemas: o que queremos medir, como acompanhar essas métricas e o que fazer com a imensidão de dados que temos à disposição? O caminho até atingir um dashboard de acompanhamento de desempenho dos times não foi perfeito. Sendo bem transparentes, cometemos alguns erros no processo.
Um de nossos gestores de engenharia, o Rodrigo Miguel, e nosso Agile Coach, Cleiton “Caco” Mafra, prepararam a palestra “Métricas — Como NÃO Usar” para o TDC Florianópolis 2018. Além de já terem apresentado no Agile Floripa 2018, e compartilhado internamente esse conteúdo, fruto dos aprendizados aqui na RD mesmo, decidimos então abrir para que você possa também extrair aprendizados para seus times — e ser visto como um líder: alguém que entende quais são os fatores mais relevantes para entender a realidade de um time de desenvolvimento e como reagir à realidade evidenciada pelos dados. Neste post, queremos compartilhar quais foram alguns desses erros, para que você possa evitar que seu time os cometa também.
6 erros comuns na aplicação de métricas
1. Comparar métricas entre times
O primeiro erro que ficou claro pra gente foi querer colocar lado a lado números de diferentes times. Se alguns times trabalham com Scrum, por exemplo, não adianta comparar número de estórias entregues por sprint. Essa métrica não pode ser usada para dizer que um time é ou está melhor que o outro.
O contexto de cada time (maturidade da equipe, nível de débitos técnicos, nível de conhecimento sobre o projeto que está tocando), o tamanho dos itens de trabalho, a gestão das filas do time (se há gargalos em alguma etapa do processo, ou se há etapas com muita variação de duração) são alguns dos fatores que devem ser compreendidos para poder dizer se qualquer métrica de está saudável ou não para aquele time. No final, a melhoria contínua é focada em cada contexto, e cada time deve mirar em ser cada vez melhor que si mesmo, e não que o time do lado.
2. Falar do futuro sem se basear nas métricas
Todos os times precisam responder a famosa pergunta “quando fica pronto?”. Projetos são isso, começam e precisam terminar. Essa previsibilidade é necessária para a transparência com os demais interessados no produto do nosso trabalho (marketing, comercial, produto, clientes e parceiros).
No início, respondíamos baseados em estimativas dos esforços necessários para cada etapa do projeto. Tentávamos prever quanto tempo ia durar um determinado trabalho, e a soma desses esforços era a duração do projeto. Normalmente, descobríamos que estávamos atrasados, e começávamos a nos preocupar em entregar mais rápido. Mas mesmo que tivéssemos acertado (muito raro) em nossas estimativas, a duração do projeto não é a soma do esforço das tarefas. Ainda teriam que ser consideradas todas as dependências e os tempos de fila de um sistema complexo de desenvolvimento e entrega (fila de QA, fila de deploy, fila de revisão de código pelo especialista).
A melhor forma de predizer o futuro é construir a visão dele com base no histórico registrado, como o throughput (a vazão) médio de um time, por exemplo. Ainda assim, estaremos falando de uma estimativa, de probabilidade estatística, mas uma baseada em observação da realidade, e não em achismo. De qualquer forma, se você está medindo o desempenho do time, não chute o prazo, calcule.
3. Transformar métricas em metas
Todos precisamos orientar nossas ações a melhorar algum índice. As metas são a nossa orientação para o que precisamos melhorar. O problema é quando aplicamos metas às nossas métricas. As métricas não servem para serem controladas, mas para evidenciar o ritmo e permitir diminuir a variabilidade do sistema.
Um atleta acompanha seus batimentos cardíacos para monitorar a saúde do sistema ao tentar bater uma meta (diminuir o tempo para percorrer uma distância, por exemplo). Mas não há uma meta para esse ritmo cardíaco.
Com os times, também não faz sentido tentar estabelecer uma meta para a quantidade de entregas por semana, mas entender o que é um ritmo saudável e estabelecer uma margem aceitável. Quando sair da margem, a métrica não é o problema em si. Ela está nos dizendo que algo não está saudável e que há um problema por trás que deve ser investigado.
4. Ter métricas sem acionáveis
Toda a ideia de ter as métricas é conseguir identificar problemas a serem resolvidos. Acompanhar o trabalho através de um CFD (cumulative flow diagram) nos ajuda a identificar gargalos no sistema, por exemplo. A partir disso, podemos investigar mais a fundo.
Na investigação, podemos identificar que em um determinado período tivemos um aumento no lead time médio de entrega de tarefas. O que aconteceu? Tivemos um problema no deploy? Um dos membros da equipe ficou doente? Alguma outra tarefa urgente roubou foco de um pedaço da equipe?
As métricas precisam ser úteis para identificar os problemas e dar início às investigações. Mas de nada adiantam se usarmos qualquer problema como desculpa para algo ter acontecido, ao invés de realmente entender e atacar a causa raiz, para evitar futuros impactos da mesma forma. Seja resolvendo um problema, criando caminhos alternativos ou mecanismos de reação rápida. Com as ações tomadas, é preciso voltar a observar a situação novamente, para garantir que o problema foi resolvido. Ir no detalhe entender o problema, estudar as causas, planejar e executar ações, e observar novamente.
5. Usar métricas como vitrine do time
Não é difícil cair na tentação de olhar para um gráfico de entregas de um determinado time, com esse formato, e querer dizer “aumentamos o desempenho do time em 300%”. Já fizemos isso.
O problema é que gerar esse comportamento na métrica é bem fácil. Apenas com a redução do tamanho do lote (granularidade de tarefas), fica fácil continuar entregando a mesma coisa, só que mostrando mais números de “cards em done”. Diminuir o lote não é ruim — muito pelo contrário. Aumenta flexibilidade e diminui risco. Mas a mensagem do aumento do desempenho não é real. Não necessariamente aumentou a velocidade de valor chegando na mão do cliente, e usar uma métrica como vitrine pode passar uma mensagem errada, e mascarar o verdadeiro problema.
Esperar sempre ganhos rápidos
A verdade é que em times que estão buscando melhoria contínua, se embasando em métricas para identificar problemas e aplicando soluções cirúrgicas para gerar essas melhorias, algumas vezes o resultado de uma pequena mudança pode vir muito rápido. Isso é ótimo, e gera uma sensação de vitória no time. Mas nem sempre vai ser assim. Em diversas vezes, o time vai ter períodos de estabilidade, e as melhorias não geram um impacto tão grande. Algumas mudanças, inclusive, podem custar um pouco do desempenho do time temporariamente, antes de estabilizar novamente. A alta performance não é a respeito de subir a montanha. É a respeito de conseguir se estabilizar no topo da montanha.
Estamos sempre abertos para conversar com pessoas interessadas em melhorar a performance de seus times. Se alguém quiser entender onde está errando, esses 6 erros comuns podem ser o começo da conversa.
Para entender mais a fundo os pontos abordados, disponibilizamos o vídeo da palestra ministrada aqui na RD. Também, trouxemos as recomendações de livros dos palestrantes. Se ainda restarem dúvidas, ou se você quiser compartilhar um erro que gerou aprendizado em seus times, comenta aqui no post!
