Lean Inception — Reduza custos de projeto, agilize seu MVP e surpreenda seu cliente
Tem algum tempo que sigo o trabalho do Paulo Caroli sobre Lean Inception. Assisti algumas palestras, workshops e li o livro Lean Inception — Como Alinhar Pessoas e Construir o Produto Certo. Escrevo este artigo como uma forma de documentar os conhecimentos adquiridos e também para contribuir com a minha rede a respeito do assunto. Neste artigo trago dicas e os principais passos indicados por Caroli para a realização da Inception.
LEAN INCEPTION
Tempos atrás escrevi um artigo sobre a utilização de métodos ágeis na Brainny, mais especificamente sobre as práticas relacionadas ao framework Scrum. A Lean Inception é um passo anterior a isso. Ela vem com o propósito de ajudar a equipe e cliente a entender melhor a necessidade do cliente e usuário, afinal, nem sempre o que o cliente pede é o que ele realmente precisa. Conforme um dos princípios do manifesto ágil dita, precisamos zelar pela “ Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito”. Afinal, a Lei de Pareto se aplica ao desenvolvimento de software, e
20% dos esforços de desenvolvimento de software são responsáveis por 80% do valor entregue ao cliente.
e isso tem que nos levar a refletir e buscar alternativas para otimizar o valor das entregas realizadas em qualquer software house. Isso mais do que reduzir custos de funcionalidades de pouco valor, significa, muitas vezes, viabilizar uma ideia. A Lean Inception nos auxilia a definir mais precisamente o MVP (Minimum Viable Product), ela é um workshop colaborativo com sessões de brainstorming e discussões que normalmente tem a duração de 1 semana.
Ela tem feito parte dos planejamentos da Brainny, para demandas de clientes, assim como para a definição de nosso produto. Com ela realizamos o workshop sobre o nosso produto, e iniciamos com uma ideia em mente, a qual acabamos com uma definição bastante diferente, que nos deixou muito mais confiante sobre o MVP que colocaremos no mercado.
MVP
Resumidamente, a ideia de MVP validou inúmeros negócios que, hoje, revolucionaram nossa forma de ouvir música, nos hospedarmos e nos deslocarmos. A idéia é definirmos o mínimo para validarmos a ideia através de um número reduzido de hipóteses, avaliar e na sequência já aprimorá-la ou pivotá-la a partir dos resultados obtidos.
Dentre as imagens que exemplificam um MVP e o diferenciam do desenvolvimento tradicional, eu gosto bastante da que encontrei no productschool, acima. Na primeira imagem podemos visualizar o exemplo de construção tradicional, onde falando em software, vamos desenvolvendo funcionalidades que evidenciam que o software está em construção mas que não possibilitam a experimentação, são entregas sem valor. Já a imagem da esquerda é apresentada como “ideal” para validar negócios que não são do mundo de desenvolvimento de aplicações, embora seja o que muitas vezes aconteça, e sim, é legal, e é o que acontece quando o feedback dos usuários vão nos dando indicações de mudanças fortes nas ideias, inclusive, lá no primeiro MVP, o do patinete, a validação da nossa hipótese pode ser uma negativa que nos remeta a inviabilidade da ideia, que, embora a frustração, teremos investido o mínimo possível de tempo e dinheiro para validar o produto. Muito melhor do que ter esse feedback na versão final do produto, que é o que aconteceria na primeira imagem.
Já a imagem da direita nos remete a um MVP que está recebendo incrementos a partir do feedback dos clientes e sendo aprimorado. No início criamos o veículo de locomoção, na sequencia os usuários indicam a necessidade de carregar bagagens, depois de não molhar as bagagens em caso de chuva, e por fim de ter um carro mais estiloso.
Embora as imagens apresentem produtos finais iguais para todos os cenários, provavelmente não seria o que iria acontecer. Recebendo o feedback constante do usuário o produto final poderia ser mais refinado e teria características diferentes do construído de forma tradicional, detalhes que poderiam ser grandes diferenciais.
VALIOSO, USÁVEL, FACTÍVEL e DESTACADO
No seu livro, Caroli ainda fala que o MVP está sempre na interseção entre VALOR para o negócio, USÁVEL por parte dos usuários e FACTÍVEL pela equipe. Caroli ainda acrescenta que o Fator “UAU”, que conforme o nome sugere é o que fará do nosso produto DESTACADO, e que causará experiências diferencias aos usuários é um último fator determinante para o nosso MVP.
Nosso desafio fica o de conseguir atingir todos esses requisitos e parar de pensar em camadas: Fazer o factível (ex.: cadastros), depois o valoroso (ex.: extração de resultados, relatórios), depois tornar usável e por fim pensar um funcionalidades diferencias. O Lean Inception nasceu com a ideia de nos ajudar a chegar nesta interseção.
Um antigo ditado diz que “ A primeira impressão é a que fica”, então, tome cuidado, o MVP tem que ser uma demonstração do potencial que o nosso software tem a entregar, não uma ferramenta cheia de bugs e com uma experiência de usuário péssima. Isso provavelmente irá acarretar na perda permanente de usuários. Voltando lá na analogia dos MVPs de transporte, se o nosso patinete causasse acidentes com os usuários, com certeza perderíamos a credibilidade dos usuários para os próximos MVPs. Eles devem ser versões simplificadas da ideia, mas sempre buscando a excelência, sendo VIÁVEL.
WORKSHOP LEAN INCEPTION
Conforme já citado, o workshop tem duração sugerida de 5 dias, preferencialmente iniciado em uma segunda-feira para evitar que nossa memória faça “ swap” ou até mesmo despacho dos conhecimentos do workshop. Essa é uma semana intensa e cheia de atividades e a agenda sugerida é a que segue, com as atividades as quais vou passar a proposta na sequencia.
As atividades com o background em preto são atividades que contam com os stakeholders e as demais são para os membros ativos do projeto (time de desenvolvimento, Product Owner).
Em seu site, Caroli disponibiliza vários layouts para cartazes da Lean Inception que podem auxiliar o time, vale a pena conferir em https://www.caroli.org/cartazes-lean-inception.
AS ATIVIDADES
Nesta seção será apresentada as atividades sugeridas por Caroli, utilizando algumas imagens disponíveis em seu site, citadas anteriormente e outras criadas por mim para ilustrar as atividades.
1. KICK-OFF
No Kick-off serão apresentadas as expectativas com relação ao produto e a inception, provavelmente conduzida pelo P.O. e acompanhada pelos stakeholders do projeto.
Iniciar as atividades com uma dinâmica de energização é uma boa opção.
2. VISÃO DO PRODUTO
A definição da visão do produto é um passo fundamental para alinhar e manter o grupo focado.
Nesta atividade é sugerida a divisão de grupos, onde cada grupo de 2 a 3 pessoas irá trabalhar em algumas lacunas.
Na sequencia a visão do produto é mesclada, discutida e refatorada para se chegar na visão que melhor representa o produto.
Desta etapa, ao comparar, buscar diferenciais, pensar no nome, já costuma surgir ideias ricas.
3. O PRODUTO É — NÃO É — FAZ — NÃO FAZ
Esta atividade visa elucidar as características do produto, classificando através de post-its, coisas que ele é e não é, coisas que ele deverá fazer e que não cabe a ele. Desta atividade os participantes saem com uma boa e nivelada visão do produto.
Em um quadro, ou outra área qualquer com espaço suficiente, desenha-se o quadrante onde todos os participantes vão escrevendo características e inserindo no quadro de forma organizada e agrupada.
4. OBJETIVOS DO PRODUTO
Com o melhor entendimento do produto por parte do time, agora cada participante deve responder, individualmente, ao seguinte questionamento, em folhas A5, cartões ou post-its grandes:
Se você tiver que resumir o produto em 3 objetivos para o negócio, quais seriam?
Para exemplificar, considerando um produto voltado para usuários realizarem caminhadas noturnas com segurança, um participante poderia especificar objetivos como: “ Facilitar a prática de caminhadas noturnas para pessoas que só tem disponibilidade neste turno para realização de atividades físicas”, “ Localizar grupos de caminhadas nas proximidades”, “ Localizar todos os membros do grupo que estiverem com GPS ligado durante a caminhada”. Enquanto isso, outros participantes iriam escrever, pela sua ótica, quais eram os 3 principais objetivos do produto.
Com os objetivos especificados por todos os participantes, todos compartilham o que escreveram com o grupo e vão colocando em um quadro, agrupado por similaridade.
Agora, o grupo inteiro irá analisar os objetivos, concluir sobre objetivos mais pertinentes, objetivos que se complementam e objetivos que devam ser descartados. Feito isso, irão deverão reescrever os objetivos coletivamente, com objetivo de ficar com 3 objetivos, com flexibilidade de julgar a necessidade de mais.
5. MAPEAMENTO DAS PERSONAS
Caroli em seu livro destaca que é fundamental para identificarmos as funcionalidades do produto, traçarmos os objetivos dos usuários do produto, e para isso elaboramos quadrantes que identificam as nossas personas.
Esta é uma atividade que também pode ser realizada em duplas, e cada dupla deve criar uma persona e apresentá-la para todo o time.
Após as duplas apresentarem suas personas, as duplas são modificadas e novas personas são definidas e apresentadas. O processo se repete enquanto o time julgar necessário.
6. BRAINSTORMING DE FUNCIONALIDADES
Nesta fase já temos as personas e objetivos do produto definidos, e passamos a definir as funcionalidades. Para a descoberta de funcionalidades, Caroli sugere a reflexão em cima da seguinte pergunta:
O que deve ter no produto para atender às necessidades da persona? Quais funcionalidades devemos construir para atingir esse objetivo do produto?
Agora vamos organizar um quadro (acima) priorizando os objetivos da esquerda para a direita e as personas na primeira coluna com prioridade de cima para baixo.
Feito isso, a equipe executa um brainstorming das funcionalidades necessárias para cumprir com os objetivos e atender as personas.
Caso o número de personas e objetivos for muito grande e possa comprometer o tempo da atividade com muitas funcionalidades, uma atividade que pode nos ajudar a priorizar e selecionar o que realmente fará parte do MVP é nos perguntarmos:
Se estivéssemos com o orçamento muito curto, e tivéssemos que definir um único objetivo a cumprir e uma persona a atender, o que selecionaríamos?
7. REVISÃO TÉCNICA, DE NEGÓCIO E DE UX
Na atividade anterior inúmeras funcionalidades foram levantadas e agora o objetivo é refiná-las, identificar funcionalidades de maior valor para o cliente, de entendimento do negócio e o saber para desenvolvê-las.
A primeira missão é classificamos o nível de confiança para executar a funcionalidade. Utilizando o gráfico XY para classificar o nível de confiança do que fazer — nível de clareza da funcionalidade com relação ao negócio e expectativa do usuário, que está representado no eixo Y, e o saber como fazer — que no eixo X representa o quanto tecnicamente falando se sabe resolver esta funcionalidade. Para esta prática normalmente um participante pega o post-it, o coloca em alguma posição, justifica sua escolha, discute com a equipe e reavalia a posição. Conforme ela vai sendo classificada ela fica em um cartão da cor da sua classificação, como pode ser visto na imagem abaixo.
Este gráfico da figura acima também é chamado de semáforo pela analogia de cores — verde funcionalidades OK, pode seguir tranquilamente, amarelo funcionalidades que precisam de atenção, melhor esperar, e vermelho, não prosseguir.
Por fim, temos que classificar, em escala de 1 a 3 as funcionalidades quanto a esforço (E), valor para o negócio ($), e quanto o usuário amaria a funcionalidade (coração), conforme orienta a primeira imagem desta seção e exemplifica a imagem acima. Para esta a prática é a mesma do gráfico de semáforo — um participante define, justifica, discute e reavalia a classificação.
Ao fim da atividade teremos de forma bem visual as funcionalidades que estão prontas para serem desenvolvidas e que irão agregar valor ao produto, as funcionalidades que precisam de poucos ajustes (amarelas), as que precisam ser mais discutidas ou revistas e as funcionalidades críticas que devem ser revistas ou descartadas. Observe na imagem que podemos adicionar outros post-its com anotações a respeito da funcionalidade, que podem ser os esclarecimentos sobre a funcionalidade ou peculiaridades da mesma que ajudarão na hora de gerar a documentação a respeito das tarefas a serem desenvolvidas.
Essa é uma atividade bastante rica, que gera muitas discussões e esclarecimentos perante ao time.
8. JORNADAS DOS USUÁRIOS
Esta é outra prática divertida que nos ajuda a fazer um exercício de empatia, entendendo um pouco melhor nossas personas, as dores e comportamentos dela.
A ideia aqui é, através de post-its, traçarmos toda a jornada diária da nossa persona até chegar em funcionalidades e, por fim, no seu objetivo com o nosso produto.
Nesta tarefa novas funcionalidades podem surgir e, caso surjam, elas devem ser identificadas e rotuladas como todas as anteriores (cor, esforço, valor de negócio, UX…).
A proposta é montar um canvas com a Persona e o objetivo que ela irá alcançar, em destaque, no canto superior esquerdo e a partir daí, inicia a jornada da nossa persona, ilustrada na figura acima.
Assim como em outras práticas, algumas perguntas podem auxiliar o desenvolvimento da jornada, e são as seguintes:
Qual objetivo a persona X quer alcançar? Como ela começa seu dia? O que ela faz durante o dia? O que ela faz até alcançar o objetivo? O que ela faz depois que alcança seu objetivo?
Para associar a jornada com as funcionalidades, com o canvas da jornada preenchido, a sugestão é a divisão dos participantes em 2 grupos — Um responsável pelas jornadas e o outro pelas funcionalidades. O grupo da jornada lê lentamente um passo do usuário e o grupo das funcionalidades vai procurando funcionalidades para associar ao passo. Identificada a associação, é colocado um identificador no cartão da funcionalidade, por exemplo, “A01”, e em seguida coloque o número identificador no passo da jornada. Na imagem acima pode ser vista uma ilustração.
Se liguem! Uma persona pode ter mais do que uma jornada, se julgarem pertinente! Cada uma simulando algumas situações diferentes.
9. SEQUENCIADOR DE FUNCIONALIDADES
Chegou a grande hora. A hora de construir o sequenciador de funcionalidades. Para definir as mesmas, a pergunta que fica é:
Entre Lorem e Ipsum, qual a funcionalidade mais urgente/prioritária?
E repetir essa pergunta, basicamente, entre todas as funcionalidades mapeadas de acordo com as prioridades já identificadas: Principal persona, principal objetivo e principal jornada.
É importantíssimo também, verificar se a funcionalidade não possui pré requisito de outras funcionalidades. Caso isso aconteça a funcionalidade que bloqueia essa precisa, naturalmente, estar antes da analisada.
E para facilitar nossas escolhas, nas etapas anteriores da Inception definimos níveis de confiança, valor de negócio, esforço e valor de UX, e a nossa missão é sequenciar todas as tarefas na melhor ordem possível e marcar os MVPs.
Observe na Figura acima, do modelo do Caroli, que a ideia de cada onda (forma o autor chama cada linha do sequenciador, que funciona de forma similar ao que a galera do Scrum chama de sprint), é adicionar as funcionalidades dentro do quadro em ordem, sequenciado, seguindo as seguintes regras e dicas:
- Não esqueça que estamos focados no MVP e nosso objetivo é identificar o que é mais impactante o mais cedo possível, levando em conta o diagrama de Venn do início do artigo.
- A onda deve conter no máximo três cartões.
- A onda deve conter no máximo um cartão vermelho.
- A onda não deve conter 3 cartões amarelos e vermelho.
- A soma de esforço (E) dos cartões da onda não deve ultrapassar 5.
- A soma de valor de negócio ($) dos cartões não deve ser menor do que 4.
Com essas regras conseguimos criar ondas focadas com valores equilibrados e que nos auxiliam a, rapidamente, chegarmos ao nosso MVP.
Conforme a equipe vai especificando o sequenciador, deve ir identificando os cartões que representam os MVPs, que não necessariamente serão do final de uma onda, e vão adicionando post-its com o texto “MVP1”, “MVP2”, “MVP3”, e assim por diante. Nomeamos com “1”, “2” e chamamos de MVP por questão de organização, embora os seguintes do primeiro sejam incrementos do produto e não necessariamente um MVP.
10. CALCULANDO ESFORÇO, TEMPO E CUSTO
Aqui vamos encontrar a resposta para questões como:
O que e quando estará pronto?
Quanto vai custar?
O que construir nós já definimos no sequenciador de funcionalidades, o que já é um artefato incrível.
DETALHANDO O ESFORÇO
Agora vamos detalhar as funcionalidades de ondas em tarefas, por amostragem, selecionando um número limitado de ondas (ex.: 2 ou 3 ondas).
Na sequencia vamos pegando todas as funcionalidades das ondas, uma a uma para detalhamento. Em cada uma vamos anexando post-its com as tarefas menores de cada cartão de funcionalidade. Como as tarefas podem ser muitas, é uma boa prática colocarmos um identificador na funcionalidade e também nas tarefas, algo como “F1”, “F2”.
Como na Brainny trabalhamos com Scrum, estas partes menores são o que chamamos no framework de ‘Histórias de Usuários’ e as funcionalidades nós rotulamos como épicos.
DIMENSIONAMENTO DE TAREFAS
Anteriormente definimos as tarefas relacionadas a cada funcionalidade, agora precisamos dar ‘peso’ ou definir ‘esforço’ necessário para executá-las. Para isso existe diversas técnicas, uma delas é realizar o Planning Poker, baseado na sequencia de fibonacci, que é uma estratégia bastante popular que tem como principal característica eliminar a influência por parte dos colegas de equipe e que nos ajuda, após algumas iterações, a chegar na velocidade do time, que vai ditar quantas tarefas podemos pegar por vez. Outra estratégia é, em vez de usar a sequencia de Fibonacci, usar ‘tamanhos de camisas’, e estimar em ‘P’, ‘M’ e ‘G’.
A especificação é sempre de forma comparativa, a partir de uma primeira que servirá de modelo. Ex.: pegamos uma tarefa “Lorem Ipsum” e dizemos que ela é ‘M’, as conclusões dos tamanhos das demais tarefas serão sempre a partir de um olhar comparativo com tarefas já estimadas.
Considerando este segundo método, poderíamos, em uma mesa, organizar as tarefas como exemplificado na Figura abaixo, agrupadas por funcionalidades, e priorizadas da esquerda para a direita.
TEMPO E CUSTO
Agora passamos para um passo essencial, tempo e custo, e a sugestão de Caroli aqui é: Selecionar uma tarefa ‘P’, perguntar para a equipe o tempo que uma pessoa leva para resolvê-la. Fazer o mesmo para outras duas ou três tarefas de mesmo tamanho e ao fim calcular a média de tempo das tarefas deste tamanho e anotá-la. Por fim, repetir os passos para todos os outros tamanhos de tarefas.
Ao finalizar a atividade teremos o tempo médio para executar tarefas P, M e G. que poderiam ser, por exemplo, P = 1 dia, M = 2 dias e G = 4 dias. Com isso fica simples calcular o custo. Ficou fácil também de calcularmos o tempo necessário para o desenvolvimento de cada funcionalidade e de uma onda completa.
Podemos montar uma tabela com o tempo das funcionalidades para identificarmos o tempo de cada onda e até mesmo para reorganizá-la, caso necessário. Poderíamos considerar que o tempo ideal de cada onde é de 15 dias, e sendo assim, considerando a tabela de tempos abaixo, selecionaríamos F1 e F2 para a primeira onda e F3, F4 e F5 para a segunda onda.
11. CANVAS MVP
Utilizando tudo que geramos na Lean Inception e utilizando práticas de design thinking, estamos munidos a preencher o nosso canvas MVP. Responda as perguntas para os seus primeiros MVPs e mãos à obra.
Perguntas a responder por item do canvas:
- Qual é a proposta principal deste MVP? O que ele quer validar?
- Quais as personas que estão sendo atendidas neste MVP?
- Quais jornadas estão sendo atendidas nesta entrega?
- Quais são as funcionalidades que serão desenvolvidas nesta entrega? Reflita se elas realmente são o mínimo e se elas viabilizam o produto e se não podem ser simplificadas. Não deixamos nada fundamental para o MVP para trás?
- Qual é o resultado esperado neste MVP? Ex.: Nº de usuários? Nº de agendamentos? Arrecadação?
- Como podemos medir os resultados do nosso MVP? Ex.: Número de usuários cadastrados; Quantidade de agendamentos; Arrecadação com contas premium.
- Qual o custo e o previsão de entrega deste MVP? Os custos podem não ser relacionados apenas a desenvolvimento.
Com esses 11 passos principais da Lean Inception estamos prontos para criarmos o nosso produto rapidamente, com as principais funcionalidades para validarmos nossas hipóteses e com o menor custo possível. Na Brainny estamos utilizando e tendo excelentes resultados com o workshop.
