事件风暴从已经发生的业务事件出发，把跨角色的工作放在一条可共同讨论的时间线上。先收集“订单已提交”“库存已确认”等事实，再补触发动作、参与者、规则和疑问，最后收敛为需要验证或改进的具体断点。
它适合产品、运营和研发对同一流程各知道一部分，却难以说清交接关系的场景。可以用墨刀白板共同整理事件和讨论记录，让不同角色在同一张板上补充信息；关键成果不是便签数量，而是哪些分歧得到说明、哪些问题有人继续处理。
不要把它开成提前排好的流程评审
EventStorming官方网站将其描述为协作探索复杂业务领域的工作坊形式，既可用于理解现状，也可用于探索服务与软件设计。它不是只有一种固定尺寸的表格，也不是要求所有参与者先学会领域建模术语。
假设团队想减少订单付款后迟迟没有发货信息的问题。如果主持人提前画好“下单→付款→发货”三步，再请大家确认，讨论往往只会得到一串“没问题”。真正的分歧可能隐藏在付款回调、库存锁定、拣货失败和物流交接之间。
会前可以准备范围与真实材料，例如只讨论普通现货订单，从提交到签收，不讨论预售和跨境。材料包括脱敏订单记录、客服问题及现有操作说明，不需要先替大家决定流程答案。邀请确实参与这些交接的人，比只按部门凑人数更重要。
用过去式事件展开时间线
第一轮让大家分别写出自己知道的事件，一张便签只表达一件事。可以使用橙色表示事件，但颜色不是目的；图例和文字要让远程参与者也能理解。
| 容易含糊的写法 | 更适合讨论的事件 | 会追问的问题 |
|---|---|---|
| 支付 | 支付成功已确认 | 依据用户页面还是支付回调？ |
| 发货 | 包裹已交接物流 | 打印面单是否就算交接？ |
| 库存 | 库存不足已发现 | 在哪一步发现，由谁处理？ |
| 客服跟进 | 延期通知已发送 | 谁决定通知，发送失败怎样知道？ |
先把事件沿大致时间摆开，允许重复和分歧存在。两个团队都写“订单已完成”，不要马上合并；仓库可能指打包结束，客服可能指用户签收。保留两张卡并追问含义，才能暴露系统之间的术语冲突。
遇到并行事件不必强排成一条直线。付款确认与库存准备可能有不同先后约束，要把实际关系说明白。只有业务证据支持时才画顺序，不能因为白板需要整齐就补出并不存在的因果关系。
补上是谁做了什么，才发生这个事件
事件时间线大致形成后，再挑关键节点补动作和规则。例如“仓库开始拣货”是动作，“拣货已完成”是事件；执行者是仓库人员或系统；前提可能是付款已确认且库存已锁定。外部支付系统与物流系统也要显露出来，避免所有箭头看起来都属于本团队。
本例可以围绕“库存不足已发现”展开：谁收到这个信息；是换仓、拆单还是通知用户；哪些条件允许继续；哪个动作会产生下一件可观察的事。先追一条分支，不要同时把所有异常拆成完整技术设计。
更深一层的建模可增加策略、外部系统和业务对象，但无需在第一次讨论时强制使用全部卡片类型。若大家仍没说清“已发货”的含义，继续增加术语只会让问题被形式盖住。
把争论变成可回答的问题
“这里流程有问题”不够具体。可以在相邻事件旁记：“付款回调迟到时，订单页面显示什么？”“库存不足由仓库还是客服决定退款？”“打印面单后取消订单能否停止交接？”每个问题都指向可查资料或可做决定。
不要为了会议收尾把未知统一写成“待研发确认”。业务规则由谁决定、接口行为由谁核对、实际现场由谁观察，应分别记录。技术上能实现，不代表业务规则已获认可。
| 疑问 | 下一步证据 | 负责人和成果 |
|---|---|---|
| 物流接单失败是否会通知客服 | 接口返回和当前通知记录 | 研发核对触发条件，补处理结果 |
| 库存不足何时允许拆单 | 业务约定及相关客户承诺 | 运营明确规则与例外 |
| 用户为何反复询问发货 | 脱敏咨询记录、订单页观察 | 产品整理信息缺口并设计候选改法 |
会后留下三份能继续使用的成果
第一份是有范围说明和图例的事件时间线；第二份是已达成一致的业务术语与规则；第三份是仍待核实的问题、负责人和下一次讨论条件。把“已确认”与“假设”区分开，避免参会者把整张板都当成正式需求。
如果接下来要决定先做哪些用户任务，可以把确认后的问题转入用户故事地图与版本切片。事件风暴帮助理解业务发生了什么，故事地图帮助组织用户活动和交付范围；两个方法相邻，但不能把时间线直接当成功能优先级。
先选一条真实而有限的业务链，在白板上保留分歧，追清一两个交接断点。下一次讨论能从这些记录继续，而不必重新解释全流程，就已经形成了有用的协作成果。
