Como colocar a sua startup no Fluxo Unificado?

Vimos no artigo anterior as teorias que sustentam o fluxo unificado e porque deveríamos considerar essa técnica de gestão para startups. Agora vamos explorar como fazer isso.

Abrace a variabilidade

Citando Don Reinertsen, em sua excelente obra The Principles of Product Development Flow: Second Generation Lean Product Development, ele nos mostra que a variabilidade é algo que estará sempre presente, principalmente nas empresas que lidam com inovação.

A variabilidade é parte da inovação, o que a torna não só onipresente, mas necessária. tweet

Quando você inova, você está caminhando por terreno inexplorado, sendo assim extremamente infértil para previsões. Além das variações naturais do terreno imprevisível da inovação, não deixamos de ter as relacionadas ao trabalho do conhecimento, assim como as que nascem das interações das partes do sistema. Cachorro morreu, carro quebrou, ônibus não passou, fiquei doente, briguei com a minha namorada, dormi pouco, estou cheio de dívidas, cliente mudou de idéia, aquela solução não funciona… Como você elimina ou mitiga estas variabilidades? É praticamente impossível.

É neste momento que Don nos diz: “Embrace the variability”, “Deal with the variability, don’t be afraid of it. Face it!”

Quebrando mitos

É exatamente neste sentido que o Fluxo Unificado de demandas caminha. Esta não é uma solução de gestão apenas para desenvolver software e ter um pool de desenvolvedores atendendo diferentes demandas de diferentes clientes. Vamos quebrar alguns mitos:

  1. Este pool de “servidores” não está limitado a desenvolvedores. Nos bancos vemos caixas de banco, gerentes, no supermercado vemos caixas de supermercado, etc.;
  2. A obrigação de uma empresa não é apenas mapear e melhorar o seu fluxo de desenvolvimento, mas sim mapear e melhorar toda a empresa. Sob essa perspectiva, o mapeamento apenas do desenvolvimento parece uma otimização local, não?
  3. Acompanhando o item 2, se nós temos diferentes fluxos, temos diferentes demandas fluindo neles;
  4. Classes de serviço podem e devem ser usadas para classificar demandas de todos os tipos, de todos os fluxos, sem muitas restrições.

É claro que, como toda solução que conhecemos, esta também é sensível ao contexto. Extremamente sensível, eu poderia dizer, mas você pode ter uma pista sobre o que fazer.

Segundo os dados que tenho observado ao longo do tempo, a maioria das startups de tecnologia nasce de uma ou duas pessoas que tiveram uma idéia. Estas mesmas pessoas desenvolveram esta idéia, tecnicamente e comercialmente. É neste ponto que temos nossa primeira pista.

Em algumas startups, os fundadores precisam fazer tudo, isto é, possuem múltiplas funções: desenvolver uma demanda do software, criar um conteúdo em texto, criar um conteúdo em vídeo, conversar com investidores, trabalhar alguma animação, ficar atento aos competidores. Em outras startups, os fundadores não desenvolvem, mas possuem todas as outras funções também importantes e pesadas.

Mudança de mindset para o fluxo Unificado

Esta é a mudança que se faz necessária: Se você está inserido em qualquer um dos dois cenários, você já atua em um fluxo unificado e ao “lutar” contra isso, você adiciona complexidade desnecessária à gestão.

Neste momento, temos outra subdivisão de cenários: ou você mapeia os seus fluxos ou você não mapeia. Se está no primeiro cenário, você não se importa muito com a sua capacidade de visão, nem de curto, nem de médio e nem de longo prazo. Você já não enxerga muita coisa e toma as decisões no tato e no feeling. Ter ou não ter fluxo unificado mapeado não fará diferença, porque você não tem fluxo nenhum mapeado.

Agora se você está no segundo cenário, já consegue visualizar seus fluxos de trabalho e possui múltiplos fluxos dividindo múltiplos servidores semelhantes em diversas frentes de gerenciamento e metrificação, a pergunta que eu faço é: para que você faz isso? Vamos voltar à questão dos “semelhantes” no final deste artigo.

Melhorando a forma como você vê o seu trabalho

Observe o seguinte cenário fictício onde uma empresa de uma pessoa só está iniciando suas operações:

Fluxo Unificado – Marketing Flow

Fluxo Unificado – Blog Posts

Ao colocar os dois fluxos lado a lado, já fica claro que temos muita coisa em execução. Se temos um servidor e duas atividades em execução, não temos foco e não conseguimos cumprir o objetivo de “parar de começar e começar a terminar”. Isso pode matar a empresa. Ainda no berço. Olhando os dois quadros isoladamente, só temos idéia da realidade. Assim, com servidores semelhantes, podemos dizer que estes quadros possuem um alto grau de dependência e de custo de coordenação.

Isso também é facilmente notado em cima do que precisamos fazer. Se eu acabar uma das tarefas em “doing“, o que preciso fazer em seguida? Puxar uma do “to do“? Qual? Continuar a outra que já está em “doing” (caso eu me lembre dela)? Estas dúvidas, muitas vezes escondidas, compõe o custo de coordenação do meu processo. Então, além de esconder a realidade, este modelo de múltiplos fluxos para servidores semelhantes custa caro.

Você, neste caso e em todos onde existam servidores semelhantes, está quebrando algo que tende a funcionar junto. Se trabalhar desta forma, você está adicionando custo de coordenação para metrificar, analisar e gerenciar algo sob uma perspectiva artificial e está gerando uma série de problemas com isso.

Eliminando o custo de coordenação

Pense agora no mapeamento de fluxo abaixo:

Fluxo Unificado – Fluxo Unificado

Eliminamos o custo de coordenação provocado pela quebra artificial no mapeamento do fluxo. Agora está claro que esta pessoa tem um problema: está fazendo duas coisas ao mesmo tempo. Está claro o que ela precisa fazer depois que terminar o “doing“. Está claro priorizar o “to do“, pois todo o fluxo está a vista. Podemos usar cores para identificar o que é para “geração de conteúdo”, o que é para “gerar confiança no mercado” e ter quantas classes de serviço forem necessárias para organizar o fluxo.

Alinhamento com a estratégia da empresa

Percebam a clareza da estratégia da empresa. Mais uma vez, isso pode estar representado com cores. Fiz aqui com o texto (Produto A, Produto B, Interno…) para facilitar a explicação. Desta forma, como explicado anteriormente, o pool de servidores que estava fazendo tarefas técnicas, agora vai precisar criar um post para ser publicado em uma semana.

Sabemos que uma demanda de geração de conteúdo, de criação do vídeo, passou pelo fluxo recentemente, pois está no topo do “done” e isso suporta tomadas de decisão do tipo: estamos em um momento em que precisamos gerar mais conteúdo? Ou aquele suporte é mais importante? Esses planos táticos alinham com a nossa estratégia?

Neste momento pode surgir o questionamento: Então, fluxo unificado para todas as coisas? Aqui entra o “servidores semelhantes”. Sou bastante radical neste ponto. Eu vejo um risco grande caso um dos servidores não seja capaz de puxar a próxima demanda. Vamos examinar as consequências da implantação do fluxo unificado e as soluções para possíveis problemas em um próximo post.