Facilitei uma Design Sprint com diretores e especialistas da Petrobras para redesenhar e automatizar o processo de análise de gastos de requisições de transporte, que dependia de planilhas e emails que se perdiam pelo caminho.
A Petrobras precisava analisar os gastos de requisições de transporte (RT) de poços em cada gerência. O processo passava por solicitação, pré-análise, operação e consolidação. Na teoria, funcional. Na prática, um acúmulo de problemas.
Os dados vinham de um sistema externo (SST) e precisavam ser importados manualmente para a ferramenta de análise (GART). Arquivos se perdiam no caminho, emails iam para caixa de spam, não existia controle do que já tinha sido analisado e o retrabalho era constante. O processo era disperso, custoso em horas de trabalho e sujeito a erros em cada etapa.
A ferramenta GART já existia, mas era limitada. Não funcionava para o que se propunha. O desafio era transformar essa ferramenta em um serviço completo que cobrisse o fluxo de ponta a ponta.
Uma Design Sprint é um workshop intensivo de 4 dias inteiros, com dinâmicas colaborativas, entrevistas, votações, prototipação e teste com usuários reais. Tudo acontece em sequência, com a equipe inteira na sala o dia todo. É um formato que exige preparo e controle de quem facilita, porque cada decisão do grupo precisa avançar dentro do tempo.
Conduzi a sprint inteira como facilitador, com o apoio de outro designer. A sala era composta por gestores, desenvolvedores, gerentes e especialistas da Petrobras, pessoas com décadas de experiência no setor de energia.
Meu trabalho foi manter o controle da dinâmica, direcionar as decisões dentro do tempo e garantir que o grupo saísse dos 4 dias com uma solução validada. Eu não conhecia o domínio, o que significava que precisava aprender rápido e conduzir sem perder autoridade sobre o processo.
No primeiro dia, mapeamos o fluxo de tarefas completo com os especialistas. O ponto de maior dor ficou claro: o momento de importar dados do sistema externo para o GART, analisar os gastos por gerência e consolidar as informações. Era ali que arquivos se perdiam, o controle sumia e o processo atrasava.
A equipe definiu como objetivo de longo prazo: "Em 2 anos, a ferramenta será utilizada por todos os agentes do processo, de ponta a ponta, de forma ágil, robusta e confiável."
As questões críticas que guiaram a sprint foram: a integração com sistemas auxiliares (SAP, SST), a possibilidade de análise prévia para reduzir erros e a eliminação da dependência de planilhas.
Dois conceitos foram desenvolvidos pela equipe: um focado em navegação por árvore de gastos e outro focado em um dashboard com acompanhamento anual e gráficos para análise rápida. A votação do grupo escolheu o segundo, incorporando o detalhamento em árvore do primeiro (um padrão já usado em outras plataformas internas da Petrobras).
O protótipo focou nas 4 telas principais necessárias para validar a proposta com usuários reais. Não era o produto final, era o recorte mínimo para testar se a direção fazia sentido antes de investir meses de desenvolvimento.
Tela inicial com gráficos de acompanhamento anual: total de demandas, resultado das análises, visão financeira e status das solicitações em andamento. O analista entra e já sabe o estado da operação.
Lista de solicitações com status, progresso e ações. Importação de dados, acompanhamento de cada pedido, validação e consolidação em um só lugar, sem precisar de email ou planilha paralela.
Tela de histórico com registro de tudo que já foi processado. O usuário tem controle total do que já passou, sem depender de memória ou de arquivos salvos em pastas compartilhadas.
No último dia, testamos o protótipo com usuários reais da Petrobras. Enquanto eles navegavam, anotávamos dificuldades, pontos positivos e comportamento. Depois fizemos perguntas específicas para validar decisões do protótipo.
Os testes também revelaram que os arquivos importados precisariam ser validados antes de entrar na ferramenta, o que gerou um requisito novo para o time de desenvolvimento. A centralização das informações foi o ponto mais valorizado: os usuários acreditavam que a ferramenta reduziria o tempo gasto com análises e eliminaria o retrabalho causado por arquivos perdidos.
O entregável foi um protótipo navegável com dados reais, validado por usuários da operação, junto com a documentação completa da sprint: objetivo de longo prazo, questões críticas, fluxo de tarefas, conceitos escolhidos, storyboard e resultados dos testes.
As 4 telas cobriam o fluxo principal, mas o produto precisaria ser iterado com novas funcionalidades (como a validação prévia de arquivos, que surgiu nos testes) e acompanhado durante o uso real para ajustar o que só aparece em produção. O protótipo validou a direção. O caminho seguinte seria um mapeamento de histórias de usuário para priorizar o backlog do MVP.
Como consultoria (Spassu), nosso papel terminava na validação. O desenvolvimento ficava com o time interno da Petrobras. A documentação foi estruturada para que o time pudesse seguir sem depender de quem facilitou a sprint.
Esse foi o projeto que mais me tirou da zona de conforto. Facilitar uma sprint sobre um domínio que eu não conhecia, com pessoas que sabiam muito mais sobre o assunto do que eu, me forçou a separar duas coisas: conhecimento em profundidade e capacidade de influênciar. Eu não precisava saber tudo sobre gastos de poços. Precisava saber fazer as perguntas certas e manter o grupo no caminho.