两个技术小错误会毁掉一场风暴事件
原文中文，约1400字，阅读约需4分钟。
📝
内容提要
本文讨论了破坏事件风暴研讨会的两个技术错误：过度参与设计活动和使用晦涩难懂的概念和术语。提供了避免这些错误的建议。
🔎
延伸解读
避免过度设计：设定时限与迭代
事件风暴是设计活动，但容易陷入“前期大设计”的陷阱，即花费数周进行详细设计而忽视通过构建学习。建议为研讨会设定不超过两整天的时限，并采用“移动脚手架”方法：起草足够草案后就开始工作，从中学习并重复。这有助于保持敏捷，避免浪费时间和精力。
用熟悉术语替代DDD行话
事件风暴源自领域驱动设计（DDD），但DDD充满晦涩概念和行话，可能让不熟悉的参与者困惑。建议用与会者熟悉的同义词替换DDD关键字，例如用“功能区”代替“边界上下文”。如果找不到合适同义词，可逐步引入DDD概念，先从大事件风暴开始，再深入学习设计级事件风暴。
主持人与参与者的共同责任
无论是主持人还是参与者，都应警惕这两种反模式。主持人可以在研讨会开始时提醒参与者注意这些陷阱。如果发现研讨会正走向这些错误，任何人都有责任举手表达担忧。及时干预可以防止研讨会失败，确保事件风暴取得成功。
❓
Q&A
事件风暴研讨会中常见的技术错误有哪些？
常见的技术错误包括过度参与设计活动和使用晦涩难懂的概念和术语。
如何避免在事件风暴研讨会中浪费时间和精力？
建议设定研讨会时限，不超过两天，并进行有效的草案起草。
为什么使用晦涩的DDD概念会导致问题？
使用晦涩的DDD概念可能让参与者感到困惑，尤其是对不熟悉DDD的人来说。
在事件风暴研讨会中，如何引入新概念？
可以用与会者熟悉的同义词替换DDD关键字，逐步引入新概念。
事件风暴研讨会的最佳时间安排是什么？
最佳安排是将研讨会时间限制在两天内，通常第一天进行主要活动，第二天进行后续。
主持人在研讨会中应注意什么？
主持人应注意避免上述两种反模式，并在研讨会开始时提醒参与者这些陷阱。
🏷️
