Este memorial registra o trajeto do Sistema de Gestão de Frota — do diagnóstico de campo, feito entre pranchetas molhadas e mensagens soltas no aplicativo da operação, até a versão 1.0, em que uma falha crítica detectada na inspeção pré-viagem bloqueia o veículo antes que ele saia para a rua. Não é uma página de marketing. É o registro de como um produto operacional foi pensado, modelado e construído.
Aoperação acontecia em papel. O motorista preenchia a inspeção pré-viagem numa prancheta, no pátio, antes de pegar a chave. A folha era assinada no canto, dobrada no bolso e — quase sempre — perdida antes do fim do turno. Manutenção era ato de fé: o veículo entrava na oficina quando quebrava na estrada, nunca antes.
Quem coordenava a frota dependia de memória. Do mecânico. Do motorista mais antigo. Da própria. Reuniões semanais eram conversas sobre impressões. A pergunta "qual veículo está pior?" não tinha resposta baseada em dado — tinha resposta baseada em quem reclamava mais alto na última semana.
O projeto começou com uma observação simples: o conhecimento existia, só não estava em lugar nenhum. Estava no caderno do gestor, no bolso do motorista, na cabeça do mecânico. Faltava um lugar onde a frota pudesse se lembrar de si mesma.
Toda frota carrega uma memória. Quase nenhuma sabe onde guardá-la.
Software de operação não precisa de mais telas. Precisa de menos dúvida.
O melhor indicador é aquele que evita o telefonema das três da manhã.
Quando o sistema percebe risco, ele bloqueia primeiro e explica depois.
Processo bem desenhado economiza mais do que qualquer funcionalidade da moda.
Comecei este projeto sem escrever uma única linha de código. Comecei com uma prancheta, um caderno e três turnos no pátio.
Sou Engenheiro de Produção. Aprendi cedo que processo ruim não se resolve com ferramenta nova — se resolve entendendo onde a informação se perde, onde a decisão atrasa e onde a responsabilidade some.
Quando entrei no projeto, a frota funcionava por improviso disciplinado. Pessoas competentes compensando, todos os dias, a ausência de um sistema. Era admirável e insustentável.
Resolvi modelar antes de construir. BPMN, entrevistas, observação de campo. O protótipo do checklist foi de papel — só virou tela quando três motoristas conseguiram preenchê-lo sem ajuda, em menos de três minutos, sob o sol do pátio.
O software que você está lendo o memorial é o resíduo dessas conversas. Cada regra de bloqueio, cada peso da nota de saúde, cada copy de empty state foi calibrado contra uma situação real que eu vi acontecer.
Espero que, ao usar, fique a impressão de que alguém pensou no detalhe. Porque alguém pensou — em todos eles.
— Carlos Eduardo
Toda frota carrega uma memória. Quase nenhuma sabe onde guardá-la.
Software de operação não precisa de mais telas. Precisa de menos dúvida.
O melhor indicador é aquele que evita o telefonema das três da manhã.
Quando o sistema percebe risco, ele bloqueia primeiro e explica depois.
Processo bem desenhado economiza mais do que qualquer funcionalidade da moda.
Entrevistas com o gestor de frota, observação de campo e levantamento das ferramentas em uso (planilhas, mensagens e cadernos de anotação).
Modelagem BPMN da situação atual em três fluxos e identificação de sete pontos críticos de quebra.
Versão impressa do novo checklist testada com três motoristas durante duas semanas para validar o modelo.
Primeiro fluxo digital: wizard mobile-first com 12 itens em 4 categorias, assinatura digital e bloqueio automático.
Operação acompanhada com seis veículos para validar a fórmula da nota de saúde e calibrar os pesos.
Lançamento da versão completa: análise por IA, dashboard executivo, previsão de manutenção e mapa de não-conformidades.
Cada módulo responde a uma pergunta operacional específica. Foi a regra que evitou o "dashboard genérico" — telas que mostram tudo e não decidem nada. Abaixo, os sete em ordem de leitura.
Visão consolidada da frota com indicadores-chave, conformidade dos últimos 14 dias, alertas inteligentes e resumo executivo gerado por IA.
Antes · Planilha atualizada apenas no fim do mês — quando a informação já estava ultrapassada.
Visão completa da frota com nota de saúde, status atual, quilometragem e previsão da próxima manutenção.
Antes · Anotações em caderno do gestor, com saúde dos veículos guardada apenas na memória do mecânico.
Inspeção em quatro etapas guiadas pelo celular, com 12 pontos críticos, assinatura digital e bloqueio automático.
Antes · Folha de papel preenchida no pátio e raramente revisada depois.
Calendário e lista de ordens de serviço preventivas e corretivas, com custo total acompanhado por veículo.
Antes · Combinações por mensagem com o mecânico e recibos avulsos no porta-luvas.
Cadastro com CNH, categoria, validade e indicador individual de conformidade.
Antes · Lista impressa colada na parede do escritório.
Fila cronológica de eventos críticos abertos pelo sistema, com nível de severidade.
Antes · Aviso por telefone do motorista parado na estrada — o gestor sempre era o último a saber.
Mapa cruzando veículos e itens, itens mais reprovados, intervalo entre falhas e custo por veículo.
Antes · Não existia. Decisões tomadas por intuição e memória.
Toda decisão de produto é um trade-off. As cinco que mais moldaram este sistema estão registradas abaixo no formato em que foram tomadas: contexto, escolha, justificativa.
ContextoCogitamos avisos não-bloqueantes para falhas críticas, deixando a decisão final no motorista.
DecisãoFalha crítica bloqueia o veículo na hora, abre incidente e exige ordem de serviço corretiva concluída para liberar.
Por quêEm operação real, alerta opcional é alerta ignorado. A segurança não pode depender da pressa do turno.
ContextoHavia tentação de incluir dezenas de variáveis — combustível, telemetria, rotas, satisfação.
DecisãoSaúde calculada por 5 componentes ponderados, todos derivados de eventos já registrados pelo próprio sistema.
Por quêIndicador que ninguém consegue explicar de cabeça vira número de slide. Queríamos um número que o gestor defendesse em reunião.
ContextoPressão para entregar primeiro o app do motorista e deixar a gestão para depois.
DecisãoWizard de inspeção otimizado para o celular do pátio; painel executivo otimizado para o desktop do escritório.
Por quêCada papel tem um contexto físico. Forçar o gestor a operar no celular era trair o desktop. Forçar o motorista a tablet era trair o pátio.
ContextoO modelo poderia aprovar ou reprovar inspeções automaticamente, ganhando velocidade.
DecisãoA IA escreve o resumo executivo e classifica severidade — toda ação ainda passa pelo humano responsável.
Por quêAuditoria operacional precisa de cadeia de responsabilidade clara. Modelo generativo é apoio, não assinatura.
ContextoPermitir edição retroativa de checklists facilitaria correção de erros de digitação.
DecisãoRegistros são imutáveis. Correções entram como eventos novos, com referência explícita ao anterior.
Por quêEm operação, histórico editável é histórico inútil. Memória da frota tem que ser confiável em juízo.
| Fase | Insumo | Saída |
|---|---|---|
| Descoberta | 3 dias no pátio, 11 entrevistas, 2 turnos noturnos | 1 mapa BPMN do estado atual + 7 pontos de quebra documentados |
| Modelagem | Workshop com mecânico-chefe e 2 motoristas | Lista final de 12 itens críticos, agrupados em 4 categorias |
| Validação em papel | Checklist impresso testado por 3 motoristas por 2 semanas | Redução de 22 para 12 perguntas, 3 ajustes de ordem |
| Calibração da nota | 6 veículos no piloto, 4 semanas de dados | Pesos finais da fórmula de saúde + faixas de cor |
| Refinamento da IA | Mais de 40 inspeções rodadas em 3 prompts diferentes | Prompt único com severidade, fonte e ação recomendada obrigatórias |
Nenhuma decisão é tomada sem o indicador correspondente ao lado. Achismo não entra na pauta.
Quando o sistema percebe risco, ele bloqueia primeiro e explica depois.
Cada módulo responde a uma pergunta de gestão específica. Sem painéis genéricos.
O motorista usa no celular, sob luz solar, em poucos minutos.
Cada insight da IA traz severidade, fonte e ação recomendada — sempre auditável.
A primeira tela vazia ensina o usuário a operar o sistema. Reescrevemos cada uma três vezes até o motorista mais experiente entender sem perguntar.
Trocar 'Erro 422' por 'Quilometragem menor que a última registrada — confira o hodômetro' eliminou metade das mensagens no grupo da operação.
Skeleton screens, transições curtas e otimismo de UI fizeram o sistema parecer mais rápido do que medições mostram. Confiança nasce do ritmo.
BPMN, diagrama de Ishikawa e 5 porquês resolveram problemas que nenhuma sprint de produto teria endereçado. Processo primeiro, código depois.
Transformar uma frota movida a papel e mensagens soltas em um sistema vivo, capaz de aprender, alertar e bloquear antes que um pequeno descuido se torne um grande incidente.
Como idealizador e único responsável técnico, Carlos conduziu o ciclo completo — mapeamento bpmn dos processos atuais (inspeção pré-viagem, ordens de serviço e troca de motorista); padronização dos 12 pontos críticos em 4 categorias de inspeção; definição da fórmula da nota de saúde a partir de 5 fatores ponderados; modelagem das regras de bloqueio operacional automático; desenho da interface mobile-first para uso no pátio; integração com inteligência artificial para análise executiva por inspeção. O projeto foi pensado como uma peça de engenharia de produção aplicada a software: descobrir o problema em campo, modelar o processo, validar a hipótese em papel antes do código, e só então construir.
"Este sistema é uma carta de amor à frota — e à ideia de que um processo bem desenhado vale mais do que qualquer funcionalidade da moda. Cada linha de código aqui resolve um problema que eu vi acontecer no pátio, na chuva, com motorista cansado. Que sirva."