Seu time lança diversas funcionalidades, trabalha muito, mas os resultados não aparecem? Entenda agora as principais causas tudo isso

Por Filipe Machado e Thiago Fregni

Em qualquer negócio, seja ele um produto digital ou não, uma das principais preocupações é atender as necessidades dos stakeholders e isso acaba se tornando um dos grandes objetivos a serem cumpridos. Com isso, o time trabalha muito, se empenha em lançar várias funcionalidades, mas vai deixando de lado uma meta muito importante: a maximização de valor e o retorno de investimento daquela iniciativa.

Ou seja, por mais que a Agilidade tenha sido implantada e as entregas estejam acontecendo com mais velocidade, ainda há stakeholders super descontentes. “Não há nada tão inútil do que fazer com grande eficiência, aquilo que não deveria ser feito.” Essa frase do Peter Drucker é uma daquelas que pode resumir de forma simples esse cenário. O time está trabalhando bem, com diversas funcionalidades em produção, mas será que estão fazendo algo realmente útil?

Isso soa comum para você? Pois realmente acontece em muitos negócios que estão iniciando uma transformação digital e por três principais motivos:

• Maximização de valor e o retorno de investimento

Geralmente, o Product Owner fica muito preocupado em atender os stakeholders e acaba deixando de lado uma das suas principais responsabilidades que é a maximização de retorno do investimento.

• Senso de propósito

É comum o time (Agilista, PO e Devs) não saber de forma clara qual o objetivo do produto ou não ter visão sob o motivo de estarem trabalhando em determinada demanda. Sabem o que é, como deve ser feito, mas não o por quê – não possuem senso de propósito!

• Discovery/Ideação/Upstream 

A maximização de valor do produto, ou seja, aquilo que o cliente recebe na ponta, precisa passar por um processo de discovery e refinamento, antes de iniciar o desenvolvimento. E não é sempre que isso acontece!

Mas qual é a causa raiz desse problema?

É possível identificar alguns sinais que ocasionam essas situações descritas acima. Os principais são: 

• Baixa autonomia do Product Owner, que depende de outras pessoas para tomar decisões e esclarecer detalhes;
• Product Owner que não tem a competência correta;
• PO tirador de pedido (PO Proxy/Escriba), que não tem ownership do produto. Anota os pedidos sem entender o porquê da solicitação e quais os resultados esperados;
• Time se preocupa em encher o capacity. Ou seja, durante reuniões de Planejamento, existe uma preocupação maior em “arrumar” backlog suficiente para deixar todos ocupados, do que gerar realmente valor para o cliente;
• PO que não sabe quanto custa cada PBI e não tem noção do custo do time, o que o impossibilita de fazer trade-offs baseados no RoI;
• Times que não possui objetivos claros, impossibilitando-os de fazer escolhas e manter o foco no que mais gera valor;
• Não possui Discovery (UX). Ou seja, assim que a solicitação chega, vai direto para o time desenvolver. Não existe um processo no qual o cliente é envolvido e hipóteses são tratadas como verdades;
• Não existe uma visão Customer Centric, focada no consumidor/usuário.

Bom, se você tiver identificado alguns desses pontos acima em seu time de transformação, você está cometendo esse erro. E isso pode ser nítido em um time ágil que ainda está no paradigma tradicional de trabalho.

Resolvendo essas questões 

Quando identificamos esse cenário – que é bem comum, fazemos um trabalho bem intenso de coaching com o Product Owner, com o Scrum Master e com os stakeholders. Para isso, executamos técnicas como:

– Criar um time de discovery: a fim de descobrir que funcionalidades devem ser implementadas para atender as necessidades dos usuários;

– Técnicas de ordenação de backlog: o backlog deve estar ordenado e tais técnicas nos ajudam a ordená-los de acordo com os objetivos a serem alcançados;

– Criar bem claramente um esteira ágil utilizando Flight Levels: esta técnica dá visibilidade de portfólio até chegar na mão do usuário final;

– Organizamos os times por Value Stream ligados ao usuários, com objetivos claros, utilizando OKR´s, por exemplo;

– Definição de objetivo do produto e deixar o claro qual o valor (aumentar 10% as vendas, aumentar a taxa de conversão em 5%, entre outros) esperado a ser atingido por aquele item, mais valor de itens;

– Roadmap: uma visão geral dos próximos passos do produto;

– Utilizar dados para tomada de decisão em itens de backlog;

– Criação de conceitos de hipóteses: uma ótima forma de trabalho que ajuda a validar as hipóteses é chamada HDD (Hypothesis Driven Development). Este método auxilia na escrita do nosso backlog, orientado à validação de hipóteses.

No geral, tentamos dar o correto propósito para o time como um todo, ligado a valor para o cliente ou negócio… Por que, quando não se sabe onde quer chegar, qualquer caminho serve. E, por isso, o trabalho se torna eficiente, mas não realmente eficaz!

Mais valor entregue, com menor investimento

Solucionando essas falhas durante o processo de desenvolvimento de um produto com um time ágil, é possível ter diversos benefícios, entre eles:

• Conseguir trabalhar no processo empírico, focando sempre no objetivo desejado;
• Se torna mais fácil gerenciar a ansiedade dos stakeholders quanto aos resultados;
• O stakeholder fica mais contente com a entrega, pois ela está ligada ao propósito, com foco em gerar realmente valor com a iniciativa;
• O clima de confiança do stakeholder com o time melhora;
• Resumindo, mais valor entregue, com menor investimento e foco na maximização de valor e o retorno de investimento da iniciativa.

Esperamos que você consiga aplicar essas sugestões em seu dia a dia. Qualquer dúvida, estamos à disposição para ajudar… É só entrar em contato conosco!