Em outro artigo que escrevi aqui no blog sobre métricas básicas para o seu time, um leitor fez uma pergunta muito interessante sobre como medir valor em um projeto de dados.
Ao formular a resposta percebi que esse é um assunto muito interessante. E que, baseado na minha experiência com vários times de dados recentemente, pode ser a dúvida de várias outras pessoas.
Por isso, decidi escrever esse artigo rápido.
De acordo com o Scrum Guide, “The Product Backlog is an ordered list of everything that is known to be needed in the product”. Backlog é uma lista priorizada do que sabemos que é necessário para este produto. Logo, para termos um backlog precisamos de um critério de priorização.
Como já falamos em vários outros posts aqui do blog, precisamos trabalhar orientados a valor. Essa diretiva está presente em vários momentos no manifesto ágil como por exemplo no princípio: “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado“.
Mas no caso de um projeto de dados, o que seria valor? Qual unidade ou prática eu poderia usar para medir isto?
O backlog de um projeto de dados
Nesse post sobre o trabalho do Product Owner falamos sobre como fatiar um produto e como essa tarefa é uma busca constante pela menor parte que realmente agrega valor para o usuário final.
Mas no caso de um projeto de dados, as coisas mudam um pouco.
O desafio de fatiar a entrega de valor e priorizar o backlog é ainda maior em um projeto de dados
Para responder à pergunta do nosso leitor, vamos começar analisando o investimento, e depois passaremos a analisar o retorno, assim poderemos calcular o Return On Investiment, carinhosamente chamado de ROI.
Investimento
Um projeto de dados comumente parte da aquisição de uma ferramenta (que normalmente não é das mais baratas). E o desenvolvimento do projeto consiste da inclusão de novos dados e construção de relatórios e visões dentro da ferramenta adquirida.
Isso por si só já fere um pouco o seguinte princípios do manifesto ágil: “As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis“. A compra de uma ferramenta já é uma decisão arquitetural que você, por já ter um custo explícito anexado a ela, não vai (tão facilmente assim) poder mudar ao longo do projeto.
Logo, partimos, no ponto zero, de um investimento, que foi a aquisição da ferramenta. Podemos ter o impulso de ratear este custo para todos os itens do projeto. Mas isso vai acabar jogando contra você em um futuro próximo.
Vamos imaginar que cada item carrega uma parte do investimento para comprar a ferramenta. Isso significa que quanto mais itens, menor a parcela do investimento para cada item individualmente.
Logo, quanto mais itens, ou quanto mais dados, relatórios e visões disponibilizados na ferramenta, melhor. Ou seja, aumentar a quantidade de itens entregues baixa o “I” o que melhora seu ROI.
O problema dessa perspectiva é que logo você estará “matando uma formiga com canhão”. Utilizando a ferramenta para coisas simples, onde ela não é necessária, e às vezes nem é a melhor opção, por não ter sido pensada para isso.
O problema dessa abordagem é que ela vai te levar a ter um alto custo de manutenção. Levando para a ferramenta coisas que poderiam ter sido resolvidas com uma consulta direta, um flat file ou um relatório simples.
Essas tecnologias mais rudimentares permitem que várias pessoas na organização possam realizar as manutenções, em vez de ficarem presas em uma ferramenta ou tecnologia que necessite de uma licença ou o treinamento dessa competência.
Então, fuja disso, como o diabo da cruz! O importante é deixar seu projeto com a menor carga de manutenção possível.
Retorno
Isso posto, vamos para a visão de resultado. A melhor forma de medir o retorno é observar a velocidade (quanto mais rápido, melhor) e a qualidade (quanto mais assertiva, melhor) das decisões tomadas com base no que a ferramenta foi capaz de apresentar.
Mas isso é muito difícil de medir. Você teria que consultar historicamente quais foram os impactos da decisão tomada, e medir quando uma dúvida surgiu até o momento em que foi resolvida. Tudo isso são do tipos de coisas que normalmente não ficam registradas em sistemas de controle ou gestão. Por isso é sempre muito difícil ter esse dado.
Contudo, existe uma exceção. Quando nosso projeto tem como cliente áreas que estão tomando decisões corriqueiras (ou cotidianas), podemos coletar esses dados no sistema de gestão dessas áreas.
Passamos a poder medir a velocidade da decisão medindo o avanço na produtividade ou o tempo de duração de uma tarefa.
Podemos também medir a qualidade. Por se tratar de decisões corriqueiras, devem existir sistemas de qualidade para validar essas decisões. Ou seja, calcule o valor em cima das melhorias perceptíveis nos resultados na operação do seu cliente.
Exemplo: um projeto que visa construir o relatório de vendas de uma business unity. A pessoa que solicitou essa informação possivelmente está trabalhando em uma equipe e deve ter um ticket em algum sistema, ou uma tarefa em algum quadro. Observando os impactos nesse time você poderá medir o valor da sua entrega.
É possível, só que às vezes é muito caro.
Outra solução, as vezes mais viável
A solução então passa a ser medir o uso. Você, como PO, deve passar a ser perguntar frequentemente: “As ferramentas que estamos disponibilizando estão, de fato, sendo utilizadas?”
Medir o uso pode não ser a melhor métrica, mas definitivamente é bem mais barato. Você pode, por exemplo, medir a quantidade de vezes que uma consulta foi realizada.
A maior parte dessas ferramentas já providenciam monitoramentos, mas se por algum motivo a sua ferramenta não te der isso já pronto, você pode programar um gatilho. Ou até mesmo adicionar uma tag na página para medir quantas vezes a página foi “carregada” ou “impressa”.
Você pode também medir tempo de sessão. “Quanto tempo essa tela está exposta?” Claro, se a sua visão é um dashboard, medir tempo de sessão das telas que ficam expostas o tempo todo será um indicador enviesado, e você tem que ter um critério para ignorar os dados desta fonte.
Analisando o uso, você pode criar uma linha de tendência e acompanhando a linha de tendência, você vai ter uma métrica que reflete valor e poderá ser utilizada para (re)priorizar.
Isso vai permitir que, com base na vivência do dia a dia, o time de projeto consiga participar mais ativamente do caminhar estratégico, oferecendo não apenas uma visão tecnológica de como construir, mas também uma visão de onde estão as melhores oportunidades, quais devem ser os primeiros relatórios e até mesmo influenciar na qualidade do dado.
A linha de tendência de uso serve para que você possa argumentar com seus clientes sobre as funcionalidades que estão sendo entregues.
Após cada entrega, passe um período medindo o uso de cada relatório ou visão. É muito comum equipes terem em seus boards colunas que significam que aquela entrega está sendo medida, tanto para garantir a qualidade técnica como para garantir que ela está sendo útil para seus clientes.
É importante lembrar que essa abordagem será mais efetiva quanto menores e mais bem fatiadas forem as suas entregas. Fatiar bem e entregar constantemente. Assim você será capaz de ver a evolução da tendência depois de cada entrega.
Se você faz entregas grandes, sua tendência de uso vai demorar para ser um um dado relevante e, possivelmente, quando você tiver esse dado, já não vai mais ser possível mudar a direção, porque você já fez tudo.
Saiba mais sobre priorização e Product Owner
Entenda o papel do Product Owner e o que ele faz no Time de Scrum.
Se você está começando nessa jornada e quer material para ler, vale a pena dar uma olhada no artigo 10 livros imperdíveis para Product Owners.
Curtiu o assunto? Quer aprimorar seus conhecimentos e habilidades como PO? Não deixe de conferir o nosso treinamento Certified Scrum Product Owner!
