Lean Inception: concepção de produtos enxutos – Parte 2

No artigo anterior iniciei conceituando o que é a Lean Inception. Falamos um pouco da sua história e tratei de resumir as dinâmicas que envolvem os dois primeiros dias de trabalho de uma inception (ou três, se você considerar o trabalho prévio). Entendemos que o foco da inception é sair com um entendimento comum do que será o produto e quais serão os primeiros passos da sua construção, o seu MVP inicial, bem como o roadmap que se seguirá a partir dele.

Claro, até o término do segundo dia não é possível ter tanta clareza assim uma vez que o melhor ainda está por vir nos dias seguintes. E é desses dias que vou falar nesta segunda e última parte do artigo sobre Lean Inception!

O livro do Paulo Caroli pode ser obtido neste link!

Dia 3: Quarta-Feira

Assim como todos os dias da inception, começa-se com uma energização e em seguida faz-se uma restrospectiva dos dias anteriores, neste caso passando pela Visão do Produto, o que ele É-Não É-Faz-Não Faz, quem são as Personas que usarão o produto e quais as Features que descobrimos para ele.

E é com esse gancho das features que iniciamos o terceiro dia da Inception, fazendo um nivelamento das mesmas, também chamado de Revisão Técnica e de Negócio. Esse nivelamento é feito com todo o grupo em conjunto de uma maneira tão simples quanto levantar a mão com uma nota de 1 a 3 para cada uma das perguntas seguintes:

de 1 a 3, qual o nível de entendimento de negócio que temos sobre esta feature?
de 1 a 3, qual o nível de entendimento técnico que temos sobre esta feature?

Conforme as respostas são consolidadas para cada feature (incentive o debate quando existirem notas 1 e 3 para a mesma feature, semelhante ao que fazemos em um Planning Poker), coloque-as em uma matriz como abaixo.

Ou seja, se uma feature recebeu nota 1 para entendimento técnico e 3 para entendimento de negócio, ela vai ficar no canto superior esquerdo. Essa feature deve ser sinalizada com a cor vermelha, geralmente colando o post-it dela sobre um cartão com esta cor.

Note que se a feature ficar posicionada em algum dos quadrantes com um X, ela não será incluída no MVP, pois seu nível de certeza é baixíssimo. Demais features em posições vermelhas devem ser melhor discutidas, features nos quadrantes amarelos estão com nível razoável de certeza e features verdes estão prontas para serem desenvolvidas.

Após essa análise sobre uma feature, fazemos uma segunda análise, também em grupo, respondendo as seguintes perguntas:

de 1 a 3, qual o esforço necessário para desenvolver esta feature? Marque o consolidado no canto do cartão da feature usando os símbolos E, EE ou EEE para o esforço.
de 1 a 3, qual o retorno financeiro desta feature? Marque o consolidado no canto do cartão da feature usando o símbolos $, $$ e $$$ para a receita.
de 1 a 3, o quanto os usuários vão amar esta feature? Marque o consolidado no canto do cartão da feature usando corações (1 a 3).

Na imagem abaixo está um exemplo de feature “estimar preço” nivelada com grau amarelo de certeza, esforço médio e receita alta. Não tem o coração ainda pois essa foi uma adição mais recente do Caroli ao método.

Após fazer isso com todas as features descobertas no dia anterior, teremos um canvas de features (aquele com as Personas x Features, lembra?) com mais detalhes sobre cada uma delas.

Note que as discussões geradas por esse nivelamento produzem muito mais do que apenas cards coloridos e marcações, elas dão uma clareza muito maior do que pretende-se desenvolver para todos os membros do grupo e inclusive você pode incluir mais informações aos cards para uso posterior, oriundas dessas discussões.

Na parte da tarde, sim o dia ainda não acabou, é hora de falarmos de Jornadas dos Usuários. Aqui a dinâmica é mais simples: cada grupo pega uma persona (se sobrar tempo pode fazer para mais de uma) e trabalha em uma jornada dela, onde haja ponto de contato com o produto que será desenvolvido.

Um excelente framework para essa dinâmica é pegar uma folha A2 para cada jornada e traçar uma matriz com as colunas sendo: antes, durante e depois e com as linhas sendo: ação, ponto de contato, pensamento e humor. Na coluna Antes você vai colocar as ações, em ordem cronológica, que vão levar o usuário a ter contato com seu produto, ele se deparando com o problema ou necessidade o qual o levará até o produto. Vale qualquer coisa, até falar do café da manhã dele. Para cada ação, não esqueça de citar os pontos de contato com o produto, o que o usuário está pensando naquele momento e como está o humor dele.

Na coluna Durante, descreva as ações do usuário já usando o produto, não esquecendo dos pensamentos e sentimentos também. Já na coluna Depois, descreva as ações pós-uso do produto, do usuário aproveitando o benefício obtido, por exemplo.

Caso mais de algum grupo faça a mesma jornada, é importante que haja uma consolidação através do consenso entre eles. Podem existir várias jornadas por persona, mas que não descrevam a mesma situação de uso do produto. Ao término do dia, todos apresentam suas jornadas, registra-se tudo e enviam-se os materiais gerados por email.

Dia 4: Quinta-Feira

No quarto dia, após a energização e recapitulação dos dias anteriores, é hora de mapear as features às jornadas do usuário. Lembra que lá atrás mencionei que era uma boa colocar identificadores únicos nas features? Pois é, aqui isso vai ser bem útil.

Mudam-se os grupos para que cada grupo fique com uma jornada que não foi criada pelo próprio grupo. Para cada ação do usuário (principalmente na etapa Durante), verifica-se quais features seriam utilizadas naquela ação, anotando o código da feature em um post it e colando próximo ou sobre a ação.

Caso note-se que tem alguma feature faltando, já cria-se ela e faz-se o nivelamento da feature individualmente que nem foi feito no dia anterior, colocando-a à disposição dos demais grupos no canvas de features.

Caso note-se que alguma feature ficou sobrando, talvez seja o caso de despriorizá-la, pois nas principais jornadas do usuário ela não se mostrou presente.

Após todos os times terminarem de mapear o uso das features nas suas jornadas, apresenta-se o resultado para o grande grupo.

Na parte da tarde do mesmo dia é hora de fazermos o Sequenciador de Features. Considerando tudo que foi aprendido e co-criado até aqui, vamos usar o Sequenciador de Features para definir o escopo do nosso MVP e o que sobrar ficará para as releases seguintes, em um roadmap incremental de produto.

Você cria a dinâmica do sequenciador com um único cartaz dividido em linhas horizontais (com altura suficiente para um card de feature e largura para três), numeradas à esquerda, como mostra a imagem abaixo.

Os times vão debater e decidir quais features devem ser implementadas primeiro (i.e. serem colocadas primeiro no sequenciador) considerando as jornadas mais importantes, precedência de features, etc. O preenchimento do Sequenciador é um trabalho do grupo inteiro. No entanto, existem algumas regras que devem ser seguidas, criadas pelo Caroli após várias inceptions na prática:

Cada linha pode conter no máximo 3 features;
Cada linha não pode conter mais do que 1 feature vermelha;
Cada linha deve conter uma feature verde;
A soma do esforço das features de uma linha não pode ser superior a 5 Es;
A soma da receita das features de uma linha não pode ser menor que 4 $s;

Cada regra tem uma razão de existir e é recomendado que sejam seguidas à risca para garantir releases que balanceiem a entrega de valor x o risco. Considerando a ordem de cima para baixo e da esquerda para direita, em algum momento você conseguirá definir o escopo do primeiro MVP e dos MVPs seguintes.

Caso nunca tenha feito uma estimativa de alto nível antes, você pode pegar uma das features cujo nível de entendimento de negócio e técnico seja muito alto e tentar estimar em quanto tempo ela seria desenvolvida (usando T-Shirt Sizing, por exemplo) usando o time que você possui hoje. Com base nela você consegue estimar as demais por comparação e sinalizar no Sequenciador onde terminam cada um dos MVPs, montando o roadmap incremental do produto.

Dia 5: Sexta-Feira

No último dia da inception enxuta, é hora de consolidar tudo o que foi aprendido ao longo da semana em um MVP Canvas (técnica mais recente do que a mostrada no livro Direto ao Ponto original), cujo template você encontra abaixo. Claro, não esqueça de enviar a todos por email os resultados do dia anterior, fazer uma energização no início do dia e uma recapitulação das dinâmicas anteriores.

Um único MVP Canvas será criado para cada release do roadmap criado a partir do Sequenciador de Features, de maneira colaborativa entre todo o grupo. Mas nem só de consolidação é formado o canvas, pois algumas áreas exigirão que o grupo raciocine sobre o construído, de forma a torná-lo “user centered” e que seja possível medir o seu sucesso para pivotar ou não, uma vez que dependendo do aprendizado obtido a partir da construção deste MVP, todo o restante do roadmap pode ser alterado (não caia na armadilha de seguir um roadmap de MVPs à risca e às cegas). É só seguir a cartilha do Lean Startup, não tem erro!

Resumidamente, você preenche o MVP Canvas da seguinte forma:

MVP Vision: baseado na Product Vision criada no primeiro dia da inception, derive para uma visão específica desta release;
Outcome Statement: qual o foco de aprendizado deste MVP? O que estaremos validando com esta entrega? O que esperamos alcançar?
Metrics: como iremos medir o progresso/sucesso deste MVP? Que índice indicará sucesso ou falha?
Personas & Platforms: para quais personas este MVP será lançado? E para quais plataformas? Restrinja a uma ou duas personas/plataformas em cada resposta.
Journeys: quais jornadas das personas escolhidas serão atendidas por este MVP?
Features: quais features do Sequenciador entrarão neste MVP?
Cost & Schedule: qual o custo e prazo desta entrega?

Após a construção do MVP Canvas, na parte da tarde é feito o showcase para todos os stakeholders do projeto, além do próprio grupo que trabalhou duro para chegar neste resultado, não é mesmo?!

E depois?

Com o MVP Canvas em mãos e todo mundo alinhado com o que deve ser feito no primeiro MVP, é hora de colocar a mão na massa rodando o bom e velho Scrum: o Product Owner terá de incluir as features dos canvas no seu Product Backlog, refinando-as em User Stories os que devam entrar no primeiro MVP, para que na primeira Sprint Planning o Time de Desenvolvimento consiga quebrá-las em tarefas, estimá-las em pontos e iniciar o desenvolvimento do produto de fato.

Para se aprofundar no assunto, leia o livro do Caroli, abaixo. Para mais conteúdo sobre Métodos Ágeis de desenvolvimento de software, recomendo o meu livro Scrum e Métodos Ágeis: Um Guia Prático e meu curso sobre o mesmo assunto.