O que é Lean Inception e como conduzir a semana

Lean Inception é um workshop de uma semana que coloca negócio, produto e tecnologia na mesma sala para decidir qual é o primeiro MVP. Termina com escopo acordado e um MVP Canvas preenchido, não com um documento de requisitos. O método é de Paulo Caroli, que o formalizou no livro Lean Inception: Como Alinhar Pessoas e Construir o Produto Certo, de 2018.

O nome vem de uma herança mais antiga. Inception é a primeira das quatro fases do RUP, o Rational Unified Process criado pela Rational nos anos 90: Inception, Elaboration, Construction e Transition. Na fase de Inception se analisava objetivo, arquitetura e planejamento, por meio de entrevista com os stakeholders, e o resultado virava requisito escrito em casos de uso.

A diferença entre as duas está menos na atividade e mais em quem decide.

No RUP, alguém entrevistava e depois escrevia o que entendeu. Na Lean Inception, as pessoas decidem juntas, na mesma sala, e o artefato é consequência do acordo. O método também bebe do Lean Startup de Eric Ries e do Design Thinking, e é por isso que termina em MVP e não em especificação.

A agenda da semana

Repare que a decisão do MVP só aparece na quinta. Os três primeiros dias servem para as pessoas construírem entendimento comum, e é justamente essa parte que a pressa costuma cortar.

Segunda: kick-off e o que o produto não faz

O kick-off existe porque a sala tem gente de áreas que não trabalha junta no dia a dia. Vale investir em ambiente, em apresentação e em deixar claro onde a semana vai chegar.

Uma observação que aprendi a levar a sério: grupo com o chefe presente produz menos ideia. As pessoas evitam sugerir o que possa parecer simplório na frente de quem avalia o desempenho delas. Se a liderança precisa participar, o melhor é que participe do kick-off e da apresentação final, e deixe as sessões de geração de ideia com o time.

Na parte da tarde vem a atividade que mais rende, e que é a mais desconfortável: o produto é, não é, faz, não faz.

Um quadrante em quatro partes, preenchido em grupo. O que o produto é e o que ele não é, o que ele faz e o que ele não faz. É aqui que aparecem as perguntas que ninguém tinha feito em voz alta: vai ser gratuito ou pago, app ou web, atende todo mundo ou um nicho.

O valor da atividade está na coluna do "não". Escopo se define excluindo, e excluir em grupo é o que evita a discussão de escopo três meses depois.

Terça: personas e funcionalidades

Personas descrevem quem vai usar o produto. Um quadrante ajuda a separar quem é central de quem é periférico, porque nem toda persona precisa ser atendida no MVP.

Não estranhe se elas ficarem caricatas. O método incentiva, porque nome memorável é nome que a sala usa depois. Um exemplo simples:

• Apelido: Pedro Produtor
• Perfil: 28 anos, solteiro, mora sozinho, médico
• Comportamento: conectado, assíduo, passa horas em rede social
• Necessidades: organizar encontro com amigos, resolver pelo celular, à noite e no fim de semana

Com as personas na parede, o brainstorming de funcionalidades usa um canvas simples: objetivos nas colunas, personas nas linhas. A pergunta que guia é sempre a mesma. O que precisa existir no produto para atender esta persona e alcançar este objetivo?

Quarta: esforço, valor e jornadas

Agora as funcionalidades recebem duas leituras diferentes, e é o encontro delas que decide o escopo.

O time técnico marca esforço. Nessa fase não existe estimativa em hora, e tentar produzir uma é perda de tempo. Funciona indicar grau, por cor ou por escala, ou usar planning poker.

O time de negócio marca valor, junto com o custo de não ter aquilo.

Caroli sugere uma notação enxuta para isso:

Verde para nível de confiança alto, amarelo médio e vermelho baixo. Marcações de valor de negócio variam em escala comparativa: $, $$ e $$$ para valor alto, muito alto e altíssimo. E E, EE e EEE para esforço baixo, médio e alto.

De tarde vêm as jornadas. Cada grupo pega uma persona e monta o passo a passo dela até o objetivo, em post-it, para a sala ver o fluxo inteiro. Três perguntas destravam:

• Qual objetivo essa persona quer alcançar?
• Como começa o dia dela?
• O que ela faz depois disso até chegar lá?

Duas jornadas do mesmo produto, um app de eventos:

Quinta: cruzar recursos com jornadas, e decidir o MVP

Neste ponto existem duas visões prontas, as funcionalidades e as jornadas, e elas são colocadas lado a lado. Para cada etapa de cada jornada, quais recursos são necessários.

O cruzamento revela dois tipos de furo, e os dois são úteis:

• Jornada sem recurso. Falta funcionalidade, e ela entra agora, com esforço e valor marcados.
• Recurso sem jornada. Aqui a pergunta é direta: se essa funcionalidade não aparece em nenhuma jornada de nenhuma persona, por que ela está no escopo?

A segunda pergunta é a que corta escopo de verdade, e ela só é possível porque o trabalho dos dias anteriores existe.

De tarde vem o sequenciamento. As funcionalidades são ordenadas e a sala responde: quantas dessas são necessárias para uma versão simples que já permita validar uma hipótese de negócio? Essa fatia é o MVP. O que sobra vira MVP2, MVP3, e assim por diante.

Escrever "MVP" em um flipchart e pedir que as pessoas coloquem as funcionalidades ao lado é um recurso simples e eficaz, porque torna a fronteira visível em vez de teórica.

Sexta: o MVP Canvas e a conversa com quem decide

Cada atividade da semana preenche um quadrante do MVP Canvas. Ele não é um documento novo, é a consolidação do que já foi decidido.

Repare no que esse quadro faz com a conversa de aprovação. Ele diz o que será construído, para quem, em quanto tempo, por quanto, e como se vai saber se funcionou. A linha das métricas é a que costuma faltar, e é a que transforma um pedido de orçamento em um experimento com critério de sucesso declarado.

Na apresentação final, dependendo da prioridade, dá para levar só o resultado da semana ou já um MVP funcional para as pessoas testarem. O objetivo não é mostrar produto pronto e sem erro. É mostrar a decisão e o caminho.

O que a semana realmente produz

O artefato é o canvas. O resultado é outra coisa.

Na minha visão, o que a Lean Inception entrega de mais valioso é um grupo que decidiu junto. Quando negócio, produto e tecnologia constroem o escopo na mesma sala, a discussão de "não foi isso que eu pedi" perde o terreno onde ela costuma crescer.

E é por isso que ela funciona melhor quando não é tratada como cerimônia obrigatória. A agenda é um bom ponto de partida, não um contrato. Time menor e escopo mais simples fecham em menos dias.

Na sua organização, o escopo de um produto novo é construído junto, ou ainda é levantado por alguém e depois apresentado aos outros?