Tempo de leitura: 6 minutos.

TL;DR

Construí um MVP baratinho para rastrear gaiolas com código de barras e provar que dava para reduzir perdas e aumentar eficiência. A tecnologia funcionou, os relatórios saíram lindos… mas ninguém usou. Moral da história: no PowerPoint, tudo escala, no chão de fábrica, só escala se a operação comprar a ideia.

Dores

A operação nos acionou pedindo prioridade máxima para desenvolver uma solução completa de rastreamento de gaiolas. Transportadoras que dependem de gaiolas vivem um inferno logístico disfarçado de rotina operacional.

O pedido fazia sentido: perdas constantes, controle manual ineficiente e nenhuma visibilidade real. Mas havia um detalhe incômodo, transformar isso em um sistema robusto, com todas as camadas de autenticação, permissões e integrações, poderia consumir meses de desenvolvimento e engolir metade do time antes mesmo de sabermos se a solução teria adesão no campo.

Para não cair na armadilha de investir pesado em algo que poderia virar apenas mais uma tela ignorada, optamos por testar o essencial: um MVP de baixo custo. A ideia era validar rapidamente se o rastreamento via código de barras entregaria valor para a operação e se os operadores realmente usariam a ferramenta no dia a dia.

Se sim, ótimo! Tínhamos um caso sólido para evoluir o produto. Se não, melhor descobrir cedo, com pouco esforço e sem desperdiçar meses de engenharia.

Solução Proposta

• Rastreamento completo do ciclo de vida das gaiolas → reduz perdas.
• Controle de expedição e recebimento com vínculo a responsáveis → aumentar previsibilidade.
• Histórico detalhado de movimentações → melhorar auditoria.
• Relatórios gerenciais → embasar decisões.
• Sistema de código de barras para identificação única → agiliza operação.

Funcionalidades

1. Gestão de Funcionários

• Cadastro, edição, exclusão e reativação
• Sistema de soft delete
• Validação de duplicação: Prevenção de funcionários ativos com mesmo nome

2. Gestão de Bases Parceiras

• Cadastro, edição, exclusão e reativação
• Sistema de soft delete
• Validação de duplicação: Prevenção de bases parceiras ativas com mesmo nome

3. Gestão de Origens

• Cadastro, edição, exclusão e reativação
• Sistema de soft delete
• Validação de duplicação: Prevenção de origens ativas com mesmo nome

4. Gestão de Gaiolas

• Cadastro com códigos de barras únicos
• Exclusão e reativação
• Validação de segurança (gaiolas expedidas)
• Validação de duplicação: Prevenção de gaiolas ativas com mesmo código de barras

5. Movimentação de Gaiolas

• Expedição individual e em lote
• Recebimento de gaiolas
• Seleção de funcionário
• Registro de observações
• Histórico completo
• Validações de status

6. Relatórios e Histórico

• Relatórios de movimentações com filtros
• Histórico individual de gaiolas
• Big Numbers com métricas visuais
• Exportação CSV com formato brasileiro
• Sistema robusto com timeouts e retry

7. Notificações Slack

• Configuração de webhook do Slack
• Tempo limite configurável (1-365 dias)
• Canal customizável
• Ativação/desativação de notificações
• Verificação manual de gaiolas atrasadas
• Teste de conectividade com webhook
• Notificações organizadas por base parceira

Formato das Mensagens (Slack)

• Mensagem de Teste: Validação de webhook com emoji 🧪
• Mensagem de Alerta: Estrutura organizada por base parceira com emoji 🚨
• Informações Detalhadas: Código da gaiola, dias de atraso, funcionário responsável
• Formatação Markdown: Negrito, itálico e estrutura clara
• Call-to-Action: Instruções claras sobre o que fazer

Funcionalidades Avançadas

• Agrupamento automático por base parceira
• Cálculo preciso de dias de atraso
• Múltiplas notificações (uma por base)
• Configurações personalizáveis
• Verificação manual e automática

Stack Tecnológica

Para tirar a ideia do papel e validar rápido, montei uma stack simples e acessível. O objetivo não era construir a próxima plataforma escalável da AWS, mas sim um protótipo funcional que pudesse ser usado em campo em poucos dias. E aqui entra um ponto importante para PMs: com ferramentas atuais e editores como o Cursor, dá para desenvolver MVPs sem depender 100% do time de engenharia.

Backend	Frontend
Framework: Flask 3.1.1 Linguagem: Python 3.11+ Banco de Dados: Supabase (PostgreSQL) ORM: Supabase Client (Python) Configuração: python-dotenv 1.0.0	Templates: Jinja2 3.1.6 CSS: Customizado (global.css) JavaScript: Vanilla JS ES6+ Responsividade: Mobile-first

Experiência do Usuário

Na interface, a escolha foi pelo caminho mais simples possível. Nada de telas cheias de elementos ou menus escondidos, a operação em um hub já é caótica por natureza, não precisa de mais uma camada de frustração digital. O foco foi criar uma experiência direta: botões grandes, fluxos curtos e zero firula.

A ideia era reduzir a fricção ao máximo: o operador abre, seleciona expedição ou recebimento, registra a movimentação e pronto. Sem necessidade de treinamento longo, sem curva de aprendizado, sem perder tempo procurando onde clicar.

Se o MVP tinha que validar uso em campo, fazia sentido remover qualquer obstáculo que pudesse virar desculpa para não usar.

• Interface limpa e intuitiva.
• Fluxo simples para expedição/recebimento.
• Feedback visual imediato.
• Funciona em desktop e mobile.
• Prevenção de registros duplicados (anti-flood).
• Acesso direto (sem login) para agilidade no MVP.

O resultado foi um MVP ágil, barato e suficientemente robusto para ser usado no piloto em operação real.

Objetivos por Perfil

Para Operadores

• Registro rápido de expedição/recebimento.
• Seleção simplificada de funcionário.
• Feedback claro de operações.

Para Gestores

• Visão completa do inventário.
• Relatórios detalhados e históricos.
• Controle de responsáveis e pontos de origem/destino.

Critérios de Sucesso

• Uso constante da solução pelos colaboradores da operação
• Redução de 90% na perda de gaiolas (comparativo antes/depois).
• Aumento de 80% na eficiência logística (tempo de registro e rastreio).
• Rastreabilidade total das movimentações.
• Interface aprovada por operadores (>85% satisfação em teste piloto).

O que foi feito

1. Implantação piloto em operação real.
2. Coleta de feedback de operadores e gestores.
3. Ajustes de usabilidade e performance.

Resultados e Reflexão

No fim, o piloto durou pouco: a operação usou o app por duas semanas e depois simplesmente desengajou. Não por falha técnica ou complexidade, mas porque a vida real engoliu a iniciativa, alta demanda operacional, zero tempo para treinar gente nova e a falta de dedicar recursos humanos.

E isso ensina (ou relembra) algumas verdades incômodas sobre gestão de produtos:

• Validação barata ainda é validação: o MVP mostrou rápido que o problema não era só de rastreabilidade, mas também de adoção no dia a dia. Melhor gastar pouco para descobrir isso do que torrar meses de engenharia.
• Funcionalidade sem uso é só código morto: não basta estar alinhado ao problema no papel, é preciso que a operação tenha incentivos e capacidade real de usar.
• Métrica de entrega não paga a conta: medir apenas features entregues é inútil; impacto só aparece com uso contínuo e engajamento.
• Prioridade é sempre escolha: o tempo investido aqui foi um custo de oportunidade que poderia ter sido gasto em iniciativas com mais chance de gerar valor.

No balanço, o MVP cumpriu seu papel: mostrou rápido que a solução não estava madura para escalar. Foi barato, evitou desperdício e reforçou o valor de pensar ágil e iterativo. Melhor aprender em semanas com um protótipo simples do que gastar trimestres construindo algo que acabaria esquecido no hub.

Projeto

O projeto está disponível publicamente em:

ℹ️ https://github.com/utinside/rastreamento-gaiolas