Como priorizar backlog de time ágil sendo UX e PM ao mesmo tempo

Sabemos que as habilidades e o escopo de um UX Designer é dedicar-se a experiência do usuário. Já, a de um Product Manager é a de satisfazer a visão de negócio pensando, principalmente, no retorno financeiro. Essas duas linhas de pensamento que divergem, na verdade devem convergir para o mesmo ponto, quando apenas uma pessoa assume ambos os papéis, tão fundamentais em um time ágil. Além desses desafios, tem-se os interesses do time de desenvolvimento que por naturalidade é voltado à tecnologia. Como equilibrar e entregar valor nesses três pilares — Tecnologia, Usuários e Negócios — é o que será compartilhado neste artigo.

Em março do ano passado (2017), eu assumi a cadeira de UX Senior na Involves, no recém formado time de Produto (Involves é uma empresa que desenvolve o produto Agile Promoter, voltado para o Trade Marketing). Ao passar 1 mês de trabalho, me propuseram ser Product Manager de um time de desenvolvimento que seria focado em Experiência do Usuário, ou seja, um time de desenvolvedores com especialidade em Front-end. Eu fiquei primeiramente muito honrada e feliz em saber que uma empresa de tecnologia estava dedicando 20% do time de desenvolvimento para ser especialista em experiência do usuário. Isso com certeza é uma inovação na área de tecnologia, pois sempre vemos apenas o time de UX com esse pensamento, já um time inteiro de dev voltado para isso é muito inusitado e inovador.

Com certeza eu assumi mais este papel no meu currículo profissional e é por meio desta experiência que gostaria de compartilhar aprendizados, felicidades e descontentamentos aqui para vocês.

Ao iniciar o primeiro quarter com o time, eu vislumbrava exatamente um time voltado ao Design, onde todas as nossas “loucuragens” seriam desenvolvidas e isso me fazia estar a mil.

Ao iniciar no time, nós designers estávamos desenvolvendo o projeto de “Design System” da nova UI, responsável pela componentização do novo Agile Promoter. Esta componentização facilitaria o desenvolvimento do produto bem como de protótipos. Assim, os times não necessitariam de um especialista front-end. Tudo estava indo tão bem quando comecei a me deparar com a quantidade de issues de manutenção que o meu time possuía em backlog. Sim, além de sermos o time de inovação da interface, ainda tínhamos o escopo de todas as telas atuais do produto. Como ele é um produto de legado e era a primeira vez que um time de UX estava "botando a mão" nele, tinham alguns problemas de usabilidade e bugs de interface.

Neste momento percebi que não deveria focar somente na visão de UX, pois o cliente também demandava minha atenção como PM, negociando prazos e atuando em urgências. Além do mais, havia a preocupação do time de que em breve a tecnologia usada no Agile iria entrar em depreciação. Neste momento, me vi tendo que assumir as duas linhas de pensamento: experiência do usuário (UX) e visão de negócio para o retorno financeiro (PM). (Quando na minha cabecinha de UX eu iria levar em conta, correção de bugs críticos ao invés de uma tela com uma usabilidade perfeita?) Foi assim que me vi, tendo que decidir entre algo que sempre "lutei" por algo novo para mim. Ou seja, como equilibrar e entregar valor nesses três pilares — Tecnologia, Negócio e Usuários.

Método 1 — Colocando os pés no chão.

Comecei pelo mais óbvio, levantei todos os tickets abertos que eram relacionados ao meu time e comecei a planejá-los. Desta maneira, eu já tinha participado de algumas Sprints e possuía o valor do Lead Time do time, o que poderia me ajudar a planejar as próximas e o que seria entregue. Sim, ainda estava meio às escuras e em maio de 2017, já tinham issues planejadas para janeiro de 2018. Cenário que não me ofereceu muitas opções, a não ser dar vazão para as issues e entrar em contato com os clientes, os quais estavam esperando há muito tempo sem nenhum retorno.

Depois desse trabalho árduo, imaginei que tinha resolvido tudo. Que belo engano! O time continuou a receber chamados, ainda referentes à base legada e o backlog aumentava a cada Sprint. Então, consultava na minha planilha em quais das próximas 20 Sprints que já tinha mapeado, a issue iria se encaixar. O que me deixou tranquilizada para atribuir um prazo ao cliente, foram as datas de atualização do sistema programadas, que tinham por regra serem liberadas a cada bimestre. Na época, havíamos definido no nosso time, as entregas de melhorias e bugs não críticos nas Majors e apenas hot fixes em Minors, então ficava mais fácil dar um prazo, pois se não entrasse nessa Major, com certeza seria na próxima, daqui a dois meses.

Bom, esse problema aparentemente estava sendo resolvido. Todos os itens de backlog estavam mapeados e, a partir disso, poderíamos entender o que seria entregue em relação à inovação. A expectativa pra inovar era altíssima, porém conhecendo o cenário e as dores envolvidas, sabíamos que as demandas não iriam ser entregues, como por exemplo o projeto do Design System.:'(

Método 2 — Evangelizando o processo de UX.

Como estávamos iniciando o time de UX na Involves, ainda não tínhamos um processo bem definido. Foi quando começamos a desenhar um modelo de especificação, o qual faria parte do novo processo de desenvolvimento de produto, incluindo a etapa do PM, UX, QA, DEV, Documentação, Treinamentos, etc. Como eu era PM de um time, essa barreira que sofri em experiências anteriores, de fazer rodar o processo de UX numa empresa que não tem essa cultura foi bem menor, pois eu era a UX e a PM ao mesmo tempo, então consegui facilmente inputar esse processo no time e testá-lo. O desenvolvimento de novas features que meu time iria assumir já fazia parte desde o início da concepção, portanto, quando a história chegava para desenvolvimento, já possuíam conhecimento do que se tratava , diminuindo assim o retrabalho, a falta de entendimento dos requisitos e, principalmente, das regras de negócio.

Método 3 — Definindo OKRs coerentes.

Como nem tudo são flores e os times ainda não tinham Designers dedicados, os demais Designers também entregavam artefatos para o meu time desenvolver. Dessa forma, acabei tendo que enfrentar o meu maior desafio em 2017: a visão do Gestor de Produto era uma, a visão do UX responsável pela feature era outra, a do meu time era completamente outra e eu ali no meio tendo que balancear novamente os três pilares — Tecnologia, Negócio e Usuários.

Meu time já havia se familiarizado com o tipo de especificação que eu estava entregando e, como eles haviam participado desde o início, esta estava sendo entregue completa e com poucas falhas. Porém, foi a primeira vez que receberam uma especificação de outro Designer e este ainda não estava alinhado no processo ao qual estávamos desenhando como teste dentro do time. Assim o time acabou "não aceitando" aquela especificação, pois para eles, faltava ser finalizada. Já na visão do Designer, ela estava completa e pronta. O Gestor estava confiante e tinha certeza de que isso iria agregar valor ao cliente final. Essa especificação tratava especialmente do OKR do nosso time.

Eu me vi numa situação em que não poderia entregar algo com pouca confiança para o time sabendo que eles não conseguiriam ter a visão do todo e o prazo que eles iriam me dar, com certeza seria falho. Nisso eu tive que assumir novamente a postura de PM e deixar a de UX um pouco de lado, mesmo sabendo que naquela especificação estava um projeto mais conceitual de uma nova feature e seria algo super inovador e encantador para o usuário. Tive que me por no lugar do time e compreender melhor as dores deles para então entender o que eu poderia adequar àquela especificação para que ficasse coerente ao Designer que a tinha iniciado, ao Gestor de Produto e ao meu time. Assim ,após algumas rodadas de iterações com o time, o designer e o gestor, conseguimos mapear uma versão menor e viável da feature, que ainda assim agregaria valor ao usuário, ao negócio e à tecnologia.

Dessa forma podemos contar que hoje, após algumas rodadas de testes de processo de UX dentro do processo de desenvolvimento do Produto, nosso time ficou apto para atuar mais próximo ao PM e ao UX num projeto de definição de uma nova feature, embasando e disseminando ainda mais o processo de UX para os demais times da empresa.

Agora que começamos a rodar um processo de UX equilibrado e dando vazão às issues de manutenção, podíamos dar atenção ao Roadmap do produto. No entanto como faríamos para priorizá-lo, visto todos os problemas que levantei anteriormente e ainda assim, entregar valor ao cliente?

Método 4 — Priorização baseado no RICE

Na época estávamos estudando o método RICE, divulgado pela Intercom. Entendemos que para a Involves precisaríamos de mais variáveis naquele método, para aí sim termos uma melhor posição do que seria uma prioridade que atendesse os pilares — tecnologia, negócios e clientes.

Assim, desenhamos nossa tabela de priorização, onde ainda conseguíamos medir a Audiência, Impacto, Esforço e Confiança das informações. Essa tabela foi desenhada entre todos os PMs e também os Designers, para conseguirmos ter as duas visões convergindo para o mesmo lugar. Nesses pilares usamos regras baseadas no nosso contexto, por exemplo: dentro de Audiência, colocamos "percentual de clientes que utilizam atualmente ou potencialmente utilizariam"; em Impacto, usamos valores como Suporte, Inovação, Experiência e fator "Uau"; em Esforço, usamos quantas pessoas por semana seriam dedicadas para as demandas: PM, Designer, Dev e pessoas de outras áreas. Confiança, nada mais é do que a porcentagem de confiança à qual temos dessas informações levantadas. Se uma demanda estiver num estágio embrionário, o grau de confiança das informações será bem inferior, já uma demanda que já passou por um processo de Discovery, com certeza terá um grau de confiança bem maior. Assim, começamos a utilizá-la, de maneira que nosso Roadmap conseguisse responder à motivação do que estávamos priorizando.

Posteriormente surgiu também uma necessidade de criarmos regras para priorização, não apenas de inovações e melhorias, mas também das nossas issues de manutenção. Dessa forma, nosso CTO e o time de Information Aquisition, começaram alguns estudos relacionados ao método GUT — Gravidade, Urgência e Tendência e construíram uma evolução desse método unificado com o nosso método de priorização baseado no RICE, mas isso é conteúdo para um próximo artigo, né Gabriel Menezes?! hehehe. ;)

Me diz aí, você já esteve em uma posição em que teve que tomar uma decisão dentre duas paixões? Conta aí pra gente!!!

— —

Agradecimentos à minha equipe ExD: Paulo Martins, Daniel Kuroski, Gabriel Werlich, Igor Carneiro e Jorge Maronezzi) e aos demais UX Designers: Augusto Sobieski e Eric Martins.