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!

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.

Matriz de Entendimento
Matriz de Entendimento

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.

Feature Nivelada
Feature Nivelada

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.

Feature Canvas nivelado
Feature Canvas nivelado

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.

Sequenciador de Features
Sequenciador de Features

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:

  1. Cada linha pode conter no máximo 3 features;
  2. Cada linha não pode conter mais do que 1 feature vermelha;
  3. Cada linha deve conter uma feature verde;
  4. A soma do esforço das features de uma linha não pode ser superior a 5 Es;
  5. 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.

MVP Canvas
MVP Canvas

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.

Lean Inception: concepção de produtos enxutos

A Lean Inception é uma técnica de concepção de produtos enxutos criada por Paulo Caroli, consultor da ThoughtWorks. É um método bem popular entre os agilistas brasileiros e é fortemente documentada nos livros Direto ao Ponto e Lean Inception (mais moderno, mas apenas em Inglês), do mesmo autor.

Caroli conta em suas palestras e livros que até então as inceptions (reuniões para concepção de um novo produto) duravam mais de um mês na TW e como Caroli atuava como consultor, não raro ele tinha de passar várias semanas por mês fora de casa, fazendo inceptions em clientes. No entanto, quando seu filho nasceu, ele decidiu que não mais ficaria tanto tempo longe da sua família e construiu uma técnica que, em apenas uma semana, é possível definir tudo que é necessário para se conseguir de fato tangibilizar um produto para que tenhamos insumos suficientes para o time de desenvolver começar a trabalhar.

Lean Inception, Sprint 0, Pré-Jogo…

A Lean Inception ocorre logo no início do projeto, no período que antecede a primeira sprint do time de desenvolvimento, período popularmente chamado de Sprint 0 ou Pré-Jogo. Embora o Scrum não aceite a existência de uma Sprint 0, é comum que isto aconteça de fato logo no início de grandes projetos onde a incerteza é tão grande que não vale a pena iniciar o desenvolvimento às cegas.

A ideia central da Lean Inception é fornecer momentos únicos de interação entre os membros do time e os stakeholders para definição dos conceitos elementares do produto, suas funcionalidades, jornadas do usuário, escopo das entregas, roadmap, etc. Tudo em uma semana muito intensa onde a cada dia novas atividades são realizadas e documentadas.

A ideia deste artigo é dar uma resumida no processo completo, cabendo aos interessados em aplicar esta dinâmica na prática buscar os livros do Caroli ou os treinamentos dele e dos treinadores certificados, como a Mayra Souza. O resumo do treinamento que fiz com esta última pode ser visualizado no vídeo abaixo.

Dia 0: Antes de Começar

O trabalho da Lean Inception começa antes do primeiro dia de dinâmicas. Você terá de montar um grupo heterogêneo de profissionais que possam colaborar com a definição do MVP do produto (objetivo final da inception) ou que estejam diretamente interessadas na construção do mesmo (usuários-chave ou stakeholders, por exemplo). Converse individualmente com cada uma destas pessoas e faça o convite pessoalmente, explicando a importância do comparecimento em todos os dias, como que funciona o processo, etc.

Monte uma lista de emails contendo o contato de todos os membros do grupo e dias antes da inception já comece a lembrá-los de que ela vai começar em breve. Certifique-se que seu grupo tenha até 30 pessoas e que tenha facilitadores suficientes para dar conta desta galera toda, em média 1 facilitador para cada 10 pessoas. Os facilitadores não executam as atividades, apenas conduzem, sem influenciar. Também garanta que todos os perfis abaixo estejam presentes neste grupo:

  • Product Owner do produto;
  • Scrum Master do time (geralmente um dos facilitadores);
  • profissionais técnicos do time (programador, analista, etc);
  • profissionais criativos de UX, UI, marketing, etc;
  • profissionais das áreas de negócio da empresa;
  • profissionais das áreas de atendimento da empresa;
  • usuários-chave do sistema;

Dia 1: Segunda-feira

Como a inception dura a semana inteira, o ideal é que ela comece em uma segunda-feira, para que não aconteça quebra de raciocínio. Mande um email reforçando o início da inception para todos os convidados e tenha um ambiente minimamente dedicado para que a dinâmica aconteça todos os dias no mesmo local e com os mesmos materiais, para que nada se perca entre cada um dos dias.

No primeiro dia as regras da inception são explicadas e em alto nível o que é a ideia do produto (geralmente o Product Owner dará este briefing). Geralmente pede-se que todos os membros do grupo se apresentem, expressem suas expectativas e faz-se uma dinâmica de energização para quebrar o gelo e animar o pessoal. Paulo Pontual, Zip-Zap-Zum, entre outras são sugeridas.

São formados grupos de trabalho, geralmente de 2 a 5 e na parte da manhã a primeira atividade é escrever a Visão do Produto. Cada time escreve a sua visão usando o template abaixo:

Para [cliente final],

cujo [problema que precisa ser resolvido],

o [nome do produto]

é um [categoria do produto]

que [benefícios-chave, razões para comprá-lo].

Diferente do [alternativa de mercado],

nosso produto [diferença-chave].

Depois, cada grupo apresenta a sua versão da visão do produto e ao término das apresentações, consolida-se em apenas uma só, gerando debates para que esta consolidação gere o melhor resultado. Documente a Visão do Produto com fotografias, isso será útil mais tarde, e preferencialmente transcreva-a para um cartaz que deverá estar fixo na sala da dinâmica a semana inteira.

Product Vision
Product Vision

Na parte da tarde (que tal uma energização após o almoço?) faz-se a dinâmica de definição do produto, também chamada de É-Não É, Faz Não-Faz. Aqui a ideia é que cada grupo trabalhe em um cartaz dividido em 4 quadrantes: É, Não É, Faz, Não Faz.

É-Não É-Faz-Não Faz
É-Não É-Faz-Não Faz

Em cada quadrante os membros do grupo discutem o que o produto é, o que ele não é, o que ele vai fazer e o que ele não vai fazer. Depois que cada grupo cria as suas definições individualmente, novamente cada grupo apresenta e o resultado final é consolidado em apenas uma versão após várias rodadas de discussão envolvendo cada quadrante.

As evidências destas duas dinâmicas são enviadas a todo o grupo no final do dia, bem como quaisquer outras fotos tiradas e uma descrição rápida de como o dia passou. Caso não seja possível deixar os cartazes consolidados nas paredes da sala, o facilitador deve guardar os mesmos para que seja possível manter o histórico da dinâmica completa.

Dia 2: Terça-feira

Começa-se o segundo dia reforçando o compromissos com todos via email, antes mesmo da dinâmica começar. Quando a dinâmica começa de fato, após a energização/quebra-gelo (sim, sempre faz-se uma no início do dia) inicia-se uma recapitulação do dia anterior, mostrando o produto final das dinâmicas de Visão do Produto e da É-Não é-Faz-Não Faz, para que todos estejam na mesma página novamente.

Uma vez que temos em alto nível os conceitos mais fundamentais do produto, é hora de falarmos de quem vai usá-lo/comprá-lo: as personas. As personas são arquétipos de usuários-chave típicos do produto. Cada produto possui no mínimo uma persona, enquanto que alguns podem possuir várias.

Cada grupo de trabalho pega uma persona para trabalhar, preenchendo um cartaz com os quatro quadrantes sobre a persona que escolheram:

  • nome e retrato: qual o nome ou apelido deste usuário-chave do produto? como ele se parece, se veste, etc?
  • perfil: idade, nacionalidade, etnia, renda, formação, profissão, etc
  • comportamentos: hobbies, crenças limitantes, crenças fortalecedoras, etc
  • necessidades: o que ele está buscando? Quais as suas dificuldades? As suas “coceiras”? As suas aspirações?
personas
personas

Uma vez que um produto pode ter várias personas, pode ser que cada grupo fique com uma diferente, não havendo necessidade de consolidação. Caso alguma persona se repita, deve-se consolidar os resultados obtidos para a mesma persona. De qualquer forma, cada grupo apresenta aos demais os resultados obtidos.

No mesmo dia, na parte da tarde, é hora de fazer a Descoberta das Features. Uma feature ou funcionalidade é a descrição de uma interação do usuário com o produto ou alguma ação que o sistema é capaz de realizar. As descrições das features devem ser simples e sem entrar em detalhes técnicos.

Para fazer esta descoberta de features existem diversas dinâmicas possíveis, desde simples brainstormings até entrevistas com usuários-chave. A técnica sugerida pela Lean Inception é fazer uma matriz onde cada coluna é algo que o sistema faz (lembra do Faz-Não Faz?) e cada linha é uma persona. O cruzamento das personas com o que o produto faz deve induzir às features necessárias.

Personas x Features
Personas x Features

Note que esta matriz é para ajudar o raciocínio para a descoberta de features, não para limitar a criatividade das pessoas nem para obrigar a fazer todas as combinações de coisas que o produto faz com as personas existentes. No entanto, é sempre interessante descartar features neste momento que de fato não auxiliem na resolução de nenhuma necessidade das personas, direta ou indiretamente.

Ao final do dia, tiram-se fotos dos cartazes das personas e do resultado da descoberta de features. É interessante também adicionar uma numeração nas features para facilitar a organização posterior. Envia-se um email a todos envolvidos com as evidências da dinâmica.

Este artigo ia ficar muito grande, resolvi quebrar em duas partes, sendo que a segunda parte está neste link. 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.

4 segredos do operador Spread em Javascript

Você conhece o operador Spread do JavaScript? Ele é representado por três pontos, sim, o Spread operator é o famoso ‘…’ (três pontinhos para os mais íntimos). Ele basicamente permite que expressões expandam o conteúdo de arrays em locais onde múltiplos elementos são esperados.

Conseguiu entender?

Vou mostrar de um jeito mais prático. Imagine o seguinte código abaixo:

Note que neste caso eu não usei o Spread. Ao colocar o array dentro de outro array (formando um jagged array ou nested array, erroneamente chamado de matriz em algumas universidades) temos um resultado um tanto inusitado ao imprimir ‘arr’.

Agora experimente colocar ‘…’ antes do array middle para você ver o que acontece, como abaixo:

Spread significa espalhar, ou seja, este operador é usado para ‘espalhar’ os elementos de um array quando interpretado em tempo de execução. Neste último caso, os itens de middle foram espalhados dentro de arr.

Este é o uso default do Spread operator, mas ele é mais poderoso que isso, e é desses segredos que quero falar no artigo de hoje.

Segredo #1 – Cópia de arrays com Spread

Você sabe como copiar um array em JavaScript? Programadores mais novatos podem achar que isso aqui funciona:

Mas infelizmente a vida não é tão simples. Neste caso arr2 não é uma cópia de arr, mas sim o próprio arr, uma vez que a referência de memória de ambos é a mesma. Duvida, então teste isso:

Notou que ao adicionar um item no arr2, ele também aparecer no arr? Isso porque eles são os mesmos! Uma das maneiras corretas de fazer isso é usando funções específicas.

Se você programa JavaScript há algum tempo deve conhecer a função slice, certo? É aquela que te permite copiar arrays. Mas você sabia que também conseguimos copiar arrays usando o Spread?

Ao expandirmos o array com o Spread, o valor de seus itens são copiados pra dentro do outro array. Ambos arrays são independentes, então é claramente uma forma de copiar arrays que funciona.

Segredo #2 – Concatenação de arrays com Spread

E se eu quero juntar dois arrays? Já sacamos que usar o operador de atribuição (=) não resolve. O operador de soma obviamente também não. Você sabe qual a função específica que faz isso no JavaScript? A concat:

Mas você sabia que tem um jeito muito mais fácil de fazer isso usando o Spread operator?

Bacana, não?!

Segredo #3 – Operações matemáticas com Spread

Você sabia que é possível usar as funções matemáticas do JavaScript em conjunto com o Spread?

Vamos começar falando do Math.max(), função que retorna o maior de um grupo de números, que passamos a ela por parâmetro.

Não tem como passarmos um array por parâmetro nesta function, mas com uma função auxiliar sim, embora fique bem estranho:

Mas e o Spread?

Show, hein!

Segredo #4 – String para Array

E se você precisar transformar uma string em um array de caracteres? Tipo nos tempos do C-ANSI, lembra?

Essa é bem fácil, como abaixo:

E é isso por hoje, o artigo foi curto, mas a intenção foi grande! Até a próxima! 😉

Quer se aprofundar mais em JavaScript e Node.js? Dá uma olhada no meu curso abaixo.

Curso Node.js e MongoDB
Curso Node.js e MongoDB