قسمت دوازدهم مدرن‌سازی معماری: Event Storming

1. مقدمه:

رهبران مدرن‌سازی باید از اتخاذ تصمیم‌های حیاتی در معماری بر اساس درک محدود و سطحی از محیط اجتناب کنند. وقتی جزئیات زیادی را نمی‌دانید ممکن است به سادگی یک طراحی بد را خوب فرض کنید و کار را پیش ببرید.اخیرا با یکی پلتفرم‌های ویدئو همکاری داشتم که تلاش می‌کنند نرم افزار و فرایندهای خود را به روز کنند. طرح اولیه‌ای توسط مدیران سطح بالا آماده شده بود که وقتی این ایده را در مقابل کارمندان مختلف قرار دادیم، آن‌ها دلایل متعددی پیدا کردند که چرا معماری پیشنهادی کار نمی‌کند. آن‌ها درک بسیار عمیق‌تری از پیچیدگی‌های دامنه داشتند که مدیران طراح فاقد آن بودند. خدا رو شکر این مدیران به اندازه‌ای باهوش و فروتن بودند که بازخورد را بپذیرند، اما همیشه اینطور نیست و در بسیاری موارد ایده‌های ساده لوحانه تحمیل شده و مسیر معمار برج عاج را انتخاب می‌کنند.

تکنیکی که رهبران مدرن‌سازی می‌توانند برای جلوگیری از نفوذ تفکر برج عاج به یک پروژه استفاده کنند، Big Picture Event Storming است. فرمت کارگاه به شما امکان می‌دهد تا وارد جزئیات یک دامنه شوید و اطمینان حاصل کنید که هیچ پیچیدگی یا nuance پنهانی هنگام تصمیم‌گیری‌های مهم مدرن‌سازی از قلم نیفتد. این یک تکنیک انعطاف‌پذیر است که در طول سفر مدرن‌سازی مفید خواهد بود، از اولین قدم ساخت یک چشمانداز تا شناسایی دامنه‌ها و زیردامنه‌هایی که طبقه‌بندی محصول را شکل می‌دهند و برای سازمان‌ها در انواع صنایع مؤثر است. من از این تکنیک برای تیم‌های مختلفی در بخش‌های آن را با مشتریانی در بخش‌های مختلف مانند مالی، ویدئو، خبر و ... استفاده کرده‌ام. این تکنیک یکی از مهم‌ترین ابزارها در جعبه ابزار من است بخصوص زمانی که در یک حوزه تازه وارد هستم.

کارگاه Event Stroming حول ایده حداکثر مشارکت و تنوع شرکت‌کنندگان طراحی شده است. گرد هم آوردن افراد از سراسر کسب‌وکار با مهارت‌ها و نقش‌های مختلف این امکان را فراهم می‌کند که بازتاب واقعی از نحوه عملکرد کسب‌وکار ساخته شود. هیچ محدودیتی برای شرکت‌کنندگان و بهره‌وری در یک کارگاه Event Stroming وجود ندارد: افراد محصول، توسعه‌دهندگان نرم‌افزار، متخصصان دامنه، مهندسان کیفیت، طراحان UX، حسابداران و تقریباً هر کسی که در مشارکت در مدل کسب‌وکار شرکت نقش دارد. برگزاری این کارگاه امکان‌پذیر است زیرا Event Stroming به طور عمدی با یک نماد ساده طراحی شده است که به هر کسی که در یک کارگاه شرکت می‌کند اجازه می‌دهد به راحتی دانش خود از دامنه را به اشتراک گذاشته و آن را با دانش دیگران ترکیب کند. این نماد Domain Event یا رویداد دامنه نامیده می‌شود، که به سادگی به عنوان "رویدادهایی که در دامنه اتفاق می‌افتند" تعریف می‌شوند و به صورت یک جدول زمانی از چپ به راست تشکیل می‌شوند، همان‌طور که در شکل زیر نشان داده شده است. توجه کنید که این یک نمونه کوچک است؛ در یک جلسه واقعی، یک فضای دیواری بزرگ 8 تا 20 متری با یادداشت‌های چسبنده نارنجی پوشیده خواهد شد.

در این قسمت، شما در مورد اصول Event Stroming یاد خواهید گرفت و راهنمایی عملی لازم برای برنامه‌ریزی و تسهیل اولین کارگاه Big Picture Event Storming خود را دریافت خواهید. تقریبا 4 سال پیش نیز طی مطالبی در این باره آموزش‌هایی در همین سایت داشتیم. اما این بار با ریکرد مدرن‌سازی و کمی به روز شدن مطلب به این موضوع می‌پردازیم.

2. درک Event Storming:

تکنیک Event Storming به طور آگاهانه ساده طراحی شده است. این تکنیک موانع ورود مانند نمادهای پیچیده و نقش‌ها و قوانین سخت‌گیرانه را کنار می‌گذارد. درک اصول اولیه بیشتر مربوط به درک ذهنیت Event Storming است، اینکه چگونه برای حداکثر همکاری و مشارکت بهینه‌سازی شده است ممکن است با تکنیک‌هایی دیگر تفاوت‌های زیادی داشته باشد.

شما آزاد هستید که از تکنیک‌های دیگر هنگام نقشه‌برداری از کسب‌وکار و ساخت طبقه‌بندی محصول استفاده کنید. Event Storming به عنوان یک گلوله نقره‌ای که تکنیک‌های دیگر را از رده خارج می‌کند، معرفی نشده است. اما وقتی از Event Storming استفاده می‌کنید، مهم است که فلسفه آن را بپذیرید تا حداکثر ارزش را از جلسات خود به دست آورید.

2.1. نمادها:

فرضیه‌ی اصلی Event Storming ساخت یک جدول زمانی است که از چپ به راست با استفاده از رویدادهای دامنه، که از طریق یادداشت‌های چسبنده نارنجی بیان می‌شوند، اجرا می‌شود. در حالی که برخی تکنیک‌ها، مانند نقشه‌های سفر مشتری و نقشه‌های سرویس، بسیار ساختارمند هستند، رویدادگردانی انعطاف‌پذیرتر است. با توجه به شکل زیر شما متوجه خواهید شد که، شاخه‌های مختلف و خوشه‌های به ظاهر تصادفی وجود دارند تا یک خط واحد از رویدادها که از چپ به راست اجرا می‌شوند. این ساختار به این دلیل است که Event Storming بر روی قرار دادن تمام اطلاعات مفید روی دیوار و نمایش پیچیدگی منحصر به فرد دامنه شما در هر شکلی که به طور تصادفی یا عمدی ظاهر می‌شود، تمرکز دارد. ثبت تمام جزئیات مهم‌تر از نظم است.

2.1.1. رویدادهای دامنه:

یک رویداد دامنه به طور کلی به عنوان "چیزی که در دامنه اتفاق می‌افتد" تعریف می‌شود. این تعریف دقت کمی دارد تا از حذف هر کسی که ممکن است چیزی ارزشمند برای مشارکت داشته باشد، جلوگیری کند. هر چیزی که به نظر مرتبط با کسب‌وکار شما باشد می‌تواند در جدول زمانی نمایش داده شود. لیست زیر انواع رویدادها را به همراه یک مثال از هر کدام نشان می‌دهد.

• تعامل کاربر با یک محصول — مثلاً، "بررسی اضافه شد" یا "بیمه نامه خریداری شد" یا "سریال بارگذاری شد"، جایی که کاربر با یک محصول مانند استفاده از یک برنامه موبایل تعامل می‌کند.
• اقدامات در زندگی کاربر — مثلاً، "فکر کردن به نقل مکان به خانه جدید" یا "برنامه ریزی برای خرید یک سهام"، جایی که کاربر کاری انجام می‌دهد که شامل تعامل با یک محصول نیست اما هنوز برای کسب‌وکار جالب است.
• اقدامات درون سازمان — مثلاً، "ادعا تأیید شد" یا "قسمت جدید سریال بارگذاری شد"، جایی که یک کارمند درون سازمان عملی انجام می‌دهد یا تصمیمی می‌گیرد.
• اقدامات مدیریت شده توسط نرم‌افزار — مثلاً، "راننده انتخاب شد" یا "ترنسکد قسمت جدید سریال انجام شد" ، جایی که قوانین کسب‌وکار خودکار و الگوریتم‌ها عملی را انجام می‌دهند، مانند محاسبه یک مقدار یا تصمیم‌گیری.

شما از همه این مثال‌ها متوجه خواهید شد که رویدادهای دامنه به زمان گذشته بیان می‌شوند. این یکی از معدود قوانین در Event Storming است که تا حد امکان باید رعایت شود. اگر همه از زمان گذشته استفاده کنند، جدول زمانی سازگارتر و درک آن آسان‌تر خواهد بود. علاوه بر این، استفاده از زمان گذشته این امکان را فراهم می‌کند که به یک نقطه دقیق در زمان اشاره شود. به عنوان مثال، یک رویداد "خبر منتشر شد" به لحظه دقیقی اشاره می‌کند که یک خبر منتشر و در وب‌سایت قابل مشاهده شد، که باعث می‌شود اشاره به نقاط خاص در جدول زمانی و بیان بدون ابهام آنچه قبل و بعد از آن می‌آید، آسان‌تر شود.

معمول است که مبتدیان از نام‌های مبهم‌تری مانند "ثبت‌نام کاربر" استفاده می‌کنند. مشکل این نوع نام‌گذاری این است که مشخص نیست کجا شروع و پایان می‌یابد و چه چیزی شامل می‌شود. پشت رویداد ساده مثل این، نکات ظریف زیادی وجود دارد که ممکن است مهم باشد که باز شود.

این تکنیک در مورد اندازه دقیق رویدادها بیش از حد مته به خشخاش نمیگذارد. با این حال، چند اصل اساسی وجود دارد که باید در نظر داشته باشید. از یک طرف، ماندن در سطح خیلی بالا به این معنی است که جزئیات مهم و پیچیدگی دامنه پنهان خواهد ماند. به عنوان مثال، مهم است که نه تنها مسیرهای خوش‌بینانه را بررسی کنید، بلکه سناریوها و موارد لبه‌ای مختلف را نیز بررسی کنید. از طرف دیگر، رویدادهایی که خیلی جزئی هستند ممکن است روایت واقعی کسب‌وکار را با جزئیات غیرضروری مبهم کنند، مانند "کاربر روی فرم کلیک کرد" و "آیتم در پایگاه داده ذخیره شد". گاهی اوقات مکانیزم‌های انجام کار مفید هستند، اما معمولاً بهتر است روی دامنه تمرکز کنید: قصد کاربر هنگام کلیک روی فرم چه بود (مثلاً، "درخواست عضویت")؟ و چه آیتمی در پایگاه داده ذخیره شد (مثلاً، "درخواست عضویت دریافت شد")؟

2.1.2. افراد، سیستم‌ها و نقاط حساس کانونی:

علاوه بر رویدادهای دامنه که با رنگ نارنجی نمایش داده می‌شوند، نمادهای دیگری نیز می‌توانند در یک جلسه Big Picture Event Storming استفاده شوند، همان‌طور که در شکل نشان داده شده است. یادداشت‌های چسبنده کوچک زرد برای نشان دادن نقش‌ها یا شخصیت‌ها در دامنه استفاده می‌شوند، مانند یک مشتری در بانک، تماشاچی در پلتفرم نمایش خانگی یا نماینده بیمه. یادداشت‌های چسبنده بزرگ صورتی روشن برای نشان دادن سیستم‌هایی مانند سیستم مدیریت سفارش (OMS) یا یک پلتفرم پرداخت شخص ثالث خارجی استفاده می‌شوند. یادداشت‌های چسبنده صورتی تیره (فوشیا) چرخانده شده برای نشان دادن نقاط کانونی (Hotspot)استفاده می‌شوند. یک نقطه کانونی به عنوان یک نماینده برای نشان دادن چیزی مهم، مانند یک مشکل یا یک منطقه اختلاف استفاده می‌شود. به طور کلی، این نمادها به تدریج معرفی می‌شوند تا یادگیری ساده باشد.

2.1.3. موارد خاص، جریان‌های موازی و حلقه‌ها:

در هر دامنه‌ی پیچیده، بسیاری از شاخه‌ها وجود خواهند داشت که سناریوها و موارد حساس خاص مختلف را نشان می‌دهند. اغلب فرآیندهایی نیز به طور موازی اتفاق می‌افتند. برخلاف تکنیک‌های دیگر، Event Storming نماد خاصی برای نشان دادن این مفاهیم ندارد. با این حال، آن‌ها هنوز هم می‌توانند به راحتی نمایش داده شوند. ساده‌ترین رویکرد برای تجسم چندین سناریوی ممکن این است که یک مسیر خوش‌بینانه در جریان اصلی حفظ کنید و موارد خاص را به عنوان جریان‌های افقی زیر جریان اصلی نشان دهید، همان‌طور که در شکل زیر نشان داده شده است.

شما در شکل بالا متوجه خواهید شد که نقطه داغ خالی باقی مانده است، در حالی که سایر شکل‌ها توضیحاتی روی آن‌ها نوشته شده است. قاعده کلی من این است که وقتی مشکل از قبل واضح است، زمان را ذخیره می‌کنم و نقطه داغ را خالی می‌گذارم. در این مثال، واضح است که خراب شدن برنامه یک مشکل است. جایی که یک مسیر خوش‌بینانه واحد وجود ندارد، حاشیه‌نویسی‌ها می‌توانند در ابتدای هر جریان اضافه شوند که نام سناریو را توصیف می‌کنند، همان‌طور که در شکل زیر نشان داده شده است.

جریان‌های موازی می‌توانند با تقسیم جریان اصلی به چندین شاخه تجسم شوند، همان‌طور که در شکل بعد نشان داده شده است. اگر تشخیص اینکه یک شاخه خاص به طور موازی اجرا می‌شود یا یک سناریوی جایگزین است آسان نباشد، یادداشت‌های اضافی می‌توانند اضافه شوند. برای مثال در تصویر از یک یادداشت چسبنده زرد با کلمه "موازی" روی آن استفاده شده است. علاوه بر این تکنیک‌ها، همچنین ممکن است از استراتژی‌های مرتب‌سازی مختلف، که بعداً پوشش داده می‌شوند، مانند ایجاد خطوط شنا برای تأکید بر ماهیت یک دامنه و جریان‌های مختلف استفاده شود.
نمایش حلقه‌ها سوال پیچیده‌تری نسبت به فقط تصمیم‌گیری در مورد نحوه تجسم آن‌ها است. ما باید بپرسیم، "آیا واقعاً به یک حلقه در اینجا نیاز داریم، یا رویکرد بهتری وجود دارد؟" ما نمی‌توانیم در زندگی واقعی به عقب برگردیم، و این موضوع معمولاً در مورد جدول زمانی در Event Storming نیز صادق است.

به عنوان مثال، پرداخت با تاخیر به یک ISP (ارائه‌دهنده خدمات اینترنت) را در نظر بگیرید. اگر یک مشتری به موقع پرداخت نکند، ISP به او یک نامه یادآوری می‌فرستد. اگر مشتری پس از 30 روز هنوز پرداخت نکند، نامه دیگری ارسال می‌شود. این ممکن است به نظر یک حلقه برسد، اما آیا واقعاً اینطور است؟ آیا این حلقه برای همیشه ادامه می‌یابد، و آیا هر تکرار حلقه یکسان است؟ به عنوان مثال، اگر یک مشتری اولین پیام را نادیده بگیرد، پیام دیگری با زبان قوی‌تر و تهدید به قطع اینترنت مشتری دریافت می‌کند. اگر مشتری هنوز پرداخت نکند، تکرار سوم یک تماس تلفنی به جای نامه خواهد بود. و سپس، در نهایت، اگر مشتری هنوز پرداخت نکند، خدمات او لغو می‌شود و فرآیند وصول بدهی آغاز می‌شود. بنابراین، هر زمان که احساس می‌کنید می‌خواهید از نماد حلقه خاصی استفاده کنید، ابتدا سعی کنید چند تکرار از حلقه را نقشه‌برداری کنید و سعی کنید تفاوت هر تکرار را شناسایی کنید.

2.1.4. خطوط و فلش‌ها:

یک تمایل رایج در جلسات Event Storming رسم خطوط و فلش‌ها است، همان‌طور که در تکنیک‌های دیگر وجود دارد. خطوط و فلش‌ها به راحتی مانند یادداشت‌های چسبنده قابل جابجایی نیستند، و این بسیار مشکل‌ساز است زیرا رویدادهای دامنه در یک جلسه معمولی زیاد جابجا می‌شوند. از نظر مفهومی، خطوط و فلش‌ها معنا ندارند زیرا سفر به عقب و جلو در زمان غیرممکن است. ممکن است سخت به نظر برسد که علیه غرایز خود مبارزه کنید، اما به سرعت به عدم نیاز به خطوط و فلش‌ها عادت خواهید کرد.

2.2. اکتشاف آشفته:

علاوه بر دیواری پوشیده از یادداشت‌های چسبنده نارنجی، ویژگی تعیین‌کننده دیگر Big Picture Event Storming، اکتشاف آشفته است. بیشتر تکنیک‌ها برای نقشه‌برداری از سفرهای کاربر و فرآیندهای کسب‌وکار یک رویکرد گام به گام ساختارمند دارند. از طرف دیگر، Event Storming با کل گروه شروع می‌شود که تعداد زیادی رویداد دامنه اضافه می‌کنند و آن‌ها را به طور موازی روی دیوار قرار می‌دهند. نتیجه این کار بسیار به هم ریخته به نظر می‌رسد، و شرکت در یک جلسه Event Storming برای اولین بار ممکن است کمی ناراحت‌کننده به نظر برسد. با این حال، مرحله آشفته Event Storming بخش کلیدی فلسفه آن است. اکتشاف آشفته این امکان را فراهم می‌کند که هر شرکت‌کننده آنچه را که در مورد دامنه می‌داند و آنچه برای او مهم است را مطرح کند، و تا حد امکان ایده‌ها و بینش‌ها را با کمترین سوگیری و پیش‌فیلترینگ ممکن روی دیوار قرار دهد. در اصل، طوفان فکری فردی به منظور اجازه دادن به ظهور مهم‌ترین موضوعات است. بعدا این به هم ریختگی به راحتی مرتب خواهد شد.

اکتشاف آشفته برای ساختار‌های نوظهور یک توانمندساز است. این مفهوم در مورد اجازه دادن به مرزهای دامنه برای ظهور از به هم ریختگی و آشفتگی به جای تعریف هر ساختاری از قبل است. اضافه کردن برخی ساختارها از قبل، مانند مرزهای دامنه یا سازمانی موجود، ساختارهای تعریف شده در طول کارگاه را تحت تأثیر قرار می‌دهد. در عین حال، اجازه دادن به ظهور ساختارها با استفاده از تکنیک‌هایی مانند رویدادهای محوری (که بعداً در توضیح داده می‌شوند) احتمالاً مرزهای دامنه ایده‌آلی را نشان می‌دهد که تحت تأثیر فرضیات نادرست قرار نگرفته‌اند.

نکته: در برخی موقعیت‌ها، اکتشاف آشفته رویکرد درستی نیست و کار را با چالش‌هایی همراه خواهد کرد. جلسات از راه دور مثالی از ایجاد مشکل با اکتشاف آشفته است. اکتشاف آشفته و مکالمات موازی به سختی از راه دور قابل بازسازی و مدیریت هستند، بنابراین می‌توان از حالتی خاص استفاده کرد که در آن فقط یک نفر رویدادها را روی جدول زمانی قرار می‌دهد و سایر شرکت‌کنندگان آن‌ها را راهنمایی می‌کنند. شخصا گاهی از حالت تک‌رشته‌ای برای کارگاه‌های حضوری نیز استفاده می‌کنم. وقتی انرژی و همکاری شرکت کنندگان کم است یا می‌خواهم جهت کارگاه را کنترل کنم معمولا در نقش مدل‌ساز ایجاد تایم لاین را مدیریت میکنم.

2.3. بهینه‌سازی برای یادگیری و همکاری:

برای بسیاری از افراد، ایده‌های ارائه شده در این بخش می‌تواند درک Event Storming را دشوار کند. به عنوان مثال، عدم وجود نمادهای خاص و دقت اغلب منجر به نظراتی مانند موارد زیر می‌شود:

• این یک به هم ریختگی است؛ سازگار نیست.
• برخی رویدادها بسیار سطح بالا هستند و در بخش‌های دیگر جدول زمانی، جزئیات بسیار بیشتری وجود دارد.

غلبه بر این موانع نیاز به پذیرش این دارد که Event Storming یک تکنیک بهینه‌سازی شده برای همکاری و یادگیری است. جدول زمانی روی دیوار راهی است برای اینکه افراد به طور مشارکتی آنچه را که به طور فردی می‌دانند را در یک تصویر از دانش جمعی به اشتراک گذارند که این تصویر خود به عنوان پایه‌ای برای مکالمات نقشه‌برداری استفاده خواهد شد.

اگر برخی بخش‌های جدول زمانی جزئیات بیشتری داشته باشند، ممکن است به این دلیل باشد که افراد تصمیم گرفته‌اند که ارزش دارد به برخی مناطق زوم کنند و به برخی دیگر نه. همچنین ممکن است نشان‌دهنده این باشد که برخی افراد که مناطق کمتر تعریف شده را درک می‌کنند در کارگاه حضور نداشته‌اند. یادداشت‌های چسبنده روی دیوار فقط یک ابزار برای داشتن مکالمات عالی، به اشتراک گذاری دانش و شناسایی فرصت‌های بهبود هستند. خیلی روی مصنوع یا ارزش استفاده مجدد بعد از جلسه وسواس نداشته باشید. اما بعد از جلسه آزادانه عکس بگیرید و هر یادگیری مهم را به فرمت‌های دیگر تقطیر کنید.

2.4. زمان استفاده از Event Storming:

داشتن Event Storming در جعبه ابزار شما به این معنی است که برای مقابله با طیف گسترده‌ای از سناریوها مجهز هستید. هنگام ساخت یک چشمانداز برای مدرن‌سازی معماری، این مفید است که بخش‌هایی از دامنه را بررسی کنید تا فرصت‌های مدرن‌سازی را شناسایی کنید یا یک پیشنهاد موجود برای مدرن‌سازی یک بخش خاص از کسب‌وکار را تأیید کنید.

در یک پروژه بورسی، ما به دنبال منطقه‌ای از کسب‌وکار بودیم که مناسب برای یک برش اولیه مدرن‌سازی باشد. ما چهار منطقه کاندید را شناسایی کرده بودیم که به نظر می‌رسید بر اساس ارائه نتایج کسب‌وکار و فرصت‌های یادگیری، مناسب باشند. اما هنوز به اطلاعات بیشتری نیاز داشتیم تا به ما کمک کند انتخاب نهایی را انجام دهیم. بنابراین تصمیم گرفتیم جلسات Event Storming را اجرا کنیم. پس از اجرای یک جلسه Event Storming در یک منطقه، به سرعت آن را رد کردیم. همان‌طور که وارد جزئیات دامنه شدیم، می‌توانستیم تعداد زیادی وابستگی بین زیردامنه‌های مختلف را ببینیم. مدرن‌سازی آن منطقه شامل 3 تیم و لمس پنج پایگاه کد در کنار 3 دیتابیس می‌شد. اینکار برای یک برش اولیه بسیار چالش‌برانگیز و پرخطر بود.

یکی از موضوعات اساسی در تلاش برای مدرن‌سازی معماری، طراحی مرزهای نرم‌افزار و سازمانی است که باید توسط مرزهای دامنه هدایت شود. برای من، Event Storming ابزاری ضروری در این فرآیند است و اغلب به عنوان نقطه شروع عمل می‌کند زیرا رویدادگردانی می‌تواند به دامنه‌ها و زیردامنه‌ها تقسیم شود، همان‌طور که تصویر نشان داده شده است.

نکته‌ی عالی‌ای که در مورد استفاده از Event Stormingبرای تعریف دامنه‌ها و زیردامنه‌ها وجود دارد این است که Event Storming نشان‌دهنده دانش جمعی دامنه از دیدگاه‌های متنوع است. این به ما اطمینان بسیار بالایی می‌دهد که ما مرزهای دامنه را بر اساس تمام جزئیات کلیدی دامنه شکل می‌دهیم و فرضیات حیاتی را از دست نمی‌دهیم. البته دقت کنید این فرض تا زمانی که اطمینان حاصل کنیم تمام افراد کلیدی در کارگاه حضور دارند صحیح است.

در قسمت‌های بعدی استفاده از Event Storming را برای شناسایی دامنه‌ها و زیردامنه‌ها، از جمله طیف وسیعی از اصول و اکتشافات، نشان می‌دهد. سپس می‌توان از تکنیک‌های دیگر، مانند مدل‌سازی جریان پیام دامنه و توپولوژی‌های تیم، برای ارزیابی و اصلاح مرزهای شناسایی شده با Event Stormingاستفاده کرد. در مجموع، این ابزارها به چالش کشیدن طراحی از بسیاری از دیدگاه‌ها کمک می‌کنند، و اطمینان بالایی می‌دهند که تمام عوامل مهم در نظر گرفته شده‌اند و طراحی برای نتایج مدرن‌سازی مورد نظر بهینه شده است.

در این قسمت روی Big Picture تمرکز داریم، در آینده به مدل‌سازی فرآیند و طراحی نرم‌افزار به کمک Event Storming خواهیم پرداخت. Big Picture برای اکتشاف آشفته و یادگیری گروهی در یک منطقه بزرگ بهینه‌سازی شده است. مدل‌سازی فرآیند می‌تواند برای نقشه‌برداری از مناطق کوچکتر دامنه با درشت دانگی بالاتر با استفاده از ساختار و نماد بیشتر استفاده شود. اینکار برای نقشه‌برداری از وضعیت فعلی و طراحی فرآیندهای جدید یا بهبود یافته عالی است. طراحی نرم‌افزار به کمک Event Storming (که به عنوان رویدادگردانی سطح طراحی نیز شناخته می‌شود) ساختار و جزئیات بیشتری اضافه می‌کند و به عنوان یک پل برای نقشه‌برداری بین دامنه و نرم‌افزار که به شدت با دامنه همسو است، استفاده می‌شود.

2.5.نکته:

طی سالیانی که از این تکنیک برای کارهای مختلف و با همراهی تیم های متفاوت استفاده کرده ام درس بزرگی که دریافتم این است که Event Storming یک تکنیک است که فضایی ایجاد می‌کند که مکالمات و یادگیری ارزشمند در آن اتفاق می‌افتد. اگر چندین تیم در یک منطقه کسب‌وکار کار می‌کنند یا بخشی از یک ابتکار بزرگتر هستند، فقط گرد هم آوردن آن‌ها برای یک جلسه Event Storming می‌تواند منجر به بسیاری از نتایج مثبت شود حتی بدون یک هدف مشخص شده از قبل. این کشف است — ما نمی‌دانیم چه چیزی را کشف خواهیم کرد. اگر زمان را برای مکاشفات سرمایه‌گذاری نکنید، ممکن است هرگز ندانید که چه فرصت‌های یادگیری مهمی را از دست می‌دهید.

3. اجرای یک جلسه Event Storming:

در حالی که Event Storming بر اساس یک نماد ساده است که به یک گروه بزرگ با مهارت‌ها و تخصص‌های متنوع اجازه می‌دهد به راحتی همکاری کنند، باید اعتراف کنم که برنامه‌ریزی و اجرای یک جلسه Event Storming کمی چالش‌برانگیزتر است. پیدا کردن زمانی که برای همه مناسب باشد، آماده کردن یک اتاق با فضای مدل‌سازی زیاد، و به ویژه مدیریت دینامیک یک گروه ترکیبی از شخصیت‌ها می‌تواند مشکل‌ساز باشد. خوشبختانه، پس از چند کارگاه اول، مواجهه با مشکلات آسان‌تر می‌شود. مانند بیشتر مهارت‌ها، تمرین و پشتکار داشتن کلید موفقیت است. این بخش برای کمک به آماده‌سازی شما برای اولین کارگاه شما با ارائه راهنمایی برای هر مرحله از فرآیند است.

3.1. برنامه‌ریزی یک جلسه:

محدوده و هدف اولین عناصری هستند که هنگام برنامه‌ریزی یک جلسه Event Storming باید در نظر گرفته شوند. اگر محدوده را خیلی محدود تعیین کنید، ممکن است ارتباطات مهم بین بخش‌های مختلف دامنه را از دست بدهید که برای منطقه‌ای که روی آن تمرکز کرده‌اید حیاتی هستند. با این حال، اگر محدوده را خیلی گسترده تعیین کنید، مجبور خواهید بود افراد زیادی را دعوت کنید، و ممکن است تسهیل چنین گروه بزرگی غیرممکن شود. من معمولاً با محدودیت حدود 15 تا حداکثر 20 شرکت‌کننده برای یک جلسه Big Picture Event Storming کار می‌کنم،تجربه نفرات بیشتر موفقی نداشته ام و شاید برای تعداد بیشتر نیاز باشد تسهیل‌گرهای بیشتری همراه ما باشند. من این تعداد را نقطه مناسبی برای بسیاری از بینش‌ها و دیدگاه‌های متنوع بدون اینکه تعداد افراد طاقت‌فرسا شود، می‌دانم. با این محدودیت انسانی در ذهن، سپس این سوال مطرح می‌شود که چگونه می‌توانید محدوده را به اندازه‌ای گسترده تعیین کنید که تمام افرادی که نیاز به حضور در جلسه دارند را شامل شود.

برای ساخت یک تصویر دقیق از نحوه عملکرد کسب‌وکار، شرکت‌کنندگان باید تا حد امکان نماینده کسب‌وکار باشند: طراحان UX، افراد محصول، متخصصان حوزه کسب و کار، مهندسان، تسترها، افراد پشتیبانی و غیره. فرض کنید شما در حال ساخت یک پیشنهاد برای اولین برش مدرن‌سازی هستید و یک دامنه خاص (محدوده 2) را شناسایی کرده‌اید که می‌تواند نقطه شروع خوبی باشد. دامنه شامل پنج زیردامنه است که هر کدام توسط یک تیم جداگانه اداره می‌شود، با حدود 30 مهندس نرم‌افزار که در آن دامنه کار می‌کنند. حداقل لیست شرکت‌کنندگان ممکن است چیزی شبیه به این باشد:

• 5 توسعه‌دهنده نرم‌افزار (حداقل یک نفر از هر تیم)
• 1 مهندس ارشد/معمار/مدیر مهندسی (مسئول کل دامنه)
• 2 مدیر محصول (به طور جمعی مسئول کل دامنه)
• 1 طراح UX (در کل دامنه کار می‌کند)
• 1 متخصص کسب و کار
• 1 نماینده پشتیبانی مشتری
• 1 مهندس عملیات/پلتفرم
• 1 تستر

انتخاب یک دامنه در محدوده‌ی 2 این پیشفرض را دارد که مرزها در آن سطح از قبل تعیین شده‌اند. اما اگر اینطور نباشد و هدف کارگاه شما تعیین آن‌ها باشد، در این سناریو منطقی است که ابتدا یک سری کارگاه‌ها برای تعیین مرزهای محدوده 2 داشته باشید و سپس جلسات عمیق‌تری در هر یک از آن‌ها برگزار کنید. کارگاه‌های Event Storming که چندین دامنه محدوده 2 را پوشش می‌دهند ممکن است از 15 تیم یا بیشتر عبور کنند، بنابراین در آن سطح ممکن است امکان حضور یک مهندس از هر تیم وجود نداشته باشد. ممکن است به اجبار فقط رهبر فنی هر دامنه را برای شرکت در کارگاه دعوت کنیم.

دعوت از شرکت‌کنندگان و کمک به آن‌ها برای دیدن اهمیت حضور در جلسه گاهی اوقات نیاز به تلاش و صبر دارد. معمولاً تمایلی برای خروجی‌های مشخص و یک دستور کار برای جلسه وجود دارد. از آنجا که Event Storming شامل مقدار زیادی مکاشفه است، ارائه لیستی از خروجی‌های خاص و یک دستور کار دقیقه به دقیقه از قبل امکان‌پذیر نیست.

در زمینه مدرن‌سازی، ربط دادن جلسه به موضوع مدرن‌سازی و توضیحی کوتاه مثل "ما به دنبال مدرن‌سازی این منطقه از کسب‌وکار هستیم، و این کارگاه شامل نقشه‌برداری از وضعیت فعلی و بررسی وضعیت‌های آینده خواهد بود"، یا "ما به دنبال تعریف دامنه‌ها و زیردامنه‌ها در این منطقه هستیم، و از تکنیکی به نام رویدادگردانی به عنوان نقطه شروع استفاده خواهیم کرد." کارآمد و جذاب خواهد بود.

مدت زمان نیز یک ملاحظه‌ی مهم است. برای یک جلسه رویدادگردانی پایه با کمی زمان برای بررسی مشکلات و فرصت‌ها، حداقل 3 ساعت را پیشنهاد می‌کنم. به طور متناوب، اگر قصد دارید یک دامنه را نقشه‌برداری کنید، چندین مشکل و فرصت را بررسی کنید که به وجود می‌آیند، و زیردامنه‌ها را شناسایی کنید، توصیه می‌کنم حداقل 3 روز کامل را کنار بگذارید.

3.2. آماده‌سازی فضا:

فضای موجود و چیدمان اتاق می‌تواند تأثیر زیادی بر نحوه‌ی پیشرفت جلسه داشته باشد، بنابراین آماده‌سازی فضای مدل‌سازی ضروری است. حداقل باید 8 متر فضای آزاد روی دیواری داشته باشید، مانند شکل زیر. جایی که شرکت‌کنندگان می‌توانند به راحتی جمع شوند و حرکت کنند. بهتر است از کاغذ روی دیوار استفاده کنید زیرا ریسک استفاده از سطح دیوار برای یادداشت‌های چسبنده زیاد است و معمولا چسبندگی خوبی ندارند. یک میز کوچک برای تمام یادداشت‌های چسبنده، خودکارها و سایر لوازم کارگاه نیز لازم است. علاوه بر این، بهتر است تمام میزهای دیگر را از اتاق خارج کنید تا حواس‌پرتی‌های خارجی مانند استفاده افراد از لپ‌تاپ به حداقل برسد. یک جلسه معمولی بین 3 ساعت تا یک روز کامل طول می‌کشد، بنابراین غیرمنطقی است که کاملاً صندلی‌ها را حذف کنید، اما ممکن است بخواهید آن‌ها را برای یک یا دو ساعت اول که می‌خواهید انرژی و مشارکت بالا باشد، بردارید. یکی از مزایای جلسات مجازی با استفاده از ابزارهایی مانند Miro این است که نیازی به نگرانی در مورد این چیزها نیست و فضای مدل‌سازی نامحدود دارید.

3.3. شروع جلسه:

معمولا دوست دارم کارگاه‌ها را با یک مرور سریع از هدف شروع کنم، سپس با یک سوال شخصی-اجتماعی مرتبط با شرکت کنندگان ادامه می‌دهم. علاوه بر معرفی معمول که نقش فرد در شرکت و امیدهای او برای کارگاه را پوشش می‌دهد، این سوال همچنین فضایی ایجاد می‌کند که افراد چیزی درباره خودشان را آشکار کنند و کمی سرگرمی به جلسه بیاورند. برخی از مثال‌هایی که من استفاده کرده‌ام عبارتند از: "اولین شغل شما چه بود؟"، "برنامه تلویزیونی مورد علاقه شما در کودکی چه بود؟"، و "چه کسی را بیشتر دوست دارید ملاقات کنید (هر فردی که زنده است یا بوده) و چرا؟"

در بخش بعدی در صورتی که افراد با Event Stroming آشنا نباشند، با یک مثال ساده و در دامنه‌ای عمومی موضوع را خیلی سریع برای همه معرفی می‌کنم. بعد از اینکه از درک کلی کارگاه توسط همه شرکت کنندگان مطمئن شدم، سراغ شروع جلسه می‌روم.

امکان‌های متعددی برای شروع نقشه‌برداری از دامنه وجود دارد. برخی افراد دوست دارند مستقیماً وارد Event Storming شوند و جدول زمانی را بسازند، در حالی که دیگران دوست دارند با فعالیت‌های دیگر شروع کنند. کارگاه Event Storming در ابتدا به طور عمدی آشفته است؛ ممکن است مدتی طول بکشد تا افراد شروع به درک ارزش‌های آن کنند. بنابراین، اغلب تمایل دارم با فعالیتی شروع کنم که افراد را گرم کند تا در مورد دامنه فکر کنند و ارزش کافی را ارائه دهد تا افراد اطمینان داشته باشند که بقیه کارگاه نیز ارزش ارائه خواهد داد. تکنیکی که من استفاده می‌کنم، نقشه‌برداری از نقش‌ها و شخصیت‌ها در دامنه است.

با لیست کردن تمام افراد در دامنه و توصیف هدف آن‌ها، کارهایی که باید انجام دهند، و سایر اطلاعات مفید درباره‌ی آن‌ها، شما شروع به لمس مناطق مختلف دامنه می‌کنید و مکالمات ارزشمندی دارید. شما در حال شروع به ساخت تصویر بزرگ و ایجاد ارتباطات هستید، که آماده‌سازی ایده‌آلی برای یک جلسه Big Pircutre Event Storming است. افراد محصول و UX ممکن است قبلاً این کار را انجام داده باشند، اما توصیه می‌کنم از یک بوم خالی شروع کنید. هدف این است که برای جلسه گرم شوید و همه را به فکر وادارید. پس اگر شخصیت‌هایی از قبل وجود دارند، در ابتدا استفاده نکنید، بلکه افراد را در تابلو خالی وارد کرده و بعدا از افراد موجود برای مقایسه استفاده کنید.

در تصویر بعد، می‌توانید نمونه‌ای از نقشه‌برداری نقش‌ها و شخصیت‌ها در یک دامنه را ببینید. این تصویر بر اساس یک کارگاه با مشتری‌ای در بخش املاک است . فقط با لیست کردن نقش‌ها و مسئولیت‌ها، افراد شروع به تقسیم آن‌ها به طرف تقاضا و طرف عرضه کردند و اصطلاحات کلیدی را تعریف کردند. ما همچنین اینکه چگونه یک نفر می‌تواند چندین نقش را بازی کند را برجسته کردیم، مانند یک نفر که اغلب همزمان خریدار و فروشنده است.

3.4. ساخت جدول زمانی:

وقتی آماده شروع رویدادگردانی هستید، اولین قدم ساخت جدول زمانی است. به هر فرد چند یادداشت چسبنده نارنجی و یک خودکار داده می‌شود. سپس به همه گفته می‌شود که شروع به اضافه کردن رویدادهای دامنه در طول جدول زمانی کنند، آن‌ها را در هر جایی که احساس می‌کنند درست است، قرار دهند. ابتدا یک توضیح کوتاه از رویدادهای دامنه لازم است، و سپس افراد می‌توانند شروع به اضافه کردن یادداشت‌های چسبنده در هر جایی که دوست دارند کنند.

معمولاً رویدادهای دامنه را به عنوان چیزی که می‌تواند در فرآیند کسب‌وکار یا دنیای کاربر اتفاق بیفتد، به زمان گذشته بیان می‌کنم. و برخی مثال‌های کلی مانند "بیمه نامه خریداری شد"، "منو منتشر شد"، "حادثه گزارش شد"، و "دستگاه فعال شد" ارائه می‌دهم. همچنین مهم است که توضیح دهید که هر چیزی می‌تواند ناقص باشد. من به شرکت‌کنندگان تأکید می‌کنم که قسمت اول یک مرحله طوفان فکری به هم ریخته است، و سپس همه چیز را مرتب می‌کنیم.

یک تکنیک کنترل‌شده‌تر برای شروع جلسه، تسهیل چند رویداد اولیه است. به عنوان تسهیل‌کننده، از یک شرکت‌کننده بخواهید مثالی از یک رویداد بدهد و آن را روی جدول زمانی قرار دهد. سپس از شرکت‌کننده دیگری بخواهید یک رویداد متفاوت بدهد. در این حالت، من از شرکت‌کنندگان می‌خواهم که به رویدادهایی فکر کنند که در بخش‌های دیگر جدول زمانی اتفاق می‌افتند، همان‌طور که در شکل زیر نشان داده شده است. به این ترتیب، افراد به کل فرآیند فکر می‌کنند و کل جدول زمانی روی دیوار را پر می‌کنند. فضای خالی بین رویدادها نشان‌دهنده این است که من انتظار دارم شرکت‌کنندگان شکاف‌ها را پر کنند و وارد جزئیات دامنه شوند تا اینکه در سطح بالا بمانند. پس از اضافه شدن چهار یا پنج رویداد اولیه، و زمانی که افراد می‌دانند یک رویداد دامنه خوب چیست، جلسه به اکتشاف آشفته تغییر می‌کند.

چند لحظه اول هنگام ساخت جدول زمانی می‌تواند دوره گیج‌کننده‌ای باشد. افراد هنوز دقیقاً نمی‌دانند چه کاری انجام دهند و یک رویداد دامنه چیست. به عنوان یک تسهیل‌کننده، بهترین کار این است که به افراد یادآوری کنید نگران نباشند زیرا جدول زمانی بعداً مرتب می‌شود. در ابتدا، هدف این است که تا حد امکان رویدادها را روی دیوار قرار دهید، هر جایی که به نظر می‌رسد مناسب است. با این حال، اگر افراد خیلی از مسیر خارج شوند، باید مداخله کنید و آن‌ها را اصلاح کنید. به عنوان مثال، اگر متوجه شوید که کسی رویدادها را به زمان گذشته بیان نمی‌کند، می‌توانید به آرامی آن‌ها را اصلاح کنید. پس از 5 دقیقه، برخی افراد ممکن است هیچ رویدادی اضافه نکرده باشند، بنابراین می‌توانید از آن‌ها بپرسید که آیا می‌توانید کاری برای کمک انجام دهید. ممکن است بخواهید آن‌ها را تشویق کنید تا کار خود را توصیف کنند و سپس شروع به مدل‌سازی آن برای آن‌ها کنید، اما سپس به آرامی عقب‌نشینی کنید و به آن‌ها بگویید که باید ادامه دهند. مراقب نقش تسهیل‌گری خود باشید که به مدل‌ساز تغییر پیدا نکند.

مشکلی ندارم که افراد در مرحله اول صحبت کنند، تا زمانی که به اضافه کردن رویدادها ادامه دهند و در مورد رویدادهای روی دیوار بحث کنند. اگر به نظر می‌رسد که خیلی صحبت می‌کنند، توصیه می‌کنم به آرامی افراد را تشویق کنید که به طوفان فکری رویدادها ادامه دهند و به آن‌ها بگویید که بعداً در مورد آن‌ها بحث خواهیم کرد. به عنوان یک راهنمای کلی، من دوست دارم حداقل 25 دقیقه فعالیت مداوم و دیواری که به خوبی با یادداشت‌های چسبنده نارنجی پوشیده شده است، قبل از اجازه دادن به مکالمات طولانی ببینم. وقتی انرژی کاهش می‌یابد، می‌توانید به گروه اعلام کنید که زمان استراحت است، و وقتی بعد از استراحت دوباره جمع می‌شویم، به هم ریختگی را مرتب می‌کنیم و آن را معنا می‌دهیم.

3.5. مرتب‌سازی جدول زمانی:

این مرحله شامل مرتب‌کردن جدول زمانی به هم ریخته با استفاده از یکی از تکنیک‌های مرتب‌سازی متعدد است. ساده‌ترین رویکرد این است که از گروه بخواهید تمام رویدادها را مرور کنند و آن‌ها را به ترتیب درست قرار دهند. همه رویدادها به طور طبیعی در یک مکان واحد قرار نمی‌گیرند، بنابراین می‌توانید به شرکت‌کنندگان بگویید که می‌توانند یک مکان را انتخاب کنند یا برای حالا رویدادها را تکرار کنند. این کار اغلب نقطه خوبی برای گروه است که از نماد نقش‌ها/شخصیت‌ها و سیستم‌های خارجی استفاده کنند.

فقط خواستن از یک گروه برای مرتب‌کردن جدول زمانی کمی خوش‌بینانه است، بنابراین یک رویکرد ساختارمندتر می‌تواند مفید باشد. رایج‌ترین رویکرد، رویدادهای محوری (Pivotal Event) نامیده می‌شود، که شامل تقسیم جدول زمانی به بخش‌هایی با استفاده از رویدادهای خاص به عنوان نقطه تفکیک بین مناطق مختلف، با استفاده از نوارهای زرد برای برجسته‌کردن آن‌ها است. من همچنین رویدادهای محوری را بزرگ‌تر و سیاه می‌کنم تا وقتی از راه دور کار می‌کنم،کاملا مشخص باشد.

انتخاب رویدادهای محوری یک علم دقیق نیست، اما افراد اغلب هنگام شناسایی آن‌ها به دنبال دقت و کمال هستند. مهم‌ترین چیز این است که جدول زمانی را به حدود 5 تا 10 بخش کوچک‌تر تقسیم کنید تا رویدادها راحت‌تر مرتب شوند. توضیح ساده من برای شناسایی رویدادهای محوری این است که به دنبال یک نقطه انتقال باشید، مانند شروع یا پایان یک فرآیند یا زیرفرآیند. برخی مثال‌ها شامل "درخواست عضویت"، "تیکت پشتیبانی ایجاد شد"، "حساب غیرفعال شد"، و "خبر منتشر شد" است. یک راه برای بررسی اینکه آیا رویدادهای محوری مناسبی دارید این است که بپرسید: آیا رویدادهای محوری به تنهایی داستان سطح بالای دامنه را بیان می‌کنند؟

همچنین ممکن است یک رویدادگردانی را با استفاده از swimlaneها مرتب کنید. با این حال، این رویکردی نیست که اغلب به عنوان راهکار اصلی استفاده کنم زیرا می‌تواند خیلی محدودکننده باشد، اما می‌تواند انتخاب خوبی باشد وقتی دامنه شامل تعاملات پیچیده رفت و برگشتی بین چندین بازیگر است یا به عنوان راهکاری جانبی برای مرتب سازی از این تکنیک استفاده کنیم.

همان‌طور که در شکل زیر نشان داده شده است، نقاط عطف زمانی (Temporal Event) رویکرد دیگری است که در آن جدول زمانی بر اساس لحظات خاص تقسیم می‌شود. به عنوان مثال، من یک جلسه Event Storming برای یک شرکت فناوری مدیریت همایش که نرم افزاری برای مدیریت آنلاین همایش ها ارائه می‌کرد، اجرا کردم. ما نقاط عطف زمانی مانند روز شروع دریافت مقالات،شروع داولی مقالات، شروع بلیط فروشی، یک هفته قبل از همایش، روز همایش، فردای همایش، یک ماه بعد از برگزاری همایش و غیره را بر اساس نقاط عطفی که بیشترین اهمیت را برای متخصصان دامنه داشتند، اضافه کردیم.

3.6. مرور جدول زمانی:

پس از اینکه جدول زمانی به طور منطقی مرتب شد، کل گروه دور هم جمع می‌شوند و جدول زمانی را مرور می‌کنند. این مرور زمانی است که افراد شروع به دیدن تصویر بزرگ و نحوه‌ی تأثیر بخش‌های مختلف کسب‌وکار بر یکدیگر می‌کنند. این زمانی است که افراد چیزهای زیادی در مورد بخش‌هایی از شرکت که با آن‌ها آشنا نیستند، یاد می‌گیرند. به عنوان تسهیل‌کننده، من از یک شرکت‌کننده می‌خواهم داوطلب شود تا جدول زمانی را مرور کند. وقتی این کار را انجام می‌دهند، رویدادهای روی جدول زمانی را مانند یک داستان می‌خوانند در حالی که از چپ به راست در طول جدول زمانی راه می‌روند. سوالات از شرکت‌کنندگان و تسهیل‌کننده در هر زمان مجاز است.

هنگام مرور جدول زمانی، هدف این نیست که در مورد هر مشکل یا فرصت توقف و بحث کنید. هدف اول این است که داستان را از ابتدا تا انتها بیان کنید تا همه بتوانند تصویر بزرگ را ببینند و دوم این است که تمام مکالمات جالب ممکن را شناسایی کنید. بنابراین، در این مرحله می‌توانید از نقاط حساس به عنوان یک نگه‌دارنده استفاده کنید، همان‌طور که در شکل زیر نشان داده شده است (نقاط حساس می‌توانند نگه‌دارنده‌ و ارجاع دهنده‌هایی برای هر چیزی که می‌خواهید به آن بازگردید، مانند مشکلات، بخش‌های پیچیده، اختلافات و غیره باشند). هر زمان که یک مکالمه در مورد یک منطقه خاص از جدول زمانی بیش از 2 دقیقه طول بکشد، به گروه اطلاع دهید که یک نقطه حساس قرار می‌دهید و به حرکت در طول جدول زمانی ادامه می‌دهید.

همان‌طور که در حال مرور جدول زمانی و بیان داستان کسب‌وکار هستید، ممکن است بخواهید رویدادها را اضافه و اصلاح کنید یا به اضافه کردن نمادهای اضافی مانند سیستم‌ها و نقش‌ها ادامه دهید. همچنین تمرین خوبی است که اصطلاحات مهم یا گیج‌کننده صنعت را تعریف کنید، همان‌طور که در شکل زیر نشان داده شده است. برای جلسات حضوری، می‌توانید از یادداشت‌های چسبنده بزرگ زرد یا برگه‌های کوچک کاغذ برای تعاریف اصطلاحات استفاده کنید.

4. شناسایی مشکلات و فرصت‌ها:

برای رهبران مدرن‌سازی، درک بیشتر از نحوه عملکرد سیستم فعلی ضروری است. شناسایی مشکلات و فرصت‌های موجود در محیط، برای اطمینان از اینکه مدرن‌سازی ارزش‌هایی بیش از بازنویسی سیستم قدیمی با فناوری‌های جدید ارائه می‌دهد، مهم است. پس از ساخت و مرتب‌کردن جدول زمانی با حضور بسیاری از افراد کلیدی، فرصتی عالی برای شناسایی این بینش‌ها است. در حال حاضر برخی نقاط حساس روی جدول زمانی از مرور وجود خواهد داشت. اما قبل از رای‌گیری در مورد اینکه کدام یک از آن‌ها را بررسی کنید، خوب است که به شرکت‌کنندگان 5 تا 10 دقیقه فرصت دهید تا مشکلات و فرصت‌های خود را با استفاده از همان نماد نقطه داغ برای مشکلات و یادداشت‌های چسبنده سبز برای فرصت‌ها اضافه کنند.

یک چیزی که همیشه در مورد این بخش از کارگاه قدردانی می‌کنم این است که همه ایده‌های عالی دارند. افرادی که ممکن است آن‌ها را فنی برچسب بزنیم، مانند توسعه‌دهندگان، تسترها و معماران، اغلب برخی از بهترین ایده‌های کسب‌وکار و محصول را دارند. بر این اساس، به عنوان یک تسهیل‌کننده، حیاتی است که همه را تشویق کنید تا ایده‌های خود را به اشتراک بگذارند، صرف نظر از نقش آن‌ها. وقتی به سمت یک مدل عملیاتی متمرکز بر محصول حرکت می‌کنیم، کل تیم مسئول کشف و تحویل هستند. بنابراین، این لحظه فرصتی عالی برای تشویق و الگوبرداری از این رفتارهای فرهنگی مطلوب است.

4.1. مشکلات:

هیچ محدودیتی در نوع مشکلاتی که می‌توانند در جلسه Event Storming مطرح شوند، وجود ندارد. هر چیزی که بر مشتری، کارمندان، محصول، فرآیندهای داخلی، فرهنگ شرکت، قابلیت اطمینان سیستم یا رضایت شغلی تأثیر منفی بگذارد، ممکن است ارزش برجسته‌کردن داشته باشد. این بخش به برخی مثال‌های رایج اشاره می‌کند تا به شما ایده‌ای از آنچه انتظار دارید، بدهد.

4.1.1. کاربران از یک جریان خارج می‌شوند:

کاربران از یک جریان خارج می‌شوند چیزی است که من همیشه به دنبال آن هستم زیرا این اغلب جایی است که چیزی در مورد محصول بهینه‌سازی نشده است، و کسب‌وکار در حال از دست دادن درآمد بالقوه است. رویدادهایی مانند "سبد خرید منقضی شد"، "مشتری به رقیب تغییر کرد"، و "طرح ماهانه لغو شد"، همگی مثال‌هایی از یک مشتری هستند که از برخی خطوط لوله خارج می‌شوند، جایی که ممکن است ارزش داشته باشد عمیق‌تر شویم و بفهمیم چرا این اتفاقات رخ داده و چگونه می‌توان از آن‌ها جلوگیری کرد.

4.1.2. نارضایتی کاربر:

نارضایتی کاربر به طور کلی چیزی است که همیشه باید به دنبال آن باشید. کدام بخش‌های تجربه آن‌ها در تعامل با محصولات و سازمان شما باعث بیشترین استرس، ناامیدی و خشم می‌شود؟ شاید محصول آن‌ها را مجبور کند که برای انجام یک کار ساده از موانع زیادی عبور کنند، یا گردش کار پشتیبانی مشتری بین چندین نماینده پرش کند، به آن‌ها اطلاعات متناقض بدهد. چندین نفر که نیازهای کاربران را درک می‌کنند، مانند مدیران محصول، محققان UX و نمایندگان پشتیبانی، برای کشف نارضایتی واقعی کاربر ضروری هستند. هنگام ساخت محصولات داخلی، باید خود کاربران را به کارگاه‌ها دعوت کنید تا تجربیات دست اول آن‌ها را دریافت کنید.

معمولاً چندین دیدگاه برای بررسی راه‌های مقابله با نارضایتی کاربر وجود دارد. از یک طرف، چگونه می‌توانید از وقوع مشکل جلوگیری کنید؟ و از طرف دیگر، اگر نمی‌توانید کاملاً از آن جلوگیری کنید، چگونه می‌توانید مشکلات ایجاد شده را هنگام وقوع کاهش دهید؟ یک شرکت، ایده تشویق کاربران برای علامت‌گذاری داده‌های نادرست را ارائه داد. اینکار به جلوگیری از مشکلات آینده کمک کرد و با نشان دادن تلاش برای حل مشکلات به کاربران، به مقابله با نارضایتی آن‌ها کمک کرد.

4.1.3. فناوری غیرقابل اعتماد:

در برخی دامنه‌ها، فناوری منبع اصلی مشکلات است، از سیستم‌های غیرقابل اعتمادی که به تجربه کاربری ضعیف کمک می‌کنند تا سیستم‌های IoT که در آن دستگاه‌ها می‌توانند ناگهان آفلاین شوند یا شروع به رفتار غیرعادی کنند. وقتی من با یک شرکت بیمه کار می‌کردم، یکی از همکاران که مسئول پیکربندی ساختار نرم افزار بود توضیح داد که چگونه باید رکوردهایی را در یک سیستم ایجاد کند و سپس شناسه تولید شده توسط سیستم را در سیستم دیگری کپی کند تا بتواند جنبه‌های بخش دیگری را پیکر بندی کند. همان‌طور که احتمالاً می‌توانید حدس بزنید، طیف وسیعی از مشکلات ناشی از یک خطای انسانی ناخواسته تا سیستم‌هایی که به درستی همگام‌سازی نمی‌شدند، به وجود آمد. این نشان می‌دهد که چرا مهم است که وارد جزئیات سیستم‌های مختلف شوید. اضافه کردن برخی از یادداشت‌های چسبنده بزرگ صورتی به جدول زمانی ممکن است مکالمات ارزشمندی درباره فرصت‌های کلیدی مدرنیزه‌سازی فناوری باز کند.

4.1.4. دانش گم‌شده و مورد اختلاف:

دانش — هم گم‌شده و هم مورد اختلاف — منبع اصلی دیگری از مشکلات است. در یک جلسه Event Storming که اجرا کردم، هیچ‌کس نمی‌دانست که محصول چگونه فراتر از UI کار می‌کند زیرا تمام توسعه‌دهندگانی که روی آن بخش از سیستم کار می‌کردند، شرکت را ترک کرده بودند. معمولاً مشکلات اینقدر شدید نیست، اما کمبود دانش رایج است و ارزش برجسته‌کردن دارد.

دانش مورد اختلاف وقتی افراد در مورد حقایق اختلاف نظر دارند می‌تواند حتی جالب‌تر نیز باشد. زمانی، یک کارگاه برای یک شرکت در صنعت پخش مویرگی اجرا کردم، و پرسیدم، "اعتبار خرید نسیه چگونه محاسبه می‌شود؟" یک توسعه‌دهنده برای توضیح الگوریتم پیش قدم شد، اما سپس مدیر بازاریابی حرف او را رد کرد. توسعه‌دهنده لپ‌تاپ خود را باز کرد تا تأیید کند که کد چگونه کار می‌کند، و مدیر بازاریابی شوکه شد که متوجه شد چرا گزارش‌های آن‌ها معنی‌دار نبودند. آن‌ها مدتی بود که این سوءتفاهم را داشتند اما به جای اینکه این مسئله را مرتفع کنند آن‌ها را نادیده گرفته و بر اساس آن‌ها تصمیم نیز می‌گرفتند.

4.2. فرصت‌ها:

هر مشکلی می‌تواند منجر به فرصت‌ شود، اما بسیاری از انواع فرصت‌ها حتی وقتی همه چیز به خوبی یا همان‌طور که انتظار می‌رود کار می‌کند، می‌توانند پیدا شوند. به عنوان مثال، در طول یک جلسه رویدادگردانی، یک سوال خوب که می‌تواند به یافتن بهبودها کمک کند این است که بپرسید، "چگونه می‌توانیم از این اتفاق زودتر سود ببریم؟".

4.2.1. هدف‌گیری بخش‌های جدید مشتری:

مدرن‌سازی یک سرمایه‌گذاری است که شرکت را برای رشد و نوآوری موقعیت‌دهی می‌کند. یک نوع فرصتی که باید به دنبال آن باشید، گسترش TAM (بازار قابل دسترسی کل) محصولات و خدمات شما است. همان‌طور که در Event Storming قدم می‌زنید، بپرسید، "کدام مشتریانی که در حال حاضر جذب نمی‌کنیم ممکن است به این خدمت یا کالا علاقه‌مند باشند؟" یا "چقدر باید این بخش از سیستم را تغییر یا تطبیق دهیم تا برای انواع مختلف مشتریان جذاب باشد؟" به عنوان مثال، اگر محصول B2C است، آیا می‌توان آن را برای B2B نیز تطبیق داد؟

4.2.2. استفاده بهتر از داده‌ها:

موضوع رایجی که در جلسات Event Storming با آن مواجه خواهید شد، داده‌ها است. شما نظراتی مانند "اگر می‌توانستیم اطلاعات بیشتری از این اطلاعات را ثبت کنیم، می‌توانستیم از آن برای انجام <چیزی> بسیار بهتر استفاده کنیم"، یا "ما داده‌های زیادی ثبت می‌کنیم، و کارهای بسیار بیشتری وجود دارد که می‌توانیم با آن‌ها انجام دهیم" خواهید شنید. به عنوان یک تسهیل‌کننده، می‌توانید آگاهی را به این موضوعات بیاورید و از افراد بخواهید فرصت‌هایی را در طول جدول زمانی اضافه کنند که فکر می‌کنند داده‌های مفیدتری می‌توانند ثبت یا اعمال شوند. در یک جلسه با یک سازمان بهداشتی، ما در مورد اینکه برخی پزشکان شرکای مشکل‌سازی بودند به دلیل عدم پاسخگویی آن‌ها بحث می‌کردیم. یکی از مهندسان اشاره کرد که سازمان قبلاً اطلاعات زیادی دارد و می‌تواند به راحتی شروع به اندازه‌گیری عملکرد پزشکان و توصیه به مشتریان در مورد پاسخگوترین پزشکان در منطقه خود کند. مشکل این بود که داده‌ها در سیستم‌های قدیمی و پایگاه‌های داده مختلف پراکنده بودند.

4.2.3. افزایش مشارکت:

در برخی دامنه‌ها، بررسی فرصت‌هایی برای افزایش مشارکت مشتری می‌تواند ارزشمند باشد. وقتی با یک شرکت سفر کار می‌کردم، آن‌ها توضیح دادند که فصلی بودن یک مشکل بزرگ است. مردم یک بار در سال یک تعطیلات رزرو می‌کنند، و برای بقیه سال مشارکت کمی یا هیچ مشارکتی وجود ندارد. شرکت سفر به دنبال راه‌هایی برای افزایش مشارکت سالانه با مشتری بود، مانند نوشتن محتوای مفید برای ایجاد ارتباطات و وفاداری قوی‌تر با مشتریان خود. Event Storming، با رویکرد مبتنی بر جدول زمانی خود، زمینه خوبی برای این مکالمات فراهم می‌کند. به عنوان مثال، بین هر تعامل مشتری، می‌توانید این سوال را بپرسید: "آیا راه‌هایی وجود دارد که بتوانیم در این فاصله با مشتری مشارکت کنیم؟"

4.3.3. استفاده از فناوری‌های جدید:

همان‌طور که در مطلب مرتبط با واردلی مپینگ دیدیم، محیط‌ها به طور مداوم در حال تکامل هستند. در طول یک جلسه Event Storming، مهم است که چگونگی تکامل محیط را در نظر گرفته و چه فرصت‌های جدیدی ممکن است با این تغییر در دسترس باشد. اینکار می‌تواند به شکل پیشرفت‌های فناوری جدید یا محصولات جدید SaaS باشد که وارد بازار شده‌اند. همیشه ارزش دارد که هر بخش از جدول زمانی را به چالش بکشید و بپرسید: "آیا محیط اطراف این رویداد تغییر کرده است؟ آیا امکان‌های جدیدی وجود دارد که در زمان طراحی این بخش از سیستم در دسترس نبوده است؟"

4.3.4. رسیدگی به مشکلات و فرصت‌ها:

در بیشتر موارد، تعداد زیادی مشکل و فرصت کشف خواهید کرد. شما زمان کافی برای رسیدگی به همه آن‌ها در طول جلسه نخواهید داشت، بنابراین باید به عنوان یک گروه تصمیم بگیرید که بهترین استفاده از زمان خود را چگونه انجام دهید. رویکرد پیش‌فرض رای‌گیری نقطه‌ای است، جایی که هر فرد تعداد مشخصی رای برای قرار دادن در کنار نقاط بحث که فکر می‌کنند مهم‌ترین هستند، دریافت می‌کند. در برخی موارد،زمانی که کارگاه هدف خاصی دارد و ذینفع بیشترین درک را از مسائلی که باید پوشش داده شود دارد، ذینفع کلیدی ممکن است تعیین کند که کجا تمرکز شود.

برای هر موضوعی که نمی‌توان در طول جلسه به آن رسیدگی کرد، چندین امکان پیگیری وجود دارد، از جمله:

• سازماندهی کارگاه‌های Big Picture بیشتر با محدوده‌ی یک منطقه خاص.
• گذراندن زمان با کاربران برای درک کامل تجربه آن‌ها. Event Storming عالی است، اما گاهی اوقات بهترین راه برای یادگیری در مورد دامنه و فرصت‌های آن، گذراندن زمان با افرادی است که در آن کار می‌کنند.
• برنامه‌ریزی جلسات مدل‌سازی فرآیند با کمک Event Storming برای طراحی فرآیندهای جدید و آینده.
• برنامه‌ریزی کارگاه‌ها برای تأیید مرزهای دامنه (با استفاده از تکنیک‌های پوشش داده شده در قسمت‌های بعدی).

پس از بحث در مورد فرمت کارگاه‌ها و اینکه چگونه یک Event Storming پایه عالی برای کشف مشکلات و فرصت‌ها است، مهم است که کارگاه‌ها را به طور مؤثر تسهیل کنید تا پتانسیل این مفاهیم را باز کنید، که موضوع بخش بعدی است.

4. نکات و چالش‌های تسهیل‌کننده:

چسباندن یادداشت‌های چسبنده روی دیوار در یک جدول زمانی تقریبی بسیار ساده به نظر می‌رسد، اما هر چه بیشتر Event Storming را تمرین کنید، بیشتر یاد می‌گیرید که چگونه از هر جلسه مزایایی استخراج کنید. منحنی یادگیری برای شرکت‌کنندگان به طور عمدی کوتاه است، اما به عنوان یک تسهیل‌کننده، منحنی یادگیری تقریباً بی‌نهایت است. هیچ چیز جای تمرین را نمی‌گیرد، اما نکات و ترفندهای زیر به شما کمک می‌کند تا زمان یادگیری خود را تسریع کنید و از مشکلات رایج مبتدیان اجتناب کنید.

4.1. اکتشافات مدل‌سازی:

کیفیت رویدادهای قرار داده شده روی جدول زمانی می‌تواند تأثیر زیادی بر بینش‌های به دست آمده و مشکلات و فرصت‌های کشف شده داشته باشد. رویدادهای خوب افراد را به پرسیدن سوالات جالب وادار می‌کنند و اجازه می‌دهند دانش افراد مختلف به یک دیدگاه جمعی از نحوه عملکرد کسب‌وکار متصل شود.

همان‌طور که در طول این قسمت اشاره شد، هیچ قانون، فرآیند یا نمودار جریانی سخت‌گیرانه‌ای وجود ندارد که به شما کمک کند تعیین کنید چه چیزی یک رویداد خوب است. و احتمالاً مفید هم نخواهد بود زیرا ایده این است که تعداد ایده‌های به اشتراک گذاشته شده را به حداکثر برسانید و سپس آنچه مفید نیست را فیلتر کنید، نه اینکه اطلاعات مهم به دلیل نگرانی افراد از شکستن قوانین به اشتراک گذاشته نشود. با این حال، برخی هیوریستیک‌ها می‌توانند شما را در مسیر درست هدایت کنند بدون اینکه به مشارکت آسیب بزنند، و تمرکز این بخش است. فقط به یاد داشته باشید که آن‌ها را خیلی مشتاقانه در ابتدای یک کارگاه اعمال نکنید تا مطمئن شوید که افراد را ناراحت نمی‌کنید و آن‌ها را از این تکنیک جدید دور نمی‌کنید.

4.1.1. مراقب انتزاع بیش از حد باشید:

وقتی رویدادهای دامنه اطلاعات زیادی را انتزاع می‌کنند، تفاوت‌های ظریف و مهم دامنه را پنهان می‌کنند. تصویر بعد دنباله‌ای از رویدادها را نشان می‌دهد که به نظر می‌رسد رویدادهای دامنه خوبی هستند. آن‌ها روی یادداشت‌های چسبنده نارنجی هستند، به زمان گذشته بیان شده‌اند، و آنچه در دامنه اتفاق می‌افتد را توضیح می‌دهند تا اینکه خیلی فنی باشند، مانند کلیک‌های دکمه و تراکنش‌های پایگاه داده. با این حال، مقدار زیادی پیچیدگی توسط فقط چهار رویداد نشان داده شده است. در این سطح جزئیات چیز کمی برای یادگیری وجود دارد. چگونه می‌توانیم فرصت‌هایی برای بهبود فرآیندهای ثبت‌نام، اشتراک یا ایجاد کمپین‌ها شناسایی کنیم اگر هر کدام توسط یک یادداشت چسبنده پوشش داده شده است؟

محدوده کارگاه روی این که چه چیزی خیلی سطح بالا در نظر گرفته شود و چه چیزی معقول باشد، و احتمالاً امکان ندارد که در هر بخش از دامنه به عمق جزئیات برویم تأثیر می‌گذارد. تصمیم‌گیری در مورد اینکه گروه باید و نباید روی کجا تمرکز کند، یکی از مهم‌ترین مهارت‌ها به عنوان یک تسهیل‌کننده است و متأسفانه یکی از سخت‌ترین‌ها برای تسلط.

4.1.2. مدل نکنید؛ یک داستان بگویید:

برای جبران رویدادهای بیش از حد انتزاعی، یک هیوریستیک مفید برای به خاطر سپردن این است که "مدل نکنید؛ یک داستان بگویید." این جمله کلیشه‌ای به معنای پذیرش جزئیات و مشخصات و عدم تلاش برای ایجاد مدل‌های انتزاعی است که تمام موارد استفاده را پوشش می‌دهد. ما ممکن است یک شخصیت تعریف کنیم و به طور خاص‌تر آنچه را که آن‌ها می‌بینند و انجام می‌دهند در سطح جزئیات بیشتری توصیف کنیم.

برای مهندسان و معمارانی که از مدل‌سازی لذت می‌برند، این ممکن است غیرطبیعی به نظر برسد. اما توانایی تغییر بین مشخصات و مدل‌های انتزاعی در زمان‌های مناسب مهم است.

4.1.3. تکرار واگرایی:

وقتی واگرایی در دامنه بر اساس برخی ویژگی‌ها شناسایی می‌کنید، ایده خوبی است که به دنبال واگرایی‌های مشابه در طول جدول زمانی باشید. در شکل زیر، جدول زمانی ابتدا بر اساس اینکه تبلیغ‌کننده برای یک استارت‌آپ یا یک شرکت بزرگ کار می‌کند، واگرا می‌شود. پس از مرحله ثبت‌نام، جدول زمانی ممکن است همگرا شود و تجربه در برخی مکان‌ها مشابه باشد، اما نوع تبلیغ‌کننده ممکن است دلیلی برای واگرایی‌های بعدی در جریان باشد.

4.1.4. کنجکاو مفاهیم معرفی نشده باشید:

وقتی یک مفهوم جدید ناگهان در جدول زمانی ظاهر می‌شود، ممکن است نشانه‌ای باشد که بخش‌هایی از دامنه نمایش داده نشده‌اند. به عنوان مثال، نقش یک متخصص در دامنه در رویداد "کمک متخصص ارائه شد" ظاهر می‌شود. اگر این اولین باری است که این مفهوم در جدول زمانی ظاهر می‌شود، خوب است که برخی سوالات کاوش‌کننده مانند "چگونه یک متخصص در این لحظه در دسترس می‌شود؟" یا "می‌توانید داستان یک متخصص را توصیف کنید؟" بپرسید. با اضافه کردن داستان متخصص به جدول زمانی، ممکن است بینش‌ها و فرصت‌های جدیدی را آشکار کند که افراد فکر می‌کردند بی‌ربط هستند. کشف همه چیز در مورد کاوش راه‌های جدید و به چالش کشیدن فرضیات است.

4.1.5. رویدادهای با نام یکسان را واجد شرایط کنید:

گاهی اوقات رویدادهایی وجود دارند که در چندین مکان در جدول زمانی ظاهر می‌شوند. در ابتدا ممکن است به نظر برسد که همان رویداد است، اما خطر این وجود دارد که تفاوت ظریفی بین رویدادها وجود داشته باشد که پنهان است. یک سوال تسهیل‌کننده خوب این است: "آیا همان چیزها می‌توانند بعد از هر رویداد اتفاق بیفتند؟". ممکن است وسواسی یا آکادمیک به نظر برسد، اما روشن‌سازی و پاک‌سازی اصطلاحات دامنه برای ایجاد یک زبان مشترک، همکاری را بسیار آسان‌تر می‌کند.
4.1.6. رویدادهای مشابه که به نظر یکسان هستند را نگه دارید:

گاهی اوقات ممکن است به نظر برسد که چندین رویداد نمایانگر همان چیز هستند، و ممکن است وسوسه شوید که یکی را نگه دارید و دیگری را دور بیندازید. با این حال، قبل از انجام این کار، ارزش دارد که عمیق‌تر شوید. ممکن است این دو رویداد نمایانگر چیزهای کمی متفاوت یا همان رویداد از دیدگاه‌های مختلف افراد باشند. دو رویدادی که به نظر یکسان می‌رسند حتی ممکن است نشانه‌ای از مرزهای دامنه باشند. به عنوان مثال، رویدادهای "پیام ارسال شد" و "پیام دریافت شد" را در نظر بگیرید. ممکن است به نظر برسد که آن‌ها در همان زمان دقیق اتفاق می‌افتند و نمایانگر دو دیدگاه از همان چیز هستند. با این حال، آن‌ها می‌توانند هر طرف مرز بین دو زیردامنه مانند "ترکیب پیام" و "مشاهده پیام" را نشان دهند. این یک مثال از یک هیوریستیک کلی‌تر است، "تعارض را قابل مشاهده کنید." شما همیشه نیازی به عجله برای یافتن یک راه‌حل ندارید؛ گاهی اوقات خوب است که نظرات متضاد را تجسم کنید و اجازه دهید مدتی بمانند.

4.1.7. از فضای خالی به طور هدفمند استفاده کنید:

به عنوان یک تسهیل‌کننده، می‌توانید از فضای سفید برای تشویق شرکت‌کنندگان به پیشروی عمیق‌تر به جزئیات استفاده کنید. اگر احساس می‌کنید که رویدادها سطح بالا و بیش از حد انتزاعی هستند، می‌توانید دو رویداد را با هم بگیرید، آن‌ها را گسترش دهید، و به گروه اطلاع دهید که می‌خواهید شکاف را با رویدادهای بیشتری در سطح ریز یا درشت دانگی بیشتر پر کنند.

4.1.8. ترکیب Example Mapping و Event Storming:

تکنیک Example Mapping یک تکنیک مشارکتی است که برای کشف سناریوها و موارد لبه‌ای مختلف استفاده می‌شود. وقتی با Event Storming ترکیب شود، راهی عالی برای زوم کردن روی مناطق خاص دامنه و جستجوی بینش‌ها و پیچیدگی‌های پنهان در سطح ریزدانگی بالاتر است. این تکنیک مانند گرفتن یک ذره‌بین به یک منطقه کوچک از دامنه است.

تکنیک Example Mapping با طعم Event Storming با انتخاب یک رویداد روی جدول زمانی شروع می‌شود و سپس یک عمل را مشخص می‌کند، با استفاده از یک یادداشت چسبنده آبی، که رویداد را تحریک می‌کند. به عنوان مثال، رویداد "سفارش لغو شد" ممکن است توسط عمل "لغو سفارش" تحریک شود. سپس، هدف این است که به سناریوهای دیگری فکر کنید که می‌توانند هنگام انجام عمل اعمال شوند. به عنوان مثال، اگر یک مشتری درخواست بازپرداخت برای سفارشی که قبلاً از انبار خارج شده است، کند، سپس یک "لغو رد شد" اتفاق می‌افتد. همان‌طور که شکل نشان می‌دهد، سناریوها به عنوان یادداشت‌های چسبنده سبز بین عمل و رویدادی که در سناریوی داده شده اتفاق می‌افتد، وارد می‌شوند.

وقتی به حالت Example Mapping تغییر می‌کند، همیشه سعی می‌کنم شرکت‌کنندگان را تشویق کنم که تا حد امکان به سناریوها فکر کنند و خلاق باشند، خارج از چارچوب فکر کنند. همان‌طور که سناریوهای بیشتری کشف می‌کنید، ممکن است متوجه شوید که منطقی است که آن‌ها را تقسیم کنید و برخی مفاهیم را صریح‌تر کنید.

4.2. چالش‌های رایج :

تسهیل جلسات رویدادگردانی می‌تواند چالش‌برانگیز باشد. از وارد کردن افراد به ذهنیت درست تا برخورد با افراد دشوار که از همکاری امتناع می‌کنند، بیشتر چالش‌ها مربوط به افراد هستند. این بخش برخی از چالش‌های رایجی که احتمالاً با آن‌ها مواجه خواهید شد و برخی نکات برای برخورد مؤثر با آن‌ها را بیان می‌کنم.

4.2.1. وارد کردن شرکت‌کنندگان به ذهنیت کشف

چیزی که اغلب هنگام برنامه‌ریزی Event Storming و سایر کارگاه‌های کشف نادیده گرفته می‌شود، نیاز به ایجاد محیطی است که شرکت‌کنندگان بتوانند ذهنیت خلاقانه کشف مورد نیاز را بپذیرند. وقتی افراد تحت فشار برای تحویل هستند، به ویژه با مهلت‌های فوری، چالش بزرگی برای آن‌ها است که آن را به پشت ذهن خود نگهداشته و ساعت‌ها یا روزها را صرف نقشه‌برداری از فرآیندهای کسب‌وکار کنند در حالی که احساس می‌کنند هیچ پیشرفت فوری در اهداف کوتاه‌مدت حاصل نشده است.

برای یک جلسه مؤثر، رهبران باید اطمینان حاصل کنند که کار کشف به طور مناسب اولویت‌بندی شده است و فقط یک تعهد اضافی نیست که افراد انتظار دارند علاوه بر تمام تعهدات دیگر خود انجام دهند. ضرری ندارد که قبل از زمان جلسه با شرکت‌کنندگان کارگاه تماس بگیرید تا اطمینان حاصل کنید که آن‌ها از قبل بیش از حد متعهد نیستند. در غیر این صورت، وقتی در کارگاه شرکت می‌کنند، ذهن آن‌ها بیش از حد روی اولویت‌های دیگر متمرکز خواهد بود، و احتمالاً چندوظیفه‌ای نیز خواهند بود. برای اینکه یک جلسه Event Storming مؤثر باشد، واقعاً می‌خواهید همه کاملاً درگیر و هیجان‌زده برای به اشتراک گذاشتن دانش خود از کسب‌وکار و یادگیری از دیگران باشند.

4.2.2. اجتناب از bikeshedding:

به پدیده صرف زمان زیاد برای بحث در مورد جزئیاتی که در طرح کلی چیزها واقعاً مهم نیستند،bikeshedding نام دارد. bikeshedding باعث یکی از بزرگترین شکست‌های Event Storming من شد، جایی که یک مدیر عصبانی در مقابل تیم خود به من فریاد زد. ما شروع به راه رفتن در جدول زمانی کردیم، و گروه زمان زیادی را صرف بحث در مورد فرآیند ثبت‌نام کرد. من فکر می‌کردم همه چیز عالی پیش می‌رود زیرا بحث‌های زیادی وجود داشت. اما من دلیل عصبانیت مدیر را درک می‌کنم: فرآیند ثبت‌نام واقعاً آنقدر مهم نبود. در یک کارگاه که همه برای فقط چند روز دور هم جمع شده بودند تا در مورد مشکلات بزرگ‌تر بحث کنند، چیزهای مهم‌تری در زمان محدود وجود داشت که باید روی آن‌ها تمرکز می‌کردیم.

برای به حداقل رساندن شانس تکرار اشتباه من، اجازه ندهید در جلسات Event Storming هیچ مکالمه‌ای بیش از چند دقیقه طول بکشد. سعی کنید قبل از اینکه خیلی عمیق به یک منطقه بپردازید، به انتهای جدول زمانی برسید. اگر واقعاً مهم‌ترین چیزی است که باید در مورد آن صحبت کنید، گروه از طریق رای‌گیری تصمیم می‌گیرد که پس از رسیدن به انتهای جدول زمانی به آن بازگردند.

4.3.3.ما قبلاً نمودارهای این را داریم:

برخی افراد با ایده Event Storming مخالفت می‌کنند زیرا فکر می‌کنند که زائد است. آن‌ها قبلاً نمودارهایی در برخی فرمت‌های دیگر مانند UML یا BPMN ایجاد کرده‌اند. در یک کارگاه، یک مهندس فرآیند گفت: "من نمودارهایی از تمام این فرآیندها دارم؛ من دلیلی برای این کارگاه را نمی‌بینم" و در طول کارگاه به این موضوع ادامه داد. یکی از کارمندان که در منطقه‌ای که نمودارها برای آن ایجاد شده بود کار می‌کرد، گفت: "خوب، آن‌ها کجا هستند؟ ما هرگز آن‌ها را ندیده‌ایم." مهندس فرآیند سپس اعتراف کرد که نمودارها در مقایسه با آنچه تاکنون در کارگاه کشف کرده‌ایم، قدیمی هستند، همان موضوعی که در قسمت بازبینی مستندات به طور مشروح به آن پرداختیم.

گاهی اوقات یک برخورد فرهنگی اتفاق می‌افتد که افراد فکر می‌کنند Event Storming به خوبی ابزارهای موجود آن‌ها نیست. من سعی می‌کنم با این افراد به طور منطقی صحبت کنم و آن‌ها را به کارگاه‌ها دعوت کنم، اما اگر رفتار آن‌ها در طول کارگاه مشکل‌ساز شود، باید حذف شوند. با این حال، گاهی اوقات مشکل عمیق‌تر است، و افراد فکر می‌کنند که انتظار می‌رود آن‌ها متخصص فرآیندهای شرکت باشند. جلسه Event Storming بعضا باعث نگرانی است زیرا ممکن است چیزهایی را آشکار کند که متخصص نمی‌داند، یا متخصص دوست دارد دانش را برای محافظت از موقعیت خود در شرکت نزد خود نگه دارد. این یک موقعیت اجتماعی بسیار پیچیده‌تر است؛ نحوه برخورد با آن به رابطه شما با افراد درگیر و فرهنگ شرکت شما بستگی دارد.

4.3.4. نمی‌توان همه چیز را در یک کارگاه دو روزه حل کرد:

گاهی اوقات افراد ناامید می‌شوند که در پایان یک کارگاه دو روزه کل سیستم خود را دوباره طراحی نکرده‌اند و توپولوژی‌های تیم جدید طراحی نکرده‌اند. این انتظارات غیرواقع‌بینانه است، بنابراین مهم است که بیش از حد وعده ندهید یا بیش از حد Event Storming را بزرگ نکنید. اطمینان حاصل کنید که انتظارات واقع‌بینانه در دعوت تنظیم شده و هنگام شروع جلسه تقویت شود.

4.3.5. حضوری در مقابل از راه دور:

وقتی همه‌گیری در اسفند ماه سال 98 شروع شد، بسیاری از متخصصان Event Storming به شدت به دنبال راه‌هایی برای اجرای جلسات Event Storming از راه دور بودند. تمرکز به شدت روی بازسازی تجربه جلسات حضوری تا حد امکان در محیط‌های مجازی بود. بسیاری ناامید شدند زیرا تجربه از راه دور بسیار متفاوت بود و بسیاری از مزایای حضوری، مانند مکالمات موازی و توانایی خواندن زبان بدن، را نداشت. در همین حال، دیگران در جامعه به دنبال راه‌هایی برای بهینه‌سازی تجربه رویدادگردانی آنلاین بودند، و آن‌ها از تمام انتظارات فراتر رفتند، نه با بازسازی آنچه در حضوری کار می‌کرد، بلکه با تمرکز بر نقاط قوت محیط‌های مجازی.

جلسات رویدادگردانی حضوری نیاز دارند که همه در یک فضای فیزیکی باشند. در بسیاری از سازمان‌ها، اینکار مقدار زیادی هماهنگی می‌طلبد، و در برخی سازمان‌ها، تقریباً غیرممکن است. محدودیتِ بودن در یک فضای فیزیکی همچنین به این معنی است که یک سری کامل از کارگاه‌ها باید در یک دوره کوتاه زمانی که همه دور هم هستند، فشرده شود.اما در جلسات راه دور، این محدودیت‌ها وجود ندارند (اگرچه هنوز هم یافتن زمان مناسب که همه در دسترس باشند، دشوار است). ممکن است بسیاری از جلسات کوتاه‌تر را در یک دوره طولانی‌تر اجرا کنید. به عنوان مثال، اغلب جلسات 2 تا 4 ساعته را هنگام اجرای جلسات از راه دور ترجیح می‌دهم. این‌ها می‌توانند در طول هفته‌ها یا ماه‌ها پخش شوند، و پس از هر جلسه، فرصت‌هایی برای ارزیابی مجدد مراحل بعدی و دعوت از چه کسانی داریم.

جلسات از راه دور همچنین از محدود نبودن به یادداشت‌های چسبنده فیزیکی سود می‌برند. در واقع، ابزارهای تخته سفید مجازی مانند Miro (اگر فیلترها و تحریم ها به ما اجازه کار کردن بدهند) به شما اجازه می‌دهند که بسیار بیان‌گرتر باشید، با انواع بیشتری از اشکال، رنگ‌ها، تصاویر و ایموجی‌ها برای بیان مفاهیم دامنه و احساسات افراد.مزیت بزرگ دیگری که هنگام اجرای جلسات مجازی داریم، توانایی کپی و چسباندن است. این امکان به شما اجازه می‌دهد که یک Event Storming کامل را کپی کنید و برای ادامه کار به گروه‌های کوچک تقسیم شوید، جایی که هر گروه یک کپی از Event Storming را برای کاوش و شکل‌دهی به مرزهای دامنه دریافت می‌کند.

این‌ها چند مورد از نمونه‌های مورد علاقه من برای بهینه‌سازی تجربه کارگاه برای فرمت داده شده هستند. به شما پیشنهاد می‌کنم که به طور مداوم به راه‌هایی برای بهینه‌سازی هر یک از کارگاه‌های خود برای فرمتی که آن‌ها را در آن ارائه می‌دهید، فکر کنید.
5. جمع بندی:

اکنون به پایان این قسمت درباره Big Picture Event Storming رسیدیم. Event Storming یک تکنیک عالی برای نقشه‌برداری از دامنه‌ها، همسو کردن گروه‌های افراد و افزایش پتانسیل مدرن‌سازی است. در قسمت‌های بعدی، همچنین خواهید دید که Event Storming چگونه نقطه شروعی عالی برای شناسایی دامنه‌ها و زیردامنه‌ها است. به خاطر داشته باشید که Event Storming به تنهایی تمام نیازهای شما را پوشش نمی‌دهد. به عنوان مثال، در برخی شرایط خوب است که زمان را با کاربران واقعی بگذرانید، به یاد دارم که در کاری که در حوزه بیمه دیجیتال انجام میدادیم دو روز کامل از فصل سرد زمستان را در یکی از مراکز تعیین خسارت بیمه در مرکز شهر با کارشناسان شرکت بیمه و مراجعه کنندگان گفتگو کرده و وقت گذراندم— موضوع فصل بعدی که به مدرن‌سازی محصول و دامنه عمیق‌تر می‌پردازد.