11 de março de 2022

Product backlog: como priorizar tarefas ao desenvolver um produto

Vamos falar sobre product backlog? No desenvolvimento de um produto é normal lidar com diversas vontades e necessidades, principalmente quando, se tratando de um produto digital, já estamos em estágio de produção, onde há efetivamente pessoas utilizando e sendo impactadas por ele.

Quanto maior esse impacto, quanto mais pessoas utilizarem e mais efetividade aquele produto tiver, eventualmente mais necessidades também existirão. Isto é, de todos os lados envolvidos, haverão expectativas, desejos e necessidades com relação ao uso daquele produto.

É muito comum que, nesse cenário, equipes menos preparadas acabem não dando a devida atenção a organização e priorização do product backlog, o que pode gerar um verdadeiro caos no sentido de que, em meio a tantas coisas a se fazer, a equipe perde a noção do que realmente é mais importante. Isso muitas vezes gera gastos maiores e baixa eficiência

Então, como definir a melhor ordem de execução das tarefas? Como garantir que o que está sendo desenvolvido é o que realmente agrega mais valor ao produto no momento? É sobre isso que vamos falar agora.

O que é o product backlog?

Todo desenvolvimento de produto envolve a constante necessidade de realização de tarefas. A simples modo, o product backlog é formado por uma lista priorizada de atividades a serem desenvolvidas. É quando pegamos todos aqueles pensamentos dos stakeholders (interessados no produto) – sejam eles necessidades, desejos, melhorias – e os concretizamos em tarefas a serem desenvolvidas. Essa lista deve seguir uma ordem coerente, dentro da realidade de cada produto, que priorize a entrega de valor para o cliente final.

Parece simples, mas no plano prático é um desafio para muitas equipes. Quanto mais complexo o produto, mais cuidado tem que se ter para que o backlog não se torne uma lista confusa, cheia de desejos e expectativas das diversas partes envolvidas.

É importante seguir uma cronologia organizada e pensada para trazer o máximo de eficiência, economia e resultados. Quando falamos em entregar valor, pensamos em não apenas satisfazer as vontades de uma parte específica, mas em mensurar, em meio a tantas entregas a serem feitas e partes a serem satisfeitas, o que será mais benéfico no geral.

Por que o backlog de produto é tão importante?

A rotina de quem trabalha em Produto é bem dinâmica. Isso significa que as tarefas são muitas e a todo momento chegam novas responsabilidades. Priorizar é a melhor forma de executar tudo no tempo certo, mantendo a transparência quanto ao andamento das atividades.

Defindo o escopo de trabalhado para períodos pré-determinados é possível se organizar para entregar valor continuamente para os clientes, por meio de entregas rápidas e eficientes.

O que é Scrum backlog?

O Scrum é uma metodologia ágil que visa acelerar processos, sem deixar de entregar valor. Considerando esse modelo de trabalho, que faz parte da rotina de Product Owners, temos também o sprint backlog.

Podemos dizer que ambos são uma lista de tarefas, mas que atuam em diferentes instâncias. Enquando o backlog de produto está focado em valores (algo mais abstrato e de médio prazo), o backlog das sprints é mais voltado para o operacional (ou seja, o que de fato o time vai executar ao longo da semana para chegar mais perto do resultado esperado).

Sendo assim, o product backlog deve ser revisitado semanalmente, enquanto que o sprint backlog deve ser repassado com o time todos os dias, definindo e reorganizando prioridades.

Como fazer product backlog?

“Como priorizar quando tudo é prioridade?”

Como Product Owner, é normal que no dia a dia você viva situações nas quais tudo parece prioridade. Correções de bugs, desenvolvimento de features, otimizações, refatorações, etc. Ocorre que, por mais que isso possa parecer verdade, para que o time de desenvolvimento não perca o direcionamento, faz-se necessário definir quais tarefas são mais importantes naquele momento.

Dessa análise deve surgir uma organização quanto a entregas de curto, médio e longo prazo que fazem parte do acompanhamento da saúde do produto, a depender do modelo de gestão e metodologias adotadas.

Em outras palavras, a priorização do backlog do produto é fundamental, mas antes de se chegar nessa prática, é importante adotar uma estratégia de produto macro e efetiva, para que o backlog seja estruturado e priorizado em conexão a esse plano. Ou seja, devemos pensar no backlog após planejar toda estratégia de negócio e produto. 

É comum que em equipes que adotam Agile e Scrum, por exemplo, o desenvolvimento de roadmaps amplos sejam esmiuçados em backlogs práticos para equipe de desenvolvimento, associados a um plano de releases bem definido e transparente, com entregas constantes. Esse nível de estruturação, por si só, se bem executado, é capaz de gerar um alto nível de satisfação entre todas as partes envolvidas.

Product backlog: como priorizar tarefas ao desenvolver um produto

2 sugestões de técnicas de priorização

Matriz de Impacto x Esforço

matriz impacto x esforço para product backlog

Esse método consiste na ferramenta de matriz acima, que nos permite dividir as atividades em quatro quadrantes, de acordo com o nível de impacto a ser gerado e o esforço a ser tomado. Quanto maior o impacto e menor o esforço para realização de uma atividade, maior deve ser a priorização dela numa listagem de afazeres.

Ter uma matriz como essa em mente na hora de priorizar as atividades no backlog é definir o que trará mais benefício (impacto) com menor custo e tempo (esforço) no desenvolvimento de um produto. Na tomada de decisão, é importante explicar aos stakeholders que muitos dos desejos manifestados podem envolver muito esforço, mas gerar baixo impacto em comparação a outras tarefas. 

Método MoSCoW

método moscow para product backlog 2

Criado por Dai Clegg enquanto desenvolvia seus trabalhos na Oracle nos anos 90, a técnica MoSCoW foi pensada já na área de gestão e negócios para o desenvolvimento de software. A palavra MoSCoW consiste num acrônimo das letras maiúsculas MSCW que representam as categorias “Must Have”, “Should Have”, “Could Have” e “Won’t Have”, nas quais devemos estar dividindo nossas tasks para priorizar:

  1. Must Have: “Tem que ser feito” numa tradução literal, seria a categoria para as tarefas mais indispensáveis para o produto, no qual sem elas poderia se considerar um fracasso;
  2. Should Have: “Deveria ter”, ou seja, é importante, mas não crucial, por isso são tarefas que devem vir logo após as categorizadas como essenciais;
  3. Could Have: “Poderia ter”, tarefas desejáveis, mas que também não necessárias, ou seja, a serem priorizadas apenas se as tarefas das categorias anteriores forem completadas;
  4. Won’t Have: “Não será feito”, tarefas que envolvem muito esforço e têm baixo impacto. Não devem ser priorizadas no momento.

Como podemos ver, criar e gerir o product backlog não é uma tarefa fácil, mas com frameworks como esses você terá mais clareza sobre o que é mais importante no momento, conquistando um product backlog muito mais organizado e assertivo.

Conheça outros frameworks

Se você gostou desses métodos e quer conhecer outros frameworks que podem simplificar a sua rotina em Produto, confira também o nosso Guia de Frameworks. O material é gratuito e você pode acessar agora mesmo!

guia-de-frameworks-product-backlog

Confira outros conteúdos sobre estratégia de produto:

Autoria de:

Você também pode gostar de ler