# Rangoo Delivery — ArcelorMittal Tubarão > Sistema de gestão de entregas desenvolvido do zero para uma das maiores siderúrgicas do Brasil. Do discovery ao produto em produção, com squad enxuto e evolução contínua. Fonte: https://ph.etc.br/cases/rangoo-delivery-arcelormittal/ Autor: PH Munhoz Case publicado em 10/01/2026 --- ## Em números - **Zero** soluções prontas que atendiam a demanda - **Squad** enxuto do discovery ao produto - **SaaS** modelo de receita recorrente ## Ficha - Tipo de projeto: Desenvolvimento sob Demanda - Setor: Indústria Siderúrgica - Porte: Grande porte · B2B - Duração: Em evolução contínua - Papel: Discovery, arquitetura, desenvolvimento e evolução ## Contexto **Uma operação logística complexa que nenhum software pronto resolvia.** A ArcelorMittal Tubarão é uma das maiores siderúrgicas do Brasil, com uma operação logística que envolve múltiplos fornecedores, rotas e controles de entrega espalhados por diferentes times. A demanda chegou porque já tinham tentado adaptar ferramentas genéricas — sem sucesso. O problema era específico demais para soluções de prateleira. Precisavam de algo construído para a realidade deles, não do contrário. O projeto entrou pela Future Ventures: descoberta aprofundada do problema antes de qualquer decisão técnica, seguida de desenvolvimento iterativo com squad enxuto e entrega incremental — sem big bang no final. ## Desafios **O que tornava esse problema difícil de resolver.** A operação de entregas da ArcelorMittal não era apenas grande — era heterogênea. Fornecedores diferentes, regras diferentes, times diferentes. Nenhuma ferramenta genérica conseguia modelar essa complexidade sem virar um projeto de customização infinita. - **Gestão manual e fragmentada**: Escalas de entrega controladas por planilhas descentralizadas. Cada time com sua versão, sem sincronização e sem histórico confiável. - **Sem visibilidade da operação**: Nenhuma visão centralizada do status das entregas. Para saber o que estava acontecendo, era preciso ligar ou mandar mensagem — em tempo real. - **Sem integração entre áreas**: Times de logística, operação e fornecedores operando em silos. Informação que precisava chegar em três lugares chegava em um — ou em nenhum. - **Nenhuma solução pronta que servisse**: Sistemas de gestão de entregas do mercado foram avaliados e descartados. A especificidade da operação exigia algo construído do zero — ou adaptações tão profundas que equivaliam a isso. ## Como foi feito **Do discovery ao produto em produção.** O projeto seguiu o modelo da Future Ventures: o trabalho começa pelo entendimento do problema real, não pela tecnologia. Só depois de mapear a operação em profundidade é que a arquitetura foi definida — e o desenvolvimento, iniciado. ### Fase 01 · Discovery: Imersão na operação Entrevistas com operadores, gestores e fornecedores para entender o fluxo real de entregas — não o fluxo documentado. Mapeamento de regras, exceções e pontos de fricção que nunca apareceriam num briefing. ### Fase 02 · Arquitetura: Definição da solução Escolha de stack, modelagem de dados, definição de módulos e escopo do MVP. O objetivo era resolver o problema central primeiro — e construir a base certa para evoluir depois. ### Fase 03 · Build iterativo: Desenvolvimento incremental Squad enxuto, ciclos curtos, validação contínua com o time da ArcelorMittal. Cada entrega parcial em produção antes de seguir para o próximo módulo — sem acumular risco. ### Fase 04 · Evolução contínua: Produto em operação O sistema entrou em produção e segue evoluindo. Novas funcionalidades são priorizadas com base no uso real — não em roadmaps definidos no início do projeto. ## Resultados **O que o sistema entrega hoje.** - **100% · Visibilidade da operação**: Gestores têm visão centralizada e em tempo real de todas as entregas — algo que antes dependia de ligações e planilhas atualizadas manualmente. - **Zero · Planilhas no processo crítico**: O controle manual foi eliminado do fluxo principal. A operação roda pelo sistema — com histórico, rastreabilidade e dados confiáveis. - **SaaS · Contrato recorrente**: O modelo não foi de entrega pontual. É uma solução que evolui junto com a operação do cliente — com receita recorrente e relação de longo prazo. O Rangoo Delivery não foi um projeto que terminou na entrega. É um produto que continua sendo desenvolvido, com novas funcionalidades sendo priorizadas com base no uso real da operação. ## Aprendizados **O que esse projeto confirma.** 01. **Discovery não é opcional em projetos complexos**: Projetos que pulam a fase de descoberta para economizar tempo quase sempre pagam mais caro depois — em retrabalho, funcionalidades erradas e arquitetura que não escala. A imersão no problema real é o trabalho mais importante. 02. **Entregas incrementais reduzem risco e aumentam confiança**: Cada módulo entregue em produção antes do próximo ser iniciado cria um ciclo de validação contínua. O cliente vê progresso real, a equipe aprende com o uso e os riscos ficam controlados. 03. **O modelo certo é contínuo, não pontual**: Sistemas de operação não terminam — evoluem. Um modelo de contrato recorrente alinha os incentivos certos: a solução só funciona de verdade se continuar funcionando, e isso exige evolução constante. ## Próximo passo **Tem um problema que nenhuma ferramenta pronta resolve?** Esse é o tipo de projeto que fazemos. Se você tem uma demanda específica de operação que soluções genéricas não atendem — fale comigo. - Serviço relacionado: [Do zero ao produto que fica de pé.](https://ph.etc.br/projetos/) - Contato: https://ph.etc.br/contato/ (Projetos de desenvolvimento sob demanda têm ticket alto e modelo recorrente. Aceito novos projetos quando o perfil faz sentido.)