Ahhh sua empresa finalmente resolveu trabalhar com métricas. Que maravilha! Todos acompanhando o Customer Lead Time de todos os times, olhando para a taxa de retenção de clientes, acompanhando o RoI das iniciativas. Finalmente você está em uma empresa 100% Orientada a Dados (Data-Driven)!
Ouça este artigo!
É nesse momento que toca o despertador e.... Tudo não passou de um sonho.
Trabalhar com dados e fatos é algo que todos dizem querer, mas na prática é muito mais difícil do que parece. Você já participou de reuniões e mais reuniões em que você poderia até criar um Bingo de Métricas em que você pode esperar que as seguintes frases sejam ditas:
| Quanto tempo leva para entregar….? | Qual o impacto disso? | Quanto vamos atrasar? (leia-se você vai atrasar) |
| Por que essa área demora tanto? | Isso não é culpa minha porque a minha prioridade é… | Se estabelecer direitinho o que tem que ser feito com antecedência, então faremos. |
| Vamos marcar outra reunião para falar desse assunto. (normalmente é muito mais importante do que todos que serão discutidos na reunião corrente). | Eu preciso de números para tomar essa decisão, mas nesse momento não os tenho. | A clássica e lendária: “Faltou combinar com os russos”. |
Por curiosidade, a frase “Faltou combinar com os russos” teve origem na Copa do Mundo de Futebol Masculino de 1958 quando o técnico da seleção brasileira, Vicente Feola, apresentou um plano tático muito bem montado que garantiria a vitória do Brasil contra a União Soviética.
Garrincha, jogador do Glorioso Botafogo e ponta-direita da Seleção Canarinho, percebeu a falta de praticidade daquele “maravilhoso plano” e questionou o treinador: “Seu Feola, o senhor já combinou com os russos?”. Garrincha já tinha agilidade no sangue.
Deixando as curiosidades futebolísticas de lado, vamos para a prática. No que você deve pensar quando deseja adotar o trabalho baseado em métricas?
Neste Artigo
Data-Driven é Construir, Medir e Aprender
O ciclo Construir, Medir e Aprender não é utilizado apenas quando construímos um produto, deve ser usado em outros pontos da agilidade. Inclusive no aperfeiçoamento de times e organizações. Pense que a adoção de métricas também deve respeitar esse ciclo baseado no Plan, Do, Check, Act (PDCA) – Planejar, Executar, Avaliar e Agir.
1. Construir – Preparando a Medição
Antes de termos números, precisamos fazer um set up (preparação). É muito importante para manter a sua sanidade ,meu amigo e minha amiga agilista.
Imagino que você esteja em uma empresa com alguns times (ou squads, como preferir chamar) e que você tenha que olhar para eles ou, no mínimo, o relacionamento entre eles.
Se cada um decidir tocar o “seu mundo” como der na telha, você terá um megaproblema no futuro tentando juntar informações para chegar a alguma coisa minimamente compreensível. Logo, vamos começar com o básico.
Uma ferramenta Data-Driven
Existe um universo de ferramentas que podemos utilizar para a gestão do fluxo de valor / trabalho dos nossos times: Jira, Trello, ScrumHalf, IBM Rational Team Concert (RTC) com Aplication Lifecycle Management ALM , Azure Boards, Kanbanize e muitas outras.
Escolha uma e somente uma delas para todos os times da organização. Se você tiver um time utilizando o Jira, o outro usando o Trello e outro usando Excel, o tempo que você gastará juntando informação será enorme, algo como:
Definição clara dos itens de trabalho
Uma vez que escolhemos a ferramenta, temos que ter uma definição muito clara de quais itens de trabalho representam o quê.
No artigo Product Backlog: Épico, História de Usuário e Tarefas falei sobre o problema introduzido pelas ferramentas e como cada uma introduziu a sua própria nomenclatura para itens de valor / trabalho e a confusão que isso causa nos times. Logo, você precisa que os times tenham uma definição clara do que é o quê. Por exemplo:
Épico são histórias tão grandes que nós não conseguimos construí-las. Ela deve ser fatiada em histórias menores que entregam valor.
Histórias são os itens de valor que podem ser construídos pelo nosso time. Suas características primárias são: Entregam valor e o cliente final “toca” no incremento produzido por ela.
Tarefas são atividades técnicas que devem ter no máximo 1 dia de duração e que, sozinhas, não entregam valor, mas são fundamentais para a construção da história.
Se você utiliza uma ferramenta que já se baseia nessa estrutura, como é o caso da ScrumHalf, beleza, nada a fazer. Caso contrário, você deverá fazer um Dê-Para.
Exemplo: Se você utiliza o Jira, então todos os itens marcados como Epic ou Features são épicos. Todos os itens marcados como Story ou Bug são Histórias e todos os itens marcados como Subtasks são Tarefas.
Cuidado, pois o Jira, Azure Boards e RTC-ALM permitem que você crie outras categorias de itens de valor. Para cada um deles faça o dê-para. Se você utiliza ferramentas como Trello ou Kanbanize, provavelmente utilizará capas ou tags para diferenciar um item do outro.
Exclusão de itens de natureza distinta
Podem existir itens no quadro do time que você não deseja acompanhar no momento. Por exemplo, eu gosto de colocar as ações de melhoria que são o resultado da retrospectiva (muitas vezes chamado de Kaizen) no quadro do time. Para que as ações estejam sempre visíveis e não saiam do radar do time e se tornem algo secundário.
Todavia, a gestão sobre essa melhoria deve ser apartada do fluxo de valor do produto. Por exemplo, se eu meço o Customer Lead Time de um time, não quero que essa ação de melhoria interfira no cálculo porque é um trabalho com natureza distinta do propósito primário do time.
Ponto de Compromisso e Ponto de Entrega
Todas as métricas estão vinculadas a alguns marcos nas etapas do fluxo de valor. Dois deles são fundamentais. O primeiro é o ponto de compromisso. Qual é a etapa do fluxo de valor / trabalho em que o time se compromete com o item de valor? Como se o time dissesse: “Cliente (gestor, investidor), deixa comigo, vou entregar isso aqui para você”.
A maioria das métricas passam a contar a partir desse ponto. Logo, seja muito transparente com ele. Todo o time tem que saber que aquele é o Ponto de Compromisso. Os gerentes têm que saber que aquele é o ponto de compromisso. Muitas das vezes os clientes também têm que entender que o ponto de compromisso é aquele. Antes dele, temos apenas ideias e elas valem 10 centavos a dúzia (frase atribuída a Mary Kay Ash).
Ponto de Entrega também é outro marco fundamental, pois é justamente o momento em que paramos de contar as métricas.
Esse ponto é quando a sua história DE USUÁRIO que foi quebrada em tarefas, navegou no fluxo de trabalho, virou um incremento é disponibilizada (entregue) para o usuário (cliente ou consumidor final). Não falta mais nada para ser feito. Como se o time dissesse: “Cliente (gestor, investidor), lembra aquele item que eu me comprometi? Pois bem, aqui está ele. Pode usar”.
Talvez você pense, mas o meu time não faz a entrega. Eu entrego para um outro time que tradicionalmente tem nomes como: Deploy, Delivery, Devops ou algo nesse sentido e esse time é quem entrega para o cliente. Não seria mais correto trazer o meu Ponto de Entrega para o momento que eu “entrego” para esse time?
Bom, aprendi uma frase em francês que tenho usado com muita frequência: “Je suis désolée” Em tradução direta seria: Eu sinto muito, mas com um jogo de palavras acaba parecendo: Eu estou desolado. Se você quiser usar o carioquês pode mandar aquele: “Só lálá” (Só lamento).
Seu cliente não tem culpa nenhuma se entre você e ele(a) acrescentaram mais dez times. O Ponto de Entrega é o ponto de entrega. É o momento em que o seu cliente recebe valor e sua empresa percebe valor. O esforço investido no meio é importante para gerar valor, mas sozinho não representa valor.
Qual será o fluxo de trabalho (workflow) que iremos visualizar?
Aqui há algumas definições que precisamos fazer. Não tem resposta certa. Há vantagens e desvantagens em cada opção e ao tomar uma decisão temos que saber o que estamos abraçando e o que estamos perdendo.
Fluxo de trabalho do produto ou do time?
Fluxo de trabalho do produto significa que vemos todas as etapas de todos os estágios do fluxo.
Digamos que eu tenho um time que é responsável pelas seguintes estágios do fluxo: Priorização, Construção, Avaliação. No final ele passa para o time de Entrega (dependência externa). Se eu represento no quadro todas as etapas dentro desse estágio de Entrega, então eu acompanho o fluxo do produto. Todos os times necessários em um único quadro.
Vantagens:
- Foco na entrega de valor independente da responsabilidade;
- Fluxo de trabalho real;
- Todos olhando para um mesmo local.
Desvantagens:
- Quadro complexo;
- Muita informação;
- Aperfeiçoamentos no fluxo requer ciência dos outros times.
“Meu Deus, vai ser muito difícil fazer isso. Esse time de entrega terá que ter um quadro para cada time que atende”.
Agora que a escolha de ferramenta será importante. Em ferramentas como Jira e Azure o quadro não passa de um filtro. Logo, você pode criar um Filtro no qual o time só vê o trabalho dele (Figura 2), outro em que o time de entrega vê tudo o que tem para fazer (da linha tracejada em diante) e um quadro completo que visualiza o fluxo do produto (Figura 3).
Já o Fluxo do Time é aquele apresentado na Figura 2. A entrega, como não está sob a minha responsabilidade, é uma espécie de Buraco de Minhoca. Entra demanda e sai entrega e eu não sei como a mágica acontece lá dentro.
Vantagens:
- Trabalho bem delimitado e independente;
- Sabemos exatamente como está o nosso time;
- Apenas informações relevantes para o nosso time.
Desvantagens:
- Trabalho das dependências externas totalmente desconhecido, falta de transparência;
- Fortalecimento de silos de conhecimento e superespecialização;
- Cada time tem a sua prioridade.
Fluxo de Trabalho Único ou cada time tem liberdade para criar o seu?
Essa aqui é polêmica. Não padronizar nada tornará a empresa gasosa e cada quadro trará surpresas para você, ó Guerreiro / Guerreira da Agilidade. Você vai descobrir que colocaram pontos de compromisso muito depois do acordado, ponto de entrega antes dos testes.
Cada cabeça, uma sentença. Todavia, a liberdade para mexer no quadro tem uma grande vantagem. Ela facilita que o time represente a realidade dele com todas as particularidades do contexto em que ele está inserido.
O contrário de gasoso é sólido. Todos os fluxos de trabalho são iguais para todos os times. Ninguém pode mexer em nada. Facilita muito a obtenção de métricas. Todavia engessa ou até mesmo paralisa as melhorias no fluxo. Siga a dica do Bruce Lee:
O ideal (mas nem sempre prático) é nem ser tão gasoso que cada quadro seja uma surpresa e nem tão sólido que impeça a melhoria. Mudem, melhorem, mas harmonicamente e de forma que não quebre o produto e muito menos a empresa.
Com quais métricas vou começar?
Essa é uma pergunta excelente antes de começar o nosso modelo Data-Driven. Há dezenas ou centenas de métricas que podemos utilizar para medir a eficiência, eficácia, ecossistema e excelência do time. Não tenho uma resposta pronta para te dar.
Você pode acabar com uma disfunção de ter um monte de métricas na mão, mas não saber o que fazer com elas. Seria como ter soluções e ficar procurando problemas para encaixar nelas. Vamos fazer o contrário: Dado que eu tenho problemas, quais métricas seriam interessantes para nós:
1) medirmos o tamanho do problema
2) sabermos se a solução que estamos construindo está ou não resolvendo o problema?
Comece com poucas métricas, por exemplo, uma por domínio da Agilidade, e expanda conforme necessário.
Use sempre a dica do Balu: 🎵🎵“Necessário, somente o necessário, o extraordinário é demais”.🎵🎵
Eficiência
Minha resposta acabaria por aqui, mas digamos que você é uma pessoa insistente e quer porque quer uma dica sobre qual métrica adotar. Bem, nesse caso:
Customer Lead Time é justamente o tempo decorrido entre o compromisso e a entrega e ele é o que melhor mede a eficiência do seu time / organização. Ele também é uma métrica base e dele derivam outras que também são importantes. Escrevemos sobre isso no artigo: Métricas Ágeis no Cumulative Flow Diagram (CFD).
Eficácia
Return on Investment (Roi) – Retorno sobre o Investimento. Quanto a empresa ganha dividido pelo quanto a empresa investe.
Ecossistema
Satisfação do Time. Escrevemos sobre isso nos artigos Radar da Satisfação e Pesquisa de satisfação de times: como funciona o método Health and Check?
Excelência
Quantidade de erros (bugs) reportado e resolvidos e comparativo entre a quantidade de erros e quantidade de entregas.
Quem avisa amigo é
OK, você pediu e eu dei um conjunto básico de métricas para cada área de domínio da agilidade. Todavia muito cuidado ao tomar isso como verdade e sair apresentando para toda organização.
Imagina se você chega naquela reunião com todo mundo (time, gerente, diretor, cliente) e fala: “Galera, o RoI do nosso produto é -10%. Somos um baita preju.”. Seria o equivalente a apagar a luz e lançar fogos de artifício em uma sala 2x2 fechada.
Se o seu produto for uma aposta e a expectativa de resultado for de médio, longo prazo, essa informação é apenas criadora de caos e irrelevante no momento. Cuidado, muito cuidado com métricas prontas.
Tem uma frase famosa dos estudiosos bíblicos que diz: Texto sem contexto é pretexto para heresia. Deixo aqui a minha versão:
Métricas sem contexto é a alvorada do caos.
Avelino F. Gomes Filho - Depois de cometer esse erro algumas vezes
A Regra dos 3 + 1 As das Métricas
Segundo Eric Ries em seu livro A Startup Enxuta, Uma boa Métrica deve respeitar a Regra dos 3 As.
Acessível
Você descobre uma métrica muito legal, mas você não tem os dados para gerá-la ou não tem autorização para obtê-los, ela está inacessível. Se é inacessível é apenas um desejo e você não a terá.
Auditável
As informações são confiáveis e é possível provar que se outra pessoa partir dos mesmos dados, chegará às mesmas informações.
Acionável
Uma boa métrica gera ação. Se a métrica está ali apenas para você ficar olhando para ela e não servir para tomar nenhuma decisão, compre um quadro.
Apresentável
Permita-me a empáfia de adicionar mais uma regra às regras dos 3 As. Esta quarta regra seria: A métrica deve ser apresentável.
Se para compreender a métrica for necessário que a pessoa tenha profunda compreensão de matemática aplicada ou estatística avançada, por mais linda que seja a equação, ninguém prestará atenção nela.
Já visitei empresas que utilizavam KPIs com 36 variáveis. Dava preguiça só de ler a fórmula, imagine compreender o que está acontecendo e dali extrair alguma ação.
2. Você não será Data-Driven se não começar a MEDIR
Agora que você e seu time definiram a ferramenta (perceba o singular utilizado), categorizaram os itens de valor / trabalho, removeram da medição aquilo que vocês não desejam medir agora, deram transparência aos pontos de compromisso e entrega e decidiram as poucas e essenciais métricas que serão utilizadas. Está na hora de medir.
No geral, as ferramentas mais robustas como Jira, ScrumHalf, Azure Boards, RTC-ALM possuem relatórios que facilitam a extração das medições.
Algumas outras como o Trello possuem plugins que auxiliam a obtenção desses números. Veja a melhor forma de extrair essa informação. Na pior das hipóteses, a maioria delas permite que você extraia dados brutos e trabalhe com eles em planilhas Excel ou Google Sheets.
3. Você também não será Data-Driven se não APRENDER
Toda medição trará um aprendizado. Afinal, você quer tornar seu time / empresa Data-Driven.
Infelizmente, muitas vezes esse novo conhecimento pode ser chocante. Já estive em time que não percebia que o Customer Lead Time deles era de 65 dias (tome como base que uma Sprint muito longa de Scrum tem no máximo 30 dias).
Já estivemos em outro time que ao comparar a Taxa de Aquisição de Clientes com a Taxa de Abandono (Churn) descobriu que o produto se tornara insustentável há cinco meses atrás.
Para quem você quer mostrar esse aprendizado?
Que você aprenda é uma coisa, agora para quem você quer apresentar o aprendizado? Time, Gestores, Diretoria, Presidência, Clientes? Para cada um deles, escolha quais informações você deseja apresentar e como apresentar.
Geralmente as métricas de ecossistema ficam dentro do time, as métricas de eficiência e excelência afetam o time e gestores diretos.
Da diretoria para cima, é comum que apenas as métricas de eficácia façam sentido. Na verdade, as métricas dessa área começam no time e chegam até o nível estratégico e, em alguns casos investidores, da organização.
Uma dica, para o time você pode apresentar as métricas em um formato mais bruto com relatórios de ferramentas, planilhas etc.
Agora, quanto mais alto você estiver indo na hierarquia da organização, o ideal é que você formate melhor como você vai apresentar essas informações. Gráficos e ferramentas de apresentação (Google Presentation, PowerPoint, Keynote, entre outras) também são de bom tom.
Sempre seguindo a dica do Balu que discutimos acima, nada de apresentar 100 slides. Quanto mais alto na hierarquia que você está, menos tempo as pessoas têm e menor a quantidade de informações você deve apresentar. Estamos falando de algo em torno de 4 ou 5.
Gosto do formato capa (normalmente as empresas têm um padrão), resultados obtidos, feedbacks dos clientes (caso existam), aprendizados e próximas ações. Você pode ter mais informações, mas foque nessas.
Espere reações adversas
Eu gostaria muito de encerrar esse texto dizendo: (imagine um carioca falando, trocando S por X 😊): “Pô mermão. Depois de usar métricas, ‘as paradas’ ficam muito ‘maneras’”. Todavia estaria mentindo.
O mais correto é: “'Mermão', 'Mermã'”, depois de começar a usar métricas há uma tendência de que as coisas piorem para o teu lado". Data-Driven traz problemas a tona e colocam dogmas à prova.
As pessoas reagem das maneiras mais emocionais possíveis quando os assuntos são fatos e dados. Vide o debate em torno da pandemia de COVID19 e, na sequência, o debate sobre as vacinas contra o COVID19.
Saiba que há pessoas que mesmo que você traga uma infinidade de números, fatos e dados elas continuarão insistindo que todos estão errados, menos ela. Principalmente se a métrica afetá-la negativamente. Haverá pessoas que tentarão te diminuir, questionar as informações, pedir uma galáxia de outros dados, relatórios, filtros e somatórios para te sobrecarregar. Como diz o meme:
É raro, mas acontece muito
Mudança de Cultura não é uma chave de liga-desliga
Resista bravamente, pois maturidade para a empresa se tornar Data-Driven só se conquista com esforço. Estamos tirando a empresa de um estágio amador e indo para o profissional. Essa mudança de cultura vai levar um tempo.
Veja por exemplo o caso das corridas de Fórmula 1 (F1). Nos anos 50-60 eram basicamente criar um carro de corrida e torcer para tudo dar certo. Só para ter ideia, a recomendação para os pilotos usarem cinto de segurança é de 1968. Nos 10 anos iniciais da F1 23 pilotos morreram. Hoje, se a repimboca da parafuseta do canto superior lateral direito tiver um problema, já tem um sensor avisando tanto o piloto quanto a equipe.
Se a pessoa que começou a pensar em alinhar métricas com performance e segurança na F1 tivesse parado no primeiro obstáculo, das duas opções, uma: ou não haveria mais corridas porque a quantidade de mortes seria inadmissível ou continuaríamos perdendo mais de um piloto por ano.
Descubra o ponto de alavancagem
O exemplo da F1 é interessante porque ela alia métricas à solução de problemas. Para a FIA (Federação Internacional de Automobilismo), a morte de pilotos é ruim, pois que empresa vai querer atrelar sua marca a um carro destruído com seu ocupante morto?
As equipes têm a mesma motivação, e também, quanto maior a performance, melhor os resultados e mais alta é a receita. É a relação ganha-ganha que você procura no seu time / produto ou serviço.
Exemplo prático. Para fazer uma entrega, seu time depende de outro time que está em outra gerência. As pessoas da sua equipe acham que o pessoal da entrega é muito lento.
Bum! Ponto de alavancagem encontrado. Qual o impacto dessa dependência externa? Vamos medir o Customer Lead Time (tempo decorrido entre o compromisso e a entrega para o cliente) e o System Lead Time (tempo decorrido entre o compromisso e a “passagem de bastão” para o próximo time = tempo do fluxo interno).
A diferença entre Customer Lead Time e o System Lead Time é justamente o impacto da dependência externa expresso em unidades de tempo (dias, semanas, meses…).
Apresente o Ponto de Alavancagem com Graça e Beleza
Você descobriu o ponto de alavancagem e vai para a reunião com gestores todo pimpão. Peito estufado parecendo um pombo no cio e a boca cheia para “falar umas verdades”. Vai devagar. Sócrates foi morto por buscar e falar a verdade nua e crua. Uma boa apresentação terá pouca resistência e uma apresentação ruim terá todas as resistências. Os fatos com retórica serão uma boa combinação.
Data-Driven não é mostrar dados, dados, dados e mais dados. Mostre um conjunto de Fatos (métricas) + Impactos (Qual a consequência dos fatos) e um leque de possíveis soluções para o problema. Esse leque deve abrir uma discussão SAUDÁVEL sobre qual será a verdadeira solução para o problema.
Conclusão
Espero ter ajudado um pouco mais sobre o uso de métricas. Ficou com dúvidas, tem alguma sugestão? Deixo aqui minha última carioquice, e última máxima: A Máxima do Rocha.
“Deixa eu te ajudar” e taca o dedo aí nos comentários.
Se quiser saber mais sobre métricas, veja também o nosso Treinamento de Métricas Ágeis. Também temos outros artigos sobre Métricas Ágeis no nosso blog. Até a próxima.
