Labs 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:
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.
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).
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.
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 Labs 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 Labs 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 Labs 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
