Pular para o conteúdo
lf

trajetória/governança

Secretaria de Estado de Governança Corporativa

Engenharia de dados e de software na secretaria que monitora o plano estratégico do Estado. Setembro de 2025 até hoje.

Plataforma de equipe que substituiu a planilha de Excel onde cerca de oito monitores digitavam à mão o que os órgãos mandavam por foto, PDF e documento de texto. Hoje mais de duzentos servidores alimentam a base direto, com regra de negócio aplicada na entrada e fila de validação humana antes do dado virar relatório. Fundei o repositório e assino o módulo de coleta e validação de entregas, a intranet com chat em tempo real por WebSocket, o mapa georreferenciado de obras e o agente de LLM que escreve consulta de leitura a partir de pergunta em linguagem natural, validada antes de tocar o banco e sob usuário restrito. Plataforma de integrações, infraestrutura e boa parte dos painéis são de colegas.

200+
usuários ativos hoje, no lugar de ~8 monitores
46
órgãos com usuário ativo na plataforma
4.811
registros históricos migrados para chave de negócio

O que a secretaria existe para fazer

A Secretaria de Estado de Governança Corporativa monitora o plano estratégico das demais secretarias de Alagoas. Coletar o que cada órgão entrega, checar se confere e transformar isso em informação que sobe até o Governador. Vinte e oito secretarias e órgãos monitorados, cerca de oito monitores.

Cheguei em setembro de 2025 para fazer engenharia. A secretaria não tinha nenhuma estrutura de tecnologia.

O que eu encontrei

Cada monitor cuidava de um grupo de órgãos. Ele pedia a informação, e o órgão mandava o que tinha. Uma foto. Um PDF. Um documento de texto. Uma planilha. O monitor lia, interpretava e digitava numa planilha de Excel chamada Entregas, que já acumulava anos de escola, creche, hospital e duplicação de pista.

Quando o Governador pedia um recorte, alguém abria o arquivo, procurava a linha e colava num relatório que servia para aquele dia e mais nada. Na semana seguinte a mesma pergunta custava o mesmo trabalho.

Por que a planilha era risco

Planilha compartilhada não tem identificador, não tem tipo e não guarda quem alterou o quê. Duas linhas parecidas podem ser a mesma entrega contada duas vezes ou duas entregas diferentes, e não dá para decidir olhando o arquivo. Uma célula sobrescrita por engano some sem rastro. Estávamos guardando milhares de entregas de um governo estadual num formato que não sabe dizer se está certo.

Foi assim que apresentei o problema, e foi por aí que a equipe de dados começou. Éramos Vinícius Ventura, Fabrício Almeida, João Victor e eu.

O que a gente construiu no lugar

Modelamos o acervo de entregas em PostgreSQL. Cada entrega ganhou identificador próprio, tabelas de relacionamento e um caminho único de escrita. A ingestão saiu do arquivo e virou formulário dentro de um sistema interno, o Governança+. Hoje esse banco tem 247 tabelas e mais de mil chaves estrangeiras.

O que resolveu o problema não foi o banco, foi a regra. O formulário carrega as condições do negócio e recusa preenchimento incompleto antes de gravar. Oito campos de cabeçalho e oito por item. Quantidade maior que zero. Unidade de medida em lista fechada, nunca texto livre.

Duas regras condicionais carregam quase todo o peso. Entrega até 2024 é histórica e precisa apontar para o registro antigo correspondente. Entrega posterior precisa de evidência anexada. Por isso a migração do acervo virou uma chave de negócio legível, com 4.811 identificadores extraídos da planilha de 2015 a 2024, uma aba por ano. Uma entrega nova pode consolidar várias antigas, então a ligação é de muitos para muitos. Essa correção veio com o sistema já em produção e custou menos do que conviver com o modelo errado.

O ciclo de validação

O dado entra como pendente e só vira base de relatório depois que o setor de qualidade avalia. Quem avalia trabalha na própria visão de dados, com ação em lote e um desfazer de dez segundos, porque avaliação em lote sem arrependimento é máquina de erro caro. Reprovar exige escrever o motivo. Quando o autor corrige e reenvia, o registro volta para o fim da fila e o parecer anterior é apagado.

Duas decisões desse ciclo eu defendo em qualquer entrevista. A primeira é a trava de concorrência. Quem avalia informa qual status esperava encontrar, e a mesma condição é repetida dentro da transação, no critério do update. Com dois avaliadores clicando ao mesmo tempo, o segundo recebe conflito em vez de sobrescrever o primeiro em silêncio. Tem teste com Postgres de verdade. A segunda é a auditoria por campo. Toda edição grava a diferença campo a campo, com autor e status anterior. Sem isso, discutir número com uma secretaria vira palavra contra palavra.

E tem o custo que eu não escondo. A mesma regra vive em três lugares independentes, no navegador, no servidor e na importação por planilha. Esquecer um deles é por onde o dado ruim volta. Confio no do servidor, porque é o único que ninguém contorna. Unificar os três é dívida que sei dimensionar e ainda não paguei.

Abrir o fluxo para fora

Arrumada a casa, sobrou o começo do problema. O monitor continuava recebendo foto e PDF. A equipe de dados foi então para fora, para reunião com secretaria e órgão, negociar como o dado sai da origem.

O desenho tem dois caminhos. Órgão com equipe de tecnologia manda por integração, recebe um contrato de campos e um guia, e alimenta a base sem ninguém digitar nada. Órgão sem equipe de tecnologia ganha acesso ao formulário, com a mesma regra que o monitor usa, e cai na mesma fila de qualidade. Cada integração tem credencial própria e todo o tráfego fica registrado.

Nem toda origem entra do mesmo jeito, e essa é a parte mais interessante do desenho. Fonte de máquina, com contrato estável, grava direto. Fonte que ainda precisa de olho humano fica numa área de espera e só entra quando alguém promove. Confiar em todas do mesmo jeito seria mais simples e seria errado.

A plataforma de integrações é obra da equipe, não minha. Minha parte foi o padrão do documento que a instituição externa recebe, um guia gerado em código, em norma ABNT, depois generalizado por um colega. Meu de ponta a ponta é uma ingestão no sentido inverso, em que nós buscamos o dado na origem por rotina diária. Ela nasceu de um incidente, porque sem agendamento uma carga ficou para trás enquanto a origem seguia publicando.

Onde chegou

Em julho de 2026 a plataforma passa de duzentos usuários ativos no ano, distribuídos por mais de sessenta secretarias e órgãos, sobre um banco com 247 tabelas relacionais e mais de mil chaves estrangeiras. Saímos de cerca de oito monitores digitando planilha para os próprios órgãos alimentando a base, com regra na entrada e revisão humana antes de virar relatório.

O ciclo de qualidade amadureceu junto. Hoje uma tela confronta o que foi aprovado com a planilha de obras e classifica cada obra concluída em consistente, divergente ou sem registro, ignorando de propósito a assinatura de ordem de serviço, que marca começo e não entrega. O que importa é que o sistema deixou de só receber dado e passou a apontar onde falta registro.

A arquitetura que estamos implantando

Hoje o Governança+ é um monólito grande, com autenticação própria e permissão por recurso e por ação resolvida a cada requisição. Funciona, e é o que sustenta os usuários de hoje.

A equipe desenhou a arquitetura seguinte e ela está aprovada, com épico aberto, dez histórias e quarenta e uma tarefas mapeadas. A ideia é segmentar por domínio. Cada sistema interno vira aplicação isolada, e um domínio único de autenticação passa a ser a porta, com SSO atrás dele distribuindo acesso aos sistemas internos. Só fica exposto o que precisa estar exposto. A orquestração das requisições fica em Kubernetes.

Preciso ser exato aqui, porque esta página é peça de candidatura e não folheto. Nada disso está implantado. Não existe uma linha de SSO nem de Kubernetes rodando. Existe desenho aprovado, épico de execução e fila. O desenho é da equipe, conduzido por outro colega, e o que é meu nessa frente hoje é a camada de sessão do sistema atual. Quando estiver de pé, eu atualizo esta página. Enquanto não estiver, ela diz que não está.

O que é meu e o que é da equipe

O Governança+ é projeto de equipe e eu não sou o autor dele. Fundei o repositório e estou nele desde o primeiro commit, e ao mesmo tempo tem colega que entrega tanto quanto eu e é dono de módulo que não é meu. As duas coisas são verdade juntas, e quem conta só a primeira está vendendo.

As frentes que eu construí são o módulo de coleta e validação de entregas, a intranet corporativa com fórum e chat em tempo real por WebSocket, o mapa georreferenciado de obras e o agente de LLM que responde consulta pelo Telegram. Esse agente não é RAG, e eu já o descrevi errado antes de conferir o próprio código. Ele escreve consulta de leitura a partir da pergunta em linguagem natural, valida antes de tocar o banco e roda sob um usuário de banco restrito. Da equipe são a plataforma de integrações, a infraestrutura de deploy e observabilidade e boa parte dos painéis de programa. Quando o mapa de obras cresceu, uma colega refez a arquitetura dele em cinco fases e escreveu os testes. O produto e os algoritmos daquele módulo são meus. A arquitetura atual dele é dela.

O código é fechado, então em entrevista eu ofereço walkthrough guiado de arquitetura e decisão.

Autoria

O Governança+ é software de equipe e nenhum número desta página vale sem essa frase antes. O commit que cria o repositório é meu, de 7 de novembro de 2025, e a primeira coisa a entrar nele foi o módulo de coleta e validação de entregas. Desde então a equipe passou de duas para seis pessoas, e hoje tem colega que entrega tanto quanto eu e é dono de módulo que não é meu. Os módulos que assino estão nomeados acima. Os números desta página são de uso da plataforma, medidos no banco de produção em 26 de julho de 2026, e não de contribuição individual.

Lastro dos números

Cada número desta página com a fonte que o produziu. Os marcados como relato não foram medidos, e estão declarados como tal.

  • 200+

    usuários ativos em 2026

    medido205 perfis com last_access_at em 2026 e 230 com is_active. Publicado o piso.

  • 46

    órgãos com usuário ativo

    medido63 cadastrados em public.aux_orgaos, dos quais 46 com ao menos um usuário vinculado. Publicamos o piso medido, e não os 63 cadastrados.

  • 247

    tabelas relacionais

    medidoinformation_schema.tables, schema public, 26/07/2026

  • 1.019

    chaves estrangeiras

    medidopg_constraint where contype=f, 26/07/2026

  • 4.811

    IDs de unificação migrados

    medidoscripts/banco-entregas/data/unificacao-2015-2024.json

  • 8 e 8

    campos obrigatórios, cabeçalho e item

    medidoformValidation.ts

  • 28

    secretarias e órgãos monitorados

    relato, não medidorelato do Falcão, fato organizacional

  • ~8

    monitores

    relato, não medidorelato do Falcão