Substituindo User Stories por Job Stories
Ter muitas hipóteses é perigoso
Por Alan Klement (publicado originalmente aqui, em inglês)
Eu escrevi sobre o problema de histórias de usuários antes. Na época, eu achava melhor ter apenas uma conversa em equipe sobre as mudanças propostas para o produto. Isso funcionou muito bem quando a equipe estava sólida e o produto bem maduro; agora, porém, estou trabalhando com um novo time e criando um produto do zero. Nesse caso, pelo fato de nosso canvas estar em branco, estamos tendo problemas de sintonia no que diz respeito às motivações, eventos e expectativas dos clientes. Mas hoje as coisas mudaram de rumo. Eu encontrei uma grande forma de usar a filosofia dos trabalhos no backlog para ajudar a definir as features.
Eu chamo isso de Job Stories.
De onde vem isso
A ideia vem de pessoas muito inteligentes da Intercom. Elas dizem que:
Nós enquadramos todos os problemas de design em uma tarefa (job), focando na situação ou evento gatilho, na motivação e no objetivo e no resultado pretendido:
Quando ______, eu quero _______, então eu posso _______.
Por exemplo: quando um cliente novo importante se cadastra na minha plataforma eu quero ser notificado para poder iniciar uma conversa com ele.
Esse artigo não perde muito tempo com o conceito de Job Stories, então eu vou falar porque gosto dele e porque é melhor que User Stories (histórias da pessoa usuária).
O problema (de novo) com histórias de usuários
Resumindo, o problema é que há muitas hipóteses e não há uma noção de causalidade. Quando uma tarefa é colocada no formato de uma história de usuário (Com um [tipo de usuário], eu quero [alguma ação], para que [resultado]) não há espaço para perguntar ‘porquê’ — você está basicamente preso em uma sequência particular sem nenhum contexto.
Eu vejo o formato assim:
O primeiro problema é que nós começamos com uma Persona, o que é uma péssima ideia, e então criamos uma ação que achamos que deve ser realizada para atingir o resultado esperado. Conforme eu destaquei na imagem acima, há uma desconexão verdadeira entre a ação e a persona.
Vamos ver um exemplo real de User Stories:
No gráfico acima, quando alguém lê moderador ou estimador, isso de fato acrescenta alguma coisa? Se acrescenta algo é ambiguidade ao fluxo. Você e eu vamos interpretar da nossa forma o que é um moderador ou porque eles estão nesse contexto em particular.
Tente. Corte toda a parte Como um e veja se você está realmente sentindo falta de algo. Compare esses dois:
Como um moderador eu quero criar um novo jogo adicionando um nome e uma descrição opcional
VS.
Eu quero criar um novo jogo adicionando um nome e uma descrição opcional
O mundo acabou?
Job Stories: Tudo sobre contexto e causalidade
Atualização 1: baseado em ainda mais usos e feedbacks, eu adotei uma explicação ligeiramente diferente agora. Veja estes tweets de como eu sugiro a estruturação. Uma atualização desse artigo virá no futuro…
Veja a imagem acima. Agora sim!
Toda a informação acima é importante e muito esclarecedora porque estamos focando em causalidade. Cada job story deve oferecer tanto contexto quanto possível e focar na motivação… ao invés de somente na implementação.
Atualização 2: Depois de trabalhar por um tempo com job stories, eu mudei ‘motivações’ por ‘motivações e forças’. Veja as 5 Dicas Para Escrever Uma Job Story que trata disso. Aprenda mais sobre as forças nesse podcast e nesse artigo rápido.
Vamos reescrever alguns exemplos do gráfico de história de usuário acima como uma job story e acrescentar motivação e contexto a cada um.
User Story:
Como moderador, eu quero criar um novo jogo adicionando um nome e uma descrição opcional, para que eu possa começar a convidar estimadores.
Job Story:
Quando eu estiver pronto para ter estimadores no meu jogo, eu quero criar um jogo no formato que eles possam entender, para que possam achar meu jogo e saber no que eles estão prestes a entrar.
User Story:
Como estimador, eu quero ver o item em que as pessoas estão apostando, para que eu possa saber o que eu estou avaliando.
Job Story:
Quando eu encontrar um item em que eu queira avaliar, eu quero poder ver este item, para que eu possa confirmar que ele é realmente o correto.
User Story:
Como moderador, eu quero selecionar um item a ser avaliado ou reavaliado. Assim, a equipe vê o item e pode avalia-lo.
Job Story:
Quando um item não tem uma avaliação ou tem uma avaliação que não me satisfaz, eu quero poder reiniciar essa avaliação e notificar todo mundo, para que a equipe saiba qual item em particular precisa ser avaliado.
E os múltiplos papéis e eventos?
Conforme fui recebendo feedbacks muito bons sobre as Job Stories e continuei trabalhando no assunto, descobri que às vezes é útil incluir papéis, ou personas, como parte da etapa Quando___.
Produtos com papéis múltiplos
Papéis/personagens são mais úteis quando o produto tem papéis variados, por exemplo, um produto de TI (Administrador, Gestor, Colaborador…) ou em um produto da área de vendas (Vendedor, Comprador).
A razão é apenas definir sobre quem estamos falando.
Vamos usar o eBay como exemplo:
Quando um Comprador ou uma Compradora já fez uma oferta em um item, ele ou ela ficam ansiosos em perder uma oferta maior e querem receber uma notificação imediatamente quando essa contraproposta for feita, para ter tempo suficiente para avaliar e atualizar suas próprias propostas.
Papéis com causa e efeito
Às vezes, há situações quando os efeitos de uma Job Story atingem múltiplos papéis de uma só vez — configurando um cenário de causa e efeito.
Vamos usar o eBay como exemplo de novo:
Quando um vendedor não está feliz com as ofertas e tira os seus produtos do mercado, compradores que já fizeram propostas querem ser notificados imediatamente sobre a retirada do produto, para que saibam que não precisam mais acompanhar aquela oferta que e devem procurar por um outro produto similar.
Usando eventos ao invés de papéis
Às vezes, no entanto, pode haver uma situação em que um evento afete todos os papéis ou grupos de papéis: como a necessidade de um lembrete de senhas. Nesse caso não há razão para ter um papel específico. Ao invés disso, tente se basear em eventos em geral usando termos como cliente ou alguém (mas não usuário):
Quando um cliente está num dispositivo móvel e esquece a senha, essa pessoa quer resgatar a senha facilmente a partir do dispositivo, para que possa continuar a logar e acessar o seu feed de notícias.
E por que não usuário? Usuário(a) parece meio sem vida e estéril. Por outro lado, cliente nos lembra que nós temos pessoas que precisam ser servidas e respeitadas.
Defina motivações, não implementações
Job Stories são ótimas porque te fazem pensar sobre motivação e contexto e tira a ênfase da adição de qualquer implementação em particular. Geralmente, porque as pessoas estão focadas no como e no que, elas se esquecem totalmente do porquê. Quando você começa a entender o porquê, sua mente se abre para pensar em formas criativas e originais de resolver um problema.
