[PAPO DE PM #9] - Upstream e downstream no time de produto com Trello

A news Papo de PM é patrocinada pela PM3. A PM3 é referência em cursos para Product Managers no país. Aprenda de forma 100% online com grandes líderes e seja Gerente de Produtos Digitais.

Instagram: https://www.instagram.com/cursospm3/

Linkedin: https://www.linkedin.com/school/cursos-pm3/

A maioria de nós, pessoas de produto, que estamos atuando diretamente com times de desenvolvimento, estamos envolvidos em grande medida com metodologias ágeis, 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 o objetivo de 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 discoverys, podemos entregar para o time de engenharia de maneira clara o que eles precisam fazer, desenvolver e entregar.

Fonte da imagem: https://medium.com/@raphaelbatagini/upstream-e-downstream-no-kanban-d0d02c56f6b6#:~:text=Upstream%20s%C3%A3o%20as%20etapas%20do,de%20itens%20gerados%20no%20upstream

Se formos olhar mais profundamente para um time de produto, iremos 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, expõe gargalos, aponta ociosidades e principalmente, se o time tem um fluxo uniformemente saudável e maduro de trabalho. 

Resolvi usar o Trello para exemplificar como podemos montar um fluxo de trabalho orientado a 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-it.

Link do quadro: https://trello.com/invite/b/ipaCU8bJ/3bec5431207a59243f166bee4ecbd4c0/upstream-e-downstream-no-time-de-produto

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.

Bem, 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.

Todo bom processo só faz sentido se ele ajuda a sua realidade. Antes de colocar qualquer coisa em prática, converse com todo o time, entendam bem suas dores e necessidades, procuram analisar cenários até que usar um fluxo de trabalho como esse faz sentido.

É isso e até o próximo papo,

Mika

Gostou? Se inscreva no Substack e receba o Papo de PM direto no seu e-mail