Me deu vontade de escrever sobre métricas, indicadores e formas de medir resultados, pessoas e qualquer coisa que você estiver pensando em medir ai na sua empresa.
Bom, a primeira pergunta que você deve responder para si mesmo é: “Qual o propósito desta medição que eu quero fazer?”. Caso a resposta a esta pergunta seja algo parecido com: “Porque eu quero saber …”, pergunte de novo, porque não é esta a resposta mais correta. Se a resposta for: “Porque eu quero saber se está bom ou ruim”, pergunte de novo, porque também não é esta a resposta mais correta. Como último exemplo, se a resposta for: “Porque eu preciso saber se as pessoas estão indo no seu limite ou se estão trabalhando na folga”, bom, você já deve saber a minha opinião sobre esta resposta também né!
A resposta ligada ao propósito da medição deve estar ligada a algum problema a ser resolvido, ou algum crescimento ou evolução esperada para a empresa, produto ou resultados apresentados. Medir por medir geralmente é desperdício, e outra, gera mais problema do que solução.
As medições são tão importantes quanto todo o restante que você faz na sua empresa, e não porque você precisa saber o que está acontecendo, mas sim porque as medições influenciam as pessoas e os seus comportamentos. Tem uma frase manjada que diz mais ou menos assim: “Me diga como serei medido que te direi como me comportarei”, e aqui começam os problemas, ou se você estiver no caminho certo, as soluções.
Em resumo, é melhor não medir nada do que medir errado e gerar comportamentos destrutivos no seu projeto, time ou empresa. Na dúvida, comece pequeno e meça pouco mas com alto propósito.
Então, o que devemos medir? Bom, ai depende 🙂
O que você precisa medir é o que você precisa melhorar, impulsionar, direcionar ou evoluir? Veja, tem que estar atrelado a um verbo positivo e alavancador de alguma coisa.
Quando falamos de trabalho em equipe, que está muito ligado a Agile hoje em dia, os indicadores precisam ser direcionados aos times, e não aos papéis individualmente. Porque? Porque vai impactar no comportamento diretamente! Caso eu cobre o PO de indicador só dele, ele vai responder por este indicador e vai esquecer o resto, e o mesmo serve para outros papéis como SM, Agile Coach, Devs. Lembre-se, todos pertencem a um mesmo time então os indicadores devem ser para todos.
Quando digo um indicador deve ser para todos, não é usar o mesmo indicador para todo mundo, exemplo: “número de horas para todo mundo” ou “número de tarefas realizadas para todo mundo” ou “número de bugs gerados ou resolvidos”. Isso ainda é individual e vai gerar uma competição entre as pessoas. Que tal “Planejamento da Sprint versus entrega da Sprint”, ou “Produto novo entregue a cliente”, ou “Retrabalho realizado no período”. Observe que estes exemplos fazem com que o time todo trabalhe para atender a 1 (um) indicador de todos, não 1 (um) indicador igual para todos.
Quando times trabalham com produto, é preciso pensar em indicadores que façam o time entregar mais produto com maior qualidade ao seu cliente, ou seja, produto com pouca falha e com alto valor agregado. Opa, “buzzword”, “entregar valor agregado”. Bom, aqui eu estou me referindo a um produto que o seu cliente irá utilizar, que resolve algum problema dele e vai mudar a forma com que ele faz algo hoje, isso é agregar valor. Caso você entregue um produto que ele te diga alguns meses depois: “Ahh ainda não usei aquilo que você me entregou”, infelizmente isso significa que você entregou um lixo para ele e o seu indicar deve ir lá para o fundo da terra. Então veja, aqui podemos conectar com o indicador que eu mencionei acima de “Produto novo entregue ao cliente”. A medição deste indicador seria para saber quanto está sendo entregue de produto novo com valor no presente, e qual é a meta de crescimento para o futuro, e quanto é este futuro.
Caso um time trabalhe muito em correção de bugs ou em atendimento de chamados de dúvidas de cliente, classificamos isto como retrabalho, porque isso impossibilita que o time gere produto novo. Muitas empresas medem o número de bugs gerados ou levantados por seus clientes, mas não tomam ações para reduzir o surgimento destes bugs ao longo do tempo. Reclamam sempre que os bugs atrapalham e que não conseguem evoluir. O problema não é medir os bugs, o problema é não colocar metas para diminuição dos bugs e melhoria dos produtos para que este problema seja reduzido no futuro.
Outro ponto importante sobre o investimento em qualidade é que o resultado não aparece de imediato, o retorno vem a médio e longo prazo. Vejo times que não investem em qualidade criticar os times que estão investindo porque os números de bugs não diminuem. Calma, que tal avaliar na linha do tempo depois de alguns meses de investimento? Então, aqui podemos conectar com o indicador que eu mencionei acima de “Retrabalho realizado no período”, e a busca deve ser para diminuir o retrabalho. A medição deste indicador seria para saber quanto é o retrabalho no presente e qual é a meta de diminuição no futuro, e quando é este futuro.
Podemos também pensar em um indicador de planejamento versus entrega de uma iteração curta, conhecida como Sprint :]. Bom, na prática até podemos mudar pequenas coisas dentro da Sprint, desde que não afete o objetivo da mesma, mas e quando as mudanças são maiores e nos atrapalham? Para entender melhor e resolver problemas como este podemos medir se estamos conseguindo manter o planejado e trabalhar e cima de várias reflexões, tais como:
- Estamos priorizando bem? Caso houveram mudanças de priorização dentro da Sprint atual é preciso refletir.
- Estamos estimando/quebrando bem? Caso houveram muitas descobertas de coisas não previstas, atrasos e vários daqueles itens “não percebemos isso lá atrás, só agora”, é preciso refletir, talvez o planejamento esteja fraco.
- Interrupções diversas atrapalharam e não conseguimos entregar os objetivos da iteração. Porque? Qual a origem das interrupções? As interrupções são mais importantes do que o planejado ou será que eu considerei no planejamento situação normal de tempo e pressão que não existe na prática?
- Muitos bugs e erros me tiram do foco do planejamento. Hmmm então? Está medindo retrabalho? No seu planejamento você considera estes bugs durante a Sprint? Que ações esta realizando para diminuir estes bugs e aumentar a sua vazão de produção de coisa nova. (lembrando que corrigir bugs é dinheiro jogado fora e você não está produzindo nada)
- Muitas dúvidas impeditivas foram geradas e não conseguimos ter as respostas em tempo hábil. Opa, será que o backlog foi preparado adequadamente, conduzido pelo PO e apoiado pelo seu próprio time? Reflita.
- No final da Sprint não deu tempo de testar tudo e não entregamos. Opa, quem tem que testar? (todos ok!) Como assim não deu tempo de testar o que vocês estimaram e planejaram? Esqueceram os testes ou deixaram para o final? Reflita.
Bom, daria para mencionar mais uns 100 (cem) itens nesta lista, então vou parar por aqui. Na verdade eu só queria mostrar o porque de medir planejado versus realizado em uma Sprint com um Time Ágil, tendo como objetivo melhorar as entregas, seja na velocidade ou vazão de entrega (mais produto novo saindo), seja na qualidade do que está saindo (menos erros e mais valor agregado – veja valor agregado acima).
Um outro indicador que pode ser utilizado é a satisfação do cliente, que pode ser medido através de vários indicadores que medem satisfação. Vou citar com exemplo o NPS (Net Promoter Score), onde é possível medir se o cliente do seu produto promove e “vende” o seu produto como algo que ele realmente acha útil e resolve um problema dele (promotor), ou se ele detona o seu produto como algo que é uma droga (detrator), ou se ele não está nem ai para o que você entregou para ele (Neutro). Lembre-se que o seu “produto”, pode ser qualquer coisa que você construa, entregue e gere algo para alguém, até um relatório ou documento XPTO.
Quando a gente consegue atrelar estas medições a todos os integrantes do time, significa que o comportamento de todos, independente da sua função, vai caminhar para o mesmo lado, que é atender aos indicadores do time e não os seus próprios, isto estimula o trabalho em equipe, o amadurecimento da equipe, e a própria evolução deste indicadores.
No mais, cada empresa é cada time é um cenário diferente e estes indicadores que citei como exemplo podem fazer sentido para o seu cenário, ou absolutamente nenhum sentido para o seu cenário, não tem problema. Não citei-os para que você utilize, mas sim para que você reflita sobre quais indicadores realmente fazem sentido para o seu cenário em questão e mais, que encaixe no seu propósito de melhorar e evoluir constantemente.
Falando e evolução destes indicadores, logo mais escrevo outro post falando sobre indicadores estratégicos, ROI, benefícios e algunas cositas más.
