A maioria dos processos de escopo de MVP está quebrada. Um fundador aparece com uma ideia, o time de desenvolvimento escreve um documento de requisitos de 40 páginas ao longo de três semanas, todo mundo aprova, e aí no meio da construção o time percebe que entendeu errado o domínio principal. Semanas desperdiçadas. Orçamento queimado. Confiança abalada.
Na Meld, substituímos esse ciclo inteiro por uma única técnica: Event Storming. Em dois dias, saímos de uma ideia vaga de produto para uma arquitetura clara e construível — com o fundador na sala o tempo todo. Sem telefone sem fio. Sem surpresas.
Veja exatamente como fazemos e por que funciona.
O Que É Event Storming?
Event Storming é uma técnica de modelagem baseada em workshops, inventada por Alberto Brandolini no início dos anos 2010. Vem do mundo do Domain-Driven Design (DDD), mas você não precisa ser praticante de DDD para se beneficiar. A ideia central é enganosamente simples:
Junte as pessoas certas numa sala, dê post-its a elas e peça que mapeiem tudo o que acontece no sistema como eventos de domínio — coisas que já aconteceram, escritas no passado.
"Pedido Realizado." "Pagamento Falhou." "Plano de Voo Aprovado." "Usuário Convidado para o Workspace."
É isso. Você começa com eventos, e todo o resto — comandos, agregados, políticas, modelos de leitura — emerge da conversa. A mágica não está nos post-its. Está no entendimento compartilhado que se forma quando especialistas de domínio e engenheiros modelam a realidade juntos.
Por Que o Escopo Tradicional Falha
O escopo tradicional segue um padrão quase cascata, mesmo em equipes que se dizem ágeis:
- Semana 1-2: Calls de descoberta, entrevistas com stakeholders, análise de concorrentes
- Semana 3-4: Documento de requisitos, user stories, wireframes
- Semana 5: Estimativa, negociação de escopo, assinatura do contrato
- Semana 6+: Começa a construção, descobre-se imediatamente as lacunas
O problema não é falta de esforço — é perda na tradução. O fundador explica seu domínio. Um analista de negócios traduz em requisitos. Um designer traduz requisitos em wireframes. Um engenheiro traduz wireframes em arquitetura. A cada salto, nuances evaporam.
Quando o código finalmente é escrito, o time está construindo uma versão de telefone sem fio da visão original. E o ciclo de feedback para corrigir é medido em semanas, não em horas.
Event Storming elimina esses saltos. O fundador e o engenheiro estão literalmente de pé na mesma parede, apontando para os mesmos post-its, discutindo os mesmos conceitos de domínio em tempo real.
O Workshop de 2 Dias da Meld
Refinamos nosso processo de Event Storming em um formato compacto de dois dias que funciona excepcionalmente bem para escopo de MVPs.
Dia 1: Event Storming — Visão Geral
Objetivo: Mapear todo o domínio em alto nível. Identificar fronteiras e pontos críticos.
A sessão começa com uma única pergunta: "Me conte tudo o que acontece no seu sistema, desde o momento em que o usuário toca nele até o momento em que ele recebe valor."
Todos escrevem eventos de domínio em post-its laranja e os colocam em uma linha do tempo em papel. Incentivamos o caos primeiro — coloque tudo na parede, sem se preocupar com ordem. Depois organizamos, agrupamos e começamos a fazer as perguntas difíceis.
Atividades principais do Dia 1:
- Exploração caótica: Todos escrevem eventos simultaneamente. Duplicatas são aceitáveis. Contradições são ótimas — revelam mal-entendidos cedo.
- Ordenação na linha do tempo: Organizamos os eventos da esquerda para a direita, cronologicamente. Lacunas se tornam óbvias. "Espera, o que acontece entre 'Plano de Voo Submetido' e 'Plano de Voo Aprovado'? Quem analisa?"
- Identificação de pontos críticos: Marcamos áreas de confusão, desacordo ou complexidade com post-its rosa de "ponto crítico". São as áreas que vão afundar o projeto se ficarem vagas.
- Identificação de contextos delimitados: Agrupamentos naturais surgem. Eventos de cobrança ficam juntos. Eventos de planejamento de voo ficam juntos. Eventos de gestão de tripulação ficam juntos. Esses agrupamentos se tornam nosso primeiro esboço das fronteiras do sistema.
Ao final do Dia 1, temos um mapa do tamanho da parede cobrindo todo o domínio, marcado com pontos críticos e fronteiras aproximadas. O fundador consegue ver seu negócio refletido como um sistema pela primeira vez — e sempre identifica coisas que esqueceu de mencionar.
Dia 2: Event Storming — Nível de Design
Objetivo: Aprofundar nos contextos delimitados mais importantes e modelá-los com precisão suficiente para derivar a arquitetura.
O Dia 2 é onde vamos fundo. Escolhemos os 2-3 contextos delimitados mais críticos (os que definem o sucesso ou fracasso do MVP) e os modelamos em nível de design usando o vocabulário completo do Event Storming:
- Comandos (post-its azuis): Ações que usuários ou sistemas executam. "Submeter Plano de Voo." "Aprovar Pagamento."
- Eventos (post-its laranja): Coisas que aconteceram como resultado. "Plano de Voo Submetido." "Pagamento Aprovado."
- Agregados (post-its amarelos): Os objetos de domínio que recebem comandos e emitem eventos. "PlanodeVoo." "Assinatura." "Workspace."
- Políticas (post-its lilás): Lógica reativa. "Quando Pagamento Falhou, então Tentar Novamente em 24 Horas." "Quando Plano de Voo Submetido, então Notificar Revisor."
- Modelos de Leitura (post-its verdes): As visualizações e projeções que os usuários precisam. "Dashboard mostrando planos de voo ativos." "Histórico de cobrança."
- Sistemas Externos (post-its rosa): Integrações com terceiros. "Stripe." "API NOTAM da FAA." "SendGrid."
Esse nível de detalhe nos dá tudo o que precisamos para derivar uma arquitetura técnica. Agregados mapeiam para modelos de banco de dados. Comandos mapeiam para endpoints de API ou server actions. Políticas mapeiam para jobs em background ou event handlers. Modelos de leitura mapeiam para queries e telas de UI.
Dos Post-its à Arquitetura
A transição do Event Storm para a arquitetura é notavelmente direta:
- Contextos delimitados se tornam módulos ou serviços. Para um MVP, geralmente são módulos dentro de um monolito — não microsserviços. Não estamos over-engineering.
- Agregados se tornam modelos Prisma e a lógica de domínio central ao seu redor.
- Comandos se tornam server actions com validação e autorização.
- Eventos se tornam a espinha dorsal de fluxos assíncronos — seja chamadas simples de função em um monolito ou uma fila de mensagens em escala.
- Políticas se tornam event handlers ou jobs em background.
- Modelos de leitura se tornam queries de banco de dados otimizadas para visualizações específicas da UI.
Documentamos tudo isso em um registro conciso de decisões de arquitetura (ADR) que acompanha o projeto. Nada de especificação de 40 páginas. Apenas um mapa claro dos conceitos de domínio para a estrutura de código.
Exemplo Real: AeroCopilot
Um dos exemplos mais claros de Event Storming em ação foi nosso trabalho no AeroCopilot, uma plataforma de planejamento de voo com IA.
O domínio de planejamento de voo é enganosamente complexo. Um piloto não simplesmente "cria um plano de voo". Ele verifica o clima, revisa NOTAMs (Avisos para Missões Aéreas), calcula requisitos de combustível, avalia peso e balanceamento, registra na FAA e se adapta em tempo real se as condições mudarem. Regulamentações variam por classe de espaço aéreo, tipo de aeronave e regras de voo (VFR vs IFR).
Na sessão de Visão Geral do Dia 1, mapeamos mais de 80 eventos de domínio ao longo do ciclo de vida do voo. Pontos críticos surgiram imediatamente:
- Timing da integração meteorológica: Quando buscar os dados de clima? Na criação do plano? Antes da decolagem? Continuamente? A resposta acabou sendo "os três, mas de formas diferentes" — o que levou a um contexto delimitado de Meteorologia claro, com suas próprias políticas de atualização.
- Conformidade regulatória: As regras para planos de voo VFR vs IFR são fundamentalmente diferentes. Isso apareceu como dois fluxos distintos na parede, o que validou a decisão de modelá-los como agregados separados compartilhando uma estrutura comum de plano de voo.
- Limites do copiloto de IA: Onde a IA auxilia vs. onde o piloto mantém autoridade? O Event Storming tornou isso visível. A IA poderia sugerir rotas e sinalizar riscos, mas comandos como "Registrar Plano de Voo" tinham que permanecer como ações humanas com confirmação explícita.
Ao final do Dia 2, tínhamos uma arquitetura limpa: quatro contextos delimitados (Planejamento de Voo, Meteorologia, Regulatório e Assistência de IA), fronteiras de agregados claras e uma lista precisa de integrações. O escopo do MVP era óbvio — poderíamos construir o fluxo principal de planejamento de voo com sugestões de IA em 6 semanas, adiando a integração completa de registro regulatório para a Fase 2.
Sem Event Storming, esse projeto teria levado semanas de idas e vindas para levantar requisitos, e quase certamente teríamos errado os limites da IA — dando ao copiloto autoridade demais (risco de segurança) ou de menos (sem proposta de valor).
A Conexão com DDD
Event Storming é poderoso mesmo que você nunca tenha lido um livro de DDD, mas se torna ainda mais valioso quando conectado aos conceitos centrais do DDD:
Linguagem Ubíqua é o resultado mais importante. Depois de dois dias, todos — fundador, designer, engenheiro — usam as mesmas palavras para descrever as mesmas coisas. Um "Plano de Voo" significa a mesma coisa na conversa, no Figma, no código e no schema do banco de dados. Isso elimina toda uma categoria de bugs: aqueles causados por mal-entendidos.
Mapas de Contexto surgem naturalmente das fronteiras dos contextos delimitados. Você consegue ver onde os contextos se comunicam, quais dados cruzam fronteiras e onde são necessárias camadas anticorrupção para evitar que o modelo de um contexto contamine o outro.
Design Estratégico se torna tangível. Você pode apontar para a parede e dizer: "Este contexto delimitado é nosso domínio principal — é onde mora nossa vantagem competitiva, e vamos investir pesado aqui. Aquele contexto é de suporte — vamos usar soluções prontas. E aquele é genérico — vamos integrar um serviço de terceiros."
Por Que Isso Importa para o Seu MVP
Se você é um fundador prestes a construir um MVP, a fase de escopo é o momento de maior alavancagem em todo o seu projeto. Acerte, e seu investimento de $30K constrói exatamente o que você precisa. Erre, e você queima $30K aprendendo o que deveria ter aprendido em dois dias.
Event Storming comprime semanas de descoberta tradicional em 48 horas. Coloca fundadores e engenheiros na mesma sala, falando a mesma língua, olhando para o mesmo modelo. Revela complexidade, desacordos e riscos antes que uma única linha de código seja escrita.
Na Meld, todo projeto começa aqui. É por isso que conseguimos definir o escopo de MVPs com confiança entre $15-50K e entregar em 4-8 semanas. Não estamos adivinhando. Estamos construindo a partir de um mapa compartilhado que todos na sala ajudaram a criar.
Quer rodar um Event Storm para o seu produto? Fale com a Meld — teremos sua arquitetura mapeada antes dos post-its perderem a cola.