Um time que busca a melhoria contínua precisa basear-se em dados e resultados. Quando um time usa métricas em benefício próprio, sem o intuito de moldar comportamentos, ele evolui.
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.
Como métricas podem moldar o comportamento de um time?
Cuidado! Se você medir apenas a velocidade de entrega do produto, poderá obter um time muito eficiente, porém com um produto de baixa qualidade. É como se o time fosse uma criança que ficou valente ao ver a água ser tragada 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 levará um caldo daqueles.
Assim, acontece com os bugs (erros). Eles surgem como uma onda e causam um verdadeiro susto no time. Por outro lado, ter um time eficiente e de qualidade, mas que entrega 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 cofundador 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 podemos usá-los para analisar times e empresas, e como definir quais são os próximos passos da Transformação Digital e da 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 equilíbrio das métricas em que um time ágil deve estar sempre de olho.
Eficácia (Negócio)
Nesse domínio, as métricas estão diretamente ligadas aos problemas do negócio. Se o time é criado para resolver problemas, essas métricas traduzem em números o propósito do Time Ágil e medem a eficácia da solução em construção.
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 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 atingido.
História do Usuário
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 a minha escolha.
Podemos dizer que a funcionalidade foi eficaz se aumentou as vendas dos livros 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.
Eficiência (Organizacional)
As métricas do domínio Eficiência estão ligadas à performance do trabalho do time na entrega do produto. Elas servem para conferir previsibilidade ao trabalho, evidenciar gargalos do processo e auxiliar práticas de colaboração, tanto internas quanto externas ao time.
Métricas Kanban costumam fornecer 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.
Qualidade (Técnica)
Essas métricas medem a qualidade técnica do produto em construção e indicam o valor das dívidas técnicas que acumulamos 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.
Atmosfera (Cultural)
Nesse domínio, as métricas medem o quão satisfeitos os participantes estão em trabalhar naquele time ou naquela organização. O número medido é subjetivo e serve apenas ao próprio time. Não é possível usá-lo para qualquer tipo de comparação entre equipes.
As métricas são tão particulares que a troca de participantes provavelmente as alterará, para o bem ou para o mal. Em alguns casos, utilizamos o Hapiness Radar para avaliar 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 de pertencer ao time, na satisfação ao realizar o trabalho, etc.
Outra técnica interessante é o Squad Health Check Model, utilizado pela Spotify. Existem outras técnicas como o NPS do Time, Ações para o Caminho do Nirvana, entre outras.
Conclusão
No texto, temos vários exemplos de métricas para cada um dos quadrantes (domínios), e o equilíbrio entre eles deve ser visto como vital. Todavia, pense muito bem em 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 necessária 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.
Gostou do tema?
Se você quer desbravar esse mundo e se aprofundar nas métricas, temos uma dica: confira nossos treinamentos! 
- Certified Scrum Product Owner (CSPO) (Eficácia);
- Kanban Oficial Kanban University (Eficiência);
- Técnicas Ágeis de Facilitação (Atmosfera);
Veja outros posts relacionados ao assunto no nosso blog:
Quer saber mais sobre métricas? Dá uma olhada nesses artigos aqui:
Sobre métricas
- Quais métricas devo usar?
- Os 3 Níveis das Métricas
- Todo mundo odeia métricas
- 4 dicas para escolher boas métricas
Métricas de gestão de times e empresas
- Métricas de saúde como Guard Rails: Porque você deveria começar a considerá-las
- Gestão 360º: uma visão sistêmica na hora de definir e acompanhar métricas
- Spotify e o poder das métricas
- OKR vs BAU: como gerenciar objetivos estratégicos e o dia a dia
Métricas de Produto
- O que são Métricas de Pirata?
- Métricas de Pirata: cresça seu negócio de forma sustentável
- Métricas de Eficácia: Utilizando as Métricas do Pirata para medir o sucesso ou fracasso do seu produto
- Métricas de Eficácia: Aquisição, Ativação e Retenção
- Métricas de Eficácia: Receita
- Os Problemas do NPS: 4 outras formas de avaliar seu produto e serviço
- Métricas de Produto Digital: como criar e acompanhar seu produto
- 6 dicas para definir métricas de sucesso para seu produto
Métricas de Fluxo (Organização de Times)
- Métricas Ágeis comuns ao upstream, midstream e downstream
- Métricas Ágeis no Cumulative Flow Diagram (CFD): como analisar
- Métricas básicas para seu time
- A confusão do Cycle Time
Métricas Técnicas
