Métricas Ágeis para um time de Product Design
--
Sempre que falamos sobre métricas ágeis especificamente para um time de design, o assunto parece ser um mito, já que, diferente de para TI, não se encontram muitas referências disponíveis.
Neste artigo, vamos contar um pouco sobre os indicadores que acompanhamos no time de design explicando cada um dos nossos gráficos de rotina, e vamos tentar desmistificar um pouco o assunto.
Esperamos que você goste!
Como tudo isso é possível
Antes de mais nada, vale ressaltar como conseguimos viabilizar esse nível de controle e organização. Primeiro, foi importante a utilização de um modelo híbrido de trabalho, quero dizer, nem squads e nem pool. Depois, contamos com a ajuda do nosso Business Agility para extrair os dados do Jira e alimentar uma planilha para nós.
Assim, trabalhando juntos, temos feito mudanças incrementais e amadurecemos a cada aprendizado, exatamente como o Ágil prega.
Os indicadores que vamos mostrar já são comuns no universo ágil para desenvolvedores, e são geralmente usados por Agilistas e Scrummasters, que revisitam os gráficos durante cerimônias de Dailies e Retrospectivas. Nossa intenção é exemplificar como utilizamos estes mesmos indicadores para um processo de design.
É importante dizer também que a maneira com que estamos atuando tem funcionado para nós. Isso não significa que vai funcionar da mesma forma no seu contexto. Estude, reinvente e experimente ;)
Nosso processo
Nosso processo é basicamente o já conhecido Double Diamond. Criamos no Jira as etapas de “Problemas em andamento” e “Solução em andamento” para que os designers movimentem as tarefas nestes quadrantes. Desta forma conseguimos obter dados da performance do time em cada uma das etapas.
Abaixo uma imagem para ilustrar o nosso processo:
Bom, mas vamos aos gráficos:
Throughput: Média de itens finalizados por ciclo (semanas)
Com este gráfico nós podemos saber, de maneira geral, se o time vem conseguindo finalizar suas demandas e qual sua velocidade de entrega. Também é uma excelente oportunidade para identificar impedimentos recorrentes durante as discoveries.
Por exemplo: nas semanas 3, 5, 12 e 26, foi entregue 1 item (tarefa) por semana, enquanto que na semana 19, foram entregues 10 itens.
Throughput Histogram: Frequência do total de itens fechados por ciclo (semanas)
Por meio do gráfico acima, que é similar ao anterior, é possível entender também com qual frequência os designers estão fechando as tarefas.
Podemos verificar, por exemplo, que o time fechou três tarefas por semana por cinco vezes durante o último mês. Ou seja, concluímos que a performance do time é de mais ou menos de uma a duas tarefas por semana.
Lead Time Breakdown: Tempo (dias) em que uma demanda fica em cada etapa do processo
Saber a quantidade de dias que determinada tarefa pode estar parada em alguma etapa da discovery é importantíssimo, pois com esse dado a liderança de Design consegue atuar e fornecer o suporte necessário ao designer.
Com este gráfico, nós analisamos qual tarefa é o principal ofensor e podemos atuar de forma específica.
Lead Time Work Days: Nível de confiança e tendência sobre o seu Lead time
Apesar de parecer difícil, depois que você entende como interpretar este gráfico, ele começa a fazer parte da sua rotina. Nele, você consegue ter um visão geral do tempo médio que os designers levam para concluir uma tarefa e também a média de demandas projetadas versus a média de demandas fechadas.
Também é possível ter um histórico da evolução do desempenho do time e ainda uma noção do nível de confiança em porcentagem que o time entregará a demanda em uma quantidade X de dias, indicadores representados no gráfico por p50 (50% de confiança na entrega no tempo indicado), p75 (75% de confiança) e p95 (95% de confiança).
Por exemplo: no gráfico acima temos 75% de confiança de que as demandas serão entregues em até 20 dias.
Cumulative flow diagram: Fluxo de tarefas por etapa
Com este gráfico, você consegue entender como está a saúde de cada etapa do processo de design. Por exemplo, se estão entrando muitas tarefas no backlog, faz sentido que a quantidade de tarefas fechadas seja proporcional mantendo o equilíbrio entre cada fase.
Como consequência dessa divisão de etapas, identificamos em determinado momento, por exemplo, que os designers estavam passando muito tempo com a tarefa em Problem in Progress.
Essa descoberta foi importante para tomarmos algumas decisões: desde disponibilizar ferramentas para esta etapa (como por exemplo, um D.O.R. — Definition of Ready) até justificar ao C-Level a contratação de mais profissionais, neste caso voltados à pesquisa (UX Researchers).
Como acompanhamos
Semanalmente, em nosso rito de Design Leadership (reunião semanal da Liderança de Design), olhamos esses e mais gráficos que vamos mostrar nos próximos artigos (alerta de spoiler ⚠).
Essa reunião é um momento de discussão, entendimento, geração de hipóteses e endereçamento. Também aproveitamos para mostrar a todo o time, em Retrôs e Plannings, tanto o que podemos melhorar quanto as nossas conquistas.
Ter o time conscientizado da importância é um ponto muito importante porque, se não houver o cuidado de fazer a atualização das tarefas no Jira, nossos gráficos serão impactados.
Concluindo
Para concluir, lembramos daquela famosa frase: “O que pode ser medido pode ser melhorado” (Peter Drucker).
Para nós da Conta Azul, que temos como princípio ser Data Driven, possuir esse material em mãos nos ajuda em muito em importantes tomadas de decisões. Pois, cada vez que medimos um resultado, novos insights e ideias de indicadores surgem, fazendo sentido o ciclo de aprendizagem proposto na frase acima: medir e melhorar.
E você, quais indicadores acompanha do seu time de design?
