O desafio não é desenvolver, é saber o que desenvolver.
User Story
Atualmente, temos utilizado, aqui na Latitude14, uma técnica interessante nos nossos projetos, que veio do Agile development: os Users Stories. Ele tem nos ajudado a manter o foco na essência, nas coisas que realmente importam.
User stories são descrições simples que representam uma funcionalidade. O recomendável é que essas user stories sejam escritas do ponto de vista de uma necessidade dos usuários. No agile, as users stories são escritas em cartões (de papel) em conjunto com o cliente, a equipe de desenvolvimento orça as horas gastas para desenvolver cada user stories e então, em conjunto com o cliente, estas são priorizadas (o que ajuda a selecionar as funcionalidades mais importantes e eliminar o excesso de funcionalidades inúteis).
Elas podem ser escritas de várias formas, mas temos adotado essa:
Eu, como X(perfil de usuário), desejo fazer Y(necessidade), de forma que possa Z(intenção).
Em uma frase temos os 3 pilares do design de interação e do design centrado no usuário: usuário, necessidade real, motivação.
Tenho percebido que as user stories tem nos ajudado em aspectos importantíssimos:
- Validar se a ideia de funcionalidade é realmente necessária antes de incluí-la
- Analisar se a ideia veio de uma necessidade real
- Manter a essência do sistema
- Ajuda a priorizar qual funcionalidade desenvolver
Mas como isso tem acontecido? Vou dar um exemplo prático, acompanhem o raciocínio:
Imagine que você está criando um sistema para IPhone e que a ideia vaga e básica inicial é que ele irá fornecer informações sobre cinema para seus usuários.
Sua ideia atual é inserir uma funcionalidade que mostre os filmes em cartaz, com horários e local de exibição.
A partir desta ideia, eu pensaria em escrever uma user story, que ficaria assim:
Eu como usuária do IPhone, desejo ver quais filmes estão em cartaz e seus respectivos horários, de forma que eu possa assistir um filme, ainda hoje.
Na última linha, temos a intenção – é a dica da essência do seu sistema. Que neste caso é “Ajudar os usuários a encontrar um filme para assistir”. É simples, e descobrir a essência é importantíssimo para você construir um sistema que atenda as necessidades dos seus usuários, além de evitar desenvolvimento de funcionalidades inúteis e reduzir tempo de desenvolvimento. Basta seguir o raciocínio ao longo do projeto, várias idéias irão surgir e agora você terá um guia – A pergunta chave: Esta nova idéia foge ou está dentro da essência do meu sistema? O quão ela é importante dentro da essência?
Exemplo: Em uma reunião da equipe, surge uma nova ideia: Inserir uma funcionalidade para que os usuários possam salvar um filme em uma lista de favoritos.
Veja como fica a user story:
Eu como usuário, desejo poder “armazenar” um filme, de forma que eu possa ver as informações depois em um próximo dia.
A pergunta que deve ser feita diante de uma nova funcionalidade é “Esta funcionalidade irá ajudar os usuários a encontrar um filme para assistir”? Pode ser que ajude, mas não existe certeza, é importante? Pode ser, é essencial? NAO. São muitas dúvidas, então não é bom sinal.
O que fazer neste caso? Guarde a idéia, lance o sistema com a essência (O google e outros fazem isso com sabedoria) e observe o uso real, para então analisar se seus usuários realmente necessitam desta funcionalidade. Prototipe, teste sempre que possível.
É isso, mantenha o foco na essência. Você pode não fazer pesquisa com usuários e tudo o mais, mas manter um foco na essência, certamente ajudará a fazer um produto mais simples, útil, mais interessante, melhor.
Artigo de referência: agile-ucd (Agile User-Centered Design)
Aqui, quer ser minha sócia!?
Recebi este comentário abaixo:
“Eu gostaria muito de ouvir da senhora um único motivo para se abstrair algo, que está claro.”
1-Os requisitos devem e continuam sendo claros e específicos. Mas nada foi simples e nada era claro, ou era? Estamos produzindo sistemas realmente úteis e simples ao longo dos anos? Quantos porcentos das funcionalidades de um software temos realmente ultilizado? Com que facilidade e com que eficiência? Quanto trabalho já foi jogado fora por requisitos que não atendiam a necessidades reais de seus usuários? Se estava tudo muito simples e tudo muito claro, você não precisa se incomodar. Para uma melhora na forma de criar e pensar sistemas interativos é preciso repensar muitas coisas, e uma delas, é cultural, ou seja, não é cômodo e muito menos fácil.
2-Não tenho todas as respostas, na maioria das vezes tenho perguntas. O que existe nos meus posts são reflexões e conclusões a cerca do meu processo de trabalho que diz respeito a um contexto muito específico: equipe pequena, multidisciplinar de desenvolvedores e designers que acreditam que existe muito mais a ser feito e mudado na forma de se pensar e fazer design e desenvolvimento no Brasil. Temos errado e aprendido muito no processo.
3-Requisitos mudam durante o projeto, principalmente quando você envolve usuários no processo, e é natural e bom que isso aconteça.
“Era preciso “complicar” um pouco as coisas para tentar justificar o seu orçamento certo?”
Não, não é preciso complicar nada, muito pelo contrário, é preciso simplificar. Tentamos sempre levar conhecimento, ao invés de justificativas abstratas. Fazer produtos melhores, mais uteis e com mais valor, não é mais complicado , mas também não é o mais cômodo, exige um compromisso maior do profissional.
“Compreendo vossa estorinha da carochinha.”
Se você estiver mesmo interessado em aprender mais sobre agile, usabilidade agil etc, sugiro você ler alguns dos links abaixo. Já se você já é bem entendido no assunto, gostaria muito de ouvir a sua opinião, se puder ser mais educado.
http://www.agileproductdesign.com/blog/
http://www.thinkingandmaking.com/view/agile-ux-six
http://www.uxmatters.com/mt/archives/2007/06/four-factors-of-agile-ux.php
Obrigada.
Vejo como muito útil o registro das user stories como forma de manter o foco na solução desejada pelo cliente. A descrição da forma adotada por vcs (perfil de usuário, necessidade e intenção) deixa isso claro e serve como guia para o desenvolvimento.
Parabéns pelo post.
Ei Diogo,
Obrigada, acho que a intenção das users storeis é exatamente essa que você disse: manter o foco na necessidade do cliente/usuário.
você já trabalhou em ambiente ágil?
Acho interessante o uso de users stories para manter o foco do projeto, mas português ainda continua sendo um obstáculo. Se permitirmos o cliente escrever as users stories, com certeza encontraremos problemas para compriender o cliente.
Se escrevermos o que entendemos, voltamos ao problema incial do levantamento de requisitos que é entender o que o cliente deseja/necessita, pois, na maioria das vezes, o cliente não sabe dizer o que necessita.
Maximiliano, em empresas que trabalham com usabilidade aliado ao agil, normalmente as user stories são escritas em conjunto com o cliente mas também é feito uma pesquisa com usuários reais, para justamente tentar entender melhor essas necessidades. Essa pesquisa, pode ser feita em ciclos curtos e em paralelo ao desenvolvimento. Enquanto uma equipe pesquisa (existem várias técnicas de pesquisa para identificar necessidades, como entrevistas informais, observação em campo, etc) a outra equipe desenvolve um outro pedaço do sistema. E o processo é feito em paralelo.
E por isso é importante também testar, validar a solução com usuário, o processo é ciclico mesmo. Infelizmente não tem outro jeito: de acertar de primeira…
Tenho um artigo muito bom sobre a prática de agil + usabilidade, coloquei ele anexado no final deste post, aí em cima. Tudo fica bem mais claro quando você ler
Volta aí depos para discutirmos o que achou.
Espero ter ajudado.
Abs,
Olá,
Esse contato próximo com o cliente é um ponto forte. Dessa forma, a realização das user stories acaba sendo um “contrato inicial” entre a equipe e o cliente. Cada user story acaba contendo uma única fucionalidade no português mais simples possível, sem margens para dúvidas e entendida por todos.
O que acho legal no processo é o estímulo à comunicação entre a equipe e cliente/usuário, o que é esquecida em muitos projetos, além do cliente poder priorizar as user stories em agrupamentos que ele considere relevante.
Claro, Maximiliano, esse é um dos primeiros estágios de todo o processo e sabemos que requisitos mudam, mas esse tipo de artefato deixa o processo transparente para todos, além de distribuir a responsabilidade entre cliente e empresa.
Respondendo à sua pergunta Karine, gosto da filosofia das metodologias ágeis. Tive um primeiro contato com um colega de trabalho que me passou alguns fundamentos desse método. Tomei gosto na pós que curso, onde tive uma visão geral sobre essas metodologias. Embora não tenha atuado num ambiente totalmente ágil, tento utilizar algumas técnicas no meu dia-a-dia.
t+
Pois é, também nos identificamos com a “filosofia” ágil, por sermos uma equipe pequena, caiu muito bem. O que fazemos é adaptar os conceitos e princípios do ágil nos projetos incluindo usabilidade. Tem dado certo, simplificado e aproximado a equipe. Mas temos aplicado mais em projetos interno nosso (desenvolvimento de produtos próprios), então não temos a figura no cliente, só os usuários, então procuramos fazer alguma pesquisa inicial e também testar as interfaces, com testes rápidos em protótipo.
As user stories, no caso, nos ajudam a alinharmos as idéias internamente e priorizar o que desenolver, mantendo a simplicidade do sistema.
T+
Oi,
Achei bem interessante a aplicação de users stories (US), é um excelente ponto de partida para a definição do escopo da aplicação.
Conheci os processos ágeis na faculdade e achei muito interessante, porém acho difícil utilizá-lo em aplicações muito robustas ou equipes muito grandes, pois a falta de documentação pode dificultar a análise de interação entre os módulos da aplicação ou extensão de novas funcionalidades. Claro que os processos ágeis não excluem os diagramas UML, mas a maior parte das pessoas que conheço que o utilizam abrem mão deles.
Talvez também um pouco de dificuldade em definir requisitos não funcionais para a aplicação?! (o que dificultaria a análise de uma arquitetura de sistema adequada).
Cara, muito bom. Conseguiu ilustrar com eficiencia o que as User Sotries representam. Execelente o post.
Pingback: Engenheiro de Software - Artigos, Tutoriais, Livros e Dicas Atuais sobre o mundo gerenciamento de Software!
Gostei do artigo.
Acho muito importante compartilhar experiências e conhecimentos, Só assim ampliamos nossos horizontes e nos tornamos parte do mesmo universo infinito de Deus.
Parabens !