منبع: بنیاد طراحی تعامل (IxDF) · بازنویسی آزاد: سپنتا پویا · مرداد ۱۴۰۵ · زمان مطالعه: حدود ۱۳ دقیقه

مسائل شرور (Wicked Problems) چیست؟

💡 این متن «بازنویسی آزاد» است: ایده‌ها و مفاهیم مطلب اصلی با نگارش کاملاً مستقل فارسی و مثال‌های تازه بازگو شده‌اند و ترجمهٔ کلمه‌به‌کلمه نیست. بخش‌های افزودهٔ مترجم در جعبهٔ منبع مشخص شده‌اند.

فهرست نمونه‌های منبع این‌هاست: تغییر اقلیم، فقر، تروریسم جهانی، کم‌آبی، امنیت غذایی، تنوع زیستی. یعنی «شرور» عملاً هم‌معنای «بحران جهانی» شده.

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

تعریف

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

این اصطلاح را هورست ریتل، نظریه‌پرداز طراحی در مدرسهٔ طراحی اولم، در مقالهٔ «دوراهی‌ها در نظریهٔ عمومی برنامه‌ریزی» ساخت و ده ویژگی برایش شمرد.

ده ویژگی ریتل

• - ۱. هیچ فرمول قطعی برای مسئلهٔ شرور وجود ندارد.
• - ۲. قاعدهٔ توقف ندارند — راهی نیست بدانید راه‌حلتان نهایی است.
• - ۳. راه‌حل‌ها درست‌یا‌غلط نیستند؛ فقط خوب‌یا‌بد‌اند.
• - ۴. آزمون بی‌درنگی برای راه‌حل وجود ندارد.
• - ۵. هر راه‌حل یک «عملیات تک‌شات» است؛ فرصت یادگیری از راه آزمون‌و‌خطا نیست، پس هر تلاش سنگین حساب می‌شود.
• - ۶. تعداد راه‌حل‌های ممکن، مجموعه‌ای معین نیست.
• - ۷. هر مسئلهٔ شرور در اساس یگانه است.
• - ۸. هر مسئلهٔ شرور را می‌شود نشانهٔ مسئلهٔ دیگری دانست.
• - ۹. همیشه بیش از یک تبیین برای مسئله وجود دارد، و تبیین‌ها بسته به منظر فرد به‌شدت تفاوت می‌کنند.
• - ۱۰. برنامه‌ریز/طراح «حق اشتباه‌کردن ندارد» و باید کاملاً پاسخگوی کنش‌هایش باشد.

و ریچارد بوکانان در ۱۹۹۲ این مفهوم را به تفکر طراحی وصل کرد: فرایند تکرارشوندهٔ تفکر طراحی — بازچارچوب‌بندی انسان‌محورِ مسئله، تولید انبوه ایده، و نمونه‌سازی و آزمون دستی — برای مسئله‌های بدتعریف‌شده کارآمد است.

پاسخ‌هایی که منبع می‌آورد

از دان نورمن سه راهبرد وام‌گرفته از توسعهٔ نرم‌افزار نقل می‌کند: گام‌به‌گام‌گرایی (حرکت در قدم‌های کوچک و انطباق‌پذیر) · کمینهٔ محصول پذیرفتنی (ساختن بخش‌های کوچک و کارکنندهٔ راه‌حل بزرگ‌تر) · و رویکرد شیءگرا (تمرکز بر ورودی و خروجی سامانه، نه فرایند درونی‌اش، تا پیمانه‌ای و انطباق‌پذیر بماند).

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

معیار درست، بزرگی نیست — اختلاف است

این بخش افزودهٔ مترجم است، و به‌نظرم مهم‌ترین چیزی که آن فهرست نمونه‌ها پنهانش می‌کند.

ویژگی نهم ریتل ــ «همیشه بیش از یک تبیین وجود دارد و تبیین‌ها بسته به منظر تفاوت می‌کنند» ــ ویژگی باربر است، نه یکی از ده. چون در مسئلهٔ شرور، تعریف مسئله و تعریف راه‌حل یک کار واحدند: نحوهٔ صورت‌بندی مسئله تعیین می‌کند چه چیزی راه‌حل شمرده می‌شود — و ذی‌نفعان طور مختلفی صورت‌بندی‌اش می‌کنند چون منافعشان مختلف است.

پس آزمون عملی این نیست که «آیا این مسئله بزرگ است؟». این است:

• - آیا دو ذی‌نفعِ صادق و مطلع، این مسئله را طور دیگری توصیف می‌کنند — طوری که «موفقیت» معنای دیگری بگیرد؟
• - اگر نه: این مسئله پیچیده است، شرور نیست. برو حلش کن.
• - اگر بله: شرور است — در هر مقیاسی.

و نتیجه‌اش این است که شرور‌بودن ویژگی موضوع نیست، ویژگی اختلاف است. پس:

• - «سامانهٔ بازپرداخت ما چطور باید کار کند» یک مسئلهٔ شرور است، اگر مالی آن را مسئلهٔ ریسک ببیند، پشتیبانی مسئلهٔ حجم تیکت، و رشد مسئلهٔ نرخ تبدیل. مقیاسش کوچک است؛ ساختارش دقیقاً همان است.
• - و «تغییر اقلیم» برای تیم محصول شما شرور نیست — بیرون از دامنه است. این دو یکی نیستند، و قاطی‌کردنشان باعث می‌شود آدم‌ها فکر کنند مسائل شرور چیزی است که به آن‌ها مربوط نمی‌شود.

دو ویژگی از ده ویژگی، برای نرم‌افزار دیگر درست نیستند

این بخش هم افزودهٔ مترجم است و به‌نظرم کاربردی‌ترین چیز در کل این موضوع.

ریتل در ۱۹۷۳ دربارهٔ برنامه‌ریزی شهری می‌نوشت: سد، بزرگراه، سیاست مسکن. و برای یک بزرگراه، ویژگی چهارم («آزمون بی‌درنگی وجود ندارد») و ویژگی پنجم («تک‌شات است؛ فرصت آزمون‌و‌خطا نیست») واقعاً درست بودند.

اما برای یک محصول نرم‌افزاری هر دو غلطاند: می‌توانید روی یک درصد کاربر منتشر کنید و اندازه بگیرید، و می‌توانید برگردانید. یعنی مزیت تیم نرم‌افزار بر برنامه‌ریز ۱۹۷۳ دقیقاً این است که ویژگی پنجم را شکسته — و همین است که پاسخ گام‌به‌گام‌گرایی و MVP نورمن را کار‌آمد می‌کند.

و روی دیگرش، نکتهٔ اصلی است: آن بخش‌هایی از محصول شما که ویژگی چهارم و پنجم در آن‌ها هنوز درست است، همان‌هایی‌اند که واقعاً مثل مسئلهٔ شرور رفتار می‌کنند. این‌ها را نمی‌شود صادقانه A/B کرد:

• - تغییر قیمت. کاربر قیمتی را که دیده نمی‌تواند ندیده بگیرد، و آزمون قیمت روی گروه‌های مختلف پیامد اعتماد دارد.
• - مهاجرت داده. برگرداندنش در تئوری ممکن است و در عمل هفته می‌برد.
• - تعهد عمومی. اعلام یک ویژگی یا یک تاریخ، برگشت‌ناپذیر است.
• - و تغییر چیزی که کاربر یادش گرفته. مهارتی که او ساخته را نمی‌توانید با بازگرداندن نسخه به او پس بدهید.

پس ده ویژگی ریتل به یک قاعدهٔ غربال تبدیل می‌شود: کدام تصمیم‌های من تک‌شات‌اند؟ همان‌ها سزاوار تمام آن آهستگی‌اند — و بقیه را باید سریع فرستاد و اندازه گرفت، چون برایشان دیگر مسئلهٔ شرور نیستند.

ویژگی دهم یک بند مسئولیت حقوقی است، نه یک اصل طراحی

این بخش هم افزودهٔ مترجم است. ویژگی دهم می‌گوید طراح «حق اشتباه‌کردن ندارد» و باید کاملاً پاسخگو باشد. و اگر این را با ویژگی دوم (قاعدهٔ توقف ندارد) و پنجم (تک‌شات) جمع کنید، نتیجهٔ منطقی‌اش فلج‌شدن است: کاملاً مسئولی، نمی‌توانی آزمون کنی، و هرگز نمی‌فهمی تمام شده.

و به‌نظرم همین بند است که در عمل باعث می‌شود مسائل شرور یا رها شوند یا به یک کمیته سپرده شوند.

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

• - صورت‌بندی‌ای که انتخاب کردید را بنویسید — و اینکه صورت‌بندی چه کسی را رد کردید. این تنها سندی است که بعداً می‌گوید چرا این تصمیم گرفته شد.
• - تغییر را هرجا شد بازگشت‌پذیر نگه دارید — چون این همان چیزی است که ویژگی پنجم را باطل می‌کند.
• - و ابزار سنجش بگذارید تا خودتان پیش از کاربر بفهمید اشتباه کرده‌اید.

این کار ویژگی دهم را از یک بند فلج‌کننده به یک وظیفهٔ مستندسازی تبدیل می‌کند — که قابل انجام است.

«۵۵ دقیقه فکر» با نمونه‌سازی زودهنگام در تناقض است

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

و حلش «تعادل» نیست. برای مسئلهٔ شرور، نمونه‌سازی همان راه فهمیدن مسئله است — می‌سازید تا بفهمید مسئله چه بود. دلیلش هم ویژگی نهم است: ذی‌نفعان نمی‌توانند صورت‌بندی‌شان را در انتزاع بیان کنند، ولی می‌توانند به یک چیز مشخص واکنش بدهند.

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

در بافت فارسی: محدودیتی که هیچ‌کس در اتاق نمی‌تواند عوضش کند

این بخش هم افزودهٔ مترجم است و سه نکته دارد.

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

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

و درمانش همان وظیفهٔ مستندسازی بالاست، با فوریت بیشتر: بنویسید که این را موقت پذیرفتید و چرا. چون شش ماه بعد آن راه‌حل موقت باربر شده و هیچ‌کس یادش نیست که قرار بود موقت باشد.

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

جمع‌بندی

• - مسائل شرور مسائلی با عوامل درهم‌تنیده و ناقص و در حال تغییرند؛ ریتل ده ویژگی برایشان شمرد و بوکانان تفکر طراحی را به‌عنوان پاسخ به آن‌ها وصل کرد.
• - اما معیار عملیاتی بزرگی نیست، اختلاف است: آیا دو ذی‌نفع صادق و مطلع این مسئله را طوری متفاوت توصیف می‌کنند که «موفقیت» معنای دیگری بگیرد؟ اگر نه، مسئله پیچیده است نه شرور.
• - پس یک مسئلهٔ شرور می‌تواند کوچک باشد (سامانهٔ بازپرداخت)، و تغییر اقلیم برای تیم محصول شما شرور نیست — بیرون از دامنه است.
• - ویژگی چهارم و پنجم ریتل برای نرم‌افزار غلط‌اند، و همین مزیت شماست؛ اما بخش‌هایی که هنوز تک‌شاتاند — قیمت، مهاجرت داده، تعهد عمومی، تغییر چیزی که کاربر یاد گرفته — واقعاً شرور‌اند.
• - ویژگی دهم («حق اشتباه ندارید») یک بند فلج‌کننده است؛ جانشینش: مسئول فرایند و بازگشت‌پذیری‌اید، پس صورت‌بندی انتخاب‌شده و صورت‌بندی رد‌شده را بنویسید، تغییر را بازگشت‌پذیر نگه دارید، و ابزار سنجش بگذارید.
• - «۵۵ دقیقه فکر» با نمونه‌سازی زودهنگام در تناقض است؛ حلش این است که برای مسئلهٔ شرور نمونه‌سازی همان راه فهمیدن مسئله است — ارزان‌ترین چیز غلط را بسازید و به مخالفان نشان بدهید.
• - و در بافت ما: مسئلهٔ شرور واقعی، محدودیت تغییرناپذیر است · حالت شکست ما فلج‌شدن نیست بلکه حل‌کردن زودهنگام است که دور‌زدن را به معماری تبدیل می‌کند · و صورت‌بندی تیم پشتیبانی را اول بشنوید، چون تنها کسانی‌اند که کل سامانه را می‌بینند.