بعضی از مشکلات، آن‌قدر آشنا هستند که خیال می‌کنیم راه‌حلشان را هم می‌دانیم.
سیستم کند شده؟ منابع بیشتری به آن اختصاص بدهیم.
فروش پایین آمده؟ تبلیغات را بیشتر کنیم.
کارها عقب افتاده؟ تیم را تحت فشار بگذاریم.
مشتری ناراضی است؟ یک تخفیف بدهیم.
و گاهی چند روز، چند هفته یا چند ماه بعد، همان مشکل دوباره برمی‌گردد. اینجاست که یک سؤال مهم مطرح می‌شود:
آیا ما واقعا مسئله را حل کرده‌ایم، یا فقط یکی از نشانه‌های آن را برای مدتی ساکت کرده‌ایم؟
حل مسئله، برخلاف چیزی که در نگاه اول به نظر می‌رسد، بیشتر از آنکه درباره «پیدا کردن جواب» باشد، درباره «فهمیدن مسئله» است.
OECD در چارچوب حل مسئله خود، یک مسئله را موقعیتی تعریف می‌کند که فرد هدف مشخصی دارد اما روش آشکاری برای رسیدن به آن هدف در اختیارش نیست. بنابراین حل مسئله یعنی حرکت از وضعیت موجود به وضعیت مطلوب، زمانی که مسیر رسیدن به آن از قبل مشخص نیست.
این تعریف یک نکته مهم در خودش دارد: اگر جواب از قبل کاملا مشخص باشد، احتمالا با یک «وظیفه» روبه‌رو هستیم، نه یک مسئله واقعی.
یکی از رایج‌ترین خطاهای ما این است که به محض دیدن یک مشکل، ذهنمان شروع می‌کند به تولید راه‌حل.
«یک جلسه بگذاریم.»
«یک نفر جدید استخدام کنیم.»
«این قابلیت را به محصول اضافه کنیم.»
«فرآیند را عوض کنیم.»
«از هوش مصنوعی استفاده کنیم.»
اما ممکن است هنوز ندانیم دقیقا چه چیزی را باید حل کنیم.
فرض کنید مدیر یک تیم می‌گوید:
«بهره‌وری تیم پایین آمده.»
این جمله یک مسئله نیست؛ بیشتر یک برداشت کلی است.
بهره‌وری کدام بخش پایین آمده؟
از چه زمانی؟
نسبت به چه معیاری؟
در کدام افراد یا فعالیت‌ها؟
اثر آن دقیقا چیست؟
و اصلا آیا مشکل «کم‌کاری افراد» است یا فرآیندی که باعث شده زمان زیادی صرف کارهای کم‌ارزش شود؟
در حل مسئله حرفه‌ای، تعریف مسئله باید تا حد امکان قابل مشاهده و قابل اندازه‌گیری باشد. انجمن کیفیت آمریکا (ASQ) نیز در روش‌های حل مسئله بر تعریف دقیق، محدود کردن و قابل‌اندازه‌گیری کردن مسئله تأکید می‌کند.
به جای اینکه بگوییم:
«تیم پشتیبانی ضعیف عمل می‌کند.»
می‌توانیم بگوییم:
«میانگین زمان پاسخ‌گویی به درخواست‌های مشتریان در سه ماه گذشته از ۴ ساعت به ۹ ساعت رسیده است.»
حالا تازه یک مسئله داریم.
یکی از مهم‌ترین مهارت‌های حل مسئله، تشخیص تفاوت میان «نشانه» و «علت» است.
فرض کنید هر چند روز یک بار سرویس یک محصول از دسترس خارج می‌شود.
Down شدن سرویس، نشانه است.
اما علت چیست؟
ممکن است Memory Leak داشته باشیم.
ممکن است یک Query ناکارآمد باشد.
ممکن است ظرفیت زیرساخت کافی نباشد.
ممکن است یک تغییر نرم‌افزاری بدون تست مناسب وارد Production شده باشد.
ممکن است اصلا مشکل در خود سرویس نباشد و از یک وابستگی خارجی ناشی شود.
اگر فقط سرویس را Restart کنیم، احتمالا مشکل برای مدتی ناپدید می‌شود. اما چیزی حل نشده است.
اینجا مفهوم Root Cause یا «علت ریشه‌ای» اهمیت پیدا می‌کند.
ASQ، تحلیل علت ریشه‌ای یا Root Cause Analysis را مجموعه‌ای از روش‌ها و ابزارهایی می‌داند که برای شناسایی علل اساسی مشکلات و هدایت اقدامات اصلاحی استفاده می‌شوند؛ با این هدف که به جای درمان موقت نشانه‌ها، از تکرار مسئله جلوگیری شود. یکی از ابزارهای معروف در این زمینه، تکنیک Five Whys است. سؤال ساده‌ای که می‌پرسد: «چرا؟» و دوباره: «چرا؟» و دوباره.
نه لزوما دقیقا پنج بار؛ عدد پنج بیشتر یک قاعده تجربی است. خود ASQ هم تأکید می‌کند که بسته به مسئله ممکن است کمتر یا بیشتر از پنج بار پرسیدن «چرا» لازم باشد.
مثلا:
سرویس از کار افتاد.
چرا؟
چون حافظه پر شد.
چرا حافظه پر شد؟
چون مصرف Memory در طول زمان افزایش پیدا می‌کرد.
چرا؟
چون یک فرآیند منابع آزادشده را به‌درستی Release نمی‌کرد.
چرا؟
چون در بخشی از کد، مدیریت منابع به شکل مناسبی انجام نشده بود.
حالا مسئله دیگر «Restart کردن سرویس» نیست.
مسئله به یک نقص مشخص در مدیریت منابع رسیده است.
پرسیدن «چرا» به تنهایی کافی نیست. چون ممکن است خیلی راحت به یک جواب از پیش ساخته‌شده برسیم.
«کاربر آموزش ندیده.»
«توسعه‌دهنده اشتباه کرده.»
«تیم دقت نکرده.»
«مدیر تصمیم اشتباهی گرفته.»
این جواب‌ها ممکن است درست باشند، اما معمولا پایان تحلیل نیستند.
حتی ASQ درباره تحلیل علت ریشه‌ای در مسائل پیچیده به خطر سوگیری تأییدی اشاره می‌کند؛ یعنی وقتی فرد یا تیم از ابتدا به یک علت خاص باور دارد، ممکن است شواهد دیگر را نادیده بگیرد. یکی از راه‌های کاهش این مشکل، وارد کردن دیدگاه‌های مختلف و بررسی عینی‌تر فرضیه‌هاست.
بنابراین در مسائل پیچیده، بهتر است به جای اینکه بپرسیم:
«چه کسی مقصر است؟»
بپرسیم:
«چه چیزی در سیستم باعث شد این اتفاق ممکن شود؟»
این تغییر کوچک در نوع سؤال، می‌تواند کیفیت تصمیم‌گیری را کاملا تغییر دهد.
وقتی مسئله را درست تعریف کردیم و درباره علت‌های احتمالی به اندازه کافی تحقیق کردیم، تازه وارد مرحله تولید راه‌حل می‌شویم. اینجا هم یک اشتباه رایج داریم: خیلی سریع به اولین ایده خوبمان می‌چسبیم. اما حل مسئله خلاقانه معمولا به تولید چند گزینه نیاز دارد.
OECD در چارچوب تفکر خلاق PISA 2022، تفکر خلاق را توانایی تولید، ارزیابی و بهبود ایده‌هایی می‌داند که می‌توانند به راه‌حل‌های اصیل و اثربخش منجر شوند. یعنی فرآیند فقط «ایده دادن» نیست؛ ارزیابی و اصلاح ایده هم بخشی از آن است.
پس بهتر است به جای اینکه بگوییم:
«این بهترین راه‌حل است.»
بپرسیم:
«چه گزینه‌های دیگری داریم؟»
«اگر این راه‌حل را اجرا نکنیم، چه گزینه‌ای داریم؟»
«آیا می‌توانیم مسئله را از زاویه مشتری ببینیم؟»
«از زاویه تیم فنی چطور؟»
«اگر محدودیت بودجه نداشتیم چه می‌کردیم؟»
«اگر مجبور بودیم با یک‌دهم هزینه این مسئله را حل کنیم چه؟»
گاهی بهترین راه‌حل، از تغییر زاویه نگاه به مسئله به دست می‌آید.
در سازمان‌ها گاهی تصور می‌کنیم حل مسئله یعنی اجرای یک پروژه بزرگ. اما همیشه این‌طور نیست. گاهی یک تغییر کوچک در فرآیند، یک Automation ساده، حذف یک مرحله غیرضروری، تغییر یک KPI یا حتی اصلاح یک تصمیم می‌تواند اثر بیشتری از یک پروژه چندماهه داشته باشد.
به همین دلیل، پیش از اجرای راه‌حل باید پرسید:
«چطور می‌توانیم این ایده را با کمترین هزینه و ریسک امتحان کنیم؟»
این همان جایی است که مفهوم Experiment وارد حل مسئله می‌شود.
به جای اینکه شش ماه روی یک راه‌حل سرمایه‌گذاری کنیم و بعد بفهمیم اشتباه بوده، می‌توانیم نسخه کوچک‌تر آن را آزمایش کنیم، نتیجه را ببینیم و سپس تصمیم بگیریم.
این رویکرد با منطق Design Thinking نیز هم‌راستاست. IDEO بر ماهیت تکرارشونده حل مسئله تأکید می‌کند؛ یعنی به جای حرکت کاملا خطی از مسئله به راه‌حل، باید میان تعریف مسئله، تولید ایده، ساخت و آزمون حرکت کرد و از نتایج آزمون برای اصلاح راه‌حل استفاده کرد.
فرض کنید مشکلی را حل کردیم.
کار تمام شده؟
نه.
یک سؤال مهم‌تر وجود دارد:
«از این مسئله چه چیزی یاد گرفتیم؟»
اگر همان مشکل دوباره اتفاق بیفتد، آیا این بار سریع‌تر متوجه آن می‌شویم؟
آیا فرآیندمان را اصلاح کرده‌ایم؟
آیا دانش به تیم منتقل شده؟
آیا مستندات به‌روزرسانی شده؟
آیا شاخصی ایجاد کرده‌ایم که بتواند هشدار زودهنگام بدهد؟
حل مسئله واقعی فقط بازگرداندن سیستم به وضعیت عادی نیست؛ ایجاد شرایطی است که احتمال تکرار مشکل کمتر شود.
NASA نیز در نظام Lessons Learned خود، تجربه‌ها و رویدادهای پروژه‌ها را به توصیه‌هایی برای بهبود آموزش، رویه‌ها، سیاست‌ها و Best Practiceها تبدیل می‌کند. این نگاه نشان می‌دهد که یک مسئله حل‌شده می‌تواند به منبعی برای یادگیری سازمانی تبدیل شود.
چون محیط کاری دیگر شبیه گذشته نیست. مسائل امروز معمولا چندلایه‌اند، اطلاعات ناقص است، فناوری به‌سرعت تغییر می‌کند و خیلی از مشکلات پاسخ از پیش آماده ندارند.
گزارش Future of Jobs 2025 مجمع جهانی اقتصاد، Analytical Thinking را مهم‌ترین مهارت هسته‌ای موردنیاز از نگاه کارفرمایان معرفی می‌کند؛ ۶۹ درصد از کارفرمایان شرکت‌کننده آن را یک مهارت کلیدی می‌دانند. Creative Thinking نیز با ۵۷ درصد در رتبه چهارم قرار گرفته است.
یعنی در بازار کار امروز، ارزش یک فرد فقط به این نیست که «چقدر می‌داند». بخش مهمی از ارزش او به این بستگی دارد که:
وقتی جواب مشخصی وجود ندارد، چطور فکر می‌کند؟
وقتی اطلاعات ناقص است، چطور تصمیم می‌گیرد؟
وقتی راه‌حل اول جواب نمی‌دهد، چطور مسیر را اصلاح می‌کند؟
و وقتی با یک مسئله پیچیده مواجه می‌شود، آیا می‌تواند آن را به بخش‌های کوچک‌تر و قابل‌حل تبدیل کند؟
این همان چیزی است که حل مسئله را از یک مهارت صرفا مدیریتی یا فنی به یک مهارت عمومی زندگی و کار تبدیل می‌کند.
اگر بخواهم کل این بحث را به یک مسیر ساده تبدیل کنم، می‌توانیم هنگام مواجهه با یک مسئله این شش سؤال را از خودمان بپرسیم:
۱. دقیقا چه چیزی مشکل است؟
۲. شواهد و داده‌های ما برای اثبات آن چیست؟
۳. نشانه را با علت چگونه تفکیک کنیم؟
۴. چه علت‌های محتمل دیگری ممکن است وجود داشته باشد؟
۵. چه گزینه‌های مختلفی برای حل مسئله داریم و چطور می‌توانیم آنها را آزمایش کنیم؟
۶. بعد از اجرای راه‌حل، از کجا بفهمیم مسئله واقعا حل شده و دوباره تکرار نخواهد شد؟
این شش سؤال شاید ساده به نظر برسند، اما اگر واقعا به آنها پاسخ بدهیم، کیفیت بسیاری از تصمیم‌های روزمره‌مان تغییر می‌کند. در نهایت، حل مسئله یعنی قبل از اینکه با عجله دنبال جواب بگردیم، کمی مکث کنیم و مسئله را درست ببینیم. چون گاهی بزرگ‌ترین اشتباه ما این نیست که جواب اشتباهی پیدا کرده‌ایم. این است که از ابتدا داشتیم مسئله اشتباهی را حل می‌کردیم.
OECD، چارچوب و نتایج Creative Problem Solving و Creative Thinking.
ASQ، Problem Solving و Root Cause Analysis.
ASQ، Five Whys و Five Hows.
World Economic Forum، The Future of Jobs Report 2025.
IDEO، Design Thinking Process.
NASA، Lessons Learned Information System.
