Get best of the week

5 regras para integrar o UX no Agile e Scrum

Uma tradução do artigo foi preparada antes do lançamento do gerente de projeto ágil no curso de TI .



Quando eu estava apenas começando minha carreira, o software veio em caixas. Se isso lhe soa estranho, saiba que quando eu era criança, meu pai trouxe para casa cartões perfurados nos quais os programas foram gravados na década de 1970. Esse software tinha um estado final. Depois de 20 anos a partir desse momento, já parecia ridículo. Hoje estamos criando sistemas que podem ser aprimorados infinitamente. Isso levanta a questão: "Quando o trabalho termina?" - e esta pergunta é difícil de responder. Estamos procurando a resposta para essa pergunta, pois ela nos ajudará a responder a outras perguntas ainda mais importantes. A equipe receberá seu prêmio ou o reportará? A equipe fará algo novo? A parte interessada se beneficiará?

As equipes de desenvolvimento que usam Scrum (ou qualquer outra variação da metodologia Agile) têm uma ideia clara de quando o desenvolvimento termina. Geralmente, isso significa "um conjunto de critérios mínimos que um produto / serviço deve ter para atender às necessidades da empresa". Como resultado, ele se resume a uma lista de funções, que é aprovada pela parte interessada (ou pelo proprietário do produto) e no momento da conclusão do projeto deve ser totalmente implementada. Os desenvolvedores chamam de "funciona como pretendido".

Mas "trabalhar como pretendido" significa apenas que o software faz o que quer dele. Infelizmente, às vezes isso não é suficiente. De fato, este é apenas o começo de uma conversa que mantemos continuamente com nossos usuários e clientes. É a melhoria contínua de nossos sistemas para proporcionar uma melhor experiência que lhes dá valor real.

Então, como podemos definir "desligamento" para uma equipe? Quando uma equipe inicia um novo projeto? A falta de ROI é um bom ponto de partida, mas como sabemos que não há retorno? A resposta será dada a nós pelos clientes. Nós olhamos para o comportamento deles. Ouvimos suas necessidades, avaliamos se nossos sistemas atendem a essas necessidades e pensamos o que podemos fazer para atender a essas necessidades em constante mudança. Chamamos essas métricas de resultados.

E esses resultados não podem ser previstos, assim como é impossível prever o comportamento humano. Bons resultados exigem que os membros da equipe se envolvam ativamente com os clientes, a fim de detectar mudanças em seu comportamento, os motivos de sua ocorrência e oportunidades para melhor atender às necessidades dos clientes no futuro. A boa notícia é que a sua empresa provavelmente já emprega pessoas que são especialmente boas nesses aspectos - designers. Apesar de hoje os designers estarem presentes em quase todas as empresas, a maioria deles não ocupa posições altas o suficiente para influenciar a adoção de grandes decisões. De fato, muitos deles são deixados de fora para os processos de desenvolvimento Agile, adaptados para programadores e gerentes de produto.

A integração de designers no processo de desenvolvimento Agile é um problema constante para muitas organizações. Graças a quase 20 anos de experiência no design, gerenciamento e consultoria de equipes de produtos, identifiquei as 5 regras a seguir que uma equipe deve seguir para garantir que a experiência do usuário (UX) seja integrada com êxito em seu processo Agile:

1. Um designer separado para cada equipes

Não há compromisso. Sem o designer "próprio" na equipe Scrum, você simplesmente tem uma equipe de desenvolvimento, que sem um designer não pode fornecer o nível apropriado de qualidade da experiência do usuário.

2. Horas de trabalho em equipe com clientes

Esta regra aprendi com Jared Spoolque realizaram um estudo comprovando que as equipes que passam pelo menos 2 horas-homem a cada 6 semanas se comunicam com os clientes (por exemplo, recebendo chamadas de suporte, conversando com usuários, observando pessoas etc.) estão desenvolvendo mais bem-sucedidas produtos.

3. O trabalho do designer é o primeiro ponto da lista de

pendências: Resumidamente: mantenha uma única lista de pendências. Desenvolvimento, controle de qualidade, design, trabalho de pesquisa - tudo isso deve estar em uma lista de pendências, priorizada por toda a equipe que realiza esse trabalho. Assim que o trabalho for dividido em dois registros em atraso, a equipe escolherá um deles e decidirá tratá-lo como o “principal”, e o segundo simplesmente o colocará na caixa posterior.

4. Resultados como filtros de priorização para backlog

que escrevi muito sobre os resultados (e Josh Seyden escreveu um livro inteiro sobre isso ), mas a única coisa que quero observar no contexto do tópico de hoje é que cada item da lista de pendências deve passar pelo filtro de objetivos finais da equipe. Pergunte a si mesmo: “Esse trabalho ajudará a atingir a meta?” Se a resposta for não, abandone este item.

5. Treinamento multifuncional

A experiência e o design do usuário têm muitas coisas interessantes que valem a pena explorar. Tais eventos podem ser conduzidos por designers (ou analistas), mas devem ser praticados e assistidos por toda a equipe. Quanto mais uma equipe pode aprender juntos, menos tempo leva para compartilhar o conhecimento adquirido e mais para decidir onde aplicá-lo (que é um assunto de conversa mais produtivo para a equipe).

A natureza retrospectiva iterativa do Scrum é bem adequada para atividades de design e UX. A integração das informações do cliente no processo de trabalho vem diretamente do Agile Manifesto (trabalho com clientes, etc.). UX e design nos aproximam do objetivo ágil de foco no cliente e maior satisfação do cliente. Siga estas 5 regras para combinar design e desenvolvimento ágil.


.

More articles:


All Articles