Algumas coisas que aprendi construindo o MULTIFNDE, um dos projetos mais interessantes que passaram pela Marrs nos últimos tempos.
Existem projetos que começam com uma lista de funcionalidades.
E existem projetos que começam com um problema.
O MULTIFNDE foi muito mais o segundo caso.
Quando começamos a trabalhar nesse projeto, uma das primeiras coisas que ficou clara para mim era que não estávamos simplesmente construindo mais um CRM.
O problema era outro: como transformar uma operação grande, distribuída pelo Brasil e cheia de relações entre pessoas, instituições e produtos em algo que alguém consiga entender olhando para uma tela?
Parece uma pergunta simples.
Não é.
A plataforma precisava trabalhar com uma base de mais de 160 mil escolas, além de secretarias de educação, representantes, contatos, equipamentos e negociações acontecendo em diferentes regiões do país.
Quando colocamos tudo isso no papel, o desafio deixa rapidamente de ser “fazer algumas telas”.
O desafio passa a ser organizar complexidade.
Software também é uma forma de organizar o pensamento
Eu sempre gostei dessa parte do desenvolvimento.
Antes de escrever código, existe uma fase em que precisamos entender como as coisas realmente se relacionam.
Uma escola pertence ao contexto de uma secretaria.
Uma secretaria possui responsáveis.
Uma negociação envolve uma secretaria, uma escola, um representante, determinados produtos e determinadas quantidades.
Essa negociação muda de estágio.
Essa mudança precisa aparecer no pipeline.
Ao mesmo tempo, precisa alterar os indicadores.
E também precisa aparecer corretamente no mapa e nos dashboards.
Quando uma dessas relações está errada na arquitetura, eventualmente ela aparece errada na interface.
Por isso, boa parte do trabalho em sistemas desse tipo acontece antes do botão existir.
Você está, na prática, criando um modelo digital de uma operação que já existe no mundo real.
E isso é uma das coisas que mais gosto em construir software.
160 mil registros mudam a maneira como você pensa uma interface
É fácil desenhar uma busca quando existem 30 registros.
Com mais de 160 mil escolas, a conversa muda.
Ninguém deveria precisar navegar por milhares de páginas para encontrar uma instituição.
Então estado, município e nome da escola passam a ser parte importante da experiência. A relação entre escola e secretaria também precisa ser simples o suficiente para que a pessoa usando o sistema não tenha que entender como os dados estão organizados por baixo.
Esse é um detalhe interessante sobre UX em sistemas corporativos.
Muita gente associa UX a interfaces bonitas.
Claro que aparência importa.
Mas, nesses sistemas, UX muitas vezes significa uma coisa muito mais básica:
não obrigar o usuário a pensar como o banco de dados pensa.
Se a pessoa precisa entender nossa arquitetura para conseguir usar o produto, provavelmente fizemos alguma coisa errada.
O mapa nasceu para responder uma pergunta
Uma das partes que mais gosto no MULTIFNDE é o dashboard geográfico.
Não simplesmente porque existe um mapa do Brasil na tela.
Mapas são bonitos. Mas colocar um mapa em um dashboard apenas porque ele fica bonito não resolve nada.
A pergunta que ele precisava responder era:
onde as coisas estão acontecendo?
As negociações são distribuídas pelo país. Então fazia sentido permitir que o administrador enxergasse essa distribuição espacialmente, filtrasse estados, visualizasse intensidade por região e chegasse até uma oportunidade específica através de um ponto no mapa.
Ao redor disso entram os números: negociações abertas, representantes, contatos, fechamentos, taxa de conversão, atividades recentes.
De repente, um conjunto enorme de registros começa a virar uma história que alguém consegue interpretar.
Isso, para mim, é a função de um bom dashboard.
Não mostrar dados.
Ajudar alguém a perceber o que está acontecendo.
O Kanban parece simples. E deve parecer.
Outra parte central foi o pipeline comercial.
Iniciado.
Em andamento.
Fechado.
Cancelado.
Visualmente, é extremamente simples.
Você pega um card e move de uma coluna para outra.
Só que aquela pequena interação provoca uma série de efeitos no sistema.
O status da negociação muda, a listagem precisa refletir essa mudança, os indicadores são recalculados e o dashboard passa a representar o novo estado da operação.
Essa é uma característica de software que considero interessante:
as melhores interfaces frequentemente escondem uma quantidade enorme de trabalho.
Para quem usa, é um drag and drop.
E é exatamente assim que deve ser.
Complexidade interna não precisa virar complexidade para o usuário.
Também havia outro sistema do outro lado
O projeto não termina no CRM.
Existe também o website.
Uma pessoa pode chegar pelo site, preencher um formulário e demonstrar interesse como representante ou como contato de uma secretaria.
A partir daí, esse dado precisa deixar de ser apenas “um formulário enviado”.
Ele precisa entrar na operação.
Por isso construímos uma integração própria entre o WordPress e o CRM.
O fluxo ficou mais ou menos assim:
site → lead → validação → cadastro → negociação.
O site institucional roda separadamente, em WordPress, enquanto a aplicação principal usa Laravel, React e Inertia. Uma API específica faz a ponte entre esses dois ambientes.
Para quem preenche o formulário, nada disso existe.
E novamente: esse é o objetivo.
Infraestrutura deveria ser invisível para quem está tentando resolver um problema.
Tecnologia importa. Mas decisões importam mais.
Do lado técnico, o projeto tem bastante coisa interessante.
A aplicação principal foi construída com Laravel e React, usando Inertia para conectar as duas camadas, Vite no build e MySQL na persistência dos dados. Na infraestrutura entraram Nginx e DigitalOcean, além de Cloudflare na camada de DNS, cache e segurança. O site WordPress ficou em AWS Lightsail e a integração entre site e CRM foi feita por API.
Também existem gráficos, mapas, geração de documentos, autenticação por código enviado por e-mail, permissões por perfil, notificações, exportações e rotinas administrativas.
É uma stack considerável.
Mas olhando para o projeto pronto, não acho que a parte mais interessante seja dizer que usamos tecnologia A ou B.
Frameworks mudam.
Bibliotecas mudam.
Versões mudam.
A pergunta que permanece é:
a arquitetura que criamos consegue representar bem o problema que estamos tentando resolver?
Essa decisão dura muito mais do que qualquer versão de framework.
Um pequeno detalhe que considero importante: entrega também faz parte da engenharia
Existe uma fase dos projetos sobre a qual quase ninguém escreve.
O final.
Entregar software não deveria significar simplesmente mandar um ZIP e dizer “está pronto”.
Um produto real possui código, banco de dados, infraestrutura, DNS, serviços externos, credenciais, backups, deploy, documentação e processos de recuperação.
No MULTIFNDE, documentamos também essa camada: repositórios, infraestrutura, bancos, integração com WordPress, API, serviços de e-mail, Cloudflare, procedimentos de deploy, rollback, backup e transferência operacional.
Talvez seja uma parte menos interessante para uma screenshot no LinkedIn.
Mas é uma das partes que diferenciam um projeto que apenas funciona hoje de um projeto que outra equipe consegue continuar amanhã.
Para mim, isso também é produto.
O que eu mais gostei neste projeto
Curiosamente, não foi uma tecnologia específica.
Foi a escala do problema.
Eu trabalho com design e desenvolvimento há bastante tempo e ainda acho fascinante aquele momento em que alguma coisa extremamente complexa começa a ficar simples.
Primeiro existe uma quantidade enorme de informações espalhadas.
Depois surgem algumas entidades.
Escolas.
Secretarias.
Representantes.
Produtos.
Negociações.
Em seguida começam as relações.
Depois os fluxos.
Depois as interfaces.
E, em algum momento, aquilo que antes precisava ser explicado em uma reunião de uma hora passa a caber em um dashboard.
É provavelmente uma das melhores sensações de construir software.
Não porque eliminamos a complexidade.
Ela continua lá.
Nós apenas conseguimos colocá-la no lugar certo.
O computador fica com a complexidade.
A pessoa fica com a decisão.
Acho que, no fim, esse foi o principal trabalho no MULTIFNDE.
E é também uma boa definição do tipo de software que eu gosto de construir.
Confira algumas imagens
