Existe um tipo de projeto que assusta qualquer time de produto antes mesmo de começar: aquele que já falhou uma vez. Foi exatamente esse o cenário que encontrei quando assumi, ao lado de mais dois colegas de UX, o desafio de destravar a Venda Regionalizada em uma das maiores varejistas do Brasil. A ideia por trás da iniciativa era simples. A execução, nem um pouco.
O problema por trás da ideia simples
A empresa vende online e entrega em todo o território nacional. Para dar conta disso, ela tinha Centros de Distribuição (CDs) espalhados em pontos estratégicos do país. Só que, na prática, quase tudo passava por um único CD, localizado no Sudeste, onde a malha logística e o fluxo de pedidos eram maiores. Os CDs regionais existiam, mas o sistema não era robusto o suficiente para identificar a localização do cliente e sugerir os produtos que estavam fisicamente mais perto dele, nem para encontrar transportadoras locais que dessem conta das entregas.
O resultado disso era estoque represado nos CDs regionais, sortimento prejudicado nos canais online e físico, prazos de entrega mais longos, frete mais caro e uma competitividade cada vez mais comprometida. A solução parecia óbvia no papel: identificar o cliente, mostrar o catálogo do CD mais próximo, e assim reduzir tempo de espera e custo de frete. O problema é que a primeira tentativa de resolver isso, lá em 2020, tinha acabado em rollback.
Por que a primeira tentativa não vingou
Quando peguei esse desafio, veio junto a preocupação dos gestores com esse histórico de falha e com a complexidade de fazer dezenas de squads diferentes se comunicarem, se alinharem e trabalharem juntas. E foi justamente aí que encontramos o principal motivo do fracasso anterior: o processo tinha sido desenhado direto a partir da arquitetura do sistema, não a partir da jornada do usuário.
Para quem trabalha com UX, isso é o básico do básico. Afinal, é o usuário quem mais sente o impacto de qualquer mudança. Mas para um time de engenharia, cuja atuação é fundamentalmente sistêmica, esse não é o ponto de partida natural. Não vejo isso como um erro dos engenheiros da época, e sim como um lembrete de algo que considero importante: qualquer área que atue em produto precisa entender, ainda que minimamente, como pensa quem trabalha com experiência do usuário. Além da arquitetura desalinhada com a jornada, havia fóruns de discussão isolados e enviesados, e uma complexidade que cruzava tanto a jornada do cliente quanto a jornada de trabalho dos próprios times envolvidos.
Um novo ponto de partida: a jornada antes da arquitetura
Assumi essa segunda tentativa em julho de 2023, ao lado de Nanci Hokino e Anderson Venancio. Dividimos as frentes igualmente entre nós três, cada um trazendo um olhar diferente para o mesmo problema. Antes de propor qualquer solução, respeitamos o que já existia. Até nas falhas há aprendizado, principalmente em produto.
Começamos pelo mapeamento da jornada do usuário. Entendemos o fluxo completo, desde o desejo de compra até o produto de fato chegar às mãos do cliente, sentando com calma para detalhar cada etapa e cada instância possível. Foi a partir dessa imersão nos contextos e cenários que o trabalho real começou: identificar, em cada etapa da jornada, quais squads atuavam ali. Uma mesma squad podia aparecer em mais de um ponto da jornada, ou dividir a atuação com outra squad no mesmo ponto.
Esse mapeamento de squads não foi um trabalho solitário. Os gestores apoiaram diretamente para reforçar, junto a cada time, a importância do projeto, e cada squad também indicava outras squads com atuação próxima. No fim, reunimos mais de vinte squads e alinhamos com todas o propósito da iniciativa. Em troca, cada uma já começava a desenhar seu plano de ação de acordo com sua própria expertise, identificando gaps, interdependências e problemas que poderiam afetar outras frentes.
Construindo a ponte entre mais de vinte squads
Com o direcionamento definido, os alinhamentos semanais viraram rotina fixa, sem exceção. O gerente de projeto (GPM) liderava esse acompanhamento, e cada squad expunha os avanços da semana e os problemas que iam surgindo. Com o tempo, as próprias squads passaram a chamar outras squads que precisavam ser envolvidas, sem esperar que isso partisse de nós.
Imagem: sessão de alinhamento entre squads
Em paralelo, criamos um documento público, aberto para toda a empresa, com o mapeamento detalhado da jornada em um formato de diagrama de fluxo com notação BPMN simplificada (a mesma técnica usada para desenhar processos de negócio, mas simplificada para dar conta da complexidade multilinear da jornada). Nele registramos toda a jornada, junto dos status possíveis do usuário em cada ponto, como logado, deslogado, com CEP cadastrado ou sem CEP cadastrado. Esse desenho fez diferença porque permitiu que qualquer squad se localizasse rapidamente e entendesse onde a própria atuação começava e terminava.
O volume de cenários possíveis era grande, então organizamos tudo em cinco macrofluxos: Home, Busca, Página do Produto, Carrinho e Shipping. Cada um deles trazia a visão tanto da área logada quanto da não logada, e cada cenário dentro desses macrofluxos era sinalizado por status, mostrando o que já estava mapeado, o que ainda não tinha sido mapeado e o que estava pendente de definição. Todo esse material ficou centralizado em um hub acessível a qualquer pessoa da empresa, junto com o detalhamento técnico da visão de inteligência comercial e outros documentos de apoio. Também cuidamos dos problemas que afetavam todo mundo, deixando claro o que era cada questão e quem ficaria responsável por resolvê-la dentro do próprio escopo de trabalho.
Saber a hora de sair
Percebi que nosso trabalho tinha cumprido o papel quando notei que já nem estávamos mais ativos nas conversas de alinhamento, e que as próprias squads, junto ao gerente de projeto, seguiam tomando a frente das atividades e resolvendo os problemas que apareciam sozinhas. Fomos deixando de acompanhar aquele ritmo aos poucos, até ficarmos disponíveis apenas para consultas pontuais.
“Quando vimos que não éramos mais necessários ali, comemoramos. Porque o verdadeiro desafio desse projeto nunca foi técnico. Era conduzir clareza e comunicação entre tantas frentes diferentes, e foi exatamente isso que passou a acontecer sem a nossa presença constante.”
O que os números e as pessoas confirmaram
Em menos de duas semanas de testes do novo sistema de Venda Regionalizada, o projeto já tinha devolvido 1 milhão de reais para a empresa. E em um segundo momento, aumentou 4 vezes a venda pela modalidade de retirada em loja. Esse número só faz sentido quando lembramos do tamanho do problema original: estoque represado que virou venda, em vez de continuar parado como prejuízo.
O que mais me marcou, porém, foram os depoimentos que vieram das próprias squads depois. Elica Silva, GPM, resumiu bem o ponto de partida que devia ter sido usado desde a primeira tentativa: “o planejamento de um projeto tão singular na história do varejo brasileiro precisa partir do princípio: qual experiência de compra a gente quer proporcionar para o nosso cliente? E, a partir disso, todo o desenho de produto e arquitetura flui muito naturalmente.” Alonso Assunção, PM, destacou como o mapeamento “lança luz ao trabalho de todos os profissionais de tecnologia, auxiliando na melhoria dos processos e na criação com maior facilidade de uma experiência inesquecível de compra.” E Pâmella Fógos, PD, falou algo que resume bem o que aprendi nesse projeto: “utilizar a forma cocriativa e colaborativa para fazer com que as frentes observassem os impactos, e como podemos ter uma jornada mais integrada, permitiu identificar lacunas e oportunidades para gerar uma solução eficiente.”
O que fica desse projeto
Se hoje eu tivesse que resumir esse case em uma frase para outro Product Designer, seria essa: em projetos grandes o suficiente para envolver mais de vinte squads, o desafio de UX raramente é desenhar a tela certa. É construir a clareza que faz todo mundo remar na mesma direção. A técnica de mapeamento em BPMN simplificado ajudou, a central pública de documentação ajudou, os alinhamentos semanais ajudaram. Mas o que destravou o projeto de verdade foi algo mais simples de explicar do que de executar: colocar a jornada do usuário no centro antes de qualquer decisão de arquitetura, e usar isso como a língua comum entre times que, até então, cada um tocava o seu pedaço sem saber direito o que o outro estava fazendo.
