Você pode estar usando User Stories de maneira errada - PM3
Marcell Almeida

Marcell Almeida

CEO – PM3

4 minutos de leitura

10 Perguntas e respostas em entrevistas para Analista de Dados

Imagine que você está em uma orquestra, cada instrumento tem sua partitura, sua função, seu momento de brilhar. As histórias de usuário são como a partitura na hora desenvolver produtos. Elas guiam, dão ritmo e harmonia ao processo. Mas, assim como uma partitura mal escrita pode desafinar uma orquestra, histórias de usuário mal escritas podem mais atrapalhar do que ajudar.

Originalmente as User Stories foram criadas para ser uma ferramenta que ajuda na comunicação entre a pessoa de produto e os engenheiros. Mas assim como uma partitura pode ser mal interpretada, as user stories podem levar a distrações e mal-entendidos dentro da equipe. O uso indevido normalmente vem de dois extremos:

1) uma pessoa de produto que passa muito tempo tentando criar a história de usuário perfeita e;

2) uma pessoa de produto pouco zelosa que passa pouco tempo articulando seu pensamento, vendo o processo de escrita como um empecilho.

Três erros comuns que os gerentes de produto cometem com histórias de usuário incluem:

1) Achar que histórias de usuário vão substituir a pesquisa com usuário:

Histórias de usuário nunca devem substituir uma pesquisa qualitativa profunda com o usuário. Elas devem servir como uma sinopse de uma linha para a funcionalidade que vai melhorar a vida do usuário. Idealmente tanto o PM quanto o time engenharia precisa entender mais do contexto e ir além da User Story – de preferência entendendo qual foi o racional para chegar naquela sinopse.

2) Criar uma história de usuário para forçar a adequação ao seu produto hipótese:

Histórias de usuário não devem ser inventadas para justificar a construção de alguma feature. Elas devem ser baseadas em necessidades reais do usuário e pesquisa, ou seja, a tal “sinopse” vem a partir de pesquisa e fatos.

3) Ser rígido com o formato de história de usuário:

Histórias de usuário não devem ser vistas como um formato rígido que deve ser seguido. Elas devem ser usadas como uma ferramenta para comunicar efetivamente quem é o cliente, o que estamos tentando fazer e por que isso é importante.

Todo mundo precisa usar User Stories?

Usar ou não histórias de usuário depende da sua empresa. Conheço grandes empresas de tecnologia que não usam – na verdade, em todas as empresas que trabalhei, apenas uma usava e até o dia que eu saí já havíamos parado de usar o modelo padrão. O mais comum que vejo no mercado são empresas focando mais em PRDs e na colaboração da equipe de produto-engenharia – em especial quando os engenheiros estão razoavelmente alinhados com o objetivo da empresa e do produto que estão trabalhando. Isso reduz a necessidade de ter uma especificação tão detalhada.

Apesar de hoje em dia não ser mais um grande fã de user stories, há maneiras efetivas de usá-las:

1) Protetoras contra o aumento de escopo: As histórias de usuário podem ser usadas para definir o início e o fim das tarefas que as equipes de engenharia precisam executa, protegendo as equipes contra aquele famoso aumento do escopo que aparecem no fim da sprint.

2) Histórias de Usuário Promovem o Foco no Cliente: As histórias de usuário podem ajudar a manter o foco no cliente, especialmente quando problemas técnicos ou questões de custo começam a surgir.

3) Histórias bem fatiadas para que o progresso seja visível e entregue valor constante:

Neste artigo de 2016 eu inclusivo explico como escrever boas user stories. Se você está buscando se aprofundar nesse tema e testar essa metodologia, recomendo ler este artigo.

Em conclusão, embora as histórias de usuário não sejam a única maneira de construir produtos, elas podem ser uma ferramenta valiosa quando usadas corretamente. Se você usa esse modelo ou algo similar e quer compartilhar com mais pessoas, contacta a gente da PM3 para publicar seu case aqui no nosso blog contato@pm3.com.br.


Referências: