Upstream e Downstream no time de Produto com Trello
Miquéias Lopes

Miquéias Lopes

4 minutos de leitura

Este texto sobre Upstream e Downstream foi publicado originalmente na newsletter Papo de PM.

Upstream e Downstream, o que é?

A maioria de nós, pessoas de Produto atuando diretamente com times de desenvolvimento, está envolvida com metodologias ágeis. Ou seja, Scrum, Kanban e mais uma variedade de metodologias, processos e frameworks que nos ajudam a chegar nos resultados que estamos buscando no que tange ao desenvolvimento de produtos digitais.

Dentro do universo de Produto, existem dois grandes marcos que definem o processo de criação de um produto: o Discovery e o Delivery.

Fazendo uma correlação com esses dois marcos, podemos associar o Upstream ao Discovery, que são etapas que tem como objetivo entender, amadurecer e validar nossas ideias/hipóteses antes de partir para o desenvolvimento em si.

O Downstream estaria associado ao Delivery, uma vez que avaliamos nossas hipóteses e temos um backlog gerado a partir dos processos de Discovery. Nessa etapa, podemos entregar ao time de Engenharia o que eles precisam fazer, desenvolver e entregar, tudo com muita clareza.

Representação do fluxo Upstream e Downstream
Representação do fluxo Upstream e Downstream. Fonte.

Zoom in

Se formos olhar mais profundamente para um time de Produto, vamos notar que o nosso objetivo é ter etapas muito bem definidas, que vão desde a ideação até a entrega final.

Além disso, o mapeamento correto dessas etapas aumenta a visibilidade do trabalho como um todo. Ou seja, expõe gargalos, aponta ociosidades e, principalmente, se o time tem um fluxo saudável e maduro de trabalho. 

Na prática

Resolvi usar o Trello para exemplificar como podemos montar um fluxo de trabalho orientado ao produto, tendo como macro visões o Discovery e o Delivery. O mesmo quadro, ou derivações dele, pode ser criado em outras ferramentas (como o Jira, ou mesmo em um quadro físico com post-its).

Upstream e Downstream no Trello
Upstream e Downstream no Trello. Link do quadro.

Explicando nossas raias:

  • Backlog: basicamente são demandas ou necessidades não priorizadas. Tudo aquilo que poderemos ou não vir a trabalhar um dia, é o nosso grande banco de ideias do nosso produto;
  • Discovery: é aquilo que saiu do backlog e precisa começar a ser estudado, investigado e aprofundado. Até que todo o discovery de produto termine, o card não sai dessa raia;
  • Refinamento Negocial: depois de feito o Discovery, vem o momento de escrever a história de usuário de fato. Documentar tudo aquilo que é necessário e importante para que o time de desenvolvimento consiga atuar de fato na demanda;
  • Refinamento Técnico: terminou o refinamento negocial? Fez todas as reuniões necessárias e documentou tudo que precisa ser documentado? Então o card vai para a raia de refinamento técnico, onde o time de Engenharia vai dissecar tecnicamente o que precisa ser feito, deixar tudo documentado e apto para ser desenvolvido;
  • To do: tudo aquilo que já foi refinado tecnicamente e pode ser enviado para a esteira de desenvolvimento;
  • Em desenvolvimento: aqui ficam os cards das atividades que estão sendo desenvolvidas pelo time de engenharia;
  • Em teste: aqui ficam os cards das tarefas que foram finalizadas e estão sendo testadas pelo time de QA;
  • Publicado: aqui ficam os cards de todas as atividades que foram validadas pelo time de QA e publicadas em produção.

O objetivo é ter um fluxo contínuo, lógico e com o mínimo de impedimento possível entre as etapas. Além disso, queremos dar autonomia para que o próprio time faça a gestão das atividades, controlando o fluxo de trabalho e entrega. Por fim, fazendo uma boa gestão do quadro, conseguimos dar uma visibilidade honesta de tudo que está acontecendo dentro do ciclo de desenvolvimento do produto.

Papéis e responsabilidades

Não é uma regra absoluta, mas, no geral, podemos usar a escala do 80/20 para entender que parte do time de Produto atua nas etapas de Upstream e Downstream.

Lembrando sempre que o nosso trabalho é colaborativo. Assim como podemos trazer o time de Engenharia para participar de dinâmicas de Discovery, o time de Produto pode ajudar nos testes e validações junto com o time de Tech.

Minha sugestão

Todo bom processo só faz sentido se de alguma forma contribui com a sua realidade. Antes de colocar qualquer coisa em prática, converse com todo o time, entenda bem suas dores e necessidades, procure analisar cenários até que, de fato, usar um fluxo de trabalho como esse faça sentido.

Domine Product Discovery

Quer dominar estratégias ferramentas que vão te dar uma visão de especialista em Discovery de produto? O Curso de Product Discovery da PM3  tem mais de 30 horas de conteúdo e, além de contar com cases reais do mercado brasileiro, te proporciona a melhor experiência de aprendizado para atuar em uma das áreas que mais cresce no Brasil.

Quer saber mais sobre o conteúdo? Então confira a ementa completa!

Leia também: