Organização de demandas em um time de UX
Escalabilidade e agilidade de forma leve.
Que atire a primeira pedra quem nunca abriu uma demanda (no Jira, Trello, Monday…) e pensou “Depois eu escrevo a descrição”… Mas depois nunca mais escreveu e isso começou a se tornar um hábito. Ou então, nunca houve o hábito em si, e acaba com um ciclo quase que: Abre a demanda > coloca um título “explicativo” > vai tocando a demanda > ninguém sabe o que aconteceu ali > provável caos.
Quando cheguei aqui no time de UX da Senior, as nossas tasks eram pouquíssimo descritas ou nem tinham descrição, geralmente quem abria, já atuava na demanda. Funcionava. Até o momento em que começamos a ver issues de pessoas que já saíram da empresa e surgiram muitas dúvidas do que foi feito, do que precisava fazer, qual era a definição de pronto, qual era a prioridade…
Ah, a prioridade. Esse era outro ponto que estava começando a acender a luzinha vermelha. Como atendemos vários produtos, cada um deles tem a sua prioridade interna de demandas, e isso poderia gargalar dentro do nosso time, uma vez que começavam a chegar muitas tasks com “alta prioridade”.
“Se tudo é importante, nada é importante.”
No exemplo acima já podemos notar alguns pontos como:
1- título diz pouco sobre a issue em si e é confuso;
2- não há descrição (só um vínculo com a issue do time externo), o que dificulta muito o entendimento por parte de outra pessoa, que não seja a que abriu a demanda;
3- já está com assign, mesmo estando em backlog, o que pode fazer com que ninguém além do assignee mexa na task;
4- não há comentários que mostrem processo, fazendo com que não haja documentação e acompanhamento;
5- não há Definition of Done.
Vendo esse problema surgir (e sendo uma pessoa relativamente metódica), conversei com o time sobre tentarmos ter um alinhamento e roteiro para as demandas, pensando principalmente na escalabilidade e facilidade de qualquer pessoa poder tocar qualquer demanda. A equipe topou o desafio e lá fui eu para o famoso benchmarking.
No grupo do Slack do IxDA Brasil consegui trocar ideias sobre como eram os processos e priorização em outras empresas, onde fui tendo um panorama de como nós, UX, podemos atuar juntamente com outras equipes e fazer tudo fluir de maneira mais natural e com menos gargalos.
Tive a ideia de falar com a equipe de marketing da Aurum, empresa que atuei anteriormente, pois lembrei que havia um problema parecido e conseguimos contornar e deixar nosso processo entendível e escalável. Após uma conversa com eles sobre como esse processo foi evoluído, saí com mil ideias na cabeça e uma luz do que fazer.
Voltando à Senior, hora de pôr a mão na massa. Fiz um compilado do nosso fluxo interno e do roteiro de tasks da Aurum e então realizei um cruzamento do que podia ser utilizado.
Temos duas frentes principais: Design Ops e Product Design. Os fluxos eram parecidos, mas o contexto deles era diferente, então a partir disso, resolvi fazer dois roteiros de descrição de tasks.
Além de termos uma descrição completa, queríamos demonstrar o nosso processo bem como o seu valor para outras pessoas, tais como Devs, POs e Analistas.
Colocando o roteiro à prova
Depois dessa estrutura escrita e apresentada ao time de UX, foi o momento de colocá-la em prática. Pedi para o time usar o roteiro em todas as issues que fossem criadas a partir do dia da apresentação e que fizéssemos isso por um mês inteiro.
Também pedi que seguissem uma ideia meio “design critique” e escrevessem as ideias de melhoria em post-its, que seriam revisitados na reunião de checkpoint. Caso alguém tivesse alguma dúvida de preenchimento do roteiro, poderia me chamar assim que a dúvida surgisse.
Ao fim do mês fiz um levantamento do total de issues criadas e quantas delas seguiam o roteiro definido, então chamei o time para conversar e ver como foi a experiência.
Foram criadas 53 demandas no período, sendo 31 de Design Ops e 22 de Produto. 3 tasks de Produto não seguiam o roteiro (mas estavam vinculadas a um épico que seguia). E 28 de Design Ops não seguiam, foi aí que percebi que precisaria mudar algo no processo.
O feedback das pessoas que lidavam com produto foi super positivo. Conseguimos perceber que o processo se tornava mais escalável e acessível, conseguimos ter uma visão mais estratégica de cada demanda e com isso também tínhamos um panorama geral do negócio. Com as perguntas os próprios stakeholders começavam a se questionar sobre o valor da demanda e o porquê de colocar esforço naquilo, naquele momento.
O que mais gerou valor para nós como time foi que, com o roteiro sendo preenchido em parceria com POs ou Analistas, eles conseguiram entender melhor nosso processo e gerou uma empatia maior tanto por parte deles, quanto da nossa, uma vez que também conseguimos ter uma visão melhor da dor de cada um deles e consequentemente conseguimos afinar melhor as entregas.
Já na parte de Design Ops, precisamos ajustar algumas coisas… Principalmente em questão de fluxo de como as demandas chegam até nosso time e, em conversa, decidimos que esse roteiro seria disponibilizado como layout para que as pessoas externas ao time já possam abrir as tasks com o nosso padrão.
Próximos passos
Uma vez validado internamente, vamos começar a abrir esse roteiro e torná-lo um template, para que outras pessoas possam usá-lo para abrir tasks diretamente para nosso time de UX e com isso, trazer uma agilidade maior.
Também continuaremos com checkpoints mensais, para que possamos balizar o processo caso algo não esteja andando muito bem. Afinal, nenhum processo é escrito em pedra e diálogo e flexibilidade, nesses casos, são rei e rainha. 😊
Tá, e o roteiro?
Product Design
Nossa definição das demandas de produto é: Demandas que venham de verticais, sejam elas de produto em si ou de verticais administrativas, rh, marketing, etc. São demandas consideradas externas, então também necessitam de informações sobre pontos de contatos externos, caso outro designer pegue essa demanda, saiba a quem recorrer para ter informações, validar, etc.
- Título de issue (Se possível trazer o problema de forma bem resumida, senão, trazer o módulo ou feature)
- Qual é o problema? (Descrição do problema que nos foi entregue, feature, módulo…)
- Por que escolhemos colocar esforço nisso? (Veio de suporte? Quebrou algo? Faz parte de OKR de time? Pedido de cliente?)
- Para quem é a entrega? (Qual time?)
- Quem é o ponto de contato?
- Qual o objetivo? (Descrever o que se espera como sucesso da demanda, também pode ser considerado como o definition of done)
- Qual o impacto se atrasar?
- Quais as restrições e dúvidas? (Devem ser sanados antes da execução, mas devem ser mapeados e também mostrar como foram contornados)
- Quais são as etapas? (Descrição do que se planeja fazer, pode ser alterado conforme necessidade, mas serve como histórico)
- Como vamos medir se o objetivo foi alcançado? (Métricas, acompanhamentos…)
Design Ops
Nossa definição de demandas de Design Ops é: Demandas que venham de verticais ou internamente, mas que digam respeito ao Design System ou a processos do time. São demandas consideradas internas, mas mesmo assim exigem o mesmo cuidado e carinho na hora de descrever. ❤
- Título de issue (Se possível trazer o problema de forma bem resumida, senão, trazer o componente ou processo)
- Qual é o problema? (Componente de sds, documentação, processo interno)
- Quem reportou?
- Por que escolhemos colocar esforço nisso?
- Qual o objetivo? (Descrever o que se espera como sucesso da demanda, também pode ser considerado como o definition of done)
- Qual o impacto se atrasar?
- Quais as restrições e dúvidas? (Devem ser sanados antes da execução, mas devem ser mapeados e também mostrar como foram contornados)
- Quais são as etapas? (Descrição do que se planeja fazer, pode ser alterado conforme necessidade, mas serve como histórico)
- Como vamos medir se o objetivo foi alcançado? (Métricas se possível, acompanhamentos…)
Nossas demandas em backlog não têm assignee (dono). O Assignee é definido assim que a task for movida para ToDo, para evitar o sentimento de “essa task já tem dono, não vou mexer se essa pessoa não falar nada”, o que acabava acontecendo às vezes e as demandas acabavam gargalando, pois o designer que estava com assign estava sobrecarregado, mas não sinalizava para designers que possivelmente estavam mais “tranquilos”.
Nossas demandas também devem ter comentados os passos que foram feitos e os arquivos gerados, para termos uma documentação concisa do processo, caso precise ser revisitado ou retomado por outro designer.
E você? Como seu time faz essa gestão de demanda? Conta pra gente 😄
