Um time que busca a melhoria contínua precisa basear-se em alguns dados além de resultados. Quando um time usa métricas em benefício próprio, sem o intuito de moldar comportamentos, ele consegue evoluir.
Sobre o uso de métricas, o pensamento precisa ser assim: se não medimos, não sabemos onde estamos. Se medimos errado, acreditamos estar em um lugar, quando, na verdade, estamos em outro. Se a métrica é irrelevante não faz sentido medir.
Quer ouvir o artigo sobre Métricas? Aperte o play!
Cuidado! Se você medir apenas a velocidade de entrega do produto, então poderá ter como resultado um time muito eficiente, porém com um produto de qualidade ruim. É como se o time fosse uma criança que ficou valente após ver a água ser sugada para o mar, mas, mesmo assim, saiu correndo em direção a ela. Em breve, a água voltará muito mais forte como uma onda e ela levará um caldo daqueles.
Assim, acontece com os bugs (erros). Eles surgem como uma onda e dão um verdadeiro susto no time. Por outro lado, ter um time eficiente e com qualidade, mas que faz a entrega de um produto sem valor, é como afundar no Titanic ao som de violino e saboreando um chá inglês. Então, em um cenário assim, surge uma dúvida: o que devemos medir?
Em 2014, o co-fundador da K21, Rodrigo de Toledo escreveu o artigo Até onde vai a agilidade?. Nele, foram apresentados os quatro Domínios da Agilidade (Negócio, Organização, Técnico e Cultural), como nós podemos usá-los para realizar a análise de times e empresas e como definir quais são os próximos passos da Transformação Digital e Transformação Ágil. Quer saber tudo sobre Agilidade? Conheça nosso hub de conteúdos!
Além disso, podemos usar os quatro domínios para mantermos o balanceamento das métricas em que um Time Ágil deve estar sempre de olho.
Exemplo de Métricas nos 4 Áreas de Domínio da Agilidade
Nesse domínio, as métricas estão ligadas diretamente aos problemas do negócio. Se o time é criado para resolver problemas, essas métricas traduzem para números o propósito do Time Ágil e medem a eficácia da solução que está sendo construída.
Em métodos ágeis, os requisitos do produto normalmente descritos no formato de História do Usuário (User Story) não devem ser tratados como certezas absolutas que temos sobre a solução que estamos desenvolvendo. Na verdade, os requisitos são apenas hipóteses que podem ou não resolver o problema. A cada lançamento do produto devemos avaliar a eficácia da entrega. Caso você use o formato de História de Usuário, essas métricas ajudam a medir se o Para foi alcançado.
Eu enquanto <persona/usuário real>
Desejo <funcionalidade, hipótese de solução do problema>
Para <problema a ser resolvido>
Exemplo: Eu, cliente regular do site X, desejo uma lista de recomendações de livros para facilitar o meu processo de escolha.
Podemos dizer que a funcionalidade foi eficaz se ela aumentou a quantidade de vendas dos livros que estavam na lista de recomendações dos clientes regulares do site. Objectives and Key Results (OKRs) é uma boa técnica para definir não apenas a métrica, mas também o alvo que queremos atingir.
Leia também o artigo do Agile Coach da K21, Magno de Santana, para saber como escolher essas métricas.
Exemplos: Atendimento, Comportamento do Usuário, Churn, Crescimento no Mercado, Custo de Aquisição, Custo do Atraso (Cost of Delay), Custo de Operação, Faturamento, Fatia do Mercado, Fatia dos Canais de Contato, Fitness For Purpose Score (F4P), Lifetime Value (LTV), Payback, Métricas do Pirata (Aquisição, Ativação, Retenção, Receita e Referência), Net Promoter Score (NPS), Retorno sobre o Investimento (RoI), Sentimento Social, Usuários ativos, Vendas, etc.
As métricas do domínio Eficiência estão ligadas à performance do trabalho do time em relação à entrega do produto. Elas servem para dar previsibilidade ao trabalho, evidenciar gargalos do processo e auxiliar práticas de colaboração internas e externas ao time.
Métricas Kanban costumam prover bons indícios de eficiência. Essas métricas podem ser obtidas por meio da análise das Histórias do Usuário, que são mapeadas por grau de importância em um determinado quadro de atividades (Quadro Kanban, Quadro Scrum, Task Board, Quadro do Time, como você preferir chamá-lo).
Exemplos: Lead Time, Tempos de Ciclo, Tempo de Execução (Touch Time), Tempo de Espera (Waiting Time), Trabalho em Andamento (Work in Progress, WIP), Vazão.
Essas métricas medem a qualidade técnica do produto que está sendo construído e indicam o valor das dívidas técnicas que criamos ao longo do desenvolvimento.
Exemplos:
A qualidade técnica de um produto pode ser mensurada por meio de:
– Falhas – a quantidade de falhas (bugs) e a quantidade de usuários afetados por elas;
– Código – se o software tem cobertura de testes automatizados, qual é a complexidade do código-fonte ou a duplicação deste código;
– Performance e segurança, isto é, pela carga de acesso ao sistema, pela quantidade de invasões e de usuários simultâneos, além do consumo de CPU, memória e HD.
Nesse domínio, as métricas medem o quão satisfeito os participantes estão para trabalhar naquele time ou organização. O número medido é subjetivo e serve apenas para o próprio time. Não é possível usá-lo para nenhum tipo de comparação entre equipes.
As métricas são tão particulares que a troca de participantes provavelmente irá alterá-las para o bem ou para o mal. Em alguns casos, utilizamos o Hapiness Radar para avaliar alguns aspectos importantes do time, tais como, os processos, as ferramentas e as práticas usadas no trabalho, no relacionamento com os colegas, na satisfação pessoal de pertencer ao time, na satisfação em realizar o trabalho e etc.
Outra técnica interessante é o Squad Health Check Model, usada pela Spotify. Existem outras técnicas como o NPS do Time, Ações para o Caminho do Nirvana, entre outras.
No texto, nós temos vários exemplos de métricas para cada um dos quadrantes (domínios) e o balanceamento entre eles deve ser visto como vital. Todavia, pense muito bem quais delas você quer manter em cada área. Se o time olha para muita coisa, ele não prestará atenção em nada.
Escolha apenas a quantidade suficiente para que o time não fique perdido. As métricas devem ser poucas, simples de medir, fáceis de compreender, relevantes para o caminho que o time está buscando e elas devem poder ser influenciadas pelo trabalho do time.
Se você quer desbravar esse mundo e se aprofundar nas métricas, temos uma dica: confira os nossos treinamentos! 
Apaixonado por inovação, com experiência em desenvolvimento de produtos digitais utilizando práticas de Design Thinking, Lean Startup e Desenvolvimento Ágil
Compartilhar
