Backlog de produto: Da necessidade ao desenvolvimento
Uma das coisas que considero mais difícil na rotina de um gestor de produtos é organizar o trabalho sendo feito nas várias frentes da equipe e acompanhar os status dessas atividades.
Durante o processo de entendimento da necessidade do negócio, a equipe de produtos acaba trabalhando em duplas ou trios, se conectando com várias áreas para fazer validações técnicas, de uso e de negócio. Dessa forma, as responsabilidades transitam entre as áreas e às vezes o acompanhamento se perde.
Em outro momento, quando já está em desenvolvimento, a equipe de produtos fica como consultor do time de engenharia e monitorando as novas atualizações. São várias peças do quebra-cabeça que precisam se encontrar.
Sei que você, assim como eu, tem várias iniciativas do produto para conduzir e a cada evolução, os stakeholders têm mais ansiedade para acompanhar o desenvolvimento. Neste texto vou compartilhar com vocês uma forma que uso para organizar esse cenário, acompanhe a seguir:
Backlog de Produto
Essa planilha me ajuda a acompanhar o desenvolvimento das features ou hipóteses. Os itens são organizados em ordem de prioridade e não entram pequenas melhorias e/ou bugs. Estes outros são cadastrados direto na ferramenta de acompanhamento do desenvolvimento, como por exemplo o JIRA.
Como podem ver, temos o nome do item e uma breve descrição (afinal, qualquer pessoa que ler tem que entender o que aquele item faz). Em seguida temos quanto está pronto (%) no ponto de vista da equipe de produto.
Sendo:
- Investigação
- Modelagem
- Validação
- Documentação.
Essas 4 etapas compõem a sprint de produto e em seguida, temos a sprint de desenvolvimento.
Sprint de produto
São grandes fases do processo de design, idealmente deve-se passar por todas elas, mas cada uma tem o seu tratamento individual dentro da necessidade apresentada. Cada etapa pode variar o tempo de entrega e quais são os entregáveis e métodos utilizados.
Não é porque você sabe todas as técnicas que você tem que usar de uma só vez. Não é porque você tem uma chave de fenda que você tem que usá-la para tudo, você usa apenas quando precisar apertar um parafuso
Investigação
Entendimento do problema, é a fase de coletar os requisitos e aprender sobre o contexto de uso. Além de mapear o comportamento e o impacto ou valor percebido de ter aquela feature e alinhar a expectativa do usuário/stakeholder.
Modelagem
É a representação de como podemos resolver o problema discutido na etapa anterior. É quando a ideação da solução começa, surgem novas hipóteses, casos de uso alternativos e prototipação. Nesta fase também é feito co-criação com mais pessoas e pesquisa de soluções já existentes no mercado. É a evolução dos rabiscos até a chegada de algo aceitável para a validação.
Validação
Então é feita a validação com pessoas interessadas naquela evolução, com quem vai usar, de quem estamos resolvendo o problema, e também é o momento de fazer validações técnicas. Essa é uma etapa com iterações rápidas, com ajustes e refinamentos.
Documentação
Essa fase é praticamente o resumo de todas as outras, é o entregável final. De fato, o que vai ser desenvolvido, user stories, fluxos e cenários, layout, requisitos de design e de negócio. Além de utilizar alguns softwares de apoio como por exemplo:
, e .Cada problema tem uma solução e cada solução tem uma documentação mais adequada.
Sprint de desenvolvimento
Quando falo do Sprint de desenvolvimento, estou referindo ao ciclo de desenvolvimento do time de engenharia. Nesta fase, os requisitos são divididos em fragmentos menores, priorizados e enfim desenvolvidos e lançados(colocados no ar de fato).
Enquanto isso, a equipe de produtos está como suporte ao time de desenvolvimento e monitorando a nova atualização e verificando se o problema foi realmente resolvido.
Neste modelo apresentado é possível acompanhar a jornada completa de desenvolvimento de uma feature, da ideia até a produção e o lançamento.
Às vezes a entrega de cada etapa não é nada tão surpreendente, mas o processo é importante para deixar todos na mesma página.
Deixando esse documento público para os interessados ou até mesmo para a empresa toda, acalmará a ansiedade dos stakeholders e trará mais previsibilidade da evolução do produto. Você ainda pode acompanhar os itens que seguiram o processo completo de design ou não, e como isso influenciou nos resultados.
Bônus
Gostou do modelo usado para acompanhar o backlog do produto? Baixe aqui o template para você usar também.
Esse modelo foi criado conforme a nossa necessidade e tem funcionado bem, estamos sempre evoluindo (na verdade essa já é a segunda versão). Ele é facilmente adaptável para qualquer processo que você queira usar, adicionando ou removendo etapas. Faça o seu e vamos conversar :)
