Daki · Case 02

Raio — a fundação do universo logístico

Papel
liderança de design — líder e executora na fase crítica
Time
squad enxuta
Resultado
migração no prazo do contrato · custo de licença eliminado · sem queda de produtividade

Em um mês, desenhei do zero a estrutura dos dois produtos que sustentam o last mile: uma operação de dezenas de hubs, em várias cidades.

A migração da plataforma que rodava a operação saiu dentro do prazo do contrato, com uma squad enxuta, e a estrutura desenhada nesse mês é a que os times evoluem até hoje.

01 — Meu papel

Na época da fusão com o grupo global, a gestão de last mile rodava numa plataforma terceira: custo de licença alto e zero espaço para personalizar funcionalidades a uma operação com particularidades muito específicas, como o modelo de hubs. A empresa decidiu substituí-la por ferramenta própria.

O que precisava nascer ou mudar, em paralelo:

  • Raio web, a torre de controle da operação: estado de entregas e viagens, atrasos, riders em rota e em retorno. Não existia nada.
  • Raio app, o app do entregador, que já existia, mas sem o conceito que passava a ser o centro da operação: viagens com stacking (agrupamento roteirizado de múltiplas entregas), no lugar de entregas únicas. Incorporar essa mudança exigia reestruturar a navegação inteira.

02 — O que estava em jogo

Se a migração falhasse, a operação não podia ficar desassistida: a alternativa seria estender o contrato e pagar caro por isso.

O prazo era duro: o fim do contrato.

Raio — a arquitetura de informação da fundaçãoSubi a primeira base de navegação de web e app; as squads evoluíram as funcionalidades sobre ela. Está em uso até hoje.Raio — a arquitetura de informação da fundaçãoSubi a primeira base de navegação de web e app; as squads evoluíram as funcionalidades sobre ela. Está em uso até hoje.RAIO WEBTorre de controle da operação de last mileweb · gestãoVisão geralestado atual · viagens ativas ·atrasos · riders em rota e emretornoViagenslista → detalhe: entregasagrupadas, rider, rota, progressoEntregasestado · atraso · históricoAcompanhamentotempo real · alertas de atrasoSubstituiu a plataforma de terceiro — e o contrato foi junto.a mesma operação, os dois ladosRAIO APPApp do entregador — viagens e ofertasapp · operaçãoHome / ofertaviagens disponíveis · aceiteViagem (stacking)sequência roteirizada demúltiplas entregasEntreganavegação até o cliente ·confirmação e validaçãoRetornovolta ao hub · disponível paranova viagemEstrutura de navegação em uso até hoje.ANTESUma entrega por vezhub → entrega → retorno, a cada pedidoA MUDANÇA CONCEITUALDe entregas únicas a viagenscom stackingnão é uma tela nova — é outro objeto denegócioDEPOISUma viagem, várias entregasmúltiplas entregas agrupadas eroteirizadas → um retorno ao hubestrutura real · sem dados de operação, volumes ou nomes de ferramentasRaio — a arquitetura de informação da fundaçãoSubi a primeira base de navegação de web e app; as squads evoluíram as funcionalidades sobre ela. Está em uso até hoje.Raio — a arquitetura de informação dafundaçãoSubi a primeira base de navegação de web e app; assquads evoluíram as funcionalidades sobre ela. Está emuso até hoje.RAIO WEBTorre de controle da operação de last mileVisão geralestado atual · viagens ativas · atrasos · riders em rota eem retornoViagenslista → detalhe: entregas agrupadas, rider, rota,progressoEntregasestado · atraso · históricoAcompanhamentotempo real · alertas de atrasoSubstituiu a plataforma de terceiro —e o contrato foi junto.a mesma operação, os dois ladosRAIO APPApp do entregador — viagens e ofertasHome / ofertaviagens disponíveis · aceiteViagem (stacking)sequência roteirizada de múltiplas entregasEntreganavegação até o cliente · confirmação e validaçãoRetornovolta ao hub · disponível para nova viagemEstrutura de navegação em uso atéhoje.ANTESUma entrega por vezhub → entrega → retorno, a cada pedidoA MUDANÇA CONCEITUALDe entregas únicas a viagens com stackingnão é uma tela nova — é outro objeto de negócioDEPOISUma viagem, várias entregasmúltiplas entregas agrupadas e roteirizadas → um retorno aohubestrutura real · sem dados de operação, volumes ounomes de ferramentas
O que este diagrama prova: a estrutura é uma só para os dois lados da operação, e a mudança do app é de objeto de negócio, de entregas para viagens, não de tela.

Ato I · 03 — Decisão de produto

Eu liderava design. As definições de escopo eram do meu par de produto e do CTO.

O que eu levava para essas decisões era o aprendizado do discovery: o que a operação de fato usava na plataforma, o que ignorava, o que precisava e não tinha.

Ato II · 04 — Decisão de liderança e craft

Quando o designer principal da squad saiu no meio do projeto, assumi também a execução: liderei e desenhei.

Decisão de contexto, não de hábito: com prazo duro e a squad sem seu designer principal, ser líder e contribuidora era o que o momento pedia.

Em um mês, subi a primeira base de arquitetura de informação e navegação dos dois produtos (a organização de viagens, entregas e acompanhamento), idealizada com o PM e validada com entregadores em loco, nas lojas.

05 — Resultado relativo

No prazo do contrato

migração dentro do prazo do contrato, com uma squad enxuta

Licença eliminada

custo de licença da plataforma terceira eliminado

Produtividade estável

a operação absorveu a troca sem queda de produtividade

Os resultados funcionais vieram nas evoluções seguintes, construídas pelas squads sobre essa estrutura, que segue sendo a base até hoje.

Anos depois, o universo de Delivery Experience, que nasceu nessa fundação, passou a reportar a mim como liderança de produto.

06 — O que eu faria diferente

Ter olhado mais cedo para a dinâmica mobile vs. desktop no momento da operação dentro da loja. Parte das adaptações que fizemos depois, com aprendizados da operação, poderia ter entrado já na fundação.