Product Backlog: como incluir na sua rotina?
Durante o início da minha atuação como Product Designer, sempre senti que faltava algo na gestão das minhas atividades. A partir dessa inquietação, comecei a procurar por métodos e ferramentas que pudessem me ajudar a não só melhorar minha organização pessoal, mas também dar visibilidade para todo o time de desenvolvimento.
A princípio, comecei a estruturar um Burndown com a evolução das minhas atividades semanais e utilizei o Trello para descrever tudo o que estava no meu backlog de design, mas alguns questionamentos começaram a surgir, como: "de onde surgem essas funcionalidades?" "quais serão as próximas?" "estamos iterando corretamente a ponto de validarmos o que já foi entregue?", dentre outros.
Depois de alguns meses atuando como designer e posteriormente assumindo um papel de pessoa de produto (responsável pelo discovery contínuo do produto e gestão do backlog como principais atividades) consegui compreender que a inclusão das atividades de design na gestão de um backlog de produto era necessária para integrar a visão do todo, além de possuir um formato para o acompanhamento da evolução de cada item. Basicamente, eu queria ter a visão do surgimento de cada demanda alinhada com os objetivos e estratégia do produto, até se transformar na funcionalidade publicada e logo após, retornada à fase de discovery para testar o valor entregue aos usuários e ao negócio.
Por que incluir atividades de design em um backlog de produto?
Para que um backlog seja uma lista de funcionalidades requeridas para um produto, ele deve conter as atividades necessárias para que tarefas sejam feitas de forma a entregar valor. A título de exemplo, uma das possibilidades para a hierarquia de um backlog é composta por epic, feature, user story e task.
Exemplo:
Para obtermos esse nível detalhado de backlog, as atividades de Discovery e Delivery realizadas pelo designer e pela pessoa de produto de um time de desenvolvimento são pré-requisitos chave e portanto, elas deveriam compor o product backlog.
Considerando-se um produto que já está em desenvolvimento há algumas iterações e que já possui sua estratégia definida, ao priorizar uma nova funcionalidade e então quebrar em histórias de usuário, existem diversas etapas anteriores que muitas vezes não são mapeadas e geridas de forma efetiva dentro dos times de desenvolvimento. Pensando-se em um quadro (kanban) de acompanhamento das entregas do produto, antes de se chegar ao refinamento das user stories e deixá-las prontas para o desenvolvimento, existe uma série de atividades que envolve desde o Discovery até o Delivery. Isso significa que o kanban precisa crescer para a esquerda para obtermos uma visualização ideal do surgimento de cada feature e priorizar dentro de cada coluna de acordo com a estratégia do produto.
Como toda prática experimental, não existe uma receita que funcione para todo e qualquer cenário e faz parte das experimentações errarmos e aprendermos ao longo do processo. Aqui na dti temos uma forte cultura de colaboração e experimentação, que me permitiu conhecer outros métodos adotados na estrutura da empresa que funcionam muito bem em contextos diversos. De acordo com a vivência que obtive e com os testes que realizei, posso resumir em alguns pontos para se levar em consideração ao pensar em um backlog de produto em ambientes ágeis, de forma geral:
1. O designer e o PO/PM (pessoa de produto do time) devem trabalhar sempre juntos dedicando-se intensamente ao Discovery
Em Squads ágeis é muito importante a presença de Product Owners ou Products Managements para o discovery. Descobrir a diferença entre esses dois profissionais foi crucial para que eu soubesse a quem recorrer em cada caso.
Marty Cagan, no livro Inspired: how to create tech product customers love, defende que times competentes em técnicas modernas de discovery geralmente realizam entre 10 e 20 iterações de testes por semana.
O autor também defende a ideia de que o designer e a pessoa de produto do time devem atuar juntos nessas atividades. Quando iniciamos o raciocínio de um backlog de produto, percebemos que as etapas do discovery são fundamentais de serem observadas e geridas. Isso se dá porque o design é, em sua essência, centrado no ser humano e quanto mais próximo o designer está dos usuários, mais assertivo será, indo ao encontro de suas reais necessidades e gerando uma entrega contínua de valor.
2. Os testes de hipóteses devem fazer parte do processo como um todo
Estamos sempre trabalhando com hipóteses, quer tenhamos consciência disso ou não. O importante é sempre ter em mente que a validação dessas hipóteses deve ser uma etapa bem estruturada.
No livro O Produto Ágil: testando hipóteses (p.7–8) de Andressa Chiara, temos uma definição de possibilidades de hipóteses, em termos práticos:
De problema: eu não sei se esse problema existe;
De solução: eu não sei se esta solução resolve o problema;
De viabilidade técnica: eu não sei se uma solução como esta para de pé;
De viabilidade de negócios: eu não sei se as pessoas pagariam para ter este problema resolvido (ou se abandonariam o que elas fazem hoje para aderir à nova solução).
Hipóteses são incertezas e suposições que possuímos e quando entendemos o impacto direto de cada uma delas no crescimento de um produto, assentimos que o processo de validar hipóteses é importante para mitigar riscos na construção, seja a resposta dessa validação positiva ou de descarte. Dessa forma, é possível eliminar desperdícios e garantir a assertividade, partindo do princípio de "falhar rápido, obter sucesso mais rápido".
Segundo Marty Cagan, também no livro citado anteriormente, os riscos principais podem ser de valor, usabilidade, viabilidade técnica e viabilidade de negócios. Dentro da visualização de um kanban, um item do backlog deveria mover de uma coluna para a outra, em etapas de Discovery, apenas após a validação de hipóteses, sendo direcionado para uma entrega de valor.
Há algum tempo atrás, comecei a utilizar o Test Card da Strategyzer para estruturar essas validações, ao descrever uma frase que conceitua a hipótese, a definição do experimento adequado para a validação, uma métrica que auxilia na verificação do resultado e um critério que estabelece se a hipótese pode ser validada ou invalidada. O framework me auxiliou muito a entender, principalmente, o objetivo de cada uma das validações necessárias. Dessa forma, é possível se apegar menos a qual ferramenta utilizar e muito mais nos resultados que deseja-se obter com determinada investigação, seja uma entrevista, teste de usabilidade, questionário, dentre outras.
3. Ter a visualização da metamorfose de uma entrega de valor é essencial
Toda entrega de valor nasce de uma dor, ou seja, podemos entregar funcionalidades que não se relacionam a um problema real, mas uma entrega verdadeira de valor está diretamente relacionada e conectada a uma necessidade não atendida. A pergunta a ser respondida pela visualização dessa conexão é: como essa dor evolui até se tornar uma entrega de valor?
É comum gerirmos atividades a partir do momento do desenvolvimento, sabendo quais são as histórias de usuário que devem ser completadas até subirem para produção e as etapas envolvidas em uma visão de kanban: to do, doing e done. Mas, para entendermos bem como uma entrega se conecta a um problema real, precisamos ter a visualização das etapas envolvidas, desde o Discovery. Dessa forma, é possível entender esse processo de metamorfose que nasce com o surgimento de uma dor até se transformar na entrega de valor, atentando-se sempre para as validações de hipóteses durante o andamento.
Tornar as atividades de Discovery de Produto e também do Delivery de responsabilidade do designer (protótipos, dentre outros) visíveis e integradas na visualização do backlog e na ferramenta utilizada para acompanhar o andamento de atividades evidencia não só a relevância da atuação do designer e da pessoa de produto, mas também garante maior alinhamento do time e do negócio acerca da aderência dos entregáveis do ponto de vista da estratégia e visão do produto.
Para conhecer mais sobre a dti digital, venha nos ouvir no nosso podcast ou siga a gente nas nossas redes sociais: Instagram, Instagram da Guilda de Design e Linkedin.
