20 de mai. de 2018

UX e Scrum de boas é possível, sim!




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

Postagens Relacionadas

UX e Scrum de boas é possível, sim!
4/ 5
Oleh

Assine via e-mail

Adicionar o seu endereço de e-mail para subscrever .

Página inicial