Ajuda: Levantamento de requisitos de design
Sarinha
projeto grande para a justiça federal.
O sistema está no início e integrará vários sistemas já existentes
além de utilizar serviços externos como os da Receita Federal, OAB,
correios, entre outros.
Usuários internos dos órgãos da justiça (STJ, CJF, TRFs, STF,
Procuradoria) utilizarão o sistema para muitas atividades de rotina,
mas ele também poderá ser acessado por usuários externos desde
advogados até réus diversos, de tooooodo país.
Uma das minhas atividades é desenvolver um questionário a ser
respondido por um grupo de trabalho, formado por uns 2 representantes
de cada região (temos 5 regiões) para ajudar no desenvolvimento do
layout e ter mais argumentos na apresentação do produto.
Daí o meu pedido: Alguem teria algum protocolo, documento ou estudo
baseado nesses questionários de levantamento de requisito de design,
que podem ser feitos com os usuários mais efetivos do sistema?
Obrigada!
Frederick van Amstel
Sua tarefa não é trivial como aplicar um questionário. Se você for
adicionando tudo que os interessados pedem, vai ter excesso de
funcionalidades e muitas vezes eles não usarão a maioria do que
pedirem.
Por outro lado, se você não ouví-los pode perder um requisito crucial
para eles e o sistema não serve pra nada.
A saída é negociar. Trazer as pessoas para discutir o que é realmente
importante e seus efeitos colaterais. Porém, é melhor que alguém tenha
uma visão global e mais distanciada dos processos, senão cada um vai
puxar a sardinha pro seu lado e o consenso vai ser difícil.
O mediador deve conhecer bem as atividades que serão executadas com o
sistema. Para isso, existe a análise da tarefa e análise da atividade
prévia que o mediador pode fazer:
Alguns links sobre:
http://www.faberludens.com.br/pt-br/node/206
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER01/martins.pdf
2008/11/7 Sarinha <sarinha....@gmail.com>:
.
.{ Frederick van Amstel }. Curitiba ´´ PR
¶ ...''''''''''|| www.usabilidoido.com.br
Instituto www.faberludens.com.br
.
MSN e Gtalk usabil...@gmail.com
\\...................
Gonçalo Ferraz
anexo uns documentos que podem ser estudados e adaptados pra você
utilizar durante o trabalho.
Basicão, gosto muito do Tutorial do webmonkey
@ http://www.webmonkey.com/tutorial/Information_Architecture_Tutorial
>> Daí o meu pedido: Alguem teria algum protocolo, documento ou estudo
>> baseado nesses questionários de levantamento de requisito de design,
>> que podem ser feitos com os usuários mais efetivos do sistema?
--
Gonçalo B Ferraz @ goncaloferraz.com
Interaction Design @ faberludens.com.br
+55 (48) 3338-2827 - Florianópolis, SC
. . . . . . . . . . . . . . . . . . . . . . .
Sonho que se sonha só
é só um sonho que se sonha só
Mas sonho que se sonha junto
é realidade nova-acropole.org.br
Fabrício Marchezini Cunha
incremental. Após o levantamento dos requisitos iniciais – utilizando
os métodos sugeridos pelo Fred e pelo Gonçalo –, ao invés da equipe
criar o sistema com tudo o que foi levantado, elege-se, junto aos
stakeholders, as funcionalidades mínimas, a essência, para que o
sistema já possa começar a ser usado. Divide-se o grande projeto em
entregas intermediárias, o mais curtas quanto possível.
Isso permite aos stakeholders darem feedback muito mais rápido sobre
um sistema "real", mesmo que com um mínimo de funcionalidades. Assim,
eles têm uma visão clara do que está sendo construído e, geralmente,
percebe-se que alguns requisitos definidos inicialmente estavam
equivocados. Além disso, permite envolver uma parcela menor de
stakeholders de cada vez.
A partir daí, vocês podem ir ajustando a direção do projeto,
corrigindo o que já foi feito e selecionando as funcionalidades a
serem implementadas no próximo ciclo.
Obviamente, não é qualquer contexto que permite desenvolver dessa
forma. A equipe de design tem que estar bem integrada com os
desenvolvedores, os stakeholders devem participar ativamente do
processo. Todos têm que estar preparados e serem favoráveis às
mudanças que vão acontecer durante o trajeto. Sem falar nas questões
políticas. Mas eu acredito ser a melhor forma de se fazer.
Quem já ouviu falar de métodos ágeis de desenvolvimento sabe do que eu
estou falando. Alguém na lista já teve a chance de trabalhar com UX
num projeto assim?
2008/11/7 Gonçalo Ferraz <goncal...@gmail.com>:
--
Fabrício Marchezini Cunha
Latitude14 | usabilidade + design centrado no usuário
www.latitude14.com.br
(31) 3542-9991
(31) 8865-7937
--
vCard: latitude14.com.br/fabricio.vcf
Frederick van Amstel
abordagem, muito influenciadas pela esquematização produtiva do Scrum.
O problema é que os stakeholders que eles trazem pra validar não são
autênticos representantes dos usuários, mas sim clientes,
administradores ou consultores no domínio. Aí claro que surgem
disparidades entre o que se espera que o usuário final faça e o que
ele realmente faz.
Eles dizem ser inviável realizar o ciclo iterativo com usuários
finais, pois estes:
- não estão facilmente disponíveis
- não tem o mesmo grau de comprometimento
- não compreendem o processo de desenvolvimento
- não conseguem especificar suas percepções em linguagem técnica
- não aceitam as restrições técnicas
De certa forma eles tem razão, mas não é porque o usuário não é capaz
de se encaixar na metodologia que não deve ser incluído. Minha
sugestão foi alterar a própria metodologia, para se tornar mais "user
friendly". Protótipos de papel é uma das técnicas que estou tentando
introduzir.
O problema fundamental desta metodologia (e de muitas outras) é que
separa desenvolvimento de avaliação. A avaliação acaba se tornando
apenas uma etapa burocrática, a qual deve ser ultrapassada com o
mínimo de alterações possível no projeto.
Avaliação constante (não necessariamente formal) é, a meu ver, o melhor caminho.
2008/11/8 Fabrício Marchezini Cunha <fabriciom...@gmail.com>:
--
Luciano Lobato
Estou prestando consultoria para algumas empresas que adotaram essa
abordagem, muito influenciadas pela esquematização produtiva do Scrum.
O problema é que os stakeholders que eles trazem pra validar não são
autênticos representantes dos usuários, mas sim clientes,
administradores ou consultores no domínio. Aí claro que surgem
disparidades entre o que se espera que o usuário final faça e o que
ele realmente faz.
Eu também notei isso no Scrum, em quase todos os textos que li a respeito e na prática. Tem a figura do product owner (quem decide e prioriza os requisitos), que geralmente é o cliente, e não o usuário-final. No Scrum falta esse papel, o de product user (complementando os papéis de product owner, scrum master e a equipe) Em projetos de aplicativos corporativos, isso fica bem claro quando o contratante / product owner (gerente da área ou chefe dos usuários) valida os wireframes e/ou protótipos, e logo depois quando o sistema começa a ser usado, "surge" magicamente outros itens do backlog ou até mesmo um redesign.
Isso é algo pouco falado até mesmo na área de engenharia de requisitos, mas que devia ser enfatizado em todo texto sobre agile-ux (seja lá qual método sendo usado): cliente, 99% das vezes, não é o usuário. E requisito funcional não fala nada sobre requisitos de usabilidades. Esse tipo de requisito é algo que dá pra "coletar" só através do usuário-final (observação, análise da tarefa, análise contextual, entrevista, etc.). Mas toma muito mais tempo e consequentemente, dinheiro do cliente.
[]s!
Luciano Lobato
http://www.nahipermidia.com/blog/
Fabio Caparica de Luna
Eu também notei isso no Scrum, em quase todos os textos que li a respeito e na prática. Tem a figura do product owner (quem decide e prioriza os requisitos), que geralmente é o cliente, e não o usuário-final. No Scrum falta esse papel, o de product user (complementando os papéis de product owner, scrum master e a equipe)
Hehehehe...
Eu vivo exatamente isto, tem pouco mais de 3 anos.
Minha 'intuição' é de que na verdade não há como fazer uma coisa envolvendo usuários de fato, que seja eficiente e ágil o bastante pra ser compreendida como uma metodologia ágil pela turma que trabalha com engenharia de requisitos.
Em projetos de aplicativos corporativos, isso fica bem claro quando o contratante / product owner (gerente da área ou chefe dos usuários) valida os wireframes e/ou protótipos, e logo depois quando o sistema começa a ser usado, "surge" magicamente outros itens do backlog ou até mesmo um redesign.
Isto, para mim, ficou claro já há um bom tempo:
Esta 'validação' só poderia ser feita com algum ciclo iterativo de testes de usabilidade. Quando a validação é feita em 'comitê' - o mais comum por ai - a porca torce o rabo, o nariz, etc.
E para este contexto ágil, o Paper Prototyping poderia ser o caminho para desonerar os custos de uma maneira geral.
Mas imho, não dá muito certo em dependendo do tamanho do projeto. Projetos pequenos, dá rock. Projetos grandes, dá lambada... (Ao som de Beto Barbosa, todo mundo "dançando lambada ê! dançando lambada há!")
Isso é algo pouco falado até mesmo na área de engenharia de requisitos, mas que devia ser enfatizado em todo texto sobre agile-ux (seja lá qual método sendo usado): cliente, 99% das vezes, não é o usuário.
Sim, sim...
o termo steakholder entra como uma máscara nos textos e se o leitor inadivertidamente acreditar que o steakholder é o usuário final, acaba se iludindo.
E requisito funcional não fala nada sobre requisitos de usabilidades. Esse tipo de requisito é algo que dá pra "coletar" só através do usuário-final (observação, análise da tarefa, análise contextual, entrevista, etc.). Mas toma muito mais tempo e consequentemente, dinheiro do cliente.
;-)
E, claro, para o pessoal de gerencia de projetos, tomar tempo e não ser facilmente previsível [afinal, se o processo de usabilidade também for iterativo incremental, não dá pra prever bem quando ele vai parar de 'rodar'.] em metodologia ágil é sacrilégio. Pecado capital...
[]´s
fcl
Luciano Lobato
2008/11/9 Luciano Lobato <luciano...@gmail.com>
Eu também notei isso no Scrum, em quase todos os textos que li a respeito e na prática. Tem a figura do product owner (quem decide e prioriza os requisitos), que geralmente é o cliente, e não o usuário-final. No Scrum falta esse papel, o de product user (complementando os papéis de product owner, scrum master e a equipe)
Hehehehe...
Eu vivo exatamente isto, tem pouco mais de 3 anos.
Minha 'intuição' é de que na verdade não há como fazer uma coisa envolvendo usuários de fato, que seja eficiente e ágil o bastante pra ser compreendida como uma metodologia ágil pela turma que trabalha com engenharia de requisitos.
Pois é.... A grande maioria dos métodos ágeis acabam pecando justamente nessa falta de envolvimento do usuário no processo. Não vejo como incompatibilidade com o design, até porque não tem nada que impeça esse envolvimento, somente a ênfase no product owner. Até onde eu sei, a IDEO prega justamente isso: prototipação ágil com o envolvimento dos usuários. Mas isso seria na fase do pré-game, antes do início da produção (ou seja, na fase de design). O que já pode ser encarado pela turma dos métodos ágeis como waterfall (especificações antes do desenvolvimento).
Uma alternativa é a do pré-game, pra se ter uma visão geral, e depois, enquanto a galera de desenvolvimento está concentrado nos itens do sprint x, a galera de design se concentra nos itens do sprint x+1. Isso é o que eu tenho visto o pessoal que prega esse casamento (agile + ux) pregar. Mas muitas vezes, acontece no sprint x+1, um melhor entendimento dos itens do sprint x (e consequentemente, um redesign). E aí, é retrabalho, ou mais itens no backlog de outro sprint.
E requisito funcional não fala nada sobre requisitos de usabilidades. Esse tipo de requisito é algo que dá pra "coletar" só através do usuário-final (observação, análise da tarefa, análise contextual, entrevista, etc.). Mas toma muito mais tempo e consequentemente, dinheiro do cliente.
;-)
E, claro, para o pessoal de gerencia de projetos, tomar tempo e não ser facilmente previsível [afinal, se o processo de usabilidade também for iterativo incremental, não dá pra prever bem quando ele vai parar de 'rodar'.] em metodologia ágil é sacrilégio. Pecado capital...
Isso é o que eu acho uma das coisas mais foda. Geralmente, quando a turma do pré-venda faz o orçamento, é com base nos requisitos funcionais. Depois que o número de horas já foi vendido, é que se vai entender os demais requisitos, como os de usabilidade, e consequentemente, entender realmente o que precisa ser feito. Como gerenciar isso?!
Uma alternativa a esse estilo de gestão de projetos orientado a requisitos funcionais é o que o pessoal de agile chama de aquisição progressiva (o cliente comprar pedaços da pizza, e não ela inteira). Pode ser um caminho ótimo, mas dificilmente eu vejo o cliente de software entendendo assim. E mesmo com esse estilo de contratação, não evita surpresas com surgimentos de requisitos no meio do mini-caminho...
Fabrício Marchezini Cunha
desenvolvimento ágil do Rio, eles prevêem o papel do designer de
interação:
"Designers de interação trabalham próximo aos clientes em um projeto
XP. Eles os ajudam a escrever histórias e escolher metáforas
consistentes para o projeto. Além disso, ajudam a criar a interface e
a refiná-la continuamente ao longo do tempo. Designers de interação
também avaliam o uso das funcionalidades pelos clientes à medida que
vão sendo entregues no final de cada ciclo semanal."
– http://www.improveit.com.br/xp/papeis/designers_interacao
A inclusão explícita de um membro (ou mais) no time responsável por UX
é interessante. Esse cara pode trabalhar sempre fazendo pesquisa para
o próximo sprint (entrevistas, observação, teste com protótipos de
papel) e validando o que foi feito ciclo anterior (testes de
usabilidade).
Talvez vocês já conheçam o trabalho do Jeff Patton, que fala muito
sobre isso. Gosto do artigo dele chamado 'Twelve emerging best
practices for adding UX work to Agile development'
(http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html)
2008/11/9 Fabio Caparica de Luna <capa...@gmail.com>:
--