Lucas Inocente
/blog/2020-12-21-o-que-estamos-medindo

O que estamos medindo?

No final da semana o time de desenvolvimento ou produto olha para que número para saber se está indo bem ou mal? Tarefas, pontos, tempo fora do ar, conversão...?

O que queremos saber?

  • Velocidade?
  • Comprometimento?
  • Qualidade?
  • Sucesso?

Você com certeza já ouviu algumas das frases "o time de desenvolvimento não entrega", "o time de desenvolvimento é gargalo", "o nosso time não entrega na velocidade que gostaríamos", mas com certeza deve ter ouvido bem menos algo parecido com "nosso time não está indo bem pois não conseguiu alcançar nosso objetivo de aumentar em 10% o número de cadastros".

Por que contamos o que contamos? Qual o objetivo? Por que queremos tanto manter o time de desenvolvimento ocupado? Por que calcular custo de hora de pessoa por custo de hora de projeto? Que diferença faz saber quanto a funcionalidade ABC irá custar se não vamos calcular o quanto de retorno ela trará? Por que tanto interesse em controlar os custos de produção e pouco interesse em saber o resultado que aquele investimento irá retornar?

O código roda por anos sem custo adicional por tempo indeterminado (as vezes tem manutenção para atualização de bibliotecas mas sabemos que a maioria dos times deixam alguns códigos rodando por 5, 10 anos sem nem tirar a poeira...). Como calcular esse lucro em cima do trabalho?

Se uma funcionalidade custou X reais pra ser feita porque demorou Y horas para ser produzida numa média de N reais a hora, quanto ela vai te trazer de retorno? Quantos novos usuários foram cadastrados à partir dela? Quantos clientes foram convertidos, por quanto tempo eles estão ficando na plataforma? Ela ficou fora do ar impossibilitando novas receitas? Esses são os números que devemos olhar no dia a dia do produto. Os times de produto devem olhar métricas de produto. Se o time não vende horas e o time não vende pontos, porque olhamos internamente para esses números se eles não são importantes a ponto de gerarem mais receita? De que adianta medirmos a qualidade de um time pelo volume de entrega se não ganhamos pelo volume e sim pelo retorno que essa entrega estará fazendo?

Vamos imaginar por exemplo que uma nova tela de cadastro seja produzida por 100 horas no seu time de desenvolvimento. Cada hora custa R$ 100,00. Se você pensar em um formato de projeto, irá perceber que a tela custou R$ 10000,00 ao total. Se você pensar em formato de produto, irá analisar que esta tela receberá durante sua vida útil, nos próximos muitos anos, cerca de 500 mil cadastros. Cada cadastro terá um custo de 2 centavos.

A forma que tu vê o time é a forma que você irá medir o sucesso. A forma que você mede o sucesso irá apontar o time pro lado certo. Se o time não vende horas, não meça horas. Se o time não vende pontos, não meça pontos como performance. Claro que é completamente justo medir a velocidade do time para se ter uma ideia do tamanho de um épico, ou pra ajudar também na priorização esforço x resultado, mas qual o motivo de a velocidade ser a métrica principal de um time que não gera receita diretamente pela produção e sim pelo uso de uma determinada feature na plataforma?

Saber a velocidade não irá te dar a resposta se a pergunta for: estamos indo para o lugar certo?