Durante os últimos 10 anos, vimos diversas técnicas, processos e organizações para melhorar o trabalho e o relacionamento entre desenvolvedores e designers, como um time único e entrosado.

Com o boom do Scrum no final dos anos 2000, muitas empresas focaram apenas no desenvolvimento, com entregas visando apenas eficiência, e não eficácia.

Nessa velocidade de entregas e sprints apertadas, era raro encontrar times que possuíam tempo/processo para pesquisa, aprendizado, experimentação, entrevistas com usuários e muito mais, pois “os programadores não podiam esperar".

Algumas empresas então, se renderam ao “dual track” (duas camadas de trabalho paralelas), que nada mais é do que colocar devs e designers em raias e épocas diferentes (como se fosse um episódio do The Flash), onde o Designer atuava sempre uma Sprint na frente, dando mais tempo para o Designer realizar o seu trabalho.

Porém, com o aumento da responsabilidade do(da) Designer, ganhando o chapéu de UX, realizando pesquisas mais densas e trabalhando com experimentações, o próprio “dual track” já não era mais o suficiente.

Algo precisava ser feito.

A mesma história, por outro ângulo

Assim como o filme do Rei Leão (o antigo né gente, vamos respeitar a idade das pessoas), precisamos contar o mesmo, por outro lado. O lado do Product Manager.

As empresas nesses últimos 10 anos, não só começaram a organizar o desenvolvimento de produto, mas também a metrificar o mesmo. Esse conhecimento necessitou de uma pessoa responsável por acompanhar e gerenciar as métricas e ajudar a priorizar o que precisa ser feito para ou corrigir, ou melhorar algum dado específico que era entregue a diretoria.

Assim, a figura do (da) PM para empresas de tecnologia nasceu, por isso estamos próximos de processo (gerando muita confusão, principalmente pela sigla de ambos serem PM).

Com todo o conhecimento de validação, hipóteses e orientação a dados, a pessoa de produto começou a trabalhar mais próxima no Briefing, Requisitos de Produto e Hipóteses.

O grande problema é que assim como o Designer, não havia muito tempo para se fazer o processo de aprendizado, validações e pesquisas em “dual track” para alimentar o time de desenvolvimento.

Assim sendo, depois de muitos anos, começamos a criar mais soluções criativas para esse relacionamento a 3, que depois se tornou um relacionamento de N para N.

Up and Down

Primeiro de tudo, vamos conceituar o que é Upstream e Downstream para quem é de Produto (não de projeto) e nunca ouviu falar do termo.

Upstream

A Upstream é uma etapa de planejamento, vista como um processo de início, meio e fim para amadurecer ideias, criar hipóteses, amarrar métricas e estudos, protótipos, telas e documentações para nutrir a etapa de Downstream.

O seu objetivo é dividido em evitar o risco de desenvolver algo que não era importante para o negócio/usuário, e entregar clareza para o desenvolvedor criar algo com mais confiança.

Downstream

A Downstream é uma etapa de desenvolvimento de produto, contemplando também testes e até mesmo o deploy.

O seu objetivo é único, entregar releases que entreguem valor para o usuário, de acordo com a priorização da pessoa de produto.

Bernard, a pessoa de programação também teria coisas para experimentar e contribuir no produto, ao invés de só desenvolver. Ela não deveria participar do Upstream também?

Claro! Uma pessoa de produto precisa trabalhar sua comunicação com seu time sempre (lembra da última news?). Dito isso, ela sempre deve comunicar ao time de desenvolvimento quando um briefing for criado, para dar tempo dos(das) Devs levantarem o nível de complexidade e abstração da tarefa (ou EPIC) e criarem suas sub-tarefas de experimentações.

Dividir o Kanban (método ágil) em Upstream x Downstream é cada vez mais comum no processo ágil de desenvolvimento de produto, não só por melhorar o valor do que está sendo criado, como melhorando métricas de cada etapa (isolando planejamento de execução), e dando a oportunidade de se reduzir o BDUF (Big Design Up Front, que é quando o Designer busca a perfeição em pesquisas e geração de artefatos em momentos inoportunos e irrelevantes, gerando gargalo para o restante do time).

Uphill e Downhill

Preciso confessar, eu gosto muito desses termos, pois, o conceito deles, apresentado pelo grande Ryan Singer (basecamp), é muito sedutor:

Cada trabalho tem duas fases. Primeiro, há uma fase difícil em que você descobre sua abordagem. Você tem uma ideia básica sobre a tarefa, mas não descobriu como será a solução nem como resolver todas as incógnitas.

Depois de explorar o que funciona e o que não funciona, você chega a um ponto em que não há mais problemas não resolvidos. É como estar no topo da colina. Você pode ver claramente todo o caminho até o outro lado. Então a fase de descida é apenas sobre a execução.

Se você gasta 15 dias para 50% das tarefas, não existe nenhuma relação de previsibilidade que você cumprirá os outros 50% em também 15 dias.

Pois, no começo de um lançamento, seja de funcionalidade ou um produto novo, nosso caminho é uma subida (uphill em inglês), que garante uma velocidade lenta por diversas incertezas e falta de confiança.

Quando conseguimos reduzir as incertezas, nosso caminho da descida (downhill em inglês) fica mais claro, por isso aceleramos a velocidade de desenvolvimento.

Vale lembrar, que também não estamos dizendo que o Designer fica em Uphill e o Dev em Downhill, pois, cada papel tem tarefas de desconhecimentos e incertezas que podem ser mapeadas e experimentadas na etapa de Uphill.

Por exemplo, um front-end pode testar alguns endpoints de API na etapa de Uphill, o back-end pode começar uma modelagem em uphill, a partir dos protótipos do Designer.

A criação dos artigos, assim como design dos emails e do post do blog com o anúncio da funcionalidade, pode tudo acontecer no Downhill.

Estamos falando da mesma coisa?

Upstream e Uphill são etapas de incertezas, experimentações e planejamentos.

Downstream e Downhill são etapas de desenvolvimento, confiança no que será feito e previsibilidade.

Embora eles tenham as mesmas características, prefiro ir com o primeiro formato, pois ele é mais próximo do Agile em geral, além de possuir mais documentações e conteúdo sobre isso na internet e em livros.

O importante é entender e evangelizar o seu time quanto a importância de se mapear as incertezas, definir o nível da abstração e complexidade de cada tarefa/funcionalidade/User Story/EPIC, para se decidir o quanto você quer investir no Uphill, e o quanto de confiança você e o time tem para acelerar o Downhill.

O interessante é que o Upstream não precisa estar em “Dual track”, o que é bom, por ser mais dinâmico e responsivo à complexidade que cada projeto tem, e ruim, por poder ser mal utilizado e gerar uma quantidade grande de histórias do usuário em estoque, esperando pelo Downstream.

E você? Como divide sua forma de atuar com produtos digitais?