01 — Uma mudança técnica também pode ser uma mudança de produto.
Alterar fornecedor, API ou arquitetura pode modificar comportamentos mesmo quando a interface quase não muda.
CASE / 01
Migração de bureau de crédito
Dados, regras de negócio e decisões de produto durante uma mudança estrutural.
Uma migração de bureau de crédito pode parecer uma troca de fornecedor.
Na prática, mudar a origem dos dados também significava rever estruturas, classificações, processamento e regras que sustentavam diferentes comportamentos do produto.
Durante a migração da Foregon para uma nova estrutura de dados de crédito com a Quod, participei do entendimento e da organização dos impactos dessa mudança, conectando discussões entre Produto, Engenharia e Negócio.
CONTEXTO
Trocar a fonte significava mexer no sistema.
Parte dos produtos e serviços da Foregon dependia de informações provenientes de bureaus de crédito.
Ao longo do tempo, comportamentos do produto haviam sido construídos considerando a estrutura e as regras da fonte anterior.
Por isso, a mudança não significava apenas substituir uma API. Precisávamos entender o que continuaria disponível, como os dados seriam estruturados, armazenados, atualizados e quais partes do produto dependiam deles.
DESAFIO
Receber o dado não significava saber o que fazer com ele.
A nova fonte podia retornar diferentes categorias financeiras.
Tecnicamente, receber essas informações era apenas uma parte do problema.
O produto ainda precisava definir como cada registro deveria ser interpretado, quando deveria ser considerado uma pendência e como informações novas substituiriam dados anteriores.
“Um dado só ganha significado dentro do produto quando existem regras capazes de interpretá-lo.”
MEU PAPEL
Design dentro de uma discussão técnica.
Meu papel não era definir a arquitetura de software.
Era compreender suas implicações para o produto, organizar relações, questionar comportamentos e ajudar Produto, Engenharia e Negócio a construir uma visão compartilhada do problema.
SISTEMA / 01
Tornando o sistema visível.
A informação não saía diretamente do bureau para o produto.
Existiam etapas de ingestão, armazenamento, processamento, aplicação de regras e consumo por diferentes serviços.
Visualizar esse caminho ajudou a tornar explícitas dependências que antes estavam distribuídas entre áreas e pessoas.
Separar origem, ingestão, armazenamento, processamento, regras e consumo tornou mais claro onde cada decisão precisava acontecer.
ORIGEM → INGESTÃO → ARMAZENAMENTO → PROCESSAMENTO → REGRAS → CONSUMO
COMPORTAMENTO DO SISTEMA
Quando a arquitetura muda, o comportamento do produto também pode mudar.
Parte do processamento aconteceria de forma assíncrona.
Isso significava considerar estados intermediários: uma atualização podia estar em processamento, um dado anterior podia continuar armazenado ou uma dependência externa podia falhar.
O usuário não precisava conhecer uma fila SQS, mas sentiria suas consequências através da disponibilidade e confiabilidade da informação.
SISTEMA / DADO
O dado também possui um ciclo de vida.
Score e pendências não eram informações necessariamente estáticas.
Era necessário discutir quando consultar novamente, quando persistir novos dados, quando manter registros anteriores e quando uma atualização deveria disparar outros eventos.
Esse comportamento ainda faz sentido na nova estrutura?
A migração também revelou que algumas regras existentes eram consequência do funcionamento do fornecedor anterior.
O objetivo não deveria ser apenas reproduzir o comportamento atual em uma arquitetura nova.
A mudança também criava uma oportunidade para questionar quais premissas ainda deveriam continuar existindo.
COLABORAÇÃO
As decisões formavam uma rede, não uma sequência.
Uma decisão de Negócio podia alterar uma regra de Produto.
Essa regra podia modificar o processamento técnico.
Uma limitação descoberta pela Engenharia podia exigir que Produto revisitasse uma decisão.
O trabalho avançava por dependências e revisões contínuas.
QUESTÕES EM ABERTO
Nem todas as respostas estavam disponíveis desde o início.
Algumas decisões dependiam da integração real, outras de validação com a Quod ou de definições de Negócio.
Tornar essas incertezas explícitas evitava que hipóteses temporárias se transformassem silenciosamente em regras definitivas.
“Documentar o que ainda não sabemos pode ser tão importante quanto documentar aquilo que já foi decidido.”— isso ainda é hipótese.
RESULTADO
Uma nova estrutura com premissas mais explícitas.
A migração estruturou a transição para uma nova fonte de dados de crédito e exigiu revisar dependências entre integração, armazenamento, processamento e regras do produto.
Mais importante do que substituir um fornecedor foi explicitar premissas da estrutura anterior e decidir quais delas ainda faziam sentido.
Ao separar origem do dado, processamento, interpretação e comportamento de produto, tornou-se mais claro onde cada problema precisava ser resolvido e quais áreas deveriam participar da decisão.
REFLEXÃO
O que ficou comigo.
02 — Nem todo problema de Design começa por uma interface.
Mapear dependências, organizar incertezas e criar entendimento compartilhado também fazem parte do trabalho.
03 — Tornar o problema visível melhora as decisões.
Mapas, fluxos e documentação podem funcionar como ferramentas para construir uma visão compartilhada entre pessoas que enxergam partes diferentes do sistema.
“Design também acontece na estrutura de decisões que determina o que o produto consegue fazer.”
