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 é 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 trabalho para períodos pré-determinados, é possível se organizar para entregar valor continuamente para os clientes. Ou seja, o time passa a trabalhar com 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.
Qual a diferença entre roadmap de produto e backlog de produto?
Tanto roadmap de produto quanto product backlog (ou backlog de produto) são termos que fazem parte da rotina de POs, Product Managers e demais profissionais de Produto. Portanto, é comum que possa haver certa confusão para quem está começando a conhecer esses conceitos.
De forma direta, podemos dizer que a diferença entre os dois está na forma como os objetivos do produto são apresentados e também no contexto no qual cada um melhor se encaixa. Isso porque, enquanto product backlog é uma lista de tarefas que ajuda o time a se organizar para as sprints, o roadmap de produto é uma representação mais visual e macro da estratégia de produto, que serve como base de alinhamento para a empresa toda.
Como fazer product backlog?
“Como priorizar quando tudo é prioridade?”
Na posição de 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 é 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.
Resumindo e pensando em um passo a passo prático de como fazer product backlog, temos:
- Definição da estratégia de produto, pensando em todo o modelo de gestão da empresa;
- Definição de tarefas que são importantes para o momento da empresa e da estratégia de produto;
- Criação de um documento ou Kanban de fácil entendimento, viabilizando a gestão do projeto e acompanhamento do mesmo por parte de todos os envolvidos;
- Priorização de acordo com importância e viabilidade de entrega;
- Estimativa do tempo de projeto, de forma a acompanhar a evolução do projeto.
Técnicas de priorização: 2 frameworks práticos
Como sabemos, frameworks são ferramentas que nos auxiliam muito nos momentos em que precisamos de um ponto de partida. Quando falamos de priorização, existem 2 métodos que considero muito úteis e deixo aqui como sugestão:
Matriz de Impacto x Esforço
Esse método consiste na ferramenta de matriz acima, dividindo as atividades em quatro quadrantes de acordo com o nível de impacto que queremos obter e o esforço que isso vai exigir. 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
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 é num acrônimo das letras maiúsculas MSCW que representam as categorias “Must Have”, “Should Have”, “Could Have” e “Won’t Have”. Consequentemente, as tasks de priorização devem ser divididas dessa forma:
- 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;
- 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;
- 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;
- 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.
Conclusão sobre product backlog
Quando falamos sobre product backlog, não se trata apenas de um processo de organização de tarefas. Estamos partindo para uma priorização estratégica, trazendo todo o objetivo de negócio e do produto para um contexto mais tático e operacional. Uma vez que esse processo pode envolver muitas pessoas (especialmente em grandes empresas) deixar isso de lado pode levar ao fracasso de tudo que a empresa tinha como meta.
Sendo assim, estruturar um bom backlog de produto é essencial. Isso permite documentar informações, gerir tarefas e times, acompanhar a evolução das atividades e ajustar a rota quando necessário.
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!
Confira outros conteúdos sobre estratégia de produto:
