مسئله‌ی پشت مسئله
یک قدم پیش از جواب
کسی در یک انجمن فنی می‌پرسد:
«چطور سه حرف آخر نام یک فایل را جدا کنم؟»
جواب مستقیم آسان است. مثلاً اگر در bash جواب بدهیم:
name="photo.jpg"
echo "${name: -3}"
خروجی jpg است.
اما پیش از جواب، این سؤال را امتحان کنید:
اگر این درخواست انجام شود، چه چیزی قرار است بهتر شود؟
درخواست انتهای یک زنجیره است
شاید زنجیره چیزی شبیه این باشد:
فایل‌ها باید دسته‌بندی شوند ← نوع فایل را بفهمیم ← پسوند را پیدا کنیم ← سه حرف آخر را جدا کنیم
پرسنده فقط آخرین حلقه را به ما گفته است. اگر دقیقاً همان را جواب بدهیم، راه‌حل برای photo.jpg کار می‌کند، ولی برای photo.jpeg یا archive.tar.gz یا فایلی بدون پسوند نه.
یک سؤال کافی است تا حلقه‌ی قبلی دیده شود:
«سه حرف آخر را برای چه می‌خواهی؟»
«برای این‌که پسوند فایل را پیدا کنم.»
حالا مسئله عوض شده است. دیگر سؤال «چطور سه نویسه جدا کنم؟» نیست. سؤال «چطور پسوند را پیدا کنم؟» است. اگر به همین‌جا اکتفا کنیم، جواب تازه‌ای به پرسنده پیشنهاد می‌کنیم:
echo "${name##*.}"
هرچه بعد از آخرین نقطه آمده برمی‌گردد. این یکی برای photo.jpeg هم کار می‌کند. اما برای README که نقطه ندارد، کل نام را برمی‌گرداند.
می‌شود همان سؤال را یک بار دیگر پرسید:
«پسوند را برای چه می‌خواهی؟»
«برای این‌که نوع فایل را بفهمم.»
حالا شما چه می‌کردید؟ هنوز سراغ نام فایل می‌رفتید؟
راه‌حل دوباره عوض می‌شود. پسوند فقط حدسی درباره‌ی نوع فایل است و فایل بدون پسوند یا با پسوند اشتباه این حدس را خراب می‌کند. ابزار file به‌جای نام، به محتوای فایل نگاه می‌کند:
file --mime-type -b "$name"
برای photo.jpg جواب image/jpeg است، برای archive.tar.gz جواب application/gzip، و برای README بدون پسوند جواب text/plain.
یک بار دیگر:
«نوع فایل را برای چه می‌خواهی؟»
«می‌خواهم فایل‌های یک پوشه را بر اساس نوعشان دسته‌بندی کنم.»
از «سه حرف آخر» شروع کردیم و به «دسته‌بندی فایل‌ها» رسیدیم.
در انجمن‌های فنی این اتفاق آن‌قدر تکرار می‌شود که نامی برای آن گذاشته‌اند: مسئله‌ی XY.
کسی مسئله‌ی را دارد، حدس می‌زند راه‌حل آن است، و به‌جای پرسیدن درباره‌ی ، فقط می‌پرسد چگونه را انجام دهد. مشکل این نیست که حتماً بد است؛ مشکل این است که ما هنوز را ندیده‌ایم.
خیلی وقت‌ها چیزی که به دست ما می‌رسد خودِ مسئله نیست، یک درخواست است. پیش از آن‌که درخواست به ما برسد، کسی چند تصمیم گرفته است: چه چیزی درست کار نمی‌کند، چه راهی شاید آن را بهتر کند، و کدام تکه از آن راه را از ما بخواهد. ما معمولاً فقط تکه‌ی آخر را می‌بینیم.
پیشنهاد این برگه ساده است:
پیش از جواب دادن، گاهی ارزش دارد یک قدم عقب برویم.
یک قدم عقب، جواب را عوض می‌کند
مثال دوم از محیط کار است. مدیری به تحلیل‌گر تیمش می‌گوید:
«از این هفته گزارش هفتگی را روزانه کنید.»
می‌شود فوراً انجامش داد. اما سؤال دیگری هم می‌شود پرسید:
«با گزارش روزانه چه تصمیمی می‌گیرید که با گزارش هفتگی نمی‌شد؟»
فرض کنیم جواب این باشد:
«هفته‌ی پیش یک افت غیرعادی اتفاق افتاد و شش روز بعد فهمیدیم.»
حالا درخواست و مسئله دو چیز متفاوت‌اند.
درخواست:
گزارش بیشتری تولید کنیم.
مسئله:
تغییر غیرعادی را دیر می‌فهمیم.
اگر این تعریف درست باشد، شاید گزارش روزانه اصلاً بهترین پاسخ نباشد. شاید همان گزارش هفتگی کافی باشد و فقط هشداری لازم باشد که هنگام یک تغییر غیرعادی فرستاده شود.
یک قدم عقب رفتیم، و فضای راه‌حل‌ها بزرگ‌تر شد. این نشانه‌ی خوبی است:
وقتی به مسئله‌ی پشت درخواست نزدیک می‌شویم، معمولاً ناگهان بیش از یک راه‌حل معقول می‌بینیم.
مشتری میلک‌شیک را برای چه می‌خرد؟
مثال سوم از دنیای کسب‌وکار است و کلیتون کریستنسن آن را بارها نقل کرده است.
یک رستوران زنجیره‌ای فست‌فود می‌خواست فروش میلک‌شیکش را بالا ببرد. درخواست روشن بود:
«فروش میلک‌شیک را بیشتر کنید.»
تیم بازاریابی مستقیم به یک راه‌حل رفت: میلک‌شیک را بهتر کنیم. و «بهتر» را از خود مشتری پرسید. غلیظ‌تر؟ شکلاتی‌تر؟ ارزان‌تر؟ با تکه‌های میوه؟ مشتری‌ها جواب دادند و رستوران همان‌ها را اجرا کرد. فروش تغییری نکرد.
کسی نپرسیده بود مشتری میلک‌شیک را برای چه می‌خرد.
همکار کریستنسن، باب موستا، یک روز کامل در یکی از شعبه‌ها نشست و فقط تماشا کرد. نزدیک به نیمی از میلک‌شیک‌ها پیش از هشت صبح فروخته می‌شد، به آدم‌هایی که تنها بودند، چیز دیگری نمی‌خریدند و با میلک‌شیک سوار ماشین می‌شدند.
صبح روز بعد از همان مشتری‌ها یک سؤال پرسید:
«این میلک‌شیک را برای چه کاری خریدید؟»
جواب‌ها بیشتر درباره‌ی مسیر صبحگاهی بودند تا خود میلک‌شیک. راه طولانی و یک‌نواختی تا سر کار در پیش بود و چیزی می‌خواستند که با یک دست خورده شود، دیر تمام شود و تا ظهر سیر نگهشان دارد.
میلک‌شیک این کار را خوب انجام می‌داد: غلیظ است و با نی باریک بیست دقیقه طول می‌کشد. رقیب‌هایش هم میلک‌شیک رستوران‌های دیگر نبودند. موز بود که زود تمام می‌شود، دونات بود که خرده می‌ریزد، و بیگل بود که دو دست می‌خواهد.
درخواست:
میلک‌شیک بهتری بفروشیم.
مسئله:
محصول در یک کار مشخص به مشتری کمک می‌کند و هیچ‌کس آن کار را نمی‌شناسد.
بعد از ظهر همان میلک‌شیک را پدر و مادرها برای بچه‌هایشان می‌خریدند، و برای این کارِ دوم میلک‌شیکی که بیست دقیقه طول بکشد بد است. یک محصول دو کار متفاوت انجام می‌داد و «بهتر کردن» کلی به هیچ‌کدام کمکی نمی‌کرد.
درخواست‌هایی که به سازندگان یک اپ یا سرویس می‌رسد اغلب همین شکل را دارند: «این فیلتر را اضافه کنید»، «این دکمه را بزرگ‌تر کنید». هر کدام راه‌حلی است که کسی پیش از ما برای مسئله‌ای حدس زده است.
همان سؤال را می‌شود این‌جا به زبان کسب‌وکار پرسید:
کاربر با این محصول چه کاری را می‌خواهد انجام دهد؟
گاهی مسئله مال کس دیگری است
مثال چهارم خانگی‌تر است. دوستی می‌پرسد:
«یک برنامه‌ی یادآوری دارو برای گوشی معرفی کن.»
یک سؤال:
«برای چه کسی؟»
فرض کنیم برای پدر سالخورده‌ی دوستمان است که با گوشی راحت نیست.
یک سؤال دیگر:
«مشکلش فراموش‌کردن ساعت داروست؟»
نه. مشکل این است که چند ساعت بعد یادش نمی‌آید قرص امروز را خورده یا نه.
حالا مسئله عوض شده است. دیگر سؤال این نیست:
چطور سر ساعت به او یادآوری کنیم؟
بلکه:
چطور چند ساعت بعد معلوم باشد داروی امروز خورده شده یا نه؟
و وقتی مسئله عوض می‌شود، راه‌حل هم ممکن است کاملاً عوض شود. شاید به‌جای یک اپ و اعلان تلفن، یک جعبه‌ی هفتگی دارو که خانه‌ی هر نوبت را جدا نگه می‌دارد بهتر باشد: اگر خانه‌ی امروز خالی است، قرص خورده شده؛ اگر هنوز پر است، نشده.
از یک «برنامه‌ی یادآوری» شروع کردیم و به چیزی رسیدیم که اصلاً برنامه نیست.
درخواست متعلق به دوست ما بود، اما مسئله متعلق به شخص دیگری. پس گاهی یک قدم عقب رفتن یعنی پرسیدن:
مسئله‌ی چه کسی است؟
به کدام سمت عقب برویم؟
در این مثال‌ها سه جور عقب رفتیم.
در سه حرف آخر نام فایل و در میلک‌شیک دنبال هدف گشتیم:
این کار را برای چه می‌خواهی؟
در گزارش روزانه دنبال وضعیت نامطلوب گشتیم:
چه چیزی الان دیر یا بد اتفاق می‌افتد؟
در یادآوری دارو دنبال صاحب مسئله گشتیم:
این مسئله برای چه کسی است؟
«مسئله‌ی پشت مسئله» الزاماً یک راز واحد نیست. منظور فقط این است که صورت فعلی درخواست را آخرین کلمه ندانیم.
اگر فقط یک پرسش فرصت داشته باشیم، این یکی اغلب چیز زیادی آشکار می‌کند:
اگر این کار انجام شود، چه چیزی قرار است بهتر شود؟
این پرسش مزیت مهمی دارد. نمی‌گوید «راه‌حلت اشتباه است». فقط می‌پرسد جواب قرار است در کجای یک برنامه‌ی بزرگ‌تر قرار بگیرد.
اگر هنوز ابهام باقی بود، سؤال دوم به وضعیت فعلی برمی‌گردد و سؤال سوم به صاحب مسئله. لازم نیست جلسه‌ی تحلیل مسئله برگزار کنیم. همین سه سؤال کوتاه اغلب کافی‌اند که ببینیم آیا ارزش دارد یک قدم عقب برویم.
دو جهت دیگر هم هست که هر کدام برگه‌ی خودش را دارد: «چرا این اتفاق می‌افتد؟» و «این چیز اصلاً چرا اینجاست؟».
اگر نتوانیم سؤال بپرسیم چه؟
گاهی پرسنده در دسترس نیست. یا جواب باید همین حالا داده شود.
در این حالت لازم نیست درخواست را نادیده بگیریم. می‌توانیم جواب دوطبقه بدهیم:
اگر واقعاً سه نویسه‌ی آخر فایل را می‌خواهید، روشش این است.
اگر منظورتان پسوند فایل است، بهتر است از این روش استفاده کنید.
طبقه‌ی اول به درخواست احترام می‌گذارد. طبقه‌ی دوم فرض ما درباره‌ی مسئله‌ی پشت آن را آشکار می‌کند. اگر فرض غلط بود، پرسنده می‌تواند آن را کنار بگذارد.
کجا متوقف شویم؟
می‌توان تا بی‌نهایت یک حلقه‌ی دیگر عقب رفت.
چرا گزارش دیر رسید؟
چرا این فرایند چنین طراحی شده؟
چرا این سازمان چنین ساختاری دارد؟
چرا آدم‌ها اصلاً سازمان می‌سازند؟
در نقطه‌ای، سؤال دیگر به تصمیم امروز کمکی نمی‌کند. قاعده‌ی مفیدی این است:
تا جایی عقب برو که پاسخ بتواند تصمیم تو را عوض کند.
اگر یک حلقه‌ی عقب‌تر راه‌حل‌های تازه‌ای باز می‌کند، احتمالاً ارزش بررسی دارد. اگر فقط ما را به پرسشی بزرگ‌تر می‌برد که هیچ انتخاب فعلی را تغییر نمی‌دهد، شاید برای این مسئله به‌اندازه‌ی کافی عقب رفته‌ایم.
هدف پیدا کردن «عمیق‌ترین علت جهان» نیست. هدف این است که مسئله را در سطحی ببینیم که بتوانیم انتخاب بهتری کنیم.
یک سؤال بزرگ‌تر: نایتینگل
در پاییز ۱۸۵۴، فلورانس نایتینگل همراه گروهی از پرستاران به بیمارستان نظامی اسکوتاری رفت. درخواست اولیه روشن بود: مراقبت از سربازان زخمی و بیمار را بهتر کنید.
اما داده‌ها به‌تدریج سؤال دیگری را برجسته کردند:
سربازان واقعاً از چه می‌میرند؟
در ژانویه‌ی ۱۸۵۵، ۳۱۶۸ سرباز جان باختند. از میان آن‌ها:
- ۲۷۶۱ نفر از بیماری‌های واگیر
- ۸۳ نفر از زخم‌ها
- ۳۲۴ نفر از علت‌های دیگر
تفاوت خیره‌کننده بود. مسئله فقط «درمان بهتر زخمی‌های جنگ» نبود. بیماری و شرایط بهداشتی بخش بسیار بزرگ‌تری از مرگ‌ها را توضیح می‌دادند.
بعد از جنگ، نایتینگل با کمک آماردانانی چون ویلیام فار داده‌ها را در مقیاس بزرگ‌تری بررسی کرد. و سؤال یک قدم دیگر عقب رفت:
آیا این فقط مسئله‌ی جنگ کریمه است؟
نه. داده‌های پادگان‌های زمان صلح بریتانیا نشان می‌دادند مردان جوانی که به‌عنوان سرباز انتخاب شده بودند تقریباً دو برابر مردان غیرنظامی هم‌سن می‌مردند.
حالا مسئله دوباره عوض شده بود. نه فقط:
چگونه در جنگ بهتر پرستاری کنیم؟
بلکه:
چرا خودِ زندگی نظامی در زمان صلح هم این‌قدر ناسالم است؟
بعد از جنگ، این بررسی به اصلاحات گسترده‌تر در وضعیت بهداشتی ارتش رسید. چیزی که به نایتینگل سپرده شده بود «پرستاری» بود؛ اما مسئله‌ای که داده‌ها آشکار کردند، در مقیاس یک سازمان بود.
عقب رفتن همیشه بهتر نیست
این حرکت هم می‌تواند بد استفاده شود.
وقتی درخواست واقعاً روشن است
اگر کسی بگوید «این فایل را PDF کن»، لازم نیست همیشه بپرسیم:
«اما مسئله‌ی عمیق‌تر زندگی تو چیست؟»
گاهی درخواست همان چیزی است که به نظر می‌رسد.
عقب رفتن باید هزینه‌ای کمتر از اشتباهی داشته باشد که می‌خواهد جلویش را بگیرد.
وقتی «چرا» تبدیل به بازجویی می‌شود
پرسیدن برای فهمیدن با مجبورکردن دیگری به پذیرفتن چارچوب ما فرق دارد. گاهی طرف مقابل اطلاعات یا محدودیت‌هایی دارد که ما نداریم.
هدف سؤال این نیست که ثابت کنیم درخواست او اشتباه بوده است. هدف این است که بفهمیم آیا فضایی برای انتخاب بهتر وجود دارد.
اکنون باید چه چیزی با شما بماند؟
حل‌کردن مسئله مهارت است. اما پیش از آن مهارت دیگری وجود دارد:
فهمیدن این‌که چه چیزی را باید حل کرد.
درخواست را نادیده نگیرید، ولی آن را با مسئله یکی نگیرید. پیش از آن‌که جواب را بهتر کنید، ببینید آیا سؤال را می‌شود بهتر کرد.
گاهی فقط یک سؤال کوچک کافی است تا حلقه‌ی قبلی دیده شود. و اگر از این برگه فقط یک جمله همراهتان می‌ماند، همان سؤال کوچک باشد:
اگر این درخواست انجام شود، چه چیزی قرار است بهتر شود؟
تمرین‌ها
تمرین ۱ — سه سؤال پیش از موافقت. مدیر تیم می‌گوید:
«از این هفته یک جلسه‌ی روزانه‌ی دیگر هم بگذاریم، عصرها.»
پیش از این‌که موافقت یا مخالفت کنید، فقط سه سؤال فرصت دارید. سؤال‌هایتان را بنویسید، بعد جعبه‌ها را یکی‌یکی باز کنید و ببینید جواب‌ها درخواست را به چه مسئله‌ای تبدیل می‌کنند.
اگر پرسیده باشید «چه چیزی قرار است بهتر شود؟»
«این هفته دو نفر سه روز روی یک کار گیر کرده بودند و تا جلسه‌ی صبح پنجشنبه کسی نفهمید.»
اگر پرسیده باشید «الان دقیقاً چه چیزی درست کار نمی‌کند؟»
«جلسه‌ی صبح برای برنامه‌ریزی است و کسی در آن از گیر افتادن حرف نمی‌زند. وقتی هم کسی گیر می‌کند، فکر می‌کند تا فردا صبح خودش حلش می‌کند.»
درخواست و مسئله
درخواست: یک جلسه‌ی دیگر.
مسئله: گیر افتادن دیر دیده می‌شود و آدم‌ها دلیلی برای زود گفتنش ندارند.
حالا بیش از یک راه‌حل معقول دیده می‌شود: یک ستون «گیر کرده‌ام» روی تابلوی تیم، یک پیام کوتاه در همان لحظه‌ی گیر افتادن، یا این‌که جلسه‌ی صبح یک سؤال ثابت پیدا کند. جلسه‌ی عصر هم یکی از گزینه‌هاست، اما دیگر تنها گزینه نیست.
سؤال سوم، «مسئله برای چه کسی است؟»، را خودتان جواب بدهید: برای مدیر، برای دو نفری که گیر کرده بودند، یا برای کسی که منتظر کار آن‌ها بود؟
تمرین ۲ — درخواست‌هایی که دریافت کرده‌اید. سه درخواست واقعی را که این هفته دریافت کرده‌اید بنویسید. برای هرکدام:
- درخواست چیست؟
- مسئله‌ی احتمالی پشت آن چیست؟
- با چه یک سؤال می‌توانید فرض خود را بیازمایید؟
دست‌کم یکی از سؤال‌ها را واقعاً بپرسید و بنویسید جواب چه چیزی را تغییر داد.
تمرین ۳ — درخواستی که خودتان داده‌اید. یکی از درخواست‌های اخیر خودتان را پیدا کنید. نسخه‌ی اول را همان‌طور که واقعاً گفته بودید بنویسید. سپس نسخه‌ی دیگری بسازید که این چهار چیز را هم با خود حمل کند:
- چه چیزی می‌خواهید
- چرا می‌خواهید
- چه محدودیتی دارید
- با جواب چه خواهید کرد
برای کسی که قرار است کمک کند، کدام نسخه فضای بیشتری برای پیدا کردن یک جواب خوب ایجاد می‌کند؟
دفترچه‌ی مسئله
در این مجموعه یک دفترچه کنار دستتان نگه دارید: برای هر مسئله چند خط، که برگه‌های بعدی به آن برمی‌گردند و خط‌های تازه‌ای به آن اضافه می‌کنند.
اولین خطش از همین برگه:
صورت مسئله‌ای که به من رسید چه بود؟
و بعد:
یک قدم عقب‌تر چه دیدم؟
گاهی همین دو جمله تمام تفاوت میان حل سریع یک مسئله و حل مسئله‌ی درست است.
منابع
- Donald C. Gause & Gerald M. Weinberg, Are Your Lights On? How to Figure Out What the Problem Really Is.
- Clayton M. Christensen, Taddy Hall, Karen Dillon & David S. Duncan, Competing Against Luck.
- Florence Nightingale, Notes on Matters Affecting the Health, Efficiency, and Hospital Administration of the British Army.