Ícone do site Taller

Upstream Kanban: gestão do fluxo de criação de demandas

Ítalo Mendonça

No final de 2019, a organização de Floripa do IxDA (Interaction Interaction Design Association) reuniu a comunidade local para fazer um evento sobre o que gostaríamos de ver sendo discutido e colocado em prática ao longo de 2020. Fui um dos cinco convidados e vi nesse convite uma excelente oportunidade para introduzir um assunto muito quente aqui na Taller: o Upstream Kanban.

O tema já foi abordado aqui no blog pelo Rafael Caceres, nosso CEO, no texto “Agilidade nos negócios com Upstream Kanban”, e deu origem à palestra “Alinhando Discovery com Delivery usando Upstream Kanban”. Como o conceito ainda está amadurecendo, e é relativamente recente, nosso objetivo aqui é, por um lado, apresentar o estado atual das discussões sobre o assunto; e, por outro, apresentar novos questionamentos e descobertas que emergem nas trincheiras do dia a dia aqui na Taller.

Para o evento do IxDA resolvi não só apresentar a abordagem do Upstream Kanban, mas também instigar uma nova dimensão de responsabilidade que os designers podem ter dentro de seus projetos: a gestão do fluxo de criação de demandas. O nome é longo, mas fará sentido se olharmos para o significado de suas partes, confie.

 

Fonte: Elaborada pelo autor.

Vamos por partes. São três termos para destrinchar: 

 

1. Upstream Kanban

Upstream Kanban é uma das partes do Método Kanban. A analogia que o método faz é a do fluxo de um rio, onde a parte de cima – nascente, ou seja, o Upstream – flui até a parte de baixo – foz, nesse caso, o Downstream. Outra metáfora que ajuda a entender o conceito é pensarmos numa represa. O que está represado é o Upstream e o que flui é o Downstream. O controle da abertura das comportas e turbinas ajuda a entender o papel do gestor de fluxo. Em termos práticos, o Upstream Kanban é a etapa para entender as necessidades dos clientes, antecipar problemas, modelar e criar opções de trabalho para o time de desenvolvimento (Downstream). Em outras palavras, Upstream Kanban é uma forma de mapear a criação de demandas e entrega de valor para o cliente. 

 

Upstream, Downstream e o controle da vazão.
Fonte: Renova Mídia – Usina de Itaipu

 

Essa divisão entre Upstream/Downstream propicia resultados práticos na qualidade do trabalho entregue. Os mais perceptíveis são:

 

O pulo do gato ao adotar o Upstream Kanban é que assim estimulamos o hábito de olhar para o processo todo, da concepção à entrega, e, a partir disso, começar observar a qualidade do pedidos que chegam para os desenvolvedores.

 

O caminho que uma demanda percorre, da ideia até a entrega.
Fonte: Palestra Alinhando Discovery com Delivery usando Upstream Kanban – Rafael Caceres.

 

2. Gestão de Fluxo

Ao olhar o fluxo de ponta a ponta (end to end), logo nos deparamos com o seguinte contraste: criar ideias é muito mais fácil do que executá-las. Eis o motivo pelo qual é preciso ter alguns “freios” nessa torrente constante de novos pedidos. É aí que o Upstream mostra o seu valor, pois é na etapa de pré-produção que as demandas, ainda abstratas e incertas, começam a ganhar mais detalhes e passar por um crivo técnico e estratégico.

Essa “peneira” é uma excelente oportunidade de trazer o usuário, o cliente, as pessoas que desenvolvem  e outros times para avaliar se vale a pena ou não tocar a demanda. Cada um contribui como pode. Devs poderão contribuir dando um aval técnico (e mostrando as complexidades ocultas); os usuários podem validar se a ideia irá melhorar a experiência de uso do produto; e o cliente pode refletir melhor sobre o valor que aquela demanda pretende gerar.

O Upstream é aberto aos mais diferentes tipos de contribuições, e é bom que seja assim, pois as boas – e más – decisões desta etapa influenciarão diretamente o que acontece no Downstream. Inclusive, é nessa passagem de bastão que o Analista de Negócios (gestor do fluxo, no nosso caso) começa a alimentar um “Inventário de demandas”, uma espécie de backlog filtrado e priorizado. Para entender como acontece essa priorização aqui na Taller veja nossa série sobre o BVP.

 

3. Criação de demanda

Agora a conversa é com designers. Quem não é designer, por favor, saia da sala. Brincadeira, pode ficar. Mas atenção com o que vou dizer agora: nem toda demanda que aparece precisa ser feita. Tatuem isso, se for o caso. Ok, mas então como saber quais demandas precisam ser feitas? Bom, vamos imaginar o quadro geral do projeto (o board do Jira, por exemplo) com um funil. Em um funil a entrada é larga a saída é estreita. Nosso board de tarefas precisa funcionar da mesma maneira.

Deixem os pedidos chegarem, registrem e comecem a triagem. Tanto  designers quanto gestores de projeto/analistas de negócio serão uma espécies de guarda-costas das pessoas que desenvolvem. Ninguém não autorizado deve ir lá perturbar o trabalho dessas pessoas, afinal, a própria tarefa de pensar soluções em linguagem de código já é estressante por natureza, somado aos prazos apertados e diversos problemas que aparecem no dia-a-dia, deixá-los responsáveis por priorizar e destrinchar demandas acaba sobrecarregando uma parte do “grande organismo” que é a empresa. Isso é ruim, pois cria uma disfunção que tende a gerar conflitos no médio e longo prazo.

 

Upstream: a entrada é larga a saída é estreita.
Fonte: Glogster – Dante Alighieri
A pessoa que desempenha o papel de designer tem duas funções importantes no fluxo de tarefas: 

  1. Conferir com o cliente/gestores/usuários a relevância e detalhamento do pedido; 

  2. Identificar, com antecedência, o momento onde os desenvolvedores ficarão ociosos, e, então, muni-los com novas atividades que gerem valor.

Conferir a relevância do pedido não chega a ser uma novidade, afinal, já estamos imersos na cultura de ir escutar as pessoas, identificar necessidades e prioridades. O difícil é entender que a gente não precisa abraçar tudo o que nos chega. Nem tudo vai precisar de uma pesquisa, ou de um novo layout cheio de camadas e efeitos. Algumas demandas complexas requerem visualizações sofisticadas; outras se resolverão com uma simples conversa e detalhamento de história, talvez um esboço rápido. Um olho no pixel, outro no fluxo.

Tem tempo e sente a necessidade de explicar algo visualmente que ainda está confuso? Ótimo! Mãos à obra. Quem sabe, seja uma boa deixar uma carta na manga para quando o time de desenvolvimento estiver próximo de “passar fome”, prestes a solicitar novas tarefas. Ter esta noção de quando aprofundar uma tarefa e quando parir outras, é, no fim das contas, o que eu gostaria que vocês levassem como mensagem principal deste texto. Isso é gestão do fluxo de criação de demanda. E acontece na parte do Upstream no Kanban, capisce?

 

Um olho no pixel, outro no fluxo.
Fonte: BuzzFeed

 

4. Aprofundando no tema

Vamos explorar esses conceitos ao longo de 2020 aqui no blog. Por hora, deixo duas indicações:

LKNA17: End-to-End Flow with Customer and Upstream Kanban – Patrick Steyaert

 

Abraço e bons estudos!

Ítalo Mendonça
Designer na Taller

Sair da versão mobile