Dentro das metodologias existentes no mercado uma que chama muito a atenção é o Lean Inception, inspirado no Lean StartUp de Eric Ries e no Design thinking possui ferramentas novas para facilitar a criação de um MVP (Minimum Viable Product). A ideia é reunir um grupo de stakeholders para participar de um workshop colaborativo com uma sequência de atividades para alinhar e definir objetivos, estratégias e escopo do produto.
A nomenclatura Inception vem do RUP (Rational Unified Process), um processo de engenharia de software criado pela Rational nos anos 90 para o desenvolvimento orientado a objetos, baseado no UML (Unified Modeling Language). Inception é a primeira de quatro fases do RUP: Inception, Elaboration, Construction e Transition. Na fase de Inception era realizado a análise sobre os objetivos, a arquitetura e o planejamento do projeto. Isso acontecia via entrevistas com os stakeholders, convertidos em requisitos descritos no formato decasos de uso.
Em 2011 Paulo Caroli de vida ao livro Lean Inception: Como Alinhar Pessoas e Construir o Produto Certo. O intuito é realizar um workshop que dure uma semana, e que no final a equipe tenha um MVP para disponível. E é sobre este livro e as ferramentas disponíveis que iremos entender na fonte.
Kick Off
Nada melhor do que começar a semana com o bom e velho Kick-Off. Como o grupo normalmente adquiri pessoas novas de diferentes áreas, o ideal é que haja café da manhã reforçado para recepcioná-los isto ajuda as pessoas a se ambientaram e torna o espaço agradável e descontraído. O objetivo do Kick-off é integrar os participantes que não se conhecem e deixar o ambiente preparado para o debate de ideias. Importante ressaltar que normalmente grupos que trabalham com a presença do “chefe” não tem um alto ganho de criatividade, pois a maioria dos profissionais ficam receosos/vergonha em dar ideias (que possam achar simplórias) na presença do julgamento do “chefe”. Durante a reunião invista em ferramentas de “quebra-gelos”, pesquise um pouco na internet e veja as melhores maneiras de integrar os participantes do grupo em uma equipe. Com os participantes mais relaxados, faça um overview do Lean Inception, de como a semana irá funcionar e qual é resultado que pretende ser alcançado ao final da semana. Caso o que você queira alcançar durante a semana seja a resolução de um problema, está é hora para falar sobre e pedir ideias para iniciar o projeto. Normalmente as Leans acontecem com a visão pronta do produto, sendo assim no final do kick-off temos uma breve apresentação.
Visão do produto
Se em sua Lean os participantes deram a ideias das melhores soluções para a resolução do problema está é hora de escolher qual irá seguir em frente, porem se já temos uma visão pronta, agora iremos expor para o grupo. De acordo com o tamanho da sua equipe, dívida os em grupos onde cada participante possa auxiliar o outro, evite “panelinhas”. Disponibilize folhas de papel A3 para que os grupos possam definir a visão do produto.
O Produto É – Não é – Faz – Não faz
Esta é umas das fazes mais importantes do produto, aqui iremos dirimir o que o produto pretende fazer, quais são as expectativas para o primeiro MVP. Como o nome do processo já diz precisamos dizer o que o produto irá fazer neste primeiro momento e o que não estará no escopo. Normalmente neste processo começam as dúvidas e perguntas como: este produto será gratuito ou pago, será app ou web, atendera a todo o público ou específico para um nicho de pessoas. Esta faze é muito importante para termos um norte do que iremos fazer durante toda a semana. Aqui definiremos o escopo do produto, neste momento foi solicitado a todos os participantes que compartilhassem o entendimento que tinham para os três principais objetivos do produto. Cada participantes escreveu post-its. Ao recolher os post-its e colocá-los em grupos de afinidade, foi identificado principais objetivos para o produto.
Descrever as personas
Agora precisamos descrevermos as personas que irão utilizar este produto, isto é, os usuários que acessaram o sistema. Utilizaremos quadrantes para verificar quais personas são importantes para a utilização do produto. Cada persona vai ganhando vida no decorrer do processo pois precisamos destes para realizarmos os testes mais a frente. Não é de se espantar se as personas ficarem caricatas, exemplo o suporte pode ser “Rodrigo Soneca”, o cliente “Chefe Zangado” o Lean até incentiva este tipo de comportamento que tem o intuito de melhorar a harmonia do grupo. Se foi necessário dividir o seu grupo, não esqueça de tirar um tempo para validar se não existem personas duplicadas.
Exemplo de Persona:
Apelido : Joazinho
Perfil : 28 anos /casado / bancário
Comportamento : Tecnológico / assíduo/ passa horas nas redes sociais
Necessidades : Jogo online/ utilizar o telefone / jogar à noite nos fins de semana
Brainstorming de funcionalidades
Após evoluirmos com os outros tópicos precisamos definir as funcionalidades que irá existir no produto. Para isto iremos utilizar a ferramenta cavas, onde os objetivos estão como títulos de colunas; enquanto as personas estão no canvas como títulos de linhas. Isso forma o canvas para o brainstorming de funcionalidades. Assim, o facilitador promover uma discussão sobre as funcionalidades. O objetivo é atender as necessidades das personas criadas, o que precisa ter no produto para atender tal persona? e para alcançar tal objetivo? Estas perguntas irão auxiliar para desenvolver as funcionalidades.
Revisão Técnica e de Negócios
Durante o brainstorming definimos as funcionalidades principais e essenciais para o desenvolvimento do MPV. Agora o time técnico inicia o processo de quantificar o esforço de cada funcionalidade. Sendo assim, voltamos para o cavas e cada funcionalidade no quadro recebe o esforço da equipe de desenvolvimento, como nesta faze do projeto é impossível obter o esforço em horas, a equipe pode indicar o grau de dificuldade por cores, índice (baixo, médio, alto) ou utilizando a técnica de planning poker bastante utilizada no scrum. Da mesma forma a equipe de negócios, valida a importância da funcionalidade em conjunto com o custo. Ao final deste processo precisamos ter as funcionalidades valoradas com o nível de confiança determinado. O livro indica utilizar as seguintes estimativas:
Verde para um nível de confiança alto, amarelo médio e vermelho baixo. Enquanto marcações de valor de negócio variam numa escala de uma, duas ou três vezes comparativamente; ou seja $, $$, $$$ para valor de negócio respectivamente alto, muito alto e altíssimo, e E, EE, e EEE para esforço respectivamente baixo, médio e alto.
Mostrar as jornadas do usuário
Neste momento retornamos à perspectiva das personas. Agora com o foco nas suas jornadas, precisamos criar um passo a passo para alcançar um objetivo. Se seu grupo for grande, novamente dívida os participantes em grupos. Cada grupo será responsável por uma persona, e identifica os principais cenários para que as personas façam as ações para alcançar seus objetivos. Para uma fácil visualização, adicione este fluxo através de post-its em um quadro ou flipchart, desta maneira iremos montar os cenários. Algumas perguntas ajudam para iniciar as jornadas.
Qual objetivo tal persona quer alcançar?
Como ela começa seu dia?
O que ela faz depois disso até alcançar seu objetivo?
Segue dois exemplos de jornadas
Exibir Recursos em Jornadas
Neste momento já precisamos ter duas informações, as funcionalidades mapeadas que o produto deve ter e as jornadas criadas das personas, esta integração mapeada irá ajudar a entender como o usuário irá interagir com o produto. Uniremos essas duas perspectivas e verificaremos ambas as visualizações, integrando-as. Disponibilizamos as jornadas e os recursos visíveis lado a lado, através de um flipchart, para cada jornada e, para cada etapa, registre todos os recursos necessários.
Ao final geralmente encontramos dois tipos de links ausentes:
Algumas jornadas estão faltando recursos, sendo assim, criamos post-its de recursos, valorando com esforço, valor e incerteza.
Alguns recursos não estão mapeados para as jornadas, sendo assim, devemos desafiá-los, será que realmente precisamos deles se não desempenharem nenhum papel nas jornadas de nossos usuários?
Sequencie as funcionalidades
Agora, chegamos ao momento de decidir o MVP. Nessa hora que toda a análise feita até o momento (produto, personas, funcionalidades e jornadas) é colocada a prova perante a ferramenta de canvas, esta é essencial para organização e visualização das funcionalidades e sua relação com o MVP. Quando começamos a sequenciar as funcionalidades, precisamos deixar os participantes a vontade para organizar as funcionalidades de maneira que estes se questionem a respeito se realmente precisamos destas funcionalidades no MVP ou podem ser retiradas ou postergadas para uma versão futura.
Enquanto os participantes escolhem e ordenam as funcionalidades no sequenciador escreva em um quadro, folha ou flipchart a palavra MVP. E peça para verificarem quantas funcionalidades são necessárias para alcançar uma versão simples do produto, que poderia ser disponibilizada para validar uma hipótese do negócio. Com isso, os participantes irão colocar post-its ao lado do flipchart identificando as funcionalidades de um MVP. Eles também colaram outros post-its MVP2, MVP3 e MVP4 indicando incrementos do produto.
Construa o MVP Canvas
Após sequenciar todas as funcionalidades e decidir o que será desenvolvido no MVP, utilizamos a ferramenta de canvas MVP. Esta, irá auxiliar na visualização do produto. Cada etapa anterior nos ajudará a preencher um quadrante do canvas, a mediada que formos colocando os post-its iremos preencher todo o plano para construção do MVP.
Reunião com os stakeholders
Depois de todo o trabalho feito, está na hora de apresentar a ideia aos interessados no projeto. Dependendo da prioridade do projeto podemos realizar uma simples apresentação do que foi feito durante a semana, ou criamos um MVP funcional para que os participantes possam testar e analisar o produto. O importante desta reunião não é ter um produto pronto sem erros e sim disponibilizar aos participantes a maneira encontrada de produzir um novo produto ou solucionar algum problema. Os envolvidos precisam aprovar todo o trabalho feito para que possamos iniciar o projeto.
Finalizando
Este foi apenas um exemplo de agenda de como fazer o Lean Inception, porém, não o trate como uma coisa fixa, mas deixe-o servir como um bom exemplo de como as coisas podem fluir de e acordo com sua equipe e tempo. Fizemos uma introdução bastante empolgante, iniciamos e terminamos com uma equipe engajada e participativa. Em um mundo ideal, nem todos estariam presentes no o início. No entanto, geralmente temos pessoas que estão muito interessadas na direção e no resultado, mas não conseguem gastar o tempo todo no esforço. O mínimo necessário é que essas partes interessadas participem das sessões de introdução, início e exibição.
Comentarios