مقدمه:
ما در تمامی طول توسعه یک نرمافزار در حال یادگیری هستم. از همان ابتدا که شروع به فهمیدن دامین مسئله میکنیم. ایده و صورت مسئلهای در ذهن و کله افرادی وجود دارد. این افراد آرزو دارند که این ایدهها و تصمیمات در نهایت در قالب یک نرمافزار به واقعیت بپیوندد. در طیف دیگر تیم توسعه هستند. این ایدهها و مسئله باید در نهایت وارد فضای ذهن توسعه دهندگان شده و آنها شروع به پیادهسازی کنند. به میزانی که این تبادل و فراگیری مسئله به درستی انجام شود، آرزوی ذینفعان به واقعیت نزدیکتر خواهد شد. زیرا که در نهایت نرمافزار آن چیزی نیست که ذینفعان درخواست دادهاند. بلکه آن چیزی است که توسعه دهندگان از مسئله فهمیدهاند و در نهایت از کیبورد و با فشار کلاویههای صفحه کلید! پیادهسازی کردهاند.
زبان مدلسازی فراگیر:
فکر کردن به دامین مسئله بیش از شروع به پیادهسازی کردن نرمافزار همیشه برای تیمهای نرمافزاری یک ضرورت بوده است. یکی از مواردی که همیشه در مورد آن تاکید وجود داشته است توجه به فهم دقیق دامین مسئلهای که در آن کار میکنیم بوده است. این تفکر بیش از شروع عملیات پیادهسازی معمولا در قالبهایی از جمله مدلسازی یا طراحی نرمافزار خود را نشان میداد.
به عنوان نمونه از روش های رایجی که برای طراحی استفاده میشد بدین صورت بود که با دقت در صحبتهای متخصصان کسبوکار(Business Expert) به دنبال اسم(noun)ها و فعل(verb)ها میگشتیم. از هزارتوی این اسمها بعضی از آنها در طراحی شیگرا تبدیل میشدند به آبجکت و برخی دیگر پراپرتیهای یک آبجکت. فعلها هم به رفتارهای آبجکتها ترجمه میشدند.
مجموعه استانداردهای Unified Modelling Language(UML) نیز تلاشی در همین راستا بود.
The Unified Modeling Language is a general-purpose, developmental modeling language in the field of software engineering that is intended to provide a standard way to visualize the design of a system.
Wikipedia
در اصل تلاش بر این بود که همه افراد تیم توسعه و تیم محصول بتوانند به کمک مصورسازی دامین مسئله به یک فهم مشترک از مسئله دست پیدا کنند.
دو ایراد اساسی به UML میتوان گرفت:
- آنها بیش از حد فرمال بودند. نیاز بود که تعداد زیادی مستند فنی مطالعه شود. با شکلها و annotationهای مختلفی آشنا شد. تاثیر بد این موضوع این بود که بخشی از افراد از قافله عقب میماندند. دست بر قضا اینها آدمای تیم محصول بودند. آدمهایی که در فضای مسئله(Problem Space) بودند. حضور این افراد بسیار کلیدی بود. در اصل همانطور که در بالا اشاره کردم همه در تلاش برای فهم صحیح و مشترک دامین مسئله بودند. اما UML ناخواسته بخش مهمی از افراد که دست بر قضا متخصصان دامین بودند، را تا حد بسیار زیادی حذف میکرد.
کریستوفر الکساندر(Christopher Wolfgang John Alexander) معمار و تئوریسن شهیر بریتانیایی-آمریکیایی مقالهی معروفی داره با عنوان A City is not a Tree.
مورد مهمی که باید به آن توجه کنیم این است که نرمافزار نیز درخت نیست. ساختار سلسله مراتبی درختی تنها و تنها یک نما از نرمافزار را ارائه میدهد. ساختار استاتیک. نمودارها UML ساختار داینامیک رفتارهای نرمافزار، وابستگیها و مهمتر از آنها گلوگاهها را در نظر نمیگرفتند(اوکی حق با شماست. مشخصا تعداد زیادی دایاگرام برای این منظور در UML در نظر گرفته شد. اما باز هم به دلیلی که در بالا اشاره کردم UML در این زمینه زیادی فرمال بود. سربار بسیار زیادی برای ایجاد یک فضای تعاملی فعال بین افراد ایجاد میکرد).
پیچیدگی در نرمافزار
وقتی از دامین پیچیده صحبت میکنیم از چه نوع پیچیدگی صحبت میکنیم؟ ارسطو فیلسوف نامی یونانی در توضیح ماهیت و ذات یک چیز، بین ویژگهای ذاتی(essential) و ویژگیهای عارضی(accidental) آن تفاوت قایل شد. از جنبههای مختلفی این پیچیدگی در نرمافزار را بررسی کردهاند.
به عنوان مثال میتوانید به Mythical Man-Month, No Silver Bullet – Essence and Accident In Software Engineering فرِد بروکس(Fred Brocks) نگاهی کنید.
فرِد بروکس نیز پیچیدگیهای موجود در نرمافزار را به دو دستهی پیچیدگیهای ذاتی(essential complexities) و پیچیدگیهای غیر ذاتی و عارضی(accidental complexities) تقسیم کرد(به پیچیدگی غیرذاتی پیچیدگی پدیدآر هم میگیم!).
در عنوان کتاب آبی Domain-Driven Design از اریک اونس(Eric Evans) آمده:
Tackling complexity in the heart of software
اما پیچیدگی موجود در قلب نرمافزار که قصد حمله به اون و سوار شد را داریم چه پیچیدگی است؟
مارتین فاولر در مقدمه همین کتاب عنوان میکنه:
There are many things that make software development complex. But the heart of this complexity is the essential intricacy of the problem domain itself
Martin Fowler
در واقع پیچیدگی ذاتی در دامینهای پیچیده، خودِ فهمیدن دامین و جزئیات دامین است.
ایونتاستورمینگ
ایونتاستورمینگ یک روش ورکشاپ محور برای کشف و دستیابی خیلی سریع به یک تصویر و فهم مشترک از چیزهایی که در دامین یک محصول نرمافزاری اتفاق میافتد است. این روش توسط آلبرتو برندولینی معرفی شد. ریشه این روش به الگوهای استراتژیک DDD بر میگردد. ایونتاستورمینگ ابزاری است که به کمک آن تیمهای توسعه و محصول، میتوانند بصورت خیلی سریع و موثر به اکتشاف در دامین بپردازند. این افراد به کمک ایونتاستورمینگ میتوانند دامین مورد نظر را مدل کرده و در نهایت نرمافزاری توسعه دهند که قادر است مسائل پیچیده را حل کند. رویکرد ایونتاستورمینگ بصورت داستان سرایی تصویری است.
the Elephant in the room
ایونت استورمینگ ماهیت جذاب گیماستورمینگ را با DDD ترکیب کرده است. ایونتاستورمینگ با کاتالیز و شتاب دادن به یادگیری گروهی، فهم مشترک از دامین نرمافزار را برای افراد درگیر در توسعه محصول، در زمانی حدود چند ساعت یا نهایت چند روز مقدور میسازد. چیزی که به کمک روشهای سنتی مدلسازی در چنین زمان کوتاهی هیچوقت امکان پذیر نبود.
ایونتاستورمینگ دانش افراد تیمهای توسعه و محصول را بالا میبرد و کمک میکند که مشکلات و چالشهای موجود در کل فرآیند کسبوکار را پیدا کنند. این کار میتواند به ما کمک کند که پیچیدگی موجود در دامین را کنترل کنیم و تصمیم درستتری بگیرم.
ایونتاستورمینگ تاکید میکند که همه افراد درگیر در توسعه محصول را دور هم جمع کنیم:
این یک موضوع ضروری است، چون فرآیندهای کسبوکار اغلب بین چندین دپارتمان و واحد در یک سازمان
تقسیم شدهاند. سیلوهای سازمانی ضمن اینکه تمرکز خوبی بر روی مسائل مبتلابه همان سیلو دارد، اما یک مانع بسیار مهم در دستیابی یه یک راهحل یکپارچه برای فرآیندهایی که چندین سیلو را شامل میشود، محسوب میشوند.
نکتهی مهم دیگر اینکه وقتی ما با دو سیلو/دپارتمان سروکار داریم، در حقیقت ما نه با 2 مدل که با 3 مدل سروکار خواهیم داشت. 1 مدل برای فرآیندهای لوکال هر سیلو و یک مدل برای چتینگ بین سیلوها (فرآیند(هایی) که هر دو سیلو را در بر میگیرد).
فرمتهای برگزاری ایونتاستورمینگ
ایونتاستورمینگ به فرمتهای مختلفی اجرا میشود. در حقیقت میتوان گفت که شامل مجموعهای از ورکشاپهاست که مکمل یکدیگر هستند و هر کدام به هدفی اجرا میشوند. ایونتاستورمینگ با Big Picture ایونتاستورمینگ شروع میشود. هدف این کارگاه این است که همه افراد فیل بزرگ موجود را در اتاق را هر چه سریعتر بینند. و همگی نسبت به تصویر بزرگ و واقعی دامین مسئله بر روی یک صفحه باشند(on the same page).
پیش از ادامه دادن، به دو نکته کلیدی که در ایونتاستورمینگ باید در نظر بگیریم اشاره میکنم. مورد اول Domain event است. Domain event اتفاقات مهمی است که در طول فرآیندهای یک دامین اتفاق میافتد و کسبوکار نسبت به آنها care است. مورد بعدی خود Domain expert است. Domain expert یا Business expert افرادی هستند که حوزه فعالیت آنها در فضای مسئله یک دامین یا بخشی از یک دامین است. به عنوان مثال مدیر بخش حسابداری یا کارشناس حسابداری. یا کارشناس حقوق و دستمزد. این افراد در حوزه تخصصی خودشان به عنوان domain expert شناخته میشوند.
فرمتهای مختلفی برای برگزاری کارگاه ایونتاستورمینگ وجود دارد. به عنوان مثال میتوان به Big Picture ایونتاستورمینگ، Process Level ایونتاستورمینگ یا Design Level ایونتاستورمینگ اشاره کرد. این فرمتها به نوعی تکمیل کنندهی همدیگر هستند. میتوان آنها را مثابه لایههای مختلفی از انتزاع در فضای مسئله دانست.
Big Picture ایونت استورمینگ
هدف این کارگاه این است که همه افراد درگیر در فرآیند تولید نرمافزار از طریق همکاری و مشارکت همزمان در زمانی سریع بتوانند به یک فهم مشترک و صحیح از تصویر بزرگ دامین خود دست پیدا کنند.
برای این کارگاه به چه مواردی نیاز داریم؟
- دعوت از افراد شامل تیم توسعه، متخصصان دامنه، تیم تست و کیفیت محصول، تیم UX، تیم بازاریابی و مشتری. کارگاه Big Picture معمولا با تعداد افراد زیادی برگزار میشود. بین 15 تا 30 نفر.
- استیکینت به تعداد زیاد. این مقدار به بزرگی و کوچکی و پیچیدگی دامین مورد نظر شما بستگی دارد. همینطور در نظر داشته باشید که همیشه بخش زیادی از استیکینتها در حین کارگاه دور ریخته میشوند. پیشنهاد میکنم برای هر نفر مشارکت کننده در کارگاه حداقل 1 یا 2 بسته استیکینت تهیه کنید. (نگران نباشید اگر استیکینت اضافه اومد بعدا هم میتونید جای دیگه ازش استفاده کنید ?) در مورد رنگ استیکینت قانون نانوشتهای است که رنگ استیکینتی که برای نوشتن ایونت استفاده میکنیم رنگ نارنجی باشد! ولی در صورتی که این رنگ را دم دست نداشته باشید، اصلا اهمیتی ندارد. فقط تا جای ممکن به یک رنگ ثابت پایبند باشید. باز هم اگر نتونستید که گاها اتفاق میافتد پیشنهاد میگم کاغذهای یادداشت سفیدی که همه جا پیدا میشه رو بردارید، چهار دایره بزرگ و مشخص در چهارگوشه آنها با هایلاتر و به رنگ استیکینتی که برای نوشتن ایونت استفاده کردید، بکشید. بقیه ایونتها ر بر روی این کاغذها بنویسید و با چسب کاغذ بچسبونید.
- ماژیک سیدی حداقل به تعداد شرکت کنندگان تهیه کنید. پیشنهاد میکنم چندتایی بیشتر دم دست داشته باشید. اگر به هر دلیل به مشکل خوردید ماژیک اضافه داشته باشید.
- فضای نامتناهی که بشود استیکیها را روی آن چسباند. اندازه این فضا کاملا به بزرگی و پیچیدگی دامین بستگی دارد. معمولا بین 7 تا 9 متر فضا برای کارگاه Big Picture گزینه مناسبی میتواند باشد. دیوار شیشهای میتواند گزینه خوبی باشد. پیشنهادم این است که اگر اتاق تیم توسعه فضای مناسب را دارد کارگاه در فضای کاری تیم توسعه برگزار شود. خروجی این جلسه بیشتر از همه در نهایت برای تیم توسعه محصول است. اگر فضای تیم توسعه مناسب نبود، پیشنهاد میکنم از رولپلاتر استفاده کنید. خوبی این رولپلاتر این است که بعد جلسه میتوانید آنرا جمع کنید و مثلا ببرید در اتاق تیم توسعه بچسبانید. نکتهی مهم دیگری که باید اشاره کنم این است که اکثر شرکتها و سازمانها معمولا بخاطر فضا و چیدمان ساختمان، اتاق دمو/جلسه/کنفرانس مناسبترین فضای برای برگزاری کارگاه است. از آنجایی که معمولا بعد کارگاه اتاق دمو/جلسه/کنفرانس باید برای جلسه بعدی خالی شود. وجود رولپلاتر به شما این انعطاف را میدهد که در صورتی که قصد داشتید کارگاه را در دو روز برگزار کنید، بتوانید خروجی روز اول را جمع کرده و فردا دوباره رولپلاتر را بر روی دیوار بچسبانید.
- ماژیک سیدی حداقل به تعداد شرکت کنندگان تهیه کنید. پیشنهاد میکنم چندتایی بیشتر دم دست داشته باشید. اگر به هر دلیل به مشکل خوردید ماژیک اضافه داشته باشید.
- چند عدد چسب کاغذی. معمولا استیکینت ها در طول کارگاه بعد از چسبیدن چندین بار کنده شده و جابجا میشوند. بخاطر همین استیکیها بخوبی بر روی شیشه یا رولپلاتر نمیچسند. از این رو ضروری است که چند عدد چسب کاغذی نیز قبل شروع جلسه تهیه کنید.
- یک تسهیلگر که تجربه برگزاری کارگاه ایونتاستورمینگ را داشته باشد. وجود تسهیلگر بخصوص برای Big Picture ایونتاستورمینگ بسیار ضروری است. کارگاه با تعداد زیادی آدم برگزار میشود. همچنین کمی بعد از شروع جلسه فضای شلوغی از رویدادها را روی دیوار میبینید. تسهیلگر روال جلسه را به پیش میبرد. همه افراد حاضر را تشویق به مشارکت کند. در صورت نیاز در حین جلسه میتواند تغییراتی در فرمت و اجرای کارگاه برگزار کند. همچنین هیوریستیکهای تسهیلگر در این کارگاه بسیار تاثیر گذار خواهد بود.
تسهیل گر
قبل از شروع کارگاه…
آلیس وقتی وارد سرزمین اعجاب انگیز شد، از گربهٔ چشایر پرسید که کجا باید بره:
“Alice: Would you tell me, please, which way I ought to go from here
Lewis Carroll, Alice in Wonderland
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don’t much care where.
The Cheshire Cat: Then it doesn’t much matter which way you go.
Alice: …So long as I get somewhere.
The Cheshire Cat: Oh, you’re sure to do that, if only you walk long enough.”
بیش از شروع کارگاه هدف خود را از کارگاه مشخص کنید. این موضوع بسیار مهم و حیاتی است. فراموش نکنید که هدف از برگزاری کارگاه بخاطر buzzword بودن ایونتاستورمینگ نیست. خود ایونتاستورمینگ هدف نیست، بلکه قرار است به شما کمک کند به هدف خود دست پیدا کنید.
شروع کارگاه…
سعی کنید راس ساعت مقرر کنید. در شروع، به عنوان پیشدرآمد تسهیلگر همه افراد را باید جمع کند و بصورت خیلی مختصر هدف از برگزاری کارگاه را بیان کند. همچنین خیلی مختصر در مورد نحوه برگزاری کارگاه به روش ایونتاستورمینگ توضیحاتی ارائه دهد. توصیه میکنم بر روی تابلو یا وایت برد یا حتی روی کاغذ رول پلاتر علایم و نشانهها و رنگ استیکینتها و معانی هر رنگ توسط تسهیلگر قبل از شروع جلسه آماده شده و در فضایی که کارگاه برگزار میشود نصب شود. این علایم راهنما میتواند در حین برگزاری کارگاه به شرکت کنندگان کمک کنند. شرکت کنندگان معمولا ابتدای جلسه سوالاتی و ابهاماتی درمورد نحوهی نوشتن رویدادها، رنگ استیکینتها و موارد از این دست دارند. وجود این علایم راهنما میتواند به تمرکز ذهنی آنها کمک کند. همچنین وقت تسهیلگر درگیر پاسخ دادن به این سوالات برای تعداد زیادی افراد نمیشود.
راند اول => با دامین ایونت شروع کنید …
همانطوری که از اسم ایونتاستورمینگ هم بر میاد اینجا با کارگاهی شبیه طوفان فکری سروکار داریم. فکر و ایدهی ما در این کارگاه بصورت ایونت یا رخداد خودش را نشون میدهد. مثل هر *(استار)استورمینگ دیگری، هر ایده یا فکر یا در اینجا ایونت و رخدادی را بدون قضاوت خواهیم پذیرفت.
در حقیقت مشارکت کنندگان در کارگاه گامهای مهم در فرآیندهای دامین را بصورت ایونت، با نوشتن هر ایونت بر روی یک استیکی نت جداگانه ثبت میکنند.
اما منظور از دامین ایونت، اتفاقات و وقایعی است که در فرآیندهای دامین مورد نظر رخ میدهد و برای ما مهم هستند. اینها در اصل حقایقی(fact) هستند که تشکیل دهنده فرآیندهای دامین میباشند.
ایونتها معمولا بر روی استیکینت نارنجی ثبت میشوند. ولی رنگ نارنجی کاملا قراردادی است. میتوانید به انتخاب خود و بر اساس استیکینتهایی که دارید رنگ دیگری انتخاب کنید. فقط تا جای ممکن سعی کنید بر روی یک رنگ بین تمامی مشارکت کنندگان پایبند بمانید. مثلا همگی برای ایونتها بجای رنگ نارنجی از رنگ آبی یا سبز استفاده کنید.
همانطور که اشاره شد این ایونتها حقایقی هستند که در دامین مورد نظر ما رخ دادهاند. بهمین خاطر آنها را به “زمان گذشته ساده” و بدون آوردن نام کاربر یا نقش و یا شرایط پذیرش و بیزنس رولها آنها را بر روی استیکینت مینویسیم و بر روی دیوار میچسبانیم.
آیا باید حتما به زبان انگلیسی بنویسیم؟
اگر برای همه مشارکت کنندگان نوشتن ایونت به زبان انگلیسی سخت نباشد توصیه میکنم به زبان انگلیسی بنویسید. در غیر اینصور حتما از زبان فارسی برای نوشتن ایونتها استفاده کنید.
زمان خالی افراد دعوت شده به جلسه معمولا محدود است. شما به سختی میتوانید همزمان تمام این افراد را دور هم جمع کنید. پس به عنوان تسهیلگر سعی کنید به این موارد ریز بسیار حساس باشید. به هیچ وجه اجازه ندهید به دلیل اینکه یکی از مشارکتکنندگان تسلط کافی بر زبان انگلیسی ندارد فرصت مشارکت حداکثری و موثر وی با اجبار به نوشتن ایونت به زبان انگلیسی از دست برود.
همچنین به عنوان تسهیلگر سعی کنید برای شکستن یخ کارگاه اولین ایونت رو خودتان نوشته و بر روی دیوار بچسبانید. پیشنهاد میکنم برای اینکه فضای کارگاه کمی از حالت رسمی خارج شود یک ایونت کاملا اشتباه رو بنویسید. اینجوری کاری میکند که افراد تریگر بشن. البته مراقب باشید حمله ور نشن بهتون ?
تصور کنید همه چیز خوب و خوش و خرم پیش رفته …
حتما قبل از شروع جلسه در مورد جلسه و نحوه برگزاری و استارت جلسه فکر کنید. با توجه به اینکه فضای این کارگاه بسته به شرایط مختلف کاملا داینامیک است، به پلنهای B و C و بیشتر فکر کنید. برای شروع جلسه هیوریستیکی که معمولا استفاده میکنم بدین صورت است:
همه مشارکت کنندگان را دور هم جمع کرده و به آنها می گویم: “فرض کنید برای این دامین که قصد داریم نرمافزاری براش تولید کنیم، این نرمافزار توسعه داده شده و 6 ماه از توسعه اون هم گذشته. حال همگی فرض کنید که به عنوان کاربر دارید با نرمافزاری که دوست دارید در نهایت تولید بشه کار میکنید! حالا در تصور خودتون، با نرمافزار کار کنید و رویدادهای مهم رو روی استیکینت بنویسید و بچسبونید به دیوار!”
برای بخش اول ورکشاپ حتما تایمباکس قرار بدید. پیشنهادم بسته به دامین، و تایمی که برای جلسه ست کردهاید و تعداد افراد مشارکت کننده تایمی بین 15 تا 25 دقیقه برای راند اول است.
راند اول باید تا جای ممکن در سکوت انجام بشود. میزان موفقیت کلی کارگاه تا اندازه زیادی به این راند اول بستگی دارد. این سکوت برای حفظ تمرکز افراد بسیار موثر و کمک کننده است. نقش تسهیلگر در اینجا حیاتی است. به عنوان تسهیلگر اگر مشاهده کردید بحثی بین افراد در مورد یک ایونت یا هر چیزی دیگری صورت گرفته حتما ورود کنید.
به هیچ وجه هیچ بحثی نباید گم بشود. در حقیقت قدرت ایونتاستورمینگ از وجود همین بحثهایی است که بین افراد شکل میگیرد. اگر بحثی بیش از چند ثانیه طول کشید و در نهایت افراد به اجماع نظر نرسیدند، سعی کنید آن را در قالب یک سوال یا چالش یا چند ایونت مختلف که بیان کننده نظرات افراد درگیر در بحث میباشد بر روی دیوار پارک کنید و افراد رو تشویق کنید به بقیه ایونتها بپردازند. سوالات، چالشها و بحثهای داغ را میتوانید بر روی استیکینت قرمز رنگ بنویسید.
هیچگونه ترتیب و توالی برای ایونتها در این راند مهم نیست. مشارکتکنندگان میتوانند ایونتها را به هر صورتی که راحت هستند بر روی دیوار پارک کنند.
بصورت خلاصه توی این راند مشارکت کنندگان مجاز نیستند که هیچ فرضی در مورد هیچ مسئلهای داشته باشند. اگر در مورد مسيلهای ابهام دارند باید آن را بر روی دیوار پارک کنند. به همین ترتیب صحبت و بحث در راند اول نیز مجاز نیست. اگر بحثی پیش گرفت سعی کنید سریع آنرا بصورت ایونت یا یک بحث داغ یا سوال روی استیکینت قرمز بنویسید و بچسبونید روی دیوار. یادتون نره این بحثهای بین افراد بسیار ارزشمند هستند. و تایم شما بسیار محدود است. پس سعی کنید این تایم رو جوری مدیریت کنید که با بحث کردن بر روی یک یا چند ایونت یا مسئله خاص از فیل بزرگ موجود در اتاق غافل نشید. زمان به سرعت داره میگذره.
بحثهای داغ، سوالات، چالشها یا ابهامات را بر روی استیکینت قرمز بنویسید. خوبی رنگ قرمز این است که به عنوان یک رنگ گرم نظر رو سریع به خودش جلب میکند. نکتهی مهم دیگر، مجدد اجباری نیست که رنگ این استیکینتها قرمز باشد. فقط به یک رنگ پایبند باشید.
Don’t Think
Don’t Assume
Talk and Doc
خروجی پارت اول یک فضای بسیار شلوغ و بدون نظم از ایونتها بر روی دیوار است. هرچه این فضا شلوغتر باشد بهتر است. این بدین معنی است که هرآنچه نیاز داشتیم از توی کله! و ذهن افراد حاضر در جلسه بیرون کشیدیم و بر روی استیکینت نوشته و روی دیوار پارک کردیم.
Welcome to chaos
خودتان را برای بخشهای اساسیتر و جذابتر آماده کنید.
راند دوم => خط زمانی را رعایت کنید…
از این مرحله به بعد باید تلاش کنیم به فضای شلوغ بوجود آمده در مرحله قبل ساختار بدهیم. کارگاه ایونتاستورمینگ تلاشی چند مرحلهای است که در هر مرحله سعی میکنیم با افزودن یک تکنیک جدید و دادن ساختار به ایونتهای بدست آمده به پیشرفت دست پیدا کنیم. در اولین گام خط زمانی و ترتیب و توالی وقوع ایونتها را خواهیم داشت.
به عنوان تسهیلگر برای این مرحله آماده باشید. بر خلاف مرحله قبل این مرحله کاملا شلوغ و پر از بحث و جدل خواهد بود. فراموش نکنید هیچ بحث یا سوالی نباید گم بشود.
در این مرحله افراد شرکت کننده در جلسه شروع به مرتبسازی ایونتها میکنند. اگر ایونتها به انگلیسی نوشته شدهاند خط زمانی را از چپ به راست و در صورتی که فارسی نوشته شدهاند از راست به چپ در نظر بگیرید. منظور از مرتب سازی ایونتها رعایت ترتیب زمانی وقوع ایونتهای پارک شده بر روی دیوار است. اگر ایونتی از یک فرآیند از نظر وقوع زمانی قبل از ایونتهای دیگر قرار دارد، باید آنها جابجا شوند.
وقتی ایونتها را به ترتیب زمانی قرار میدهید سعی کنید، کارتهای آنها را با کمی فاصله از هم قرار دهید و کارتها را به هم نچسبانید. معمولا در طول کارگاه مجبور خواهید شد کارتها را چندین بار جابجا کنید و گاها فضا کم میآید. به همین دلیل مجبور خواهید شد یکسری کارت را مجدد به جلو/عقب یا بالا/پایین شیفت دهید. در راندهای بعدی کارگاه، قبل و بعد یا حتی بالای یا پایین این کارتهای نارنجی کارتهای دیگری خواهیم چسباند. بهمین دلیل توصیه میکنم کارتها را موقع مرتبسازی با فاصله کمی از یکدیگر قرار دهید.
تا جای ممکن ایونتها را بصورت خطی مرتب سازی کنید. جهت درک بهتر خط زمانی رویدادها ترتیب زمانی را بسته به انگلیسی یا فارسی نوشتن رویدادها از چب به راست یا راست به چپ قرار دهید. در کارگاهها مشاهده میکنم افراد ترتیب رویدادها را از بالا به پایین قرار میدهند. توصیه میکنم از این کار دوری کنید. هدف از کارگاه در نهایت این است که همه افراد نسبت به فیل بزرگ موجود در اتاق بر روی یک صفحه بوده و به یک فهم مشترک و صحیح برسند.
باید وصل و پینه تمامی فرآیندها را با یکدیگر در نظر گرفت و نه فقط یک فرآیند را بصورت ایزوله. شاید اگر همان تک فرآیند را نظر بگیرم، نتوان به قرار دادن عمودی ایونتها خردهای گرفت. اما همانطور که وقتی متنی را میخوانیم بسته به کانتکست متن را از چپ به راست یا به عکس نوشته و میخوانیم در مورد ایونتهای پارک شده نیز به این امر با شدت بالاتری صادق است(بله درست حدس زدید زبانهایی هستند که نوشتار آنها بالا به پایین است ? ولی خب آنها را در نظر نگرفتم.).
برخی فرآیندها ممکن است از نقظه نظر توالی زمانی ارتباط چندانی با یکدیگر نداشته باشند. ممکن است به هر ترتیبی اجرا شوند. مثلا دامین گردشگری را در نظر بگیرید که سرویسهایی از جمله خرید بلیت هواپیما، قطار و اتوبوس را ارائه میدهد. فرآیندهای ارائهی بلیت هواپیما و قطار لزوما ترتیب منطقی از نظر مقدم یا موخر بودن یکی بر دیگری ندارند. در این حالت توصیه میکنم که اگر فضا به اندازه کافی در اختیار دارید این فرآیندها را بصورت خطی و با فاصله کمی بیشتر از یکدیگر قرار دهید و هر کدام را بصورت جداگانه مرتب کنید.
در صورتی که عرض فضایی که در اختیار دارید اجازه این کار را نمیدهد که همه این فرآیندها را با رویکردی که در بالا اشاره کردم مرتب کنید، میتوانید این فرآیندها را بالا و پایین هم قرار دهید. بین آنها حتما فاصله مناسب قرار دهید. این فاصله به مثابه یک هینت برای ما اعمال میکند. میتوانیم در یک نگاه بصورت چشمی بین آنها تمایز قایل شویم.
در این مرحله از بکار بردن هرگونه برچسب همانند چیزهایی که در تصاویر بالا مشاهده میکند خودداری کنید!.
اینکه کدام فرآیند بالاتر یا پایینتر قرار گیرد، آنقدری مهم نیست. اما یکسری هیوریستیک در این زمینه وجود دارد که معمولا استفاده میکنم. بدین صورت که بسته به زاویه دید افراد تیم توسعه، و همچنین محل قرارگیری برد، برای محل قرارگیری فرآیندها موارد زیر را بررسی میکنم:
- مهمتر است
- پیچیدهتر است
- gain بیشتری برای کسبوکار ما دارد
- pain بیشتری را بدنبال خواهد داشت
- تیم توسعه نسبت به آن کمتر تجربه و آشنایی دارد
و در نهایت فرآیندها را جوری جانمایی میکنم که تیم توسعه براحتی و در اولین نگاه بتواند به آن فرآیند احاطه داشته باشد.
نکتهی مهم این که مثالی که در بالا آوردم با این پیش شرط میباشد که از نقطه نظر ذینفعان، ارائه هر کدام از این سرویسها اولویت بالاتری نسبت به دیگری ندارد. و یا اینکه کسبوکار برای اولین ریلیز عمومی محصول نیاز دارد که هر دو سرویس را حتما داشته باشد و با تکمیل فقط سرویس رزرو و خرید بلیط هواپیما نرمافزار را پروموت نمیکند.
اما در نظر بگیرید که مثلا برای ما مهم است که اول سرویس رزرو بلیط هواپیما توسعه داده شده و بعد از آن قطار. یا اینکه نرمافزاری که توسعه میدهیم میتواند با ارائه تنها یکی از سرویسها نیز پروموت شود. و یا به هر دلیلی یکی از سرویسهایی اشاره شده در مثال بالا اولویت بالاتری نسبت به دیگری دارد، در این حالت حتما توصیه میکنم که تا جای ممکن این سرویسها بصورت خطی و پشت سر هم قرار گیرند.
برای این بخش نیز حتما تایم باکس در نظر بگیرید. این زمان نیز بسته به مدت زمان جلسه، تعداد افراد حاضر، و همینطور فرمت کارگاه ایونتاستومینگ و بزرگی و پیچیدگی دامین میتواند متفاوت باشد. پیشنهادم این است که تایم این بخش را بین 15 تا 25 دقیقه در نظر بگیرید.
پس از پایان این راند، فضای شلوغ بوجود آمده در مرحله قبل کمی دارای ساختار خواهد شد.
هم تسهیلگر و همه افراد در این مرحله، همچنان استیکینت و ماژیک دستشون باشه. همزمان که در حال مرتبسازی رویدادها هستید، متوجه میشوید که در برخی فرآیندها گپ وجود دارد. احتمالا یک یا چند ایونت فراموش شده است. سریع آنها رو بر روی استیکینت نوشته و بر روی دیوار پارک کنید. همچنین ممکن است در مورد یک یه چند ایونت روی دیوار، سوال، ابهام یا چالشی داشته باشید. بجای مکث بر روی آنها سوال یا نظر و ابهام خود را بر روی استیکینت قرمز نوشته و کنار ایونت مربوطه پار کنید. پیشنهاد میکنم استیکینتهای قرمز رنگ را بصورت مورب بر روی دیوار و کنار استیکینت نارنجی پارک کنید.
در این مرحله بین افراد شرکت کننده بحثهای زیادی شکل میگیرد. تسهیلگر باید خود را درگیر این بحثها کند. بحثها بسیار ارزشمند هستند. اما اجازه ندهید که بحث برای مدت زمان زیادی بطول بیانجامد. اگر بحث طولانی شد، سعی کنید همه آن بحثها را در قالب ایونتها یا بحثهای داغ بر روی استیکینت مربوطه بنویسید و بر روی دیوار بچسبانید. فراموش نکنید تایم شما محدود است. همچنین هدف کارگاه این نیست که در مورد یک فرآیند یا رویداد همگی به اتفاق نظر برسند. بلکه هدف این است که تصویر بزرگ رو تا جای ممکن در مدت زمان بسیار کوتاهی بر روی یک دیوار مشاهده کنیم. همچنین چیزهایی که *نمیدانیم که نمیدانیم* نیز برای ما مشخص شود.
هدف کارگاه Big Pictureایونتاستورمینگ این نیست که در مورد یک فرآیند یا رویداد همگی به اتفاق نظر برسند.
به عنوان توسعهدهنده، معمار یا طراح نرمافزار بسیار مراقب باشید. هیچ پیشفرضی در مورد ساختارهای احتمالی بوجود آمده نداشته باشید. چند فرآیند کنار هم لزوما معنی یک بانددکانتکست، سرویس یا ماکروسرویس نمیدهد. چند ایونت پشت سرهم به معنی یک اگریگیت نیستند. به جملات بر روی ایونتها دقت کنید. اما مراقب باشید آنها را خیلی زود به اسامی تکنیکال یا تصمیمات طراحی نگاشت نکنید.
بعد از اتمام تایمباکس، تسهیلگر باید روند جلسه را قطع و یک استراحت خیلی کوتاه بدهد. مراقب باشید فضای کارگاه از بین نرود. افراد درگیر موبایل یه بحثهای متفرقه نشوند. افراد رو به حال خودشون رها نکنید. مهمترین آفت جلسات ایونتاستورمینگ را distraction mind دیدم.
راند دوم => یک راوی خوش صدا رو دعوت کنید بر روی استیج …
بایاسهای ذهنی همیشه این چالش را برای ما داشتهاند که بخشی از فضای موضوع رو فراموش کنیم. همه ما تا حدودی درگیر این انواع بایاسهای ذهنی هستیم. یکی از بایاسهای جالب blind spot است. اینکه هر کدام از ما تصور میکنیم که خودمان کمتر از بقیه افراد بایاس شدهایم. blind spot یکی از بایاسهای شناخته شده است. تحقیقاتی را بر روی افراد انجام دادهاند و مشاهده شده که اکثر افرادی که تصور میکردهاند ذهنشان کمتر از بقیه بایاس شده است اشتباه کردهاند. و خود این تصویر از یک ذهن بایاس شده آمده بود. درست همان لحظه که شاید تصور کنی ذهنت بایاس نشده است، دچار بایاس شدهای.
چارلز داروین خالق نظریه فرگشت اعتقاد داره: آدمها وقتی دور هم جمع میشوند این قدرت را دارند که یکدیگر را تکمیل کنند و نقاط کور همدیگر را پوشش دهند. این بسیار نکتهی مهم و کلیدی در جلسات و کارگاههایی از جمله ایونتاستورمینگ است. باید تمام تلاشمان رو به کار بگیریم که از این قدرتی که این جمع افراد میتواند به ما بدهند نهایت استفاده را ببریم.
در مرحله قبل با تشویق افراد به مرتب کردن ایونتها این فرصت را بوجود آوردیم که افراد بتوانند با یکدیگر بحث و چالش بکنند. و متوجه شدیم چقدر این بحثها برای ما ارزشمند و مهم بودند. تعدادی زیادی استیکینت نارنجی و قرمز افزوده شده بر روی دیوار، حاصل همین امر بود.
در این راند میخواهیم همین روال را ادامه دهیم. اما با یک پرکتیس جدید و البته جذاب و فان. همه افراد از دیوار فاصله بگیرند. یک راوی را انتخاب کنید. راوی باید کنار دیوار بیاید. به ترتیب از ابتدای دیوار شروع به خواندن ایونتها کند. با صدای بلند و البته آهسته و پیوسته. اتفاقات جالبی در این بخش رخ خواهد داد. باید ایونتهای هر فرآیند شبیه به یک داستان سرایی ساده و روان از آن رویداد به گوش برسد. افراد در این مرحله همچنان استیکینتها و ماژیک را در دست داشته باشند.
بقیه افراد مشارکت کننده باید به دقت به راوی گوش بدهند. حین خوانش، سوالات و ابهامات بسیار زیادی بیرون میزند. این اولین تلاشی است که همه مشارکت کنندگان ساکت شده و به یک نفر به دقت گوش میدهند. به عنوان تسهیلگر مراقب این راند باشد. بحثها را بصورت فعال دنبال کنید. مجدد تاکید میکنم برای اینکه هیچ بحثی گم نشود، حتما بحث را بر روی استیکینتهای مناسب رکورد کرده و بر روی دیوار بچسبانید. با توجه به اینکه مشارکتکنندگان معمولا از دپارتمانهای مختلفی از سازمان حضور دارند، طولانی شدن بحث بر روی یک فرآیند یا ایونتی که مثلا مربوط به دپارتمان مارکتینگ است ممکن افرادی که از دپارتمانهای دیگر حضور دارد را خسته کند و آنها دیگر بحثها را دنبال نکنند. مراقب گوشیهای موبایل باشید ?. کسی سر وقت موبایل نرود. این یک پراسس اسمل مهم برای شماست.
اگر در حین خوانش ایونتها توسط راوی، کارتهای جدیدی بر روی دیوار افزوده شد، یا به هر دلیل حین خوانش یک وقفه ایجاد شد، پیشنهاد میکنم که راوی مجدد از ابتدای همان فرآیند شروع به خواندن رویدادها کند.
وقتی خوانش ایونتها به اتمام رسید، از راوی بخواهید که ایندفعه ایونتها را از آخر به اول بخواند. این تلاشی است جذاب و البته فان برای غلبه بر blind spot. باید انتظار اتفاقات جالبی را بکشید. مشاهده خواهید کرد که مجدد بحثهای جالبی بین مشارکتکنندگان شکل خواهد گرفت.
تایم باکس بودن این بخش را نیز فراموش نکنید. مدت زمان این بخش مجدد بستگی به عواملی از جمله بزرگی و پیچیدگی دامین، تعداد ایونتها و همینطور افراد حاضر در جلسه دارد. پیشنهاد میکنم تایمی بین 15 تا 25 دقیقه برای این بخش در نظر بگیرید.
راند سوم => پایان بخش کارگاه Big Picture ایونتاستورمینگ، شروعی بر کارگاههای دیگر …
یکی از تکنیکهای مهمی که معمولا در کارگاههای ایونتاستورمینگ استفاده میکنم Welcome Ideas است. از افراد بخواهید که بدون در نظر گرفتن هر گونه محدویتی، چیزهای دور از ذهنی که آرزو میکنند در نرمافزار وجود داشته باشد را بر روی یک استیکینت مجزا بنویسند و بر روی دیوار بچسبانند. این کار مشارکتکنندگان را از قید و بند فکری دامین رها میکند. بخصوص هنگامی که سازمان قصد دارد یکی از سیستمهای موجودش را بازنشست کرده و آنرا از ابتدا شروع به پیادهسازی کند. نکات جالبی از دل این welcome ideas بیرون میزند.
گاهی ذهن مشارکتکنندگان و متخصصان دامین آنقدری بایاس شده است که تصور میکنند ذات دامینشان جوری است که نمیتوان فلان فیچر را داشت. خیلی وقتها متوجه خواهید شد که این یک فکت صحیح نیست. بلکه بخاطر بایاس شدن ذهن ما بوجود آمده است. اینها برای تیم توسعه و بخصوص مالکان محصول ، میتواند بسیار مهم و حیاتی باشد. اگر دنبال تلاش برای خوشحال کردن مشتری هستید، اینها سرنخهایی خیلی خوبی برای شروع این سفر جذاب به شما میدهند. میتواند این ایدهها و آرزوها رو بر روی استیکینتهای سبز رنگ بنویسید.
تکنیک دیگری که میتوانید بکار بگیرید این است که از مشارکتکنندگان در کارگاه بخواهید که به مهمترین painها و gainهای موجود در دامنه فکر کنند. معمولا این فاکتورها حول و حوش پول و هزینه میچرخند. جایی که بیشترین بازده مالی را برای کسبوکار میتواند به دست بیاورد. بخشی که بیشترین چالش و پیچیدگی را به دنبال خواهد داشت. بخشی که از نظر پیادهسازی و تجارب محصولات قبلی همیشه با درد و زخم همراه بوده است.
میتوانید به این صورت عمل کنید که به هر نفر چند حق رای بدهید. به ازای هر pain و gain هر نفر بین 3 تا 5 حق رای دارد. سپس از مشارکتکنندگان بخواهید که رایهای خودشون رو بر روی کارتهای مشخص شده علامت بزنند. افراد میتوانند جهت نشان دادن اهمیت یک موضوع تمام یا تعدادی از رایهای خودشون را به یک ایونت بدهند.
توان فنی، منابع و زمان برای همه تیمها همیشه یک محدودیت مهم غیر قابل انکار بوده است. این تکنیک کمک میکند که به بیشترین تمرکز را بر روی مهمترین بخشها قرار دهیم.
در حینی که افراد در حال انجام دادن این تکنیک هستند، متوجه میشوند که برخی از مهمترین pain و gainها حتی روی دیوار پارک هم نشده است! خطر بزرگی از بیخ گوشتان رد شد ?. همواره خطر بایاس شدن و فراموش کردن بخشهایی از فرآیندها به دلایل مختلف وجود دارد. حتی اگر این بخشها مهمترین بخشهای کسبوکار باشد.
واگرایی یا همگرایی این رایها نیز نکته بسیار مهمی در پی خواهد داشت. واگرایی بدین معنی است که حداقل از نقطه نظر اهمیت مشارکتکنندگان بر روی یک صفحه نیستند. این مورد را بعدا بررسی کنید. در طول جلسه این موضوع را وارد بازی نکنید. در این بازه در مقالهای جداگانه صحبت میکنم.
عکس دسته جمعی پس از پایان جلسه رو فراموش نکنید…
این مقاله در مورد Big Picture ایونت استورمینگ بود. به کارگاههای Process Level ایونت استورمینگ و Design Level ایونت استورمینگ در مقالات جداگانهای خواهم پرداخت.
با ما باشید …