حل مشکل از طریق Simplexity

یک پست قبلا نوشته بودم، در مورد Simplexity thinking. هفته گذشته، آخرین روزش هم برگزار شد و گواهیش رو هم دریافت کردیم. البته خیلی فشرده برگزار شد، اما به هرحال همه ماژولهاش رو گذروندیم. هرچند دخالتهای نادرست یک نفر در روند کار یک جاهایی خرابکاری ببار آورد (برگزار کننده دوره وقتی میشنید که فلان کار رو کرده، سرش رو تکون میداد و میگفت اشتباهه – همه اش هم به این دلیل که میخواد به هر بهونه ای بگه من از همه بهتر و بیشتر می فهمم!)، اما در کل روش جالبی بود. خصوصا اگر زمانی برای پیدا کردن راه حل مساله، بصورت تیمی قرار به فکر کردن باشه، بشرط اینکه همه واقعا صادقانه در این راه مشارکت کنن و جو هم طوری باشه که کسی از مدیر بالای سرش نترسه. در مورد خود ما، عملا زمانی که من با فرد مورد اشاره هم گروه می شدم حرف بدرد بخوری نمی زدم، چون متوجه شدم گوش شنوایی وجود نداره و یقینا در ذهنش برای آینده تاثیر منفی هم میذاره. ولی اگر به عنوان مثال خودم مدیر باشم یا کسی مثل منصور رشتی یا علی مدیریت رو بر عهده داشته باشن، میشه خیلی خوب از این سیستم استفاده کرد.
روالش رو اینجا میگم؛ شاید به درد کسی خورد و اگر استفاده کردید، تجربیاتتون رو در اختیار بنده هم بگذارید:

1. Fuzzy situation: طرح مساله. شما یک مشکلی دارید که قراره حلش بکنید. خیلی واضح و روشن. مثلا کارآیی تیم پایینه.
2. Fact finding: درمورد این مشکل چی می دونید؟ هرچی به ذهنتون میرسه بگید. نکته بسیار مهم اینه که هیچ پیش داوری نباید رخ بده، هیچکس نباید کسی رو مسخره کنه یا بگه این حرفی که زدی چرت و پرت بود (چون دقیقا ممکنه همون نکته، راهگشای مساله باشه). اگر کوچکترین پیش داوری بشه (مثل اتفاقی که برای خود من در شرکت افتاد) این احتمال هست که دیگه شاهد بیان صادقانه موارد نباشیم. مثلا در مورد پایین بودن کارآیی تیم، می تونیم بگیم به دلیل اینکه دانش فنی کافی وجود نداره، تجربه کاری وجود نداره، افراد دوباره کاری می کنن و …
3. سه تا از موارد مرحله قبل رو انتخاب می کنیم. هرکسی سه تا از اون برچسب کوچولوهایی که توی پست قبلی بهش اشاره کردم رو کنار آیتم مورد نظرش می چسبونه. بعد که همه این کار رو کردن، هرکسی دلیلش برای انتخاب اون گزینه رو میگه. سپس یک مورد که از همه موارد (با توجه به رای همه افراد) مهمتر هست رو انتخاب می کنیم. اگر بیشتر از یک مورد بود، می تونیم چرخه رو مجدد برای سایر موارد طی کنیم، اما توجه کنید که هربار یک مشکل رو قراره حل کنیم.
4. مورد انتخابی رو به صورت How might we بررسی می کنیم. یعنی سوال می کنیم، چطور میشه فلان کار رو کرد. فرض کنید از موارد اشاره شده در مرحله ۲، دوباره کاری کردن افراد تیم به عنوان دلیل اصلی مشکل انتخاب شده باشه. در این حالت، باید سوال کنیم چگونه می توان از دوباره کاری کردن افراد جلوگیری کرد (How might we prevent team members to redo everything)
5. جواب به این سوال رو مجدد از همه می پرسیم. تمام گزینه ها مجددا با رعایت عدم پیش داوری جمع آوری میشه، افراد مجددا با برچسب های کوچیک رنگی گزینه های مورد نظرشون رو انتخاب می کنن، بحث می کنیم و در نهایت یکی رو به عنوان دلیل اصلی انتخاب می کنیم. مثلا فرض کنید دلیل انتخاب شده از طرف افراد، فقدان یک معمار سیستم باشه.
6. این مورد اصلی رو روی یک برگه می نویسیم. برگه ها از این استیکر هایی هستند که به راحتی چسبونده میشن و کنده میشن. این استیکر رو میگذاریم وسط یگ برگه کاغذ به این شکل، به عنوان مشکل اصلی:

7. باید با پرسیدن سوالات Why و What’s stopping به طرف بالا و پایین حرکت کنیم. مثلا چرا یک معمار سیستم می خواهیم؟ فرض کنیم پاسخ به این سوال، ارائه خدمات بهتر به مشتریان باشه. این جمله رو روی یک استیکر دیگه می نویسیم و یک پله بالاتر از برگه فقدان یک معمار سیستم می چسبونیم. حالا باید امتحانش کنیم. What’s stopping us تا خدمات بهتر به مشتریان ارائه بدیم؟ آیا پاسخش، فقدان یک معمار سیستم در مجموعه است؟ اگر پاسخ مثبت باشه، بنابراین معلوم میشه جایگاه استیکر جدید، درسته. ممکنه بعدا به این نتیجه برسیم که بین این دو تا استیکر، یک مرحله دیگه هم وجود داره (یعنی بین ارائه خدمات بهتر به مشتریان و استخدام یک معمار سیستم، باید مسائل دیگه ای هم در نظر گرفته بشه).
8. به همین ترتیب، به سمت پایین هم باید حرکت کنیم. یعنی این سوال رو بپرسیم که چه چیزی ما رو از داشتن یک معمار سیستم محروم کرده؟ فرض کنید پاسخ به این سوال، در نظر نگرفتن جایگاه شغلی برای معماری سیستم باشه. مجددا این گزینه رو روی استیکر می نویسیم و پایین برگه فقدان یک معمار سیستم می چسبونیم. بعد امتحانش می کنیم، آیا در نظر نگرفتن جایگاه شغلی برای معماری سیستم باعث شده که ما به فقدان یک معمار سیستم برسیم؟ جواب مثبته و می تونیم این برگه رو همینجا حفظ کنیم.
9. با در نظر گرفتن برگه فقدان یک معمار سیستم به عنوان نقطه کلیدی، باید سوالات متعدد در هر دو جهت از همه اعضای تیم بپرسیم و همه ایده ها رو جمع آوری کنیم. در آخر و با استفاده از نظر جمعی، اصلی ترین دلیل این چالش رو پیدا می کنیم. ممکنه این دلیل، اون فقدان یک معمار سیستم نباشه! به این معنی که ما برای حل یک مشکل در سازمان، ممکنه یک مشکل دیگه ای رو نادیده گرفته باشیم و با استفاده از این روش، مشکل اصلی رو شناسایی می کنیم و روی حل اون تمرکز می کنیم. به بیان دیگه با حل مشکل اصلی، اون موردی که در نظر گرفته بودیم هم حل خواهد شد.
10. این مشکل اصلی رو دوباره به مشورت میذاریم. دقت می کنید که چقدر مشارکت جمعی و نظرات مختلف افراد در این روش اهمیت داره. همه برای این مشکل راه حل ارائه میدن و در نهایت، سه تا ایده اصلی رو انتخاب می کنیم، باز هم بر طبق نظر جمعی.
11. یک برگه بزرگ دیگه رو بر میداریم، فاکتورهای کلیدی یا criteria های مهم رو توش می نویسیم. مثلا زمان، می تونه یک فاکتور کلیدی باشه. هزینه به همچنین. قابلیت پذیرش توسط افراد سازمان، مقبول مدیریت عامل یا هیات مدیره، راحتی پیاده سازی، منابع در دسترس برای مطالعه و … همه و همه می تونن جزو فاکتورهای کلیدی باشن.
12. باز هم سه تا از فاکتورهای کلیدی رو باید انتخاب کنیم. توی یک برگه جدید، فاکتورها رو به صورت افقی کنار هم می نویسیم. راه حلهای بدست اومده از مرحله ۹ رو هم بصورت عموی زیر هم می نویسیم. یک جدول تشکیل میشه و به ترتیب تعیین می کنیم در مورد هریک از راه حل ها، فاکتور مورد نظرمون چه امتیازی میاره. ۰ به معنی بی اهمیت ترین و ۳ به معنی بیشترین تاثیر خواهد بود.
13. آسانترین مورد را انتخاب می کنیم، برایش زمان، مکان و فرد عامل را تعیین می کنیم.

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