Substituir a história do usuário pela história do trabalho

Olá pessoal. Traduziu outro material interessante para os alunos do curso "Product Manager IT-projects" . Aprecie a leitura

---

Anteriormente, eu já escrevi sobre problemas com a história do usuário ( histórias do usuário). Naquela época, eu achava melhor pedir à equipe que discutisse as mudanças propostas no produto. A estratégia era boa se a equipe prestasse assistência e o produto já estivesse maduro. No entanto, agora estou trabalhando com uma nova equipe e criando um produto a partir do zero. Nesse caso, temos uma folha em branco e não é fácil chegarmos a um acordo no que diz respeito à motivação, eventos e expectativas do cliente. Hoje tudo mudou. Encontrei uma ótima maneira de usar a filosofia Jobs To Be Done para definir a funcionalidade do produto. Hoje falaremos sobre histórias de emprego.

De onde ela veio

Essa ideia veio de caras muito inteligentes da Intercom . Aqui está o que eles dizem sobre esse assunto:

Chamamos cada tarefa de arquitetura de Job, focamos na situação ou evento que a iniciou, motivação ou propósito, e obtemos o seguinte:

Quando _____, eu quero ______ para _______.

Por exemplo, quando um novo cliente importante é registrado, quero receber alertas para poder iniciar uma conversa com ele.

Neste artigo, não faço referências a esta construção quanto ao Job Story, mas vou nomeá-lo de maneira a poder me referir facilmente a ele no futuro.

Hoje não vamos gastar muito tempo explicando o conceito, apenas falarei sobre por que gosto e por que é melhor que a História do usuário.

Sobre o problema da história do usuário [novamente]

Em geral, o problema das histórias de usuários é que elas contêm muitas suposições e poucas causas. Quando uma tarefa é definida no formato de uma história de usuário ( como [tipo de usuário], quero que [ação] obtenha [resultado] ), não há lugar para a pergunta "por quê?". Na verdade, você está simplesmente limitado a uma determinada sequência retirada de contexto.

É assim que vejo este formato:


Suposições e falta de comunicação entre uma pessoa e sua ação.

O primeiro problema é que começamos com uma personalidade, o que não é uma boa ideia , depois vem a ação que, em nossa opinião, deve ser tomada para alcançar o resultado desejado. Como já observei na figura acima, de fato, a diferença está entre ação e personalidade.

Vejamos algumas histórias de usuários existentes:


Um exemplo de como escrever histórias de usuário

Observando a tabela acima, podemos dizer que os tipos de usuários "moderador" e "avaliador" acrescentam cor à imagem geral? De qualquer forma, isso adiciona ambiguidade. Podemos oferecer nossa própria interpretação desses conceitos e por que o contexto se parece com isso.

Aqui, tente. Remova toda a parte “como [tipo de usuário]” e veja se realmente está perdendo alguma coisa. Compare as seguintes instruções:

Como moderador, quero criar um novo jogo inserindo um nome e uma descrição opcional.

Ou então:
Quero criar um novo jogo inserindo um nome e uma descrição opcional.
O céu entrou em colapso?

História do Trabalho: Tudo Sobre Contexto e Causação


Formato da história do trabalho

Com base em ainda mais experiência e feedback, agora uso uma explicação um pouco diferente. Agora eu vejo o seguinte .

Vamos olhar a imagem novamente e finalmente começar!

Todas as informações acima são muito importantes e informativas, pois focamos na causalidade. Cada trabalho deve conter o máximo de contexto possível e focar na motivação, não apenas na implementação.

Depois de trabalhar com a Job Story por um tempo, mudei Motivações para Motivações e forças de atuação. Dê uma olhada no artigo "5 dicas para escrever uma história de trabalho", onde este tópico é abordado diretamente. Você pode aprender mais sobre forças de atuação neste podcast e breve artigo .

Vamos reescrever alguns exemplos da tabela Job Story acima no Job Story, adicionando motivação e contexto a cada um.

História do usuário:
Como moderador, quero criar um novo jogo inserindo um nome e uma descrição opcional.
História de trabalho:
Quando eu estiver pronto para os avaliadores apostarem no meu jogo, desejarei criar o jogo em um formato que eles entendam, para que os avaliadores possam encontrar o meu jogo e entender que podem apostar.

História do usuário:
Como avaliador, quero ver o item sendo avaliado para saber no que estou apostando.
História de trabalho:
Quando encontro um item que quero avaliar, quero poder examiná-lo para entender que realmente preciso do item em que estou apostando.

História do usuário:
Como moderador, desejo selecionar um item para avaliação ou reavaliação, a equipe vê esse item e pode avaliá-lo.
História de trabalho:
Quando um item não tem classificação ou eu não gosto da classificação, desejo poder reiniciar o processo de avaliação e notificar a todos para que a equipe saiba que um determinado assunto precisa ser classificado.

E quanto a vários papéis e eventos?

Como recebo várias resenhas sobre a História do trabalho e continuo trabalhando com elas, acho adequado incluir algumas funções ou personagens na parte Quando ____ .

Produtos com várias funções

Funções e caracteres são mais úteis quando o produto em si tem várias funções, por exemplo, um produto de TI (administrador, gerente, participante) ou um produto de mercado aberto (comprador, vendedor). A razão é que é preciso sempre entender de quem estamos falando.

Tome o eBay como exemplo:

Quando o comprador já fez uma aposta no produto, ele está preocupado que alguém faça uma grande oferta e queira receber notificações para ter tempo suficiente para avaliar e atualizar sua própria oferta.

Papéis e causalidade

Às vezes, surgem situações em que o Job Story descreve a interação de várias funções ao mesmo tempo, criando um cenário causal.

E, novamente, tome o eBay como exemplo:

Quando o vendedor está insatisfeito com as ofertas recebidas e retira seu produto do mercado, os compradores que já apresentaram lances desejam receber imediatamente uma notificação de que o produto foi retirado do leilão, para que não sigam mais sua dinâmica de preços e procurem outro produto similar.

Usando eventos em vez de funções

Às vezes, uma situação pode surgir quando um evento afeta todas as funções ou grupos de pessoas: por exemplo, você precisa obter um lembrete de senha. Nesse caso, não há razão para introduzir uma função específica; ela deve ser deixada no nível de conceitos gerais, por exemplo, "cliente" ou algo semelhante (mas não "usuário"):

Quando um cliente usa seu dispositivo móvel e esquece a senha, ele deseja ter uma senha que possa ser facilmente restaurada usando seu dispositivo móvel, para que o cliente possa continuar a fazer login e acessar seu feed de notícias.

Por que não um usuário ? Um "usuário" parece muito sem vida e infrutífero, enquanto um "cliente" lembra que existem pessoas a quem você deve prestar um serviço e que precisam ser respeitadas.

Definir motivação, não implementação

As histórias de emprego são boas porque nos fazem pensar sobre motivação e contexto, além de remover a ênfase de adicionar qualquer implementação específica. Muitas vezes, devido ao fato de as pessoas se concentrarem nas perguntas "quem" e "como", esquecendo completamente o "porquê". Quando você começa a pensar sobre o "porquê", sua mente se abre para maneiras criativas e originais de resolver o problema.

Aprenda mais

Sua história de trabalho precisa de um momento de luta (https://jtbd.info/your-job-story-needs-a- esforçando-moment-c03de87c6026), 5 dicas para escrever uma história de trabalho.
Você também pode aprender sobre JTBD e Job Story em meu livro When Coffee and Kale Compete.
Você pode dizê-lo gratuitamente em PDF ou comprar uma versão em papel aqui . E aqui você pode fazer o pedido on-line.