Lean Inception: Como desenvolver produtos em um processo de co-criação? Parte 2

No artigo anterior, apresentei como o Luiza Labs faz para se aprofundar e agir nos problemas que encontramos, fazendo uso de diversas ferramentas que buscam entender o que está acontecendo com os nossos clientes/usuários.

Neste artigo, falarei somente de como co-criamos as soluções dos problemas apontados por meio de ferramentas do Design Thinking, Brainstorming, Product Management, Coaching, entre outras.

Dia 2 — Co-criando soluções

No segundo dia, nossa agenda foi dividida da seguinte maneira:

  • Visão de produto;
  • É, não é / Faz, não faz;
  • Fluxo To Be;
  • Solução x Problemas;
  • Primeiros épicos de desenvolvimento;
  • Confidence Vote;
  • Fechamento;

Warm-up

Antes de começarmos a mostrar onde queremos chegar, fazemos um pequeno Warm-up com principais outputs que tivemos no dia anterior. De 5 a 10 minutos passamos a palavra para os participantes de forma a identificar o quão conectados eles estão com a nossa dinâmica.

Visão de Produto

O Product Owner faz uma breve apresentação dos objetivos que queremos alcançar com o produto que estamos começando a idealizar. Mostramos isso com informações abstratas, mas que de alguma maneira se conectam ao propósito da sessão. Por exemplo: "uma aplicação simples e mobile, "integração entre processo A e B", "eliminar papéis e enxugar processo", "trazer fluidez", "eliminar papéis", etc.

Desta maneira, o Product Owner consegue deixar claro qual sua expectativa com a dinâmica que estamos executando. Feito isso, partimos para um brainstorming, a fim de criar nosso elevator pitch.

Para cada palavra-chave, damos uma breve explicação, apresentando alguns exemplos de como as palavras-chave podem ser preenchidas.

Post-it's e canetas na mão, pedimos para que seja escrito 1 item por post-it, 5 minutos para cada palavra-chave e…valendo!!!

Uma boa forma de diminuir o tempo de coordenação e fazer com que o pessoal dê uma acordada, é pedir para que cada um vá colando os post-it's que escreveu na palavra-chave que foi trabalhada.

No final de cada rodada o Product Owner, com auxílio do Agile Coach, começa a criar clusters de post-it's que possuem o mesmo contexto e/ou estão repetidos e, no final do processo do elevator pitch, co-criamos uma visão unificada do produto, que será representada por uma frase ou parágrafo.

Por exemplo:

"Para usuários que hoje são impactados pelo excesso de burocracia, muitos papéis e falta de sistemas que otimizam processos, o produto xpto, que é uma plataforma de fulfillment, fará integração dos processos A & B, tornando-os simples, ágeis, acurados e seguros, eliminando vários fluxos que são ineficientes. Desta maneira, garantimos a experiência digital para nosso grupo de usuários, a melhorar a experiência do nosso cliente final."

Até chegarmos nesse parágrafo, repassamos as frases diversas vezes e pedimos para que todos os participantes façam sua contribuição. O propósito dessa dinâmica é garantir que todos acreditem naquilo que estão produzindo. Todas as opiniões são ouvidas, discutidas e caso todos concordem, agregadas.

É, não é / Faz, não faz

Essa dinâmica, puxamos do livro Direto ao Ponto, do Caroli.
Basicamente é uma atividade que vai nos ajudar a identificar qual as limitações do nosso produto, assim como quais aspectos iremos considerar na hora do desenvolvimento.

Trata-se de uma matriz de 4 quadrantes e fazemos o brainstorming, exatamente igual ao que apresentamos na visão de produto, sendo:

É: Tudo aquilo que o produto que iremos desenvolver é: aplicativo, digital, ferramenta, online, gestão de mudanças, inovador, seguro, acessível, etc.

Não é: Tudo aquilo que o produto não é: offline, gerador de demanda, gerenciador de produto, a solução de todos os problemas, etc.

Ao finalizar esses 2 quadrantes já temos idéia do escopo da nossa aplicação

Faz: Tudo aquilo que o produto faz: reduz papel, lê códigos de barra, cria cadastros, gera notas fiscais, etc.

Nesse momento já começamos a identificar as primeiras funcionalidades da aplicação e é importante que fique claro para o Product Owner, o que os participantes estão querendo dizer. Para isso, muitas vezes ele irá perguntar a turma qual o real significado de um determinado post-it.

Não faz: Tudo aquilo que o produto não faz: prioriza atividades, devolução de tickets, trocas ou cancelamentos, gera relatórios, cria etiquetas, etc.

Quando identificamos tudo aquilo que o produto não faz, já deixamos claro para todos os participantes que aquele conglomerado de post-it's não farão parte do escopo do projeto.

Fluxo To Be

Como já temos uma visão bem estruturada dos problemas, das personas e, finalizamos a visão e as restrições do produto, chega a hora de identificarmos se precisamos rever o processo que temos hoje.

Através do Storytelling, repassamos a cadeia de valor do inicio ao fim fazendo um paralelo com os problemas que foram encontrados. Notem que os problemas (post-it's pink), estão distribuídos acima de cada uma das etapas do processo:

Storytelling da Cadeia de Valor

Conforme passamos as etapas, ideias vão surgindo e cabe ao Product Owner junto ao Agile Coach entender se as propostas são aderentes ao que o novo produto se propõe a fazer e, em caso positivo, incorporar essas alterações na futura backlog do produto.

É aqui que faz-se a necessidade de pessoas com grande poder de decisão, caso contrário, teríamos que parar a Inception para podermos decidir se a sugestão de mudança caberia para esse escopo de trabalho, quebrando completamente o ritmo da cerimônia.

Soluções vs Problemas

Com o novo processo definido, passamos novamente problema a problema afim de identificar aqueles que já foram eliminados com a atualização do fluxo.

Para os problemas que ficaram, iniciamos a cocriação de soluções. Nesta etapa o Product Owner, item por item, abre a discussão de solução para todos os integrantes do evento.

Mediação

A regra é simples e vem do trabalho de coaching (motivador — objetivo — ações):

"Dado um problema, quais são as ações necessárias para eliminá-lo?"

Note que respeitamos uma sequência de cores para que fique claro onde as soluções estão impactando a cadeia de valor. Usamos também adesivos com cores diferentes para ficar claro o que é Desenvolvimento (features), Processos (novos) e Atividades (operacional).

Problemas em pink — soluções ao azul, amarelo e rosa

No final esse é o resultado. Veja que ainda existem problemas que estão sem solução localizados na parte esquerda da parede. Estes itens foram mapeados porém o produto que estamos desenvolvendo não tem relação com aquela parte do processo.

Primeiros épicos de desenvolvimento

Estamos chegando na reta final da Inception e a ideia aqui é elencar os primeiros épicos que irão compor nosso MVP (Minimum Value Product).

De uma maneira bem simples, explicamos para todos os participantes que cada um possuí 5 votos. Esses votos poderão ser distribuídos todos em um ou em vários post-its.

Como todos os integrantes participaram desde o começo, acredita-se que eles já estão com um nível de consciência bem alinhado à proposta que foi criada. Esse tipo de atividade faz com que quebrem-se os silos departamentais forçando que todas as soluções criadas, sejam de impacto sistêmico.

Votação Aberta
Priorização de épicos + Definição do MVP

Com as votações encerradas, ordenamos em uma lista aqueles que foram mais votados para os menos votados. O Resultado você vê ao lado.

Note que temos uma linha que divide o processo de priorização, chamada de MVP.

Como os Tech Leads participam da cerimônia, eles conseguem dar uma visão bem alto nível dos itens que poderiam compor o MVP.

Feito isso, alinhamos as expectativas com todos os participantes, explicando como as entregas serão feitas.

Confidence Vote

Para fechar nossa sessão de cocriação, fazemos uma votação da sala para identificar o quão confiantes as pessoas estão com o sucesso do produto que acabara de ser criado.

A ideia é que cada um possa votar de 1 até 5, com uma das mãos. Só podemos encerrar o dia no momento que todos os votos forem maior que o número 3. Isso porque, por vezes, algumas pessoas podem ter o sentimento que de alguma forma sua ideia pode não ter sido ouvida ou não está confortável com alguma decisão que foi tomada.

Para estes casos, pedimos que o integrante explique sua insatisfação ou preocupação e, caso necessário, abrimos um risco em um post-it deixando claro qual a reclamação e o que faremos com ela.

Para ordenar essa situações, utilizamos da matriz ROAM de riscos (resolved, owned, accepted, mitigated), onde:

  • Resolved (Resolvido): O risco foi eliminado, ou seja, não prejudicará o projeto;
  • Owned (Responsabilizado): Alguém ficará responsável por resolvê-lo;
  • Accepted (Aceito): O risco foi reconhecido e todos estão cientes da possibilidade de sua ocorrência;
  • Mitigated (Mitigado): Foram tomadas providências para reduzir o impacto do risco.

Com todos os riscos mapeados voltamos a fazer o Confidence Vote e, caso não exista nenhum ponto a ser discutido, finalizamos nosso Lean Inception.

Fechamento — Dia 2

Por fim, fazemos uma breve retrospectiva de tudo que havíamos falado nos últimos 2 dias. Fazemos um breve check-out, pedindo para que algumas pessoas compartilhem o que foi participar da Lean Inception, quais foram os aprendizados que tiveram e com qual expectativa eles saem da dinâmica.


Muito além da contribuição para o desenvolvimento de um novo produto, a Lean Inception é uma ferramenta poderosa para fazer com que as pessoas ultrapassem os silos empresarias que por vezes, impactam negativamente no desenvolvimento de um produto/projeto.

Ao aproximar todas as pessoas envolvidas na cadeia de valor, compartilhando suas dores e reclamações e, colocando-os juntos para resolver os problemas que impactam o seu dia-a-dia, o resultado, independente do produto, é o desenvolvimento de uma grande habilidade chamada: pensamento sistêmico.

Fontes

  • Direto ao Ponto — Paulo Caroli;
  • SAFe 4.0 (Scaled Agile Framework);
  • Crossing The Chasm — Geoffrey Moore;
  • The Lean Startup — Eric Ries;
  • Design Thinking — Tim Brown;
  • Boa formulação de objetivos — Programação Neurolinguística;

Agradecimento especial pelas revisões:Melissa Santi Itimura, Gabrielle Betoni e Mariane Ohashi

Like what you read? Give Rafael Cunha a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.