Será que PMs escrevendo histórias é o melhor cenário de eficiência?

Será que faz zero sentido econômico ou operacional ter alguém intermediando informações entre quem projeta a experiência e quem vai executá-la?

A verdade é que os designers conhecem cada pixel, cada fluxo, cada fricção que o usuário vai enfrentar. Os QAs dominam os cenários de erro, entendem dos possíveis bugs e problemas de fluxos que podem acontecer. E os devs sabem exatamente o que é tecnicamente viável e o que não é.

Então por que diabos ainda temos que delegar para os PMs escreverem histórias para essas pessoas efetivamente executarem no final?

Vou tentar fazer um exercício de cenário idealista com você nesse texto. Só abre a mente para cutucarmos melhor nosso pensamento crítico.

A história das histórias

Antes de qualquer coisa, vamos entender como chegamos até aqui. As user stories nasceram no contexto ágil como uma forma de capturar requisitos de software de maneira mais humana e colaborativa. A ideia era criar uma ferramenta que fosse simples o suficiente para qualquer pessoa no time técnico ou de negócios contribuir, não um documento que apenas uma pessoa específica deveria escrever.

O formato clássico "Como [persona], eu quero [funcionalidade] para que [objetivo]" foi pensado justamente para democratizar a criação de requisitos. Qualquer membro do time - product manager, designer UX, etc. - que entendesse o problema específico do usuário poderia contribuir com uma user story, sem precisar saber como a equipe de desenvolvimento iria codificar aquela solução.

E aqui começa o problema: como isso iniciou nesse meandro de agilidade, o papel dessa escrita era de alguém chamado PO (Product Owner). Que, como todos já sabem, é um papel do Scrum, que é apenas uma fatia pequena do que o PM faz no dia a dia.