Prep — Validação de Arquitetura IM Colliers · 30/04 17h
colliers inteligencia-mercado prep validacao
Sessão: 2026-04-30 (qua) 17:00–18:00 BRT Quem: Pedro Villa × Leandro Braga Cardoso Task tracker: T-033 Bloqueador externo: T-032 (Braga aguarda OK Ricardo Betancourt)
Objetivo da sessão (em uma frase)
Validar com Braga o dicionário as-is + a arquitetura Bronze/Silver/Gold to-be e sair com 3 decisões fechadas + escopo Onda 1 acordado, sem ambiguidade.
O que está pronto para apresentar
| Artefato | Estado | Para quê serve nesta reunião |
|---|---|---|
| Dicionário as-is (8 schemas, 4 por segmento) | ✅ pronto | Verificar se Braga reconhece tudo + corrigir lacunas semânticas |
| AS-IS vs TO-BE | ✅ pronto | 27 dores mapeadas + 9 entidades to-be + 3 decisões para tomar |
| Spec geral | ✅ existente | Background — não precisa percorrer |
Importante: o ER do as-is-vs-tobe propõe 9 entidades (5 da v1 + 4 novas:
fonte_pesquisa,ext_siila,ext_buildings,ext_fundos_cvm). Braga precisa confirmar que é fiel ao mental model dele.
Pauta sugerida (60 min)
| Bloco | Tempo | Conteúdo |
|---|---|---|
| 1 | 5 min | Recap rápido (24/04 → hoje): o que foi feito desde o discovery |
| 2 | 15 min | Walk-through do dicionário — Braga corrige/confirma campo a campo nos 8 schemas |
| 3 | 15 min | 3 decisões para fechar (próxima seção) |
| 4 | 10 min | Revisão das 27 dores — Braga confirma severidade + identifica quais “doem mais” |
| 5 | 10 min | Onda 1 acordada — escopo + prazo + dependências (T-032 Ricardo) |
| 6 | 5 min | Próximos passos + ata |
3 decisões para fechar nesta reunião
Decisão 1 — Unificar segmento ou preservar paralelo?
Recomendação Anouk: Opção A — unificar Office + Logística no Silver com subdivisao polimórfica (tipo_subdivisao enum + atributos opcionais). Destrava agentes pan-segmento.
Pergunta a Braga: “Você consegue raciocinar sobre os dois segmentos numa estrutura unificada, ou faz mais sentido manter Office e Logística como mundos paralelos?”
Decisão 2 — VENDA LOGÍSTICA sem chave estrangeira
Recomendação Anouk: Opção A — bootstrap fuzzy match (~1 dia humano). 10 anos de série temporal de cap rate destravados.
Pergunta a Braga: “Você concorda em investir 1 dia humano para fazer fuzzy match nas vendas logísticas históricas? Daqui pra frente, ID obrigatório no input.”
Decisão 3 — Escopo Onda 1
Hipótese Anouk: Bronze + Silver para os 8 schemas + dicionário formalizado + view Gold espelhando o Power BI atual (zero refator de dashboard) — 4–6 semanas após OK do Ricardo (T-032).
Pergunta a Braga: “Onda 1 entrega Bronze/Silver e mantém o Power BI igual. Onda 2 traz enriquecimento externo (SiiLa, Buildings, CVM, Receita). Faz sentido?“
3 pontos a vigiar (Pedro listou)
1. Validação sem ambiguidade
O dicionário tem 8 schemas com ~120 campos. É denso. Risco: Braga aprovar superficialmente e divergências aparecerem na implementação.
Mitigação: percorrer schema por schema, segmento por segmento, em voz alta, pedindo exemplos concretos quando uma definição parecer abstrata. Se Braga hesitar em qualquer campo, marcar como gap e voltar depois.
2. Dependência Ricardo Betancourt (T-032)
Estado atual: Braga não pode liberar dados originais sem OK do Ricardo. T-032 segue aberta com Braga como owner.
Pergunta direta: “Já falou com Ricardo? Se ainda não, posso eu pedir? Sem o OK, Onda 1 não começa.” Sair daqui com uma data: “Ricardo dá retorno até [DATA]“.
Cenário ruim: Ricardo demora ou veta. Plano B: começar Bronze com dados sintéticos derivados do dicionário (Pedro gera) para validar pipeline; quando OK chegar, troca a fonte.
3. Próximo passo objetivo
Risco real: sair com “vamos pensar” e perder 1 semana. Não sair sem:
- 3 decisões fechadas (acima)
- Data prometida para resposta do Ricardo
- Item concreto que Braga faz nesta semana (ex: corrigir 5 campos do dicionário, listar 10 imóveis para fuzzy-match piloto)
- Próxima reunião agendada (nem que seja “qd OK do Ricardo chegar, marcar em 24h”)
Riscos contextuais
| # | Risco | Mitigação na reunião |
|---|---|---|
| 1 | Braga é especialista em negócio, não em modelagem de dados — pode aprovar coisas que depois não suportam volume | Insistir em exemplos concretos: “me dê 3 imóveis onde isso acontece” |
| 2 | Ricardo não dá OK em tempo (T-032) | Plano B: dados sintéticos do dicionário para validar pipeline (acima) |
| 3 | Braga descobre na reunião que algum campo importante não está no dicionário (lacuna nossa) | OK — converter para gap, não tentar resolver na reunião. Marcar follow-up |
| 4 | Conversa derrapa para Onda 2/3 (enriquecimento externo é sedutor) | Trazer Braga de volta: “Onda 1 primeiro, antes de qualquer coisa nova” |
| 5 | Dado original é mais crítico/sensível do que se imaginava — Braga puxa o freio | Aceitar e aprofundar Plano B (sintético) — não pressionar |
O que não discutir nesta reunião
- Ferramentas específicas de Lake (Databricks vs. outras) — fora do escopo
- Custo da arquitetura — esfera Pedro × Igor × Ricardo, não Braga
- Reuso por outras frentes Colliers (CIB, CTS) — manter foco em IM
- Migração para Onda 2 (enriquecimento externo) — só sinalizar que existe roadmap
Ações pós-reunião (preparar agora)
- Template de ata: usar discovery-session adaptado
- Slot reservado para 24h pós-reunião: registrar 3 decisões em decisões + atualizar AS-IS vs TO-BE com correções de Braga
- Se Ricardo der OK durante a semana: T-032 fecha + abrir T-nova “Iniciar ingestão Bronze”
Ver também
- Spec IM
- AS-IS vs TO-BE — fonte das 3 decisões
- Dicionário — artefato central da reunião
- 04 (origem)
- T-033 · T-032 (bloqueador externo)
- Leandro Braga Cardoso
- Ricardo Betancourt (dono final dos dados)
Prep elaborado por Pedro em 2026-04-30, antes da sessão 17h.