Ao tentar unir duas automações, voltei a separar vendas e administração de pessoal

✨ Resumo do GPT-5.6 Sol

Um registro da busca por uma estrutura de automação operacional capaz de preservar as rotinas de vendas e mensagens que já funcionavam e, ao mesmo tempo, crescer para atendimento inbound e administração de pessoal.

Já existiam dois programas em funcionamento

Dentro da empresa, já havia dois programas de automação que tinham evoluído em direções diferentes.

Um deles era um programa de gestão de férias por mensagens, implementado primeiro pelo meu antecessor. O serviço calculava as férias de cada funcionário, enviava mensagens de incentivo ao uso e interpretava os pedidos recebidos por mensagem para encaminhá-los até a aprovação ou rejeição. Web, backend, DB e até um celular Android de trabalho já funcionavam como um único fluxo.

O outro era a coleta de dados públicos e a automação de vendas que eu vinha aprimorando. A estrutura reunia estabelecimentos e contatos, conectava-os às chamadas outbound da Vox e os encaminhava para atividades comerciais reais.

No começo, achei que bastaria mover os dois projetos para um único repositório para integrá-los. Mas, quando pensei nas funções que queria acrescentar, percebi que apenas juntar pastas não seria suficiente.

• atendimento inbound conectado ao outbound existente
• fluxo que recebe solicitações de funcionários e as encaminha para tarefas administrativas
• geração e entrega automática de comprovantes de vínculo empregatício
• divisão de permissões com base em informações de funcionários, contratos e locais de trabalho
• uma tela operacional para acompanhar falhas, aprovações, reprocessamentos e registros de auditoria em um só lugar

A partir daí, a pergunta deixou de ser “como unir os dois códigos?” e passou a ser “onde colocar o trabalho que ainda vai crescer?”.

Decidi não descartar o programa existente

Ao olhar o programa de férias por mensagens, tive muita vontade de refazê-lo. Eu via uma estrutura antiga, configurações provisórias e várias partes que gostaria de redesenhar segundo os padrões atuais. Parecia que levar apenas os requisitos para um código novo produziria algo mais limpo.

Mas, à medida que examinava o material, percebi que aquele programa continha coisas mais importantes que o código.

• os resultados de férias que eram mostrados aos funcionários de verdade
• a forma de calcular férias a partir da data de admissão
• quem deveria receber os avisos de incentivo ao uso e quando eles eram enviados
• as regras para interpretar pedidos por mensagem como datas e meios períodos
• a ordem entre solicitação, aprovação, rejeição e mensagens de resultado
• a forma como o celular Android de trabalho enviava e recebia mensagens
• as telas e o tratamento de exceções que os operadores já usavam

Se eu resumisse tudo isso em alguns documentos e recomeçasse do zero, o código novo poderia até ficar limpo, mas o resultado entregue aos usuários existentes poderia mudar. Eu não podia apagar, por mera preferência de design, um fluxo vertical que meu antecessor tinha realmente concluído.

Por isso, mudei de direção: primeiro reproduziria o serviço existente como ele era, manteria as telas e os resultados dos cálculos como referência de regressão e só então substituiria, função por função, as partes problemáticas. O novo sistema não deveria começar apagando o programa antigo. Ele precisava incorporar esse programa a uma estrutura maior sem perder o trabalho que já realizava.

Vendas e administração de pessoal não eram o mesmo app

Unir os projetos e, junto com eles, transformar DB e Runtime em uma coisa só criaria outro problema.

A automação de vendas lida com dados públicos, contatos, alvos de chamada e resultados comerciais. A administração de pessoal lida com dados de funcionários, emissão de documentos, férias, aprovações e mensagens. Os dois domínios podem aparecer juntos em uma tela operacional, mas a natureza dos dados, as permissões e o alcance de uma falha são diferentes.

Eu não queria uma estrutura em que uma migration do DB de vendas impedisse o deploy da administração de pessoal, nem que uma falha no serviço de férias também interrompesse a coleta comercial. Contas, credentials, queues, backups e rollbacks também precisavam ser separados por área de trabalho.

No fim, decidi manter um único repositório, mas separar vendas e administração de pessoal em apps independentes. A tela operacional permite navegar pelos dois em um só lugar, mas não lê diretamente os DBs: cada backend responde pelos próprios dados e permissões.

Mesmo que, por fora, exista uma única tela operacional integrada, por dentro não é preciso haver um serviço monolítico gigantesco.

Do outbound para o inbound e as tarefas administrativas

A automação de vendas existente se aproximava de um fluxo outbound, voltado a fazer ligações para fora. No dia 15, também passei muito tempo pensando em como acrescentar o inbound.

O fato de uma ligação ter chegado não significa que toda solicitação precise ser resolvida dentro do sistema de chamadas. A ligação pode ser apenas a entrada que recebe o pedido e o encaminha para o trabalho adequado. Se alguém solicitar um comprovante de vínculo empregatício, o pedido deve seguir para a verificação de identidade e a emissão; depois, o documento emitido precisa passar por um processo de entrega separado. Mesmo quando o mesmo pedido chega pela Web ou pelo celular, ele deve convergir para a mesma tarefa administrativa.

Foi por isso que decidi começar pelo comprovante de vínculo empregatício. Era a primeira função capaz de verificar, de uma só vez, todo o fluxo necessário à automação operacional: recebimento da solicitação, conferência dos dados de referência do funcionário, geração do documento, aprovação, entrega, tratamento de falhas e auditoria.

Não bastava desenvolver bem uma única função. As mesmas fronteiras precisavam continuar úteis quando outras tarefas de administração de pessoal fossem acrescentadas.

Eu não podia recriar os dados de referência

A empresa já administrava funcionários, contratos e alocações em locais de trabalho em outro sistema. A automação precisava dessas informações, mas, se criássemos mais um cadastro mestre de funcionários do nosso lado, logo os valores dos dois sistemas divergiriam.

O sistema externo deveria continuar sendo o proprietário dos dados de referência, enquanto nós apenas leríamos as informações necessárias e as guardaríamos como snapshots validados. Era preciso separar a função que altera o cadastro mestre da função que usa essas informações para processar casos administrativos.

O problema era que eu ainda não tinha confirmado nem o formato real do arquivo de exportação nem um identificador estável para os funcionários. Se eu chamasse de matrícula um número exibido na tela, ou escrevesse que a exportação era em Excel sem sequer verificá-la, todo o design seguinte seria construído sobre premissas falsas.

Por isso, deixei em aberto o que eu não sabia. Foi um dia em que encontrei muitas respostas, mas também em que reescrevi frases sem parar para não fingir que sabia o que ainda desconhecia.

Integrar não era juntar pastas

No dia 15, quase não escrevi código. Passei o tempo organizando o nome do projeto, as fronteiras entre os apps, a propriedade dos dados, a ordem de migração do serviço existente e o papel da tela operacional.

Eu queria respeitar o programa criado pelo meu antecessor sem congelá-lo para sempre, e também não queria prender a automação de vendas que construí à sua estrutura atual. Ela precisava poder crescer do outbound já existente da Vox para o inbound, e depois para a administração de pessoal e a automação de documentos.

Colocar os dois projetos na mesma pasta era fácil. Difícil era decidir o que preservar, o que separar e por onde começar a expansão. O dia 15 foi quando comecei a enxergar duas automações diferentes como partes de uma única estrutura operacional.