在事件风暴上，实现下面几个步骤：
- 我们首先进行了一次混沌探索，从每个人那里收集了相关的领域事件。
- 之后，我们通过整理事件、删除重复事件和微调事件来组织混乱。
- 会议结束时，我们将事件按时间顺序排列。
- 我们还指出了一个热点，强调了我们不确定的事情。
- 此外，我们还使用了一些黄色便签来记录我们不想忘记的关键部分。
- 另外，我们还指出了主设备清单流程中的初始子流程。我们突出了这些子流程，并给它们起了临时名称。
这里是我们完成后的 Miro 板快照。
看上去好像非常清晰。
但是，即使一切都井然有序，来龙去脉看起来也很清晰，我们还是意识到在先前的建模中可能还隐藏着一些漏洞或不一致的地方。
幸运的是，"大局事件风暴 "提供了两种技术：
- 显式演练（explicit walk-through）
- 反向叙述（reverse narrative）
可以帮助我们找出这些漏洞或不一致之处。
对于利益相关者来说，认识到我们不知道的事情往往是有价值的知识，尤其是当他们以前不知道的时候。
让我们从理论入手，了解如何找到事件流程中的漏洞。
1、显式演练walk-through
显式演练技术是 "事件风暴 "工作坊的一种方法，用于检查模型是否准确和完整。
它包括：
- 对研讨会期间制定的整个事件序列进行详细审查。
- 它可以让参与其中的每个人一起检查流程的每个部分。
这样，我们就能发现不一致之处、不必要的部分或任何遗漏。它确保我们所有人都了解业务流程。
在此过程中：
- 主持人可能会要求某个人按照事件的时间顺序开始讲述故事。
- 这个讲故事的角色可以传来传去，让每个人都参与进来。
为了有效地验证流程步骤并找出潜在的差距或不一致之处，在事件流程中提出正确的问题至关重要。
虽然通常是由主持人开始提问，但参与者通常也会发现其价值并开始提问。
常见的、有用的问题有助于发现潜在的缺失要素，这些问题包括：
- 为什么会发生这一事件？
- 该事件的发生还有其他原因吗？
- 该事件如何影响系统状态？
- 在此事件和之前的事件之间会发生什么？
- 此事件之后发生了什么？
- 该事件对业务有何影响？
- 该事件可能不会发生吗？如果有，这种情况的后果是什么？
- 如果该事件不止一次发生怎么办？
- 该事件是否存在特殊情况？
- 能否将此事件拆分为更小、更具体的事件？
这些问题可以帮助我们找到最初可能忽略的事件，确认每个事件的重要性，并探究事件发生前后的情况。这些问题还能帮助我们了解事情是否有可能以不同的方式发展。
这些问题很多，只是举例说明。我们不需要在每次事件中都提出所有问题，那样就太多了。经验丰富的主持人和建模者知道哪些问题对不同的事件有意义。
这种方法最重要的一点是，我们要根据事件发生的顺序来审查事件，而这一顺序是在最初的头脑风暴阶段确定的。它不同于我们用来检查工作的另一种方法，即逆向叙述法（reverse narrative）。
2、逆向叙述
我们经常使用的另一种发现流程中潜在漏洞的方法叫做反向叙述。与明确的 "走一遍walk-through "不同，我们从流程的末端开始，也就是时间轴上的最后一个事件。这种方法提供了一个独特的视角，可以发现隐藏的假设、遗漏的步骤或流程中比实际需要更复杂的部分。
通过从预期结果出发，询问 "我们是如何到达这里的？"，鼓励参与者批判性地思考之前发生的事情。回过头来看事情，我们会重新考虑每个事件是否真的有必要，或者是否可以简化。
就像在显式演练walk-through中一样，我们会提出一些问题来检查每个事件是否合理，并找出我们可能遗漏的问题。我前面提到的问题在这里也适用，但我们要对它们稍作调整，以适应逆向视角。例如
- 这个事件发生的前提是什么？
- 如何以不同的方式实现这一结果？
- 这一事件发生的必要条件是什么？
- 怎样才能避免这一事件的发生？
逆向思维不是我们通常的做事方式。想想看，从 A 到 Z 还是从 Z 到 A，哪个感觉更自然、更容易？这种逆向思维可以帮助我们注意到我们第一次错过的东西。
反向叙述技术或类似的逆向分析方法通常被执法和调查机构（如警方）用于开展刑事调查和分析事件。它尤其适用于捕捉嫌疑人故事中的不一致之处。在 "事件风暴法 "中，我们的目标不是抓住任何人的谎言，而是确保他们所描述的过程是完整的，并且不依赖于不言而喻的假设。
这两种技术的主要优点都是确保建模流程的完整性和事件的正确表达。不过，这两种技术还能帮助所有相关人员对流程达成共识。它不仅能确保各团队共享领域知识，还能确保这些知识得到验证。这有助于缩小技术和非技术参与者之间的差距，使所有人都能访问和理解复杂的领域逻辑。它还支持创建用于表达领域模型的通用语言。
既然我们已经介绍了理论知识，那就让我们看看在我们的课程中是如何实现的。
寻找流程中的漏洞
在研讨会上，我们选择了反向叙述技术。为什么呢？因为我们（建模者）只是对我们正在使用的流程略知一二，因为我们只是它的使用者。但是，我们的专家对许多隐藏的方面了如指掌，而我们却不了解。
鉴于参与者对流程的了解程度存在差异，逆向技术有助于我们更严格地检查流程。根据我的经验，当每个人对流程的理解都差不多时，明确的演示会更有效。这种情况非常罕见，所以我们通常会采用反向叙述法。
反向流程
从流程的末端开始，我们很快意识到，设备退役的原因与我们最初的想法不同。
在上一环节中，我们了解到设备退役的原因有两种，一种是设备已完全损坏且无法修复，另一种是在更换设备后选择退役。
虽然这两种情况一般都是正确的，但我们意识到事件发生的顺序并不正确。具体来说，当服务部门宣布设备无法使用时，第一步实际上是启动因损坏而更换的程序。在该子流程之后，将触发退役流程。
有趣的是，在使用反向叙述时，我们发现了一个审查设备库存的循环流程。这凸显了使用这种技术的一个重要原因--它可以帮助我们发现我们遗漏的子流程、事件，或者一开始并不清楚、也没有被识别出来的不同做事方式。
在这个被发现的审查子流程中，每个设备都可能被库存、出售或退役（如果认为太旧无法再利用）。因此，在这种情况下也可以启动退役流程。
除了我前面提到的改变流程的起点之外，我们还意识到流程本身的功能与我们最初想象的有些不同。具体来说，一旦做出决定，证明设备已退役的文档也会被发送到外部会计系统。
此外，我们将最初事件的措辞从 "设备已退役 "改为 "已决定退役设备"，以更准确地反映事件的含义。此时，设备并未实际退役。我们只是决定这样做。
设备更换流程
反向叙述帮助我们更好地理解流程的另一个例子是设备更换。起初，我们认为这是一个简单明了的过程，但在第一次会议结束时，情况却变成了复杂：
在这一阶段，只有一种方法可以启动该流程，即当承包商申请更换设备时。这将触发发放设备的常规流程，与新承包商的情况类似。然后，"旧 "电脑可能会根据其状况归还库存或退役，但前提是承包商必须清除设备数据。
然而，当我们回过头来看这些事件，并提出正确的问题时，发现情况更为复杂。
首先，我们发现了启动这一过程的其他方法。这不仅仅是承包商因为旧设备过时而要求更换新设备的问题。例如，承包商可能会丢失设备、意外损坏甚至被盗。此外，假设服务部门确定电脑无法维修。在这种情况下，这也是启动更换流程的信号，我在讨论退役流程的更新时对此进行了描述。
在所有这些情况下，都需要一台新设备，从而触发主设备发布流程。如果只是更换，承包商可以选择购买设备。这就启动了出售公司设备的流程。否则，设备将返回库存池，供其他承包商使用或退役。
在设备丢失、被盗或损坏的情况下，退役流程也会启动。此外，无论在哪种情况下，我们都需要将设备的任务从承包商处删除。我们还探讨了设备丢失或被盗时应采取的其他措施。不过，由于我们（幸运地）从未遇到过此类事件，因此我们决定推迟讨论。因此，我们在与这些情况相关的事件中添加了两个热点。
正如您所看到的，我们对这一流程进行了重大修改。我们发现了具有各种流程的不同场景，并发现了之前没有发现的事件。这显示了逆向叙述技术的威力。
（banq注：并不是逆向叙述技术的威力，而是人的认知通过反复琢磨思考的深入，切莫归因于教条，把自己变成宗教教徒）