User Story Mapping: Construindo uma visão de produto de forma colaborativa
Depois de quase oito anos como desenvolvedor de software, recebi o desafio de ser Product Manager de um dos times de desenvolvimento da Involves. Em minha carreira como desenvolvedor, sempre fui o “chato questionador” do time. Me convencer do valor de uma nova funcionalidade e/ou alteração no sistema era sempre uma tarefa árdua para meus colegas de trabalho. Apesar desse comportamento ter me gerado alguns conflitos, aprendi a lidar com eles, e assim, arrisco dizer que essa foi uma das minhas características que mais contribuiu para minha evolução profissional.
Assumi meu novo cargo com uma expectativa grande de conseguir resolver alguns dos maiores questionamentos que eu tinha enquanto desenvolvedor:
- O que é mais importante para o usuário final?
- Por que estamos desenvolvendo isso atualmente?
- Como o produto deve evoluir? O que ele deve fazer no futuro? Qual é a visão do todo?
No primeiro dia recebi um choque de realidade: eu não tinha entendimento suficiente para convencer meu time do que deveríamos fazer. E agora? Eu claramente precisava estudar mais sobre nosso mercado e clientes. Mas e o meu time? Ficaria esperando eu estudar e realizar todo um projeto de discovery para que tivéssemos um backlog? Como não repetir tudo aquilo que me incomodava em minhas experiências como desenvolvedor? Como envolver o time de desenvolvimento no processo de descoberta sobre o cliente e o produto? Eram muitas perguntas e eu já tinha uma ideia sobre o que não fazer. Faltava aprender uma coisa: como fazer.
Discovery e development, no geral, são tratados como processos diferentes, e apesar de serem dois tipos diferentes de trabalho, com duas linhas distintas de pensamento, eles fazem parte do mesmo processo. Eu tinha certeza das coisas que não funcionariam: não envolver desenvolvedores e outros interessados; e não ser transparente sobre o trabalho de discovery. Buscando formas de ajudar meu time a responder os questionamentos levantados no início, eu decidi envolver eles ao máximo na construção, priorização e manutenção do nosso backlog. E para isso decidi usar a técnica User Story Mapping.
User Story Mapping é um mapa que organiza as histórias de usuário em um modelo que ajuda a compreender a funcionalidade do sistema, a identificar falhas no seu backlog, e a, efetivamente, planejar releases holísticas que oferecem valor aos usuários e ao negócio a cada versão. Jeff Patton — The new backlog
Não me leve a mal, eu poderia ter envolvido todo o time no processo de discovery e criação do backlog sem necessariamente ter criado um mapa, mas depois de algum tempo trabalhando com um board flat tradicional e tendo dificuldade em visualizar o rumo do produto em uma lista de opções, achei que estava na hora de tentar uma nova abordagem.
Preparação para a oficina
1 — Convide seu time;
2 — Não, repito, NÃO construa o mapa sozinho;
3 — Convide clientes e/ou pessoas com vasta experiência no seu mercado para participar;
4 — Reserve uma sala com espaço para que as pessoas possam andar e colaborar na construção do mapa;
5 — Providencie blocos autoadesivos (sem propaganda de marca aqui);
6 — Utilize um quadro branco, flip chart e/ou cartolinas para mover o mapa após o término caso ele não possa permanecer na sala utilizada;
6 — Não esqueça canetas/lápis.
Para dar o pontapé na construção do nosso mapa realizamos uma oficina com o time e mais alguns interessados. Para essa dinâmica definimos uma persona importante no mercado que atuamos e mapeamos as activities. Activity, como a própria tradução sugere, é uma atividade que uma determinada persona realiza. Conceitualmente, essa atividade é grande e composta por diversos passos para que um objetivo seja alcançado.
A user story da nossa activity poderia ser: Como um supervisor de uma operação de trade marketing, eu quero poder verificar se o trabalho foi realizado como o planejado de forma que eu consiga identificar eventuais problemas na operação.
No nosso caso, essa história ainda é muito grande para ser aceita pelo desenvolvimento. Por isso quebramos a mesma em user tasks como “Visualizar promotores que já visitaram a primeira loja”, “Identificar promotores atrasados” e ”Enviar mensagem para promotores atrasados”. Esse nível de história é comumente algo que a persona realiza para atingir um objetivo maior.
Mantenha seu mapa visível
Ao ler as activities e user tasks da esquerda pra direita, deve ficar claro sobre o que é o seu sistema e como os objetivos serão atingidos! Utilize esses objetivos em favor do seu time e mantenha as discussões e planejamentos ao redor do mapa. Lembrando que ele deve ajudar a responder as perguntas que foram levantadas lá no início.
Aprendizados
1 — Dependendo do tamanho do seu problema, dificilmente você irá conseguir mapear todo seu produto em uma única oficina. Construir o mapa é tão difícil quanto construir software (pegadinha, rá). Mas não desanime, pior seria seguir a construção do seu software sem essa visão clara para todos;
2 — Contextualize as pessoas que irão participar da oficina sobre a técnica e o problema que vocês irão atacar e facilite de forma que o ambiente esteja seguro para ideias. Tudo que você não quer na construção do mapa é uma pessoa sem saber como colaborar, ou pior, com medo de dar a própria opinião;
3 — Cuidado com o número de pessoas no primeiro contato com a oficina. Muitas pessoas divergindo podem prolongar demais a atividade, principalmente quando o comportamento das personas e domínio de negócio ainda não estão claros.
No próximo post irei mostrar como organizamos nosso mapa em releases e priorizamos cada uma delas para maximizar resultados e minimizar entregas. E você? Já tentou uma abordagem parecida? Deixe aí nos comentários ;)
Referências
Jeff Patton and Peter Economy. 2014. User Story Mapping: Discover the Whole Story, Build the Right Product (1st ed.). O’Reilly Media, Inc..
