使用 EventStorming 进行协作流程建模 - ziobrando

使用 EventStorming 进行协作流程建模

EventStorming是一个系列的研讨会，基于在一个大的模型表面（通常是一个纸卷）上用便条实现集体讲故事。

1. Big Picture大图 是最大的规模的味道：它可以涉及相当多的人（25-30是典型的数字），并引导你探索整个业务线和结束。迭代法让参与者通过 "事件 "可视化其组织内的故事情节，增加 "人 "和 "系统"，可视化新出现的热点和边界，然后为更多的增值层提供非常详细的背景，如问题和机会，或价值发现。
2. 流程建模在建模中引入了更多的严谨性，作为协作游戏方法的一部分，强制执行特定的语法，但没有进入软件设计领域，因此允许在其更通用的解释中探索和设计流程。
3. 软件设计是连接事件和可能的软件实现之间的格式，在语法中加入了新的元素，如聚合和有边界的上下文，以允许在讨论中更加精确，而不撇开商业和可用性问题。

我们在图卢兹选择的格式是流程建模，最适合像招聘和入职这样的棘手流程，对于一个数字化的、可能是分布式的公司来说。

游戏规则
流程建模形式的主要演变是拥抱协作游戏的方法。这不是一个促进的研讨会，而是一个团队挑战，条件是我们的团队拥有所有必要的观点。

然而，每个游戏都有规则，以下是流程建模的4条规则。

1. 每条路径都应该完成--它应该以一个或多个导致稳定状态的事件结束。在招聘的背景下，它们可以是像合同签署，但也可以是合同注册。对于入职的部分，我们可能期望一个入职流程的完成，总结出许多账户创建和笔记本电脑提供的事件。
2. 语法必须得到尊重--下面会有更多关于语法的内容，但流程的结构是有限制的。而这是有充分理由的。
3. 利益相关者应该感到合理的快乐--这意味着我们将探索不同的视角和不同的轴线，以便在流程的任何时刻将创造和破坏的价值可视化。
4. 每一个热点问题都应该被解决--异议可以被显露出来，但我们应该尽量为尽可能多的问题找到可能的解决方案。

协作游戏的方法也意味着你可以对如何玩游戏有一些建议，但实际的策略是你的选择，在很大程度上取决于你团队中的人的类型和他们的协作动态。

在这个具体的研讨会上，我们决定只从橙色事件开始探索，以便在团队开始就基本顺序达成一致后再开始执行语法。但这是启动它的不同方式之一。有时我只是从头开始，或从终端事件开始。

流程建模语法
这里是流程建模语法的一个草图。我们应该能够或多或少地以这种方式从左到右阅读它。

考虑到阅读模型中的可用信息，一个用户决定在一个给定的系统上执行一个命令，这通常会导致一个事件。一些人可以根据给定的政策对这个事件做出反应。"每当这种情况发生时，我们必须那样做"，但也可能有自动的政策存在。只要有必要，读取模型将提供必要的信息来支持决策。

上图是流程建模的语法，在扁平化的版本中。

这是一个反复出现的模式，将重复进行，直到我们遇到一个终端状态。

在我们的方案中，该语法可以映射成...

上图一部分流程实例化的初始步骤，以及一些自发的热点。

一个提出棘手问题的工具
强制性语法是迫使你的建模团队问自己一些棘手问题所需的结构。

一个策略包含关于如何对特定事件做出反应的决定。它被关键词whenever所捕获，但在受到always和immediately这两个词的挑战时，效果非常好。

"我们的面试策略是尽快安排与候选人的通话"

"你总是安排一个电话吗？"

"不，有些候选人会被立即舍弃......"

"在我看来，这像是一个缺失的第一选择政策。你会立即安排电话吗？"

"不，提交的材料往往在周末到达，但我们会在第一个可用的工作日进行筛选和电话安排，通常平均需要2个工作日"

"那很好! 也许我们可以在自动欢迎词中加入这一信息，这样我们就可以避免不耐烦的人打电话来。"

提出棘手的问题迫使我们对筛选策略更加明确（现在只在工作日发生），但也有更多的读模式，以避免在欢迎电子邮件中做出虚假承诺。

策略是很重要的，因为它们是变化比较频繁的。如果你处于发现模式，这时人们不会在第一次尝试时说出全部真相。但是，正确地突出策略可以使你发现你的组织的真实行为，如果你正在走向实施，还可以使软件更加解耦，设计得更好。

一个读模型拥有做出决定所需的信息，而要研究的艰难步骤可能是筛选策略。

"你在筛选候选人时看什么？"
"我看一下他们的LinkedIn资料，即使他们没有提供链接。但一个主要因素也是应用程序中的错别字数量"

"你会检查其他社交媒体吗？"
"我可以真诚地回答吗？"

你明白这一点。读模式是另一个打开潘多拉盒子的工具，特别是在招聘这样一个明智的领域。有隐私问题，有平等问题，也有减轻风险的合理需要。

人是指对某一特定决定负责的人。当一些行动取决于人的时候，它就会变得更加有趣。
"那么谁来做筛选？"
"以前是人力资源部门，后来我们发现，我们过滤掉了一些错误的候选人。有一个著名的开发者离开了原来的工作，和我们的老板一起吃饭，他建议提交他们的申请。它在筛选时被丢弃了，因为它是空的，没有提到赞助人。现在我们的检查负责人正在仔细检查被丢弃的名单，以防万一。"

"你是如何发现超级明星的？"
"幸运的是，他们被示意到人力资源部门，那里有一种推荐名单。他们可以跳过招聘过程中恼人的第一步，并有可能直接进入合同细节的谈判。

一般来说，会有大量的移动，增加细节，和改写。大声朗读东西会引发对更清晰和精确的需求。

界定范围
一个常见的问题是，如何界定具体研讨会的范围。我的看法很简单。

我不相信在我的工作室之外定义的任何范围。

一个设计完美但不适合周围环境的过程是一种巨大的浪费，相比之下，写一打额外的贴纸只是为了确保我们正确地框定背景。

提示：背景上下文永远不会事先设定得很完美。研讨会是必要的，正是为了挑战预先想象的边界。

两种模式的味道
研讨会的关键时刻之一是认识到需要两种互补的建模风格。

1. 模糊的建模风格，处理不确定因素，以及事情发生的许多可能的替代顺序，例如，适合设计和谈判过程。
2. 一种更加机械的建模风格，用于流程的程序部分。

在我们的方案中，招聘和合同谈判有一些步骤，但每一次对话都有可能违反默认的顺序：工资可能在任何时候被讨论，或者一个错误的评论可能使双方决定放弃讨论。签订合同后，我们希望入职过程尽可能顺利，提供欢迎包、证书，如果还在办公室，则提供工作桌。

技术人员往往在机械、下游方面更有效，而没有认识到在更开放的部分需要不同的风格--有时一个检查表就是我们所需要的全部流程。