Sistema interno · Construção full-stack
A ideia era distribuir clientes. O sistema precisava respeitar as regras.
Uma base chega por planilha. A gestora distribui carteiras. Cada vendedora acompanha seus contatos. Veja como essa operação ganhou um sistema.
Da planilha ao sistema de operação. ·
Imagine receber esse pedido.
“Quero organizar os clientes entre as vendedoras e acompanhar os contatos.” Como você começaria? Uma tela bonita ainda não responde quem pode ver cada carteira, o que acontece quando faltam dados ou como registrar o desfecho de uma conversa.
Essa frase é uma síntese didática do problema, não uma transcrição do cliente. O trabalho real começou numa ideia de produto e avançou para regras, interface, lógica de aplicação e banco de dados.
Uma decisão definiu boa parte do produto.
A gestora decide e acompanha a distribuição. A vendedora trabalha somente a carteira que lhe pertence e registra o resultado de cada contato.
Essa diferença de responsabilidade orientou o modelo de dados, os acessos e as telas. Não bastava esconder um botão: a autorização precisava acompanhar a operação.
Mapa editorial
Do arquivo à carteira acompanhada
Escolha uma parte do percurso.
Representação didática das funções construídas; não é uma sessão de produção.
Parte selecionada · Importar
Uma planilha precisa virar uma entrada controlada.
O que acontece com um registro incompleto ou uma informação que exige conferência?
- Decisão
- A importação foi organizada para tratar a entrada dos dados e suas pendências.
- Trabalho conduzido
- Base, importação controlada, validação com fixtures sintéticas e organização de pendências.
- O que saiu
- A operação passou a ter um ponto de entrada verificável.
Da entrada da planilha ao acompanhamento da carteira.
A construção incluiu importação controlada, carteiras sugeridas e confirmadas, pendências, fila de contatos e ficha do cliente. Entraram múltiplos telefones, registro de respostas e desfechos, opt-out e exportação.
O produto também evoluiu para organização e atribuição por setor. Onde a origem dos dados não oferecia informação suficiente, a decisão manual precisava ter lugar no fluxo.
A interface, as regras e o banco foram trabalhados juntos. O resultado não ficou limitado a um protótipo de telas.
Organizar o sistema sem recomeçar tudo.
A aplicação começou como um monólito funcional e evoluiu para uma organização modular. Autenticação, carteiras, contatos, base de clientes e auditoria passaram a ter responsabilidades mais claras.
A decisão foi preservar o sistema e melhorar sua organização, sem introduzir microserviços ou uma reescrita integral. A arquitetura acompanhou o risco e as necessidades daquele trabalho.
Uma entrega interna precisa sobreviver a mais do que uma demonstração.
A validação incluiu acessos por perfil, separação de carteiras, fluxos de gestora e vendedora, importação e exportação. A preparação operacional também passou por integridade de dados, sessões, controle de tentativas de login, healthcheck e restauração de backup.
O laboratório usou dados sintéticos. A planilha real, com informações pessoais e comerciais, não foi usada como fixture pública nem incluída no repositório de teste.
O trabalho de produto continuou dentro da engenharia.
Compreender a operação, definir regras, construir telas e conferir permissões eram partes do mesmo problema. A coordenação da Roldra ligou essas frentes e manteve o uso esperado como referência para as revisões.
A pessoa responsável continuou dirigindo prioridades e regras. O Orchestrator coordenou as capacidades para materializar, revisar e preparar a entrega.
Sistema construído, validado em ambiente controlado e preparado para implantação. Este case não apresenta operação em produção ou uso por clientes reais.
Sua ideia ainda tem regras em aberto?
Comece pelo que cada pessoa precisa conseguir fazer e pelo que o sistema precisa impedir.
Organizar o contexto do trabalhoQual operação precisa virar sistema?
Conte como ela funciona hoje. As regras do trabalho são o melhor ponto de partida.
Conversar sobre um sistema