User Story Mapping: contando a história do seu produto

A documentação de um projeto não deve ser uma lista super detalhada de como o software deve se comportar. Ela precisa funcionar mais como as fotos daquela viagem que você fez ano passado. Elas não contam toda a história, mas são um suporte para uma conversa e uma forma de lembrar do que aconteceu. O User Story Mapping é uma ferramenta que nasceu exatamente com esse objetivo, dar suporte a uma conversa entre times e cliente para uma construção mais colaborativa.

Quando estamos criando um backlog temos que ter em mente que não é sobre escrever ou documentar histórias. O que precisamos é criar uma conversa entre os times e o cliente.

A falácia do backlog tradicional é que ele é uma lista priorizada do que deve ser entregue. Não é. Uma grande história bem contada tem múltiplos personagens e  linhas do tempo, e com seu produto não será diferente. 

Quando seu produto é criado de uma forma linear, muitos aspectos do negócio acabam sendo deixados de lado e a eficácia da solução acaba sendo bem menor.

O que a maioria dos gestores esquece é que não temos as respostas até termos nossos usuários de fato usando o sistema. Até isso acontecer, o que temos são apenas hipóteses. 

Para investir tempo e dinheiro em algo incerto, é preciso ter foco no resultado que desejamos, com o menor custo e no menor prazo.  O planejamento serve para criar o mínimo de aprendizado possível que valide o caminho.

Sempre ouço os gestores falando que não dão conta de implementar tudo que o pessoal de negócio quer. Não dão conta e nunca darão. Criar  ideias é muito fácil. Validar e testar se elas são boas, nem tanto.

O fluxo de ideias sempre é maior que o fluxo de implementação. O processo de seleção da coisa certa a se fazer é o que faz toda a diferença. Escolher pequeno para ter oportunidade de errar é o que faz o sucesso acontecer. 

“The only way to win is to learn faster than anyone else.”

–Eric Ries

Reduzir lead time não é apenas sobre fazer mais rápido, e sim sobre aprender mais rápido para gastar o mínimo com isso. Quando o erro é barato a inovação acontece. 

Ter muitas certezas é a morte certa na inovação.

Estamos andando em um terreno onde não se pode ver  o que está na nossa frente, só o que já passou. A chance de cair num buraco logo ali na frente é muito grande, assim, aprender é essencial para a robustez. 

Fazer o mínimo não significa fazer mal feito. Significa focar no mínimo possível, entender como validar e gerar um aprendizado. E fazer isso até se ter algo viável para lançamento. Não adianta falar que seu produto ruim é só um MVP.

Tente pensar como um artista cria um quadro. Imagine que você foi contratado para pintar um quadro de uma pessoa com uma paisagem no fundo. Um gestor de hoje em dia provavelmente faria algo assim:

• Pintar a metade superior direta do quadro.
• Pintar o rosto da pessoa.
• Pintar a parte de baixo da paisagem.
• Pintar a mão.

Certamente um artista não faria isso. É quase impossível conseguir imaginar uma pequena parte sem ter pelo menos um panorama.  

 

Criando o mapa

Histórias são a cola que nos une como humanidade desde a invenção da linguagem.  

Elas ajudam nosso cérebro a entender melhor dado ao seu fator multimídia. Histórias tem visão, tem som, tem cheiro, tem tato. Muitos cursos de memorização nos ensinam a criar histórias para conseguir lembrar melhor das coisas. 

Lembro de quando era criança e fiz um curso desses. Usei para minha prova de biologia. Lembro até hoje dessa lição pois, criei uma história totalmente absurda, mas na minha cabeça ela fazia sentido. Eu via os personagens, ouvia, simpatizava, e memorizava.

As histórias permitem que tenhamos um grupo de pessoas trabalhando como um só. As mitologias fazem isso com a humanidade desde sempre, e por que não usar esse recurso para comunicar também os nossos produtos? 

Story map são usados para contar histórias a séculos. Aristóteles já usava um modelo de mapeamento de histórias e autores como o time de criação do Breaking Bad costumavam usar algo muito parecido para fazer o roteiro ter sentido. 

Fonte

Deixar a história um pouco mais complexa, explorar mais personagens e caminhos ajudam a dar uma riqueza muito necessária para a inovação. Podemos contar a história do nosso usuário, nosso protagonista, e com isso comunicar o que queremos resolver com mais fácilidade.

Dada essa referência, Story Mapping lembra muito o modo como um filme é criado. Existe a narrativa principal, a coluna vertebral, e para o filme existir, muitas coisas precisam acontecer. Além de ser filmado, tem o set, figurino, maquiagem, iluminação, som, etc.

Aqui também, para cada uso do sistema, existe o design de experiência, UI, front, back, QA, etc. Por isso, focar na narrativa e no roteiro é tão poderoso. Ele consegue unir todas as partes necessárias para fazer um produto em uma narrativa simples. 

 

Histórias

A ideia de histórias veio de um insight do Kent Beck sobre como um usuário contou para ele, apaixonadamente, sobre um novo sistema onde se colocava o CEP (zipcode) e o sistema preenchia os formulários automaticamente. Isso nos anos 90 certamente era uma experiência sensacional. 

Histórias são isso: pessoas contando como eles usam ou usariam seu produto. Isso exige conversa. Uma história de usuário é o antídoto para o requisito! É um lembrete para que uma conversa aconteça.

Em 2008, o Jeff Patton viu que as histórias do Kent Beck precisavam ser melhor organizadas. Muita gente já estava fazendo isso, tirando a linearidade dos backlogs. Story maps são mais um padrão de criação de histórias que um método em si. O método do Jeff Patton virou uma grande sensação e é muito bom. Porém, o autor mesmo fala que devemos ir além, criar nossos próprios mapas e evoluir constantemente. 

O grande objetivo é contar a mesma história para todos os envolvidos, e isso inclui dar informações de qualidade para que todos consigam tomar melhores decisões.

Existe a história da empresa, sua visão, missão, seus OKRs. Como o usuário, ou cliente, se encaixa nessa história? O usuário é o herói dessa jornada, o que nos deixa na posição de guia, de conselheiro, de alguém com experiência e conhecimento capaz de ajudar o herói a cumprir seus objetivos.

Se seu produto for o herói, isso faz do seu cliente a pessoa indefesa que precisa ser salva, e esse não é o tipo de personagem que interessa geralmente. Isso nos dá a conexão, como juntar essas histórias e manter a coerência?

Pensando nesse problema, e depois de ler o ótimo livro “Outputs Over Outcomes”, do Josh Seiden, vimos que existe uma conexão direta com story maps, mas, que isso não fica muito explícito.

Nesse livro, Josh nos convida a pensar um caminho intermediário entre o impacto econômico que queremos atingir com o produto e a entrega do produto em si. Medir entrega de produto é um modelo que não dá conta da complexidade do digital. O ambiente externo é instável e não podemos arriscar seguir um plano que não se adapta continuamente.

Queremos objetivos de negócios, é claro. Porém, medir o impacto de negócios de uma feature de software pode ser algo sem muita utilidade. Como saber se uma feature, ou até um projeto, realmente impactou? Nisso eles trazem uma repaginada na noção de Outcomes. Um outcome seria nada mais que um resultado esperado, mas, Josh traz um significado em produtos digitais que é mais mensurável. Um outcome é uma mudança desejada no comportamento do usuário que vai predizer uma mudança no impacto de negócios. 

Se um impacto de negócios é aumentar as vendas, um outcome desejado pode ser o de aumentar o número de pedidos de orçamento pelo site. Mais pedidos de orçamento predizem um aumento de vendas em alguma proporção. Isso precisa ser testado. 

Mudanças de comportamento são muito mais fáceis de medir do que indicadores, como aumento na quantidade de vendas. 

 

Criando o mapa

Com os outcomes definidos, pensando na mudança de comportamento do usuário, já é possível contar uma história para fazer sentido de como isso vai acontecer. 

Como vamos fazer esse usuário fazer o pedido de orçamento?
Quais os outputs necessários para fazer o usuário chegar nesse resultado?

Uma coisa importante de se lembrar em um Story map é que ele é sobre uma grande História.  Histórias de usuário sendo pequenas histórias sobre algo muito específico que o usuário faz no sistema, o processo do story mapping vem para conseguir juntar todas essas pequenas histórias numa grande história e com isso criar uma visão compartilhada entre todos. 

Tudo começa com uma ideia de caminho feliz. Aqui vale ressaltar que o Story Mapping deve ser dinâmico e se ter na cabeça que é uma hipótese para atingir um ou mais outcomes. 

Essa coluna vertebral do sistema (backbone) é onde tudo acontece. Um fluxo narrativo simples de como os usuários se relacionam com o sistema é a base que une todos os times. É importante sempre pensar nisso, na perspectiva de quem vai usar o sistema. Já veremos por que isso é tão importante.

Para isso é importante pensar nas tarefas que esse usuário tem que realizar para que uma mudança de comportamento desejada seja refletida. Qual o passo a passo do que o usuário faz para chegar ao resultado que esperamos.

Talvez essa narrativa já exista na sua empresa em forma de User Journey Map, em um protótipo, ou mesmo em slides de um pitch para investidores.

Aqui na Taller estamos usando o Event Storming do Alberto Brandoline para conseguir chegar com mais acurácia nesse passo a passo em uma perspectiva de evento.

Dependendo do tamanho do seu produto, essa coluna vertebral pode ficar bem grande. Então é preciso olhar de longe e começar a classificar a narrativa com o que faz sentido. Não tenho nenhuma grande dica aqui a não ser o bom senso. 

Novamente, o Event Storming pode ajudar muito nesse trabalho, mas a ideia é olhar a narrativa e agrupá-las por atividades que façam sentido. Se a nossa narrativa fala que o usuário

• Faz o cadastro.
• Cria o seu perfil.
• Vê a programação do evento.
• Cria sua trilha de palestras.

Essas tarefas podem ser parte de uma atividade de “Onboarding”. O fluxo narrativo das atividades dará um panorama mais simples e resumido do que o sistema faz.

Com seu backbone e as atividades definidas, é hora de entrar no detalhamento. 

Agora é a hora de explorar o problema e tentar pensar em soluções criativas. O que vai fazer o usuário clicar no call to action? Quais outras opções ele pode ter para chegar no mesmo resultado? Quais caminhos podem tirar ele da rota que queremos dar?

 

Fatie a estratégia de release

Com o backbone, começamos a entrar nos detalhes. O backbone sendo o plot da sua história, aqui temos que olhar quais detalhes precisamos explorar para que as demandas seja realizadas.

Uma das partes essenciais do Story Mapping é o fatiamento de releases. É uma das coisas mais importante de todo o mapa, pois é uma forma mais visual e holística de criação de um roadmap do produto. 

Cada release, ou projeto, ou marco, como queira chamar, tem que atender minimamente uma jornada de um usuário. Limitar a uma jornada de um usuário faz com que seja possivel fazer menos e aprender mais rápido.  Qual o mínimo para validar a minha hipótese? Esse output vai realmente fazer mais usuários pedirem orçamento? Mais pedidos de orçamento vão realmente refletir em mais vendas? 

Para isso criamos as linhas horizontais que separam a jornada. Como é a jornada inicial, o outline do nosso quadro, para que seja possível ver se faz sentido. Como seria com tinta? Como vai ser finalizado? 

Sendo ágil, essas releases podem e vão mudar com o decorrer do tempo, mas usamos o planejamento para alinhar as mudanças, não para seguir o plano cegamente.

O importante aqui é sempre pensar: Como faço menos e consigo atingir essa jornada?

 

Conclusão

Histórias nos moldam e são a melhor forma de transmitir informação que conhecemos. Usar todo esse poder para contar a história do produto tanto para quem está na construção quanto para os usuários é um desafio que cada dia ganha mais adeptos. 

Quando for pensar na construção ou na melhoria, conte histórias, converse com as pessoas. O entendimento vem mais do bate-papo e da confirmação do que da escrita de requisitos em um card no board. 

---