Métricas Ágeis para um time de Product Design

#ParaTodosVerem: ilustração de dois personagens em frente a um gráfico grande. Um deles desenha o gráfico enquanto o outro observa com uma prancheta nas mãos.

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:

Processo do time de Product Design. #ParaTodosVerem: a imagem mostra quatro blocos representando as etapas do processo do time de Product Design, baseado no duplo diamante, e embaixo está escrito “Acompanhamento” e “desenvolvimento da solução” (bloco que permeia todas as etapas). Para a primeira etapa, “Problemas priorizados”, são trazidas as tarefas em que os designers trabalharão; na segunda, “Problemas em andamento”, é a hora de descobrir ou definir a solução; na terceira, “Solução em progresso”, os designers focam no desenvolvimento e entrega da tarefa; e na quarta, “Concluídos”, são colocadas as tarefas finalizadas.

Bom, mas vamos aos gráficos:

Throughput: Média de itens finalizados por ciclo (semanas)

Gráfico de itens finalizados por ciclo (semanas). #ParaTodosVerem: na imagem está um gráfico de barras e linha, mostrando a quantidade de itens (tarefas) entregues em cada semana desde novembro até abril.

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)

Gráfico de frequência do total de itens fechados por ciclo (semanas). #ParaTodosVerem: a imagem mostra um gráfico de barras, com a frequência no eixo vertical e as tarefas realizadas por semana no eixo horizontal.

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

Gráfico de Lead Time Breakdown. #ParaTodosVerem: a imagem mostra um gráfico de barras, com os dias no eixo vertical e as tarefas no horizontal. As barras são coloridas de acordo com o número de tarefas dentro das etapas do processo: solução em andamento e problema em andamento.

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

Gráfico de Lead Time Work Days. #ParaTodosVerem: a imagem mostra um gráfico de linhas e pontos, com os dias no eixo vertical e o código do item no eixo horizontal. Cada cor de linha representa uma situação da tarefa ao longo dos dias: média projetada, média feita, p50 (indicador de que a porcentagem de confiança da entrega neste tempo é de 50%), p75 (75% de confiança na entrega) e p95 (95% de confiança na entrega). E cada cor de ponto representa se a tarefa já foi feita (done) ou está sendo feita (doing), e em quantos dias.

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

Gráfico de fluxo de tarefas por etapa. #ParaTodosVerem: a imagem mostra um gráfico colorido, com tendência positiva, formando algo similar a uma montanha. No eixo vertical, está o número de itens e, no eixo horizontal, as semanas (desde novembro até abril). Cada linha preenchida representa uma etapa do processo: backlog, a fazer (to do), problem in progress (problema em andamento), solution in progress (solução em andamento), in validation (em validação) e done (feito).

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?

Design Operations Leader at Conta Azul