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

سامانه‌های پیچیدهٔ اجتماعی-فنی (Complex Socio-Technical Systems) چیست؟

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

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

این نوشته اول تعریف منبع را می‌سازد، بعد سراغ دلیل شناختی‌اش می‌رود، و در پایان پنج نشانهٔ عملی می‌دهد که بفهمید کدام‌یک از این دو را در دست دارید.

تعریف

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

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

ایراد نورمن به اصطلاح «مسئلهٔ شرور»

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

و ویژگی‌های مسئلهٔ شرور را همان‌طور که هست می‌شمارد: سخت‌تعریف‌شدنی · سامانه‌های پیچیده · نامعلوم‌بودن راه نزدیک‌شدن · و نامعلوم‌بودن اینکه آیا راه‌حل کار کرده یا نه.

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

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

چرا مغز ما برای این ساخته نشده

منبع بخش زیادی از دشواری را به خود مغز نسبت می‌دهد، و این قوی‌ترین بخش استدلالش است: ذهن ما به دیدن نتیجه در زنجیره‌های علّی مستقیم عادت دارد — «اگر X را بکنم، Y اتفاق می‌افتد». از نظر تکاملی برای فهم علت ساده و نتیجهٔ فوری ساخته شده‌ایم: سنگی می‌اندازیم و افتادنش را می‌بینیم.

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

• - مداخله‌ای که جواب نمی‌دهد، شبیه مداخله‌ای است که هنوز جواب نداده. و این دو، تصمیم متضاد می‌خواهند: یکی را باید برگرداند، دیگری را باید صبر کرد.
• - هرچه فشار بیشتری بدهید، جهش نهایی بزرگ‌تر است. وقتی چند بار مداخله می‌کنید و چیزی نمی‌بینید، همه‌شان با هم برمی‌گردند — و آن‌وقت نمی‌دانید کدام‌یک اثر داشت.
• - و شاهد، همیشه سر وقت نمی‌رسد. اگر تأخیر سامانه شش هفته باشد و چرخهٔ گزارش‌دهی شما دو هفته، هر گزارش شما دربارهٔ مداخلهٔ قبلی است، نه فعلی.

پنج نشانهٔ تشخیص

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

• - ۱. تأخیر میان مداخله و اثر. اگر نتیجهٔ کاری که امروز می‌کنید هفته‌ها بعد دیده می‌شود، هر تصمیم بعدی‌تان در تاریکی گرفته می‌شود.
• - ۲. هر اصلاح، هزینه را جابه‌جا می‌کند نه حذف. فرم را کوتاه کردید و بار به پشتیبانی رفت؟ آن یک سامانه است، نه یک صفحه.
• - ۳. اختلاف بر سر صورت‌بندی، نه بر سر راه‌حل. اگر دو نفر مطلع، همان وضعیت را یکی «مسئلهٔ فنی» و دیگری «مسئلهٔ سیاست‌گذاری» می‌نامند، شما مسئلهٔ واحدی ندارید.
• - ۴. صاحب مشخصی ندارد. مسئله در قلمرو دو یا سه تیم (یا دو یا سه سازمان) پخش است و هیچ‌کس اختیار کاملش را ندارد.
• - ۵. راه‌حل، مسئله را عوض می‌کند. همین که مداخله کردید، رفتار آدم‌ها عوض می‌شود و مسئلهٔ بعدی دیگر همان نیست. این نشانه از همه گویاتر است.

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

گام کوچک، درست انجام‌شده

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

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

در بافت فارسی: محصولی که یک گره از یک شبکه است

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

سه نتیجهٔ عملی از این وضعیت:

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

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

جمع‌بندی

• - سامانه‌های پیچیدهٔ اجتماعی-فنی مسئله‌های درهم‌پیچیدهٔ اجتماعی‌اند که راه پیشروی در آن‌ها گام‌های کوچک به‌سوی راه‌حل پایدار است — و به‌گفتهٔ نورمن، طراح نمی‌تواند مسئله‌ها و برداشت‌های غلط و خطاهای آینده را پیش‌بینی کند.
• - نورمن این‌ها را از مسئلهٔ شرور جدا می‌کند، نه به‌دلیل تفاوت ماهوی، بلکه چون آن اصطلاح زیادی به‌کار رفته؛ و چهار ویژگی‌اش را می‌شمارد: سخت‌تعریف‌شدنی، سامانهٔ پیچیده، نامعلوم‌بودن راه نزدیک‌شدن، و نامعلوم‌بودن اینکه راه‌حل کار کرده یا نه.
• - دشواری اصلی شناختی است: مغز ما برای زنجیرهٔ علّی مستقیم و نتیجهٔ فوری ساخته شده. پس مداخلهٔ بی‌اثر شبیه مداخلهٔ کندِ مؤثر است، فشار بیشتر جهش بزرگ‌تر می‌سازد، و شاهد سر وقت نمی‌رسد.
• - پنج نشانهٔ تشخیص: تأخیر · جابه‌جا‌شدن هزینه · اختلاف بر سر صورت‌بندی · بی‌صاحب‌بودن · و عوض‌شدن مسئله به‌دست راه‌حل — و اگر هیچ‌کدام برجا نیست، مسئله را درست کنید و بروید.
• - گام کوچکِ درست چهار شرط دارد: برگشت‌پذیر باشد · تأخیرش از قبل نوشته شود · یک اثر جانبی نام‌برده و سنجیده شود · و تصمیم با دلیلش ثبت شود.
• - و در بازار ما، محصول معمولاً یک گره از شبکه‌ای چندطرفه است: حالت خرابی طرف دیگر، طراحی شماست · پشتیبانی تنها ناظر کل است · و دور‌زدن‌ها معماری می‌شوند.