Como formatar histórias negativas de usuários?

9

Seguindo o estilo formal da história do usuário:

Como <user>, eu quero <goal>isso <benefit>.

Nossa equipe encontrou dificuldades em expressar coisas onde há um desejo dos proprietários do sistema de fazer algo que afeta negativamente o usuário.

Como um exemplo arbitrário, digamos que o proprietário queira que o sistema carregue os clientes toda vez que verificarem seus emails.

Seguindo o estilo formal das histórias de usuários, você pode escrever da seguinte maneira:

Como cliente, quero ser cobrado toda vez que verifico meu email para que o proprietário do sistema possa aumentar sua receita.

Obviamente, o cliente não deseja ser cobrado; a história se torna chocante de ler e a linguagem está atrapalhando os fatos.

Como o requisito pode ser escrito de maneira diferente?

user-story

— Paul Turner
fonte

1

Você está tendo problemas para escrever a história ou criar algo que não considera ético?

— JeffO 01/02/12

24

Se o pagamento afetasse negativamente os clientes, eles não usariam esse serviço. Não se preocupe com isso. Além disso, os usuários (geralmente) não pagam dinheiro porque querem ajudar os proprietários do sistema, mas porque desejam algum serviço em troca, portanto, seu exemplo deve ser assim:

Como cliente, quero ser cobrado toda vez que verifico meu e-mail para poder obter o serviço X em troca.

Além disso, as histórias do usuário são escritas da perspectiva de todas as funções do usuário, não apenas dos clientes finais. Considere escrever este da perspectiva do proprietário do sistema como outra função de usuário:

Como proprietário do sistema, quero que os clientes sejam cobrados toda vez que verificam seus emails para aumentar minha receita.

Um conselho geral: concentre-se na parte positiva da história do usuário e não pense demais nela. Eles devem ser simples. Se a história do usuário é muito negativa, sem uma maneira de evitá-la, o problema está na concepção do sistema e, nesse caso, não importa realmente o que você escreve em seus cartões.

— Goran Jovic
fonte

O perigo de escrever da perspectiva do proprietário do sistema é que todas as histórias vêm essencialmente dos proprietários e o valor da userparte da história diminui.

— Paul Turner

@ ProgrammingHero: Essa é apenas uma alternativa que eu sugeri. :)

— Goran Jovic

5

@ProgrammingHero Acho que você pode ficar de fora da semântica. O proprietário do sistema pode ser o proprietário do sistema (por exemplo, proprietário do produto). Esse proprietário do sistema também pode ser uma função exclusiva do usuário no próprio software. A história do usuário deve ser escrita com base na função ou no tipo de usuário que, por acaso, é o Dono do Sistema, onde, como Dono do Sistema, a pessoa é uma pessoa na função Dono do Produto de uma equipe de desenvolvimento de software, que na realidade é completamente diferente.

— Maple_shaft

4

@ Programação aqui: lembre-se de que a história existe para atendê- lo - para lhe dizer por que o recurso é necessário e a quem ele se beneficia. Se isso beneficiar a empresa, diga-o na história para que a equipe fique clara sobre o motivo da existência do recurso. O cartão existe para transparência, entre outras coisas. Saber que você está fazendo algo que não beneficia o usuário é uma coisa boa .

— Bryan Oakley

11

O <user>usuário não precisa ser o usuário final - ele pode ser facilmente o proprietário da empresa / proprietário do sistema:

As a system owner
I want to charge customers
So that the business can pay my programmers

— Oded
fonte

Eu não acho que ter o proprietário do sistema como o usuário esteja correto; toda história pode ser escrita da perspectiva deles, se essa abordagem for válida.

— Paul Turner

Além disso, entendi que a história está reagindo a algo que o usuário faz (verificando seu e-mail) e não a algo que o proprietário do sistema faz, portanto, tê-lo da perspectiva do usuário parece mais correto.

— johnl

4

@ JohnL: a história não está em reação a nada. É uma explicação de por que você está implementando o recurso. No entanto, mesmo que pareça que o usuário talvez não se beneficie, geralmente o faz. Mesmo nesse caso específico, eles se beneficiam porque, quando você os altera, a empresa será lucrativa, o que permite que a empresa continue a prestar o serviço ao usuário.

— Bryan Oakley

4

As histórias de usuário não existem para atender a algum tipo de requisito de metodologia. Eles existem apenas para esclarecer o que uma equipe está fazendo, por que está fazendo e quem se beneficia com isso. Se você torce as palavras para obscurecer o significado ou se encaixa em algum requisito estrito para a aparência de uma história, ela não serve para ninguém.

Então responda a pergunta "quem faz esse benefício" e "por que estamos implementando isso" honestamente. Sua equipe de desenvolvimento precisa dessas informações para fazer seu trabalho. Mesmo que a história seja negativa do ponto de vista do usuário, são informações valiosas.

Dito isto, o que você descreve parece mais um cenário de caso de uso do que uma história. Talvez se você reduzi-lo a pedaços menores, talvez seja mais claro quem são os proprietários e os beneficiários. Por exemplo, o recurso de cobrança pela verificação de e-mail possui vários componentes. No mínimo, há um componente de interface do usuário e um componente de back-end, e talvez uma regra de negócios.

Você pode dividir seu recurso nessas histórias:

Como provedor de um serviço de e-mail, desejo cobrar uma taxa por cada e-mail lido, para que eu possa ganhar dinheiro e continuar a fornecer e aprimorar o serviço

Como usuário, desejo que a cobrança da taxa de e-mail ocorra automaticamente para que eu possa ler meu e-mail sem precisar reconhecer cada taxa à medida que ela é cobrada, para que minha experiência seja mais agradável.

Como usuário, desejo poder revisar facilmente os termos de serviço e os valores das taxas, para entender as taxas cobradas, para que eu possa me sentir confiante de que estou obtendo o valor do meu dinheiro.

Como usuário, desejo que a taxa de cobrança para a leitura de e-mails seja pequena, para que eu possa usar esse serviço

— Bryan Oakley
fonte

2

Eu gosto desta resposta - existem metodologias para construir algo. Quando se tornam dogmas a serem seguidos cegamente, não servem mais para o propósito pretendido.

— Jay Elston

-1

Concordo que escrevê-lo em termos de proprietário do sistema parece errado, porque o proprietário do sistema não inicia esta história - o usuário inicia quando verifica o email. Mas não acho que você precise falar em termos do que o usuário deseja, mas do que ele espera que aconteça.

As a customer
When I check my email
I should be charged
So I continue to recieve Service X

O usuário espera ser cobrado porque você descreveu seu plano de pagamento para ele.

— JohnL
fonte

3

Não importa quem "inicia" a história. O objetivo da história é que a equipe entenda o valor comercial da história. Às vezes, o valor do negócio é melhorar a experiência do cliente, às vezes não. Seja honesto. Não é como se o cliente visse o cartão. O objetivo é garantir que a equipe esteja clara sobre por que você está fazendo alguma coisa. Se a realidade é, você está fazendo isso para extrair dinheiro do usuário, diga. No entanto, se o objetivo real é permanecer nos negócios para servir o usuário, diga isso.

— Bryan Oakley

1

Se foi assim que você aprendeu a escrever histórias de usuários, lamento informar que você foi enganado. Uma história de usuário define o que um usuário precisa ou não, o que ele espera que aconteça. O fato de que a cobrança por e-mail ocorre é simplesmente um dado. Como usuário, preciso cobrar para que eu possa verificar meu e-mail. Essa resposta é factual e inequivocamente errada e sugiro excluí-la.

— Maple_shaft

Acho que não entendi bem, embora eu sugira apenas acrescentar isso como sua resposta. Eu aprecio estar bem, o voto negativo nem tanto . E acho que importa quem inicia a história, porque é assim que sei com quais histórias estou lidando agora. Não há como manter todos eles na minha cabeça de uma só vez. Para descobrir o que acontece quando um usuário verifica seu e-mail, vou para a história que começa com As a user, when I check my email...Se eu não puder fazer isso de maneira confiável, as histórias de usuários são fundamentalmente quebradas. Desculpa.

— johnl

2

@ JohnL: O que você está descrevendo soa mais como cenários de casos de uso do que histórias de usuários. Ambos os formatos são adequados para descrever os requisitos de software, use o que for melhor para você e se encaixe melhor no seu fluxo de trabalho de desenvolvimento.

— Goran Jovic

2

Goran e Bryan fazem excelentes pontos. Parece que você está lidando com casos de uso porque as histórias de usuários não beneficiam você. Essas coisas devem ajudar seu projeto a ser bem-sucedido, se você acha que elas geralmente são um obstáculo geral, os casos de uso e as histórias de usuários provavelmente são pouco ou nenhum benefício para você e você não deve se forçar a usá-los. Esse é um cenário perfeitamente legítimo quando a lógica de negócios, a complexidade e o valor percebido pelo usuário do seu software são tão baixos que as histórias de usuários são de conhecimento escasso ou comum.

— Maple_shaft