Zoeiras a parte, percebo que vivemos realidades muito mais exigentes no que diz respeito a experiências de navegação em ambiente virtual.
Ao mesmo tempo em que a alta complexidade permeia a
construção de produtos digitais, há um movimento grade de adequação das equipes
às propostas ágeis de construção, e para este contexto onde complexo e ágil
caminham juntos, se faz necessário um olhar mais personalizado ao público
usuário.
Por esse motivo precisam ser suas necessidades, cultura e
contexto para complementar as entregas de modo a atender com sucesso a necessidade
que vem preencher o produto.
A combinação do ágil, vou me referir a partir de agora ao
Scrum, com a UX vem sendo desenhada a anos, mas no dia a dia, a aplicação ainda
está um tanto nebulosa e conflitante com formas de gerenciamento de projetos,
culturas das empresas e mesmo atuação dos papeis dentro deste contexto.
Isso porque, quando se pensa em ágil em UX e Scrum se pensa nos
processos isoladamente e não na integração dentro de um time.
Eu e alguns colegas de área (Product Owners e Scrum Masters
com anos de UX a mochila), de alguns lugares do planeta, temos conversando
muito sobre este tema e por isto resolvi dividir com vocês as impressões em
comum.
Lembrando que o que você vai ler não se trata de ponto
pacifico do tema e sim de observações empíricas da aplicação no dia a dia do
Scrum integrando profissionais UX em seu time, o que significa que você pode
ter encontrado outras saídas para os problemas identificados abaixo.
Contextualização
Talvez haja um pouco de confusão na tentativa de integração da disciplina nos times de desenvolvimento. É importante esclarecer que UX é sobre a criação de soluções. UX não é produção. Desenvolvimento é produção. São dois processos completamente diferentes projetados para saídas específicas.
A integração só poderá ser harmônica quando este entendimento
é abrangido. Muitos PO’s por não entenderem o papel do UX no projeto e por não
ter vivência ou mesmo não estarem acostumados com este perfil, tendem a tratar
o assunto com uma abordagem produtiva quando na verdade ela é pré-produção. É
criação de soluções que por contexto, devem ser entregues ao time de
desenvolvimento junto com as demais documentações da Sprint.
Entendi... Mas preciso de UX Design Por quê?
UX é a garantia de que o produto que está sendo entregue será
utilizado de forma ampla e com sucesso. Ele imprime aos fluxos a maior
possibilidade e entendimento, identificação e adesão a necessidade que foi
levantada para se criar a solução que está sendo entregue.
A menos que dentro do time de desenvolvimento tenham
simpatizantes da causa usuária, sempre serão priorizados os padrões e
ferramentas que atendam o negócio como um entregável que funcione, sem o foco
na pessoa que irá utilizar.
Por conta disto, padrões e fluxos são orientados a entregas
funcionais e não adaptadas ao “jeito” de quem vai utilizar a ferramenta. O UX
libera a equipe deste penso e garante menos frustrações e maior envolvimento da
persona com o produto.
Sentimento da equipe de
desenvolvimento.
A equipe de desenvolvimento de um time ágil está acostumada a
se envolver holisticamente no projeto (código, testes, criação de histórias, etc.)
e se o UX não costuma ouvi-los, acabam se sentindo criativamente limitados,
como se fossem apenas “caras que codam” e se desmotivam muitas vezes tirando a importância
do UX designer.
Sim, existem perfis de desenvolvedores que são focados apenas
em seguir as diretrizes das documentações fornecidas, mas isto não deve se
aplicar a um time Scrum que por padrão é integrado, curioso e multidisciplinar.
A grande questão: O time de desenvolvimento precisa apenas
aceitar os designs fornecidos pela equipe de UX?
O time deve colaborar com UX da mesma forma que colabora com
o P.O ajudando a identificar problemas e desafios técnicos, lacunas nos
requisitos e recomendando bibliotecas de componentes que possam ser aproveitadas.
Mundo ideal: se possível, desenvolvedores participando de
pesquisas, para ouvir a necessidade dos usuários e conversar com a UX sobre
como implementar as soluções sob um ponto de vista mais técnico, ajudado a
propor soluções alinhadas com as limitações de construção do produto.
Dedicar um tempo para entender e acreditar no produto pode
ser muito motivador para os desenvolvedores, pois podem ajudar a identificar os
pontos cegos e as oportunidades que a equipe de UX e PO pode ser negligenciada,
se sentindo cada vez mais integrados e parte do time.
Sentimento do UX
A equipe de UX geralmente tem alguns problemas quando o time
de desenvolvimento começa a discutir os projetos, pois muitas vezes acreditam
que devem se concentrar apenas no desenvolvimento e deixar para eles (a equipe
de UX) que são os especialistas em design, a criação da experiência do usuário.
Outro ponto bastante desmotivador é quando o time de desenvolvimento,
PO e Scrum Master tem um entendimento equivocado do UX onde acreditam que
apenas criam telas bonitas quando na verdade, sua contribuição é um processo de
desenho do projeto como um todo o que impactará significativamente o sucesso do
produto que será entregue.
Belê, mas como fazê-lo no Scrum?
Por sua proposta ágil é imprescindível o entrosamento da
equipe e uma certa criatividade do UX designer para incorporar e adequar suas
expertises. É necessário aplicar o aspecto adaptativo, colaborativo do UX tanto
no contexto do produto a ser desenvolvido quanto à comunicação com a equipe.
Resumindo a ópera: A mesma empatia que temos com o usuário
quando identificamos a solução para o problema, devemos utilizar para
solucionar os problemas internos de entendimento de proposta de design do
projeto.
Se você é um UX que acabou de sair da faculdade louco para
aplicar tudo o que aprendeu ou leu aqui no blog e caiu direto num time de Scrum....
Muita calma neste momento.
Não dá para introduzir as cadeiras aprendidas na faculdade e
nem as rotinas de uma equipe de UX ao pé da letra, dentro de um contexto de Sprints,
time boxes e time de desenvolvimento multi-perfis. Aproveite o momento para
evoluir alguns outros aspectos da profissão como adaptabilidade e criatividade pois
vai ser fundamental este treino para gerar um resultado eficiente sem
frustrações.
Pensar no futuro
Nas conversas que tive com os colegas (vale lembrar que
Nielsen também observou este comportamento em seu estudo de caso) fomos
unanimes no entendimento de que, assim como o P.O deve estar sempre à frente do
time no entendimento do backlog e na criação das US’s, o UX designer também
deve trabalhar "no futuro" construindo as experiências paralelamente
a construção do entendimento da história junto aos stakeholders.
Se há documentos gerados para entregar ao time na planning, o
UX deve compor estes documentos juntamente com o P.O (quer seja descritivos,
wireframes ou protótipos).
Nesse modelo executado empiricamente, acreditamos ser mais e
assertiva a construção das ideias que já vem amparadas pelo contexto da
experiência do usuário e quando as histórias chegarem ao time de
desenvolvimento, já terão sido validadas em nível de UX e a construção das US's
será mais objetiva, tanto para o time quanto para os envolvidos.
Tá mas... Qual o papel da UX no time?
O mesmo papel dos demais membros do time, entregar as Sprints
com todos os critérios de aceitação compreendidos. Temos que parar de
mistificar a entidade UX e trata-la como tratamos o desenvolvedor, o designer e
o testador e o PO. Todos fazem parte da equipe e entregam o mesmo produto.
E vale também, o UX se fazer integrar com o time, sendo
parte, conversando e entendendo os pontos de vista de todos, dentro das Sprints
e cerimonias.
Tá, mas e quando o UX tem que desenhar o layout também?
Mundo ideal? Design no futuro também. Não rolou, pois sobrecarregou
o UX com as análises de backlog, deixando ele sem tempo de desenhar para a planning?
Volta para o time, veste o chapéu de UI que te pertence neste momento e faz a
mágica acontecer!
O Product Owner (PO)
com a última palavra
Em alguns casos, quando a demanda UX pode impactar
diretamente a entrega da Sprint, o PO decide se será absorvida ou descartada. Quando
a decisão é entre uma proposta UX e alguma solução o time de desenvolvimento, não
importa o que decida, alguém ficará frustrado.
Tá, mas... O PO deve mandar na UX?
Não vamos confundir P.O com ditador. Na ótica do Scrum, somente
se UX impactar diretamente no aceite da história em que está envolvido, o PO
vai ter que tomar uma decisão sobre o assunto.
Se houver uma necessidade comercial que conflite com a
necessidade do usuário e o time não conseguir integrar uma solução que maximize
a experiência do usuário e atenda necessidades do negócio do cliente, o PO terá
a palavra final, pois é responsável por um produto bem-sucedido.
Dica para a vida: Quanto mais o PO estiver ciente da
necessidade do usuário, mais significativa a condução será neste sentido.
Algumas pessoas que conheço, como eu, migraram para PO com essa expertise para
equilibrar essa demanda necessária para o sucesso do produto.
Havendo oportunidade, promovam dentro de suas equipes
pequenos bate papos sobre a importância do usuário ser acolhido dentro da
proposta de desenvolvimento ágil pois além de contribuir para o entendimento do
UX ainda irá gerar um importante vínculo entre o time.
Radicalismo na
utilização do Scrum
Muitas vezes por falta de experiência ou de esquecimento do
empirismo que permeia todo o framework, sua aplicação é levada ao pé da letra
como se o Scrum guide um passo a passo a ser seguido ao pé da letra.
Esse tipo de movimento acaba trazendo frustração pois tudo o
que sair do “escopo” será considerado como uma prática errada e muitas vezes
não sobrará espaço para a adaptação de algumas tarefas, incluído UX, dentro das
cerimônias e time-boxes.
Tenha sempre em mente que o movimento ágil é bem claro quando
diz que processos não substituem as habilidades de um time de desenvolvimento,
dessa forma o papel de um processo é dar suporte ao time de no seu trabalho e
não ditar regras de trabalho.
Alinhamento da equipe
através das cerimonias
Esse último ponto vale para todos os envolvidos e devemos
sempre levar em consideração em se tratado de uma proposta ágil: Pessoas de
expertises diferentes, interagindo em níveis diferentes de expectativa,
conhecimento, cultura e formação podem tornar o processo de desenvolvimento
cansativo e frustrante se não houver sinergia, por isso, as cerimonias devem
ser respeitadas e aproveitadas para atualizar o status de cada um dentro da Sprint
e integrar a todos.
Espero ter contribuído para essa união fantástica acontecer
aí no seu local de trabalho também. Se tiver alguma coisa que faz e que é
diferente do que propus, por favor compartilha com a gente aí embaixo para que
juntos possamos criar uma forma bacana e eficiente de integrar UX e Scrum em
nosso dia a dia.
Até mais!
Compartilhar
UX e Scrum de boas é possível, sim!
4/
5
Oleh
Iris
