Gestão, Startups

O Lean Stack em Português – Parte 1

A jornada empreendedora é permeada de desafios. É preciso assumi-los e buscar alternativas eficazes para contorná-los. Como ferramenta auxiliadora nesse processo, conheça a...

· 7 min leitura >

Este post é uma tradução do original escrito por Ash Maurya, autor do Livro Running Lean, e publicado em inglês em seu blog. Esta publicação foi autorizada pelo autor.

A maioria dos produtos falha não porque falhamos construindo o que se pretendia construir, mas porque desperdiçamos tempo, dinheiro e esforço construindo o produto errado.

Eu atribuo à paixão pela solução – muitas vezes desenfreada – do empreendedor como  a maior contribuição para este fracasso.  Às vezes a solução que pensamos é sensacional para muitas pessoas, mas é mais comum que não seja.

1

Então como você pode superar isso?

Para os iniciantes, eu defendo fortemente a redefinição do “produto real” e do “trabalho real” do empreendedor.

  1. O produto real do empreendedor não é uma solução, mas um modelo de negócio funcional.
  2. O trabalho real do empreendedor é sempre diminuir sistematicamente os riscos deste modelo de negócio.

Esta redefinição foi minha motivação para criar um derivado do formato Lean Canvas e representar o que eu acredito serem os princípios para “Running Lean” descritos abaixo:

2

Você começa definindo o limite do seu Lean Canvas inicial, priorizando riscos e testando-os através de experimentos. Então você gera o loop de feedback e aprendizado que vai dos experimentos para os riscos, e dos riscos para o modelo de negócio.

Colocando em prática

Enquanto este processo acontece conceitualmente, muitas vezes ouço outros empreendedores, especialmente sobre:

  1. Priorizar riscos e definir experimentos corretamente;
  2. Acompanhar esses experimentos para que escalem com o tempo (e com mais pessoas);
  3. Refletir  no canvas o aprendizado  dos experimentos.

Mais recentemente, eu vivi esses desafios em primeira mão enquanto montava minha equipe e tentava construir uma organização de aprendizado onde todos realizam experimentos.

A raiz do problema deste processo é que cada transição entre estágios requer um “Salto de Raciocínio” que muitas vezes é difícil de ensinar e/ou compartilhar com outra pessoa.

Mesmo que realizar experimentos seja uma atividade chave de uma Lean Startup, defini-los, realizá-los e acompanhá-los é difícil.

Para me inspirar, eu recorri a Jeffrey Liker, que escreveu uma série de livros sobre o Sistema de Produção da Toyota.  Devo admitir que não sou muito bom em processos e até tenho uma aversão interior ao tema. Como muitos de vocês, trabalhei em grandes empresas e convivi com muitos relatórios inúteis e processos desnecessários. Mas na Toyota eles tinham uma visão diferente sobre esses relatórios.

O processo certo produzirá os resultados certos.

Jeffrey Liker, The Toyota Way.

No pensamento enxuto (lean), um processo não é algo passado de cima para baixo, mas um produto vivo que pertence àqueles que fazem o trabalho.  Eles são encarregados de uma única orientação: reduzir o desperdício (ou seja, eliminar o trabalho que não gera valor). Você começa documentando o processo atual (com um mapa de fluxo de valor) e então desafia a todos a continuarem melhorando-o. Nisso eu posso perder tempo pensando.

Depois de algumas iterações e muitos testes, a gente desenvolveu um processo que funciona para nós e outras startups – uma coisa que estamos chamando de Lean Stack e explicarei daqui a pouco. Primeiro, é válido explicar como chegamos lá.

Versão 1: Camadas de Riscos e Experimentos para o Lean Canvas

Nossa primeira abordagem foi utilizar um modelo de camadas para o Lean Canvas. A ideia era manter a estrutura do canvas intacta mas sobrepor visões diferentes para os riscos e experimentos a ela.

3

Isso é o que está construído atualmente na nossa ferramenta de Lean Canvas, mas apesar de muitas tentativas, não conseguimos adotá-lo na nossa rotina diária.

Encontramos-nos lutando para restringir um experimento a uma única seção do canvas. Muitos experimentos, como realizar uma entrevista sobre a solução, potencialmente testa várias hipóteses e suposições para o modelo de uma só vez.

O problema principal é que o canvas é uma visão estática, e não ajuda a visualizar o fluxo de trabalho por si só.

Use formas visuais de controle para que nenhum problema fique escondido.

Jeffrey Liker, The Toyota Way.

Versão 2:  Feature Level Kanban Board

Isso nos leva a nossa segunda versão, que criou um quadro Kanban de Recurso Mínimo Viável (Minimum Viable Feature – MVF), que eu documentei neste post: “How we build features” e no meu livro.

Para relembrar:

  • MVF é derivado de Recurso Mínimo Vendável (Minimum Marketable Feature – MMF).
  • MMF foi definido pela primeira vez no livro “Software by Numbers” como a menor porção de trabalho que gera valor para os clientes. Um Mínimo Produto Viável (Minimum Viable Product – MVP) é feito de um ou mais MMF’s.
  • Um bom teste para o MMF é se perguntar se você o anunciaria para os seus clientes em seu blog ou newsletter. Se for pequeno demais para mencionar, então não é um MMF.

A ideia aqui é usar o Lean Canvas para documentar o modelo de negócio e seus riscos, e o Quadro Kanban para documentar o trabalho atual.

A escolha de usar um MVF como uma unidade menor de trabalho foi intencional. Eu queria uma visão macro do trabalho que também capturasse aprendizado do cliente ao invés de ter apenas um quadro de tarefas (que mantínhamos separado).

4

Enquanto o Quadro Kanban era ótimo para acompanhar recursos do software, ainda era preciso um salto de raciocínio entre o canvas e o quadro.  Mesmo que usar o canvas para representar os riscos fizesse sentido, como tudo que está no Lean Canvas precisa ser testado, a composição do canvas fica em torno de suposições. Eu percebi que simplesmente marcando uma seção do canvas como um risco não era suficiente, enquanto ainda era preciso traduzir aqueles conjuntos de suposições em riscos e depois priorizá-los.

Saltos de raciocínio são ruins porque pessoas diferentes pensam em diferentes saltos, o que não é uma coisa ruim por si só. O problema aparece quando esses saltos não documentados começam a gerar trabalho para os outros.

Tarefas padronizadas são a base da melhoria contínua.

Jeffrey Liker, The Toyota Way.

Também se torna aparente quando um MVF não é apenas um experimento, mas um apanhado deles feito de um apanhado de tarefas. Ocorre quando o quadro é macro demais, o que resulta em um movimento lento.

5

Um pouco mais de inspiração: A pirâmide de visão estratégica do produto

Nós precisávamos de um processo que fluísse melhor do início ao final. A ideia para isso, e o subsequente Lean Stack, chegou ao ouvir Eric Ries descrever sua Pirâmide de Visão Estratégica do Produto em um seminário on-line que fizemos juntos.

6

Eu tinha visto a pirâmide muitas vezes antes no livro do Eric, mas desta vez ela teve um efeito diferente.

Eis a minha conclusão:

“Quando empreendedores são atingidos por uma ideia, tudo se transforma em um único e claro sinal. Outra forma de reafirmar a razão dos produtos falharem é que, como empreendedores, muitas vezes não usamos o tempo para desconstruir esta ideia em sua visão, estratégia e componentes do produto. No lugar disso, nós vamos direto para o topo da pirâmide – apenas para nos apaixonar prematuramente por nosso produto.”

Um bom jeito de explicar a pirâmide é usando uma metáfora de trânsito (como Eric faz no seu livro):

7

Imagine que você aceitou um novo emprego do outro lado da cidade. A visão representa o seu destino, ou o seu novo local de trabalho. A estratégia representa todas as possibilidades de chegar lá – você pode ir de bicicleta, pegar um ônibus, dirigir etc. Você não sabe quais rotas são as melhores, então vocês faz experimentos. Uma mudança na estratégia é um pivô. O produto é um trajeto repetível para chegar ao trabalho.

Outro modelo útil para explicar a pirâmide é usando o Círculo de Ouro de Simon Simonek. A visão é por que. A estratégia é o como. E o produto é o que.

8

Versão 3: O Lean Stack

A pirâmide não é apenas um bom modelo mental, mas também pode ser tecida em um processo que corre pela construção de um controle visual em cada um dos estágios da pirâmide. Isso é exatamente o que eu fiz com o Lean Stack.

A camada de Visão – Lean Canvas

A camada mais baixa da pilha (stack), sua “visão” ou o “porque”, ainda é melhor capturada pelo Lean Canvas. Foi feita para documentar sua melhor aposta ao formatar um modelo de negócio.

9

A camada de estratégia – Quadro de riscos e estratégia

A camada do meio da pilha é a cola que conecta as outras duas camadas que estavam faltando nas minhas tentativas anteriores. Esta camada ajuda a quebrar a visão macro em um plano de implementação (estratégia) que é alimentado tanto pelo conhecimento oriundo do estudo dos similares e opostos existentes, quanto conversando sobre riscos com sua equipe, stakeholders, conselheiros, clientes e até competidores.

10

A seção de similares/opostos  é um conceito descrito por Randy Komisar e John Mullins no livro deles: Getting to Plan B” que eu ilustrarei com exemplos no meu livro-texto.

Riscos são capturados em um Quadro Kanban na área de backlog, onde eles são priorizados e então usados para direcionar outros experimentos abaixo da linha.

A camada do Produto – Quadro de Aprendizado Validado

A camada superior do Lean Stack deve capturar o trabalho atual que leva a construção do produto que a visão indica.

11

Eu capturo este trabalho em um Quadro de Aprendizado Validado que é similar ao futuro Quadro Kanban de Recursos, mas com alguns ajustes. Por exemplo, ele foi generalizado para suportar qualquer tipo de produto (não apenas softwares), quebrando o fluxo em quatro estágios de iteração padrão:

  1. Entendendo o problema: Antes de você poder definir uma solução, você precisa entender o cliente e o problema.
  2. Defina a solução: Ao invés de se apressar em construir a solução, use um protótipo para definir a solução primeiro.
  3. Valide Qualitativamente: Valide a solução em menor escala.
  4. Verifique quantitativamente: Finalmente, verifique a escalabilidade da solução.

Mas a grande mudança aqui é que modelamos tanto o produto quanto os experimentos em um mesmo quadro, usando um quadro em dois níveis e implementado com seções horizontais. Se você quiser aprender mais sobre Quadros Kanban, recomendo fortemente o livro clássico de David Anderson “Kaban” como um ótimo começo.

O nível superior captura o estágio do produto.  Um “produto” no quadro pode representar um MVP, MMP ou um sub-produto relacionado. Em determinado momento, um produto pode estar apenas em um dos quatro estágios. Cada estágio tem um critério claro de saída definido (como números de entrevistas, um aprendizado ou um espaço de tempo) que é capturado no cartão do produto.

12

Para cada produto, você pode realizar quantos experimentos quiser, que são colocados em uma raia horizontal para o produto. Cada experimento tem uma hipótese suposta clara e, opcionalmente, um espaço de tempo restrito. Um experimento acontece através de um ciclo de Contruir/Medir/Aprender representado pelas colunas nomeadas igualmente no quadro.

13

A coluna de construção representa a definição e o estágio inicial do experimento, que costuma envolver coisas como escrever o código, desenhar a landing lage, maquetes, criação de scripts para entrevistas etc.

No momento em que o experimento é mostrado para pelo menos um cliente, o cartão se move para o estágio de Medir.

Uma vez que foram coletados dados suficientes ou o espaço de tempo expirado, o cartão é movido para o estágio de Aprender, onde é marcado como “Validado” ou “Não Validado”, baseado no critério estabelecido pela hipótese.

14

O aprendizado é então internalizado para determinar quando o critério de saída foi atingido. Caso seja, o cartão do produto se move para o próximo estágio. Caso contrário, mais experimentos são feitos.

E para acompanhar todas as tarefas dentro dos experimentos?

Mesmo sendo conceitualmente possível criar um terceiro nível para as tarefas, geralmente é melhor evitar ir além de dois níveis enquanto o quadro fica muito cheio.  Além disso, a medição de progresso no Lean Startup é o aprendizado, não a construção, o que é outro motivo para manter os detalhes fora do quadro.

Nós acompanhamos as tarefas em outro Quadro Kaban que é linkado aos experimentos. Mas, por enquanto, considero este quadro fora do nosso escopo.

O Lean Stack na prática

15

São muitas informações para um único post. No próximo, irei falar sobre juntar esses quadros e ilustrá-lo na prática, usando o exemplo de um dos nossos produtos.

Deixe seu comentário:

plugins premium WordPress