janeiro 23, 2018
por Ron Yang

Histórias. Você tem centenas deles se você é um gerente de produto. Cada um descreve as experiências incríveis que você deseja que seus clientes tenham ao usar seu produto. E como qualquer bom contador de histórias, você precisa que suas histórias sejam claras e impactantes.

todos os melhores gerentes de produto que conheço são responsáveis por compartilhar o que os clientes realmente querem por meio de histórias de usuários.

mas aqui é quando ser um gerente de produto é um trabalho árduo. Também há momentos em que você deve definir os requisitos para o que suas equipes de desenvolvimento precisam construir — sem fornecer o “porquê” da perspectiva do Usuário.

embora a maioria das novas funcionalidades deva ser definida da perspectiva de um usuário, isso nem sempre é viável ou mesmo útil. Por exemplo, considere recursos de segurança ou requisitos de infraestrutura que nem sempre são enfrentados pelo cliente.

então a questão se torna: quando você usa esses diferentes vasos? Antes que você possa responder isso, você precisa entender o que os torna diferentes.

existe uma grande distinção entre histórias de usuários e requisitos: o objetivo.

a história do Usuário se concentra na experiência — o que a pessoa que usa o produto deseja ser capaz de fazer. Um requisito tradicional se concentra na funcionalidade – o que o produto deve fazer. As diferenças restantes são uma lista sutil, mas importante, de” como”,” quem “e ” quando”.”

aqui está como as histórias e os requisitos do Usuário diferem:

como é escrito?

as histórias de usuário devem ser escritas em uma ou duas frases e capturar quem é o usuário, o que deseja e por quê. Uma estrutura simples para definir recursos ou histórias de usuários pode se parecer com isso: como ____, quero alcançar ____ para que eu perceba o seguinte benefício de ____.

exemplo: como usuário, quero poder redefinir minha senha para poder voltar ao sistema se esquecer.

os requisitos tendem a ser muito detalhados e demoram mais para escrever. Eles geralmente entram em detalhes específicos (às vezes altamente técnicos) sobre como o software deve funcionar. Esses detalhes orientam a equipe de desenvolvimento sobre como criar um novo recurso ou funcionalidade.

exemplo: o usuário tem permissão para redefinir sua senha depois de receber um e-mail de redefinição de senha. O e-mail deve conter um link exclusivo para redefinir a senha e esse link deve expirar após duas horas.

quem o Escreve?

as histórias de usuário podem ser escritas por praticamente qualquer pessoa próxima ao software-desenvolvedores levantando problemas, um testador de QA que descobre uma falha na UX — desde que represente a perspectiva do usuário final. Mas é o gerente de produto ou proprietário que mantém o backlog de histórias de usuários.

os requisitos são escritos pelo Gerente de Produto, product owner ou Business analyst. Os leads técnicos estão frequentemente envolvidos, bem como os engenheiros que serão responsáveis por trabalhar nos recursos ou melhorias.

quando eles são escritos?

histórias de usuários são escritas ao longo da construção de um produto. E atualizar as histórias (ou adicionar novas) pode acontecer a qualquer momento. Para equipes ágeis, o Product backlog serve como uma lista priorizada da funcionalidade que precisa ser desenvolvida. É aqui que as histórias de usuários são mantidas até que sejam trabalhadas — normalmente durante sprints de desenvolvimento.

os requisitos também podem ser criados a qualquer momento. No entanto, é melhor definir o que é desejado do ponto de vista do Usuário primeiro se forem necessárias histórias e definição de requisitos. Quanto mais ao longo de uma equipe está com seu planejamento, mais a equipe entende as necessidades do Usuário e do negócio. Portanto, definir requisitos difíceis muito cedo pode resultar em ter que alterá — los mais tarde-ou construir algo que não entregue totalmente o resultado desejado pelo cliente.

embora o objetivo de uma história ou exigência de usuário seja diferente, o objetivo é sempre o mesmo — construir um produto que os clientes adoram.Se você está escrevendo uma história de usuário ou um requisito, você precisa se concentrar no que mais importa: descrever o resultado desejado para o cliente e dar ao desenvolvimento o que eles precisam para construí-lo com sucesso.

eu sei que pode ser confuso decidir o que escrever. Então, aqui está um guia simples para fazer essa escolha.

se o que você está solicitando para construir tiver um benefício direto para seus usuários finais, escreva uma história de usuário. Se for mais central para o núcleo de um produto ou infraestrutura, vá para a definição de requisitos.

que diferenças você adicionaria à lista?

Deixe uma resposta

O seu endereço de email não será publicado.