از کجا بفهمیم مسئله حل شده؟
پیش از راه‌حل، پایان مسئله را ببین
تیم پشتیبانی یک فروشگاه اینترنتی مشکل دارد. هر روز صدها نفر تماس می‌گیرند و هزینه‌ی پاسخ‌گویی بالا رفته است. مدیر می‌گوید:
«باید تعداد تماس‌های پشتیبانی را ۳۰٪ کم کنیم.»
هدف روشن به نظر می‌رسد. عدد دارد و می‌شود هفته‌به‌هفته اندازه‌اش گرفت.
تیم تغییری ساده می‌دهد: شماره‌ی تماس را از بالای صفحه‌ی «راهنما» برمی‌دارد و پایین چند صفحه‌ی دیگر می‌گذارد. ماه بعد تماس‌ها ۳۵٪ کم شده‌اند. تیم از هدف هم جلوتر رفته است.
آیا مسئله حل شده؟
عدد بهتر شد. مسئله چطور؟
تماس‌ها کمتر شده‌اند. اما شاید کاربران هنوز همان‌قدر گیر می‌کنند و فقط پیدا کردن راه کمک سخت‌تر شده است.
حتی ممکن است اوضاع بدتر شده باشد. کسی که پیش‌تر بعد از پنج دقیقه تماس می‌گرفت و کارش راه می‌افتاد، حالا بیست دقیقه در سایت می‌گردد، عصبانی می‌شود و خریدش را نیمه‌کاره رها می‌کند.
اگر مسئله را این‌طور تعریف کرده باشیم، راه‌حل موفق بوده است:
تماس‌های پشتیبانی زیاد است.
اما اگر یک قدم عقب‌تر برویم، کم‌شدن تماس به‌تنهایی چیزی را ثابت نمی‌کند:
کاربران هنگام انجام بعضی کارها گیر می‌کنند و برای ادامه به کمک یک انسان نیاز دارند.
این همان حرکت برگه‌ی «مسئله‌ی پشت مسئله» است. آن‌جا پرسیدیم «چه چیزی قرار است بهتر شود؟». این برگه یک سؤال به آن اضافه می‌کند:
اگر واقعاً بهتر شد، از کجا می‌فهمیم؟
پایان مسئله را پیش از راه‌حل بنویس
فرض کنیم هنوز هیچ راه‌حلی انتخاب نکرده‌ایم. به‌جای «تماس‌ها باید ۳۰٪ کم شوند» می‌توانیم وضعیت مطلوب را بنویسیم:
کاربری که با یک مشکل معمول روبه‌رو می‌شود بتواند بدون گیرکردن کارش را کامل کند، و اگر نتوانست، زود به کمک برسد.
این جمله راه‌حل نمی‌دهد. نمی‌گوید صفحه‌ی پرسش‌های پرتکرار بسازیم، چت‌بات اضافه کنیم، یا شماره‌ی تلفن را بزرگ‌تر یا کوچک‌تر کنیم. فقط می‌گوید اگر مسئله حل شود، چه چیزی برای کاربر فرق خواهد کرد.
همین تفاوت راه‌حل‌های بیشتری را ممکن می‌کند. شاید بیشتر تماس‌ها درباره‌ی یک مرحله‌ی گیج‌کننده‌ی پرداخت باشند. در آن صورت باید خود محصول را درست کرد، نه پشتیبانی را.
پس پیش از انتخاب راه‌حل، این جمله را کامل کنید:
اگر این مسئله حل شود، …
جای خالی را با کاری که قرار است انجام دهیم پر نکنید. با چیزی پر کنید که بعد از انجام آن کار فرق کرده است.
بسیاری از هدف‌ها با کلمه‌ای شروع می‌شوند که نمی‌شود آن را دید: «تجربه‌ی ثبت‌نام بهتر شود»، «تیم کارآمدتر شود»، «دانش‌آموزان بهتر بفهمند». برای این‌ها لازم نیست فوراً دنبال یک عدد بگردیم. سؤال اول این است:
اگر این واقعاً بهتر شود، چه چیزهایی می‌بینم که امروز نمی‌بینم؟
مثلاً «دانش‌آموز ضرب کسرها را بهتر بفهمد» شاید یعنی:
- مسئله‌ای تازه را بدون تقلید از مثال حل می‌کند
- توضیح می‌دهد چرا روش کار می‌کند
- خطای خودش را پیدا می‌کند
این فهرست هنوز ممکن است ناقص باشد. اما «بهتر» را به چیزهایی تبدیل کرده که می‌شود دید.
«ساختیم» با «حل شد» فرق دارد
فرض کنید تیم پشتیبانی تصمیم می‌گیرد یک مرکز راهنمای تازه بسازد. سه ماه کار می‌کند. پنجاه مقاله نوشته می‌شود، جست‌وجو اضافه می‌شود و صفحه‌ی تازه منتشر می‌شود. پروژه تمام شده است.
اما آیا مسئله حل شده؟
مقاله‌ها، جست‌وجو و صفحه‌ی تازه چیزهایی هستند که ساخته‌ایم. می‌شود همه‌ی آن‌ها را ساخت و هیچ چیز مهمی برای کاربر بهتر نشود. برای این دو چیز دو نام جدا داریم.
خروجی چیزی است که می‌سازیم:
راهنمای تازه منتشر شد.
پیامد تغییری است که به‌خاطرش آن را ساختیم:
کاربران بیشتری توانستند بدون گیرکردن کارشان را کامل کنند.
خروجی در کنترل ماست. می‌توانیم تصمیم بگیریم تا جمعه ده مقاله منتشر کنیم. پیامد در کنترل ما نیست. شاید مقاله‌ها بد باشند، شاید کاربر آن‌ها را پیدا نکند، یا شاید درباره‌ی مشکلی نوشته باشیم که مشکل اصلی نبوده است.
تمام‌شدن راه‌حل، همان حل‌شدن مسئله نیست.
گاهی خروجی در خود تعریف موفقیت پنهان می‌شود:
موفقیت یعنی ۸۰٪ کاربران مقاله‌ی راهنما را بخوانند.
اگر محصول آن‌قدر روشن شود که کسی به راهنما نیاز پیدا نکند، این عدد صفر می‌شود. باید خوشحال باشیم یا ناراحت؟
این تعریف راه‌حل را از پیش انتخاب کرده است. همان مسئله‌ی XY برگه‌ی یکم است، این بار در معیار. تعریف زیر مقاله را فقط یکی از راه‌های ممکن می‌داند:
۸۰٪ کاربران بتوانند بدون کمک انسانی کارشان را کامل کنند.
از کجا می‌فهمیم؟
پیامد را معمولاً نمی‌شود مستقیم دید. کسی کنار تک‌تک کاربران ننشسته است. پس چیزی را اندازه می‌گیریم که می‌شود شمرد، مثلاً درصد کاربرانی که بدون تماس کارشان را کامل می‌کنند.
عددها مفیدند. بدون اندازه‌گیری، چیزی را که دوست داریم ببینیم به‌آسانی با چیزی که واقعاً رخ داده اشتباه می‌گیریم.
اما معیار با چیزی که می‌خواهیم بهتر شود یکی نیست. دمای بدن نشانه‌ای از وضعیت بدن است و خود سلامتی نیست. نمره‌ی امتحان چیزی درباره‌ی یادگیری می‌گوید و خود یادگیری نیست. تعداد تماس‌های پشتیبانی هم چیزی درباره‌ی گیرکردن کاربران می‌گوید و خود آن نیست.
معیار پنجره است. از پشت آن چیزی را می‌بینیم که مشاهده‌ی مستقیمش سخت است. مشکل وقتی شروع می‌شود که پنجره را با منظره یکی بگیریم.
بازی «عدد را دور بزن»
برای هر معیاری که انتخاب کرده‌اید یک بازی کوچک انجام دهید. فرض کنید پاداش من فقط به عدد شما بستگی دارد و هیچ اهمیتی نمی‌دهم مسئله‌ی واقعی بهتر شود یا نه. چه کار می‌توانم بکنم؟
برای تماس‌های پشتیبانی جواب را دیده‌ایم: شماره را پنهان کن.
پیش از ادامه، خودتان بازی کنید. برای هر کدام یک راه پیدا کنید: زمان انتظار بیمار در اورژانس، زمان اولین پاسخ پشتیبانی، تعداد باگ‌های باز، میانگین نمره‌ی کلاس.
چند راه ممکن:
| معیار | راه دورزدن |
|---|---|
| زمان انتظار بیمار | بیمار را از صف انتظار به صفی با نام دیگر منتقل کن |
| زمان اولین پاسخ | فوراً یک پیام «در حال بررسی هستیم» بفرست |
| تعداد باگ‌های باز | گزارش‌ها را زودتر ببند، یا ثبت باگ را سخت‌تر کن |
| میانگین نمره | آزمون را آسان‌تر کن، یا فقط سؤال‌های امتحان را تمرین بده |
در همه‌ی این‌ها عدد بهتر می‌شود و چیزی که برایمان مهم بود شاید هیچ تغییری نکند.
پس بعد از انتخاب هر معیار این سؤال را بپرسید:
چطور می‌شود این عدد را بهتر کرد، بدون اینکه مسئله بهتر شود؟
این سؤال بدبینی به آدم‌ها نیست. آزمون معیار است. اگر در ده ثانیه راهی پیدا شود، فهمیده‌ایم که این معیار به‌تنهایی کافی نیست.
این بازی فقط فرضی هم نیست. در دهه‌ی ۲۰۰۰ در انگلستان هدف گذاشته شد که بیمار اورژانس بیش از چهار ساعت منتظر نماند. بوان و هود گزارش کرده‌اند که بعضی بیمارستان‌ها بیماران را در صف آمبولانس‌ها بیرون اورژانس نگه می‌داشتند تا مطمئن شوند می‌توانند ظرف چهار ساعت به آن‌ها برسند. عدد بهتر شده بود، اما انتظار بیمار کوتاه‌تر نشده بود.
این پدیده امروز با نام قانون گودهارت شناخته می‌شود. چارلز گودهارت در سال ۱۹۷۵ درباره‌ی سیاست پولی نوشت که هر نظم آماری، وقتی برای کنترل زیر فشار قرار بگیرد، معمولاً فرو می‌ریزد. صورت مشهورتر آن از مریلین استراترن است:
وقتی معیاری هدف می‌شود، دیگر معیار خوبی نیست.
دونالد کمپبل هم در همان سال‌ها درباره‌ی ارزیابی برنامه‌های اجتماعی چیزی مشابه نوشت: هرچه یک شاخص کمّی در تصمیم‌گیری مهم‌تر شود، فشار برای دست‌کاری آن بیشتر می‌شود و همان فرایندی را که قرار بود نشان دهد منحرف می‌کند.
پس عدد را کنار بگذاریم؟
نه. اگر هیچ چیز را اندازه نگیریم، مشکل دیگری داریم: هر نتیجه‌ای را می‌شود موفقیت نامید.
راه بهتر این است که سه چیز را جدا از هم بنویسیم: مسئله، وضعیت مطلوب، و نشانه‌هایی که می‌گویند به آن وضعیت نزدیک شده‌ایم.
مثلاً مسئله:
کاربران هنگام بازپرداخت گیر می‌کنند.
وضعیت مطلوب:
کاربری که حق بازپرداخت دارد بتواند آن را بدون سردرگمی و در زمان معقول کامل کند.
چند نشانه:
- چند درصد فرایند را کامل می‌کنند
- چند نفر وسط کار رها می‌کنند
- چقدر طول می‌کشد
- چند نفر برای همین کار با پشتیبانی تماس می‌گیرند
هیچ‌کدام از این‌ها خود مسئله نیست. هر کدام پنجره‌ای است از یک زاویه. با یک عدد تنها، وسوسه‌ی بهترکردن همان عدد زیاد است. با سه یا چهار نشانه، راهی که یکی را دور بزند معمولاً در دیگری دیده می‌شود. پنهان‌کردن شماره‌ی تلفن تماس‌ها را کم می‌کند، اما اگر کاربران هنوز گیر می‌کنند، رهاکردن وسط کار بیشتر می‌شود.
چه چیزی نباید خراب شود؟
بعضی راه‌حل‌ها مسئله را حل نمی‌کنند و فقط آن را جابه‌جا می‌کنند.
زمان بازپرداخت را کم کردیم.
اما برای این کار مراحل بررسی را برداشتیم و بازپرداخت اشتباه و تقلب بیشتر شد.
زمان پاسخ‌گویی پشتیبانی را کم کردیم.
اما کیفیت جواب‌ها پایین آمد و کاربر مجبور شد سه بار برگردد.
پس تعریف موفقیت نیمه‌ی دومی هم دارد. نیمه‌ی اول می‌پرسد چه چیزی باید بهتر شود. نیمه‌ی دوم می‌پرسد:
چه چیزی نباید در راه بهترشدنش خراب شود؟
اسم این‌ها را شرط‌های محافظ می‌گذاریم. با دو کلمه نوشته می‌شوند:
بازپرداخت سریع‌تر شود،
بدون اینکه بازپرداخت اشتباه بیشتر شود.
تماس پشتیبانی کمتر شود،
بدون اینکه کاربران بیشتری کارشان را نیمه‌کاره رها کنند.
حالا هر تغییر باید از دو آزمون بگذرد. به همین دلیل سؤال «عدد بالا رفت یا پایین؟» از سؤال «مسئله بهتر شد؟» کوچک‌تر است.
یک شرط محافظ را آسان فراموش می‌کنیم: برای چه کسی بدتر شد؟
فرض کنید تغییری میانگین زمان دریافت پاسخ را از ۱۰ دقیقه به ۶ دقیقه رسانده است. بعد می‌بینیم سؤال‌های ساده حالا در یک دقیقه جواب می‌گیرند، اما سؤال‌های پیچیده به‌جای ۲۰ دقیقه ۴۰ دقیقه معطل می‌مانند. میانگین بهتر شده و کسانی که بیشترین کمک را لازم داشتند وضع بدتری پیدا کرده‌اند.
خط پایان را پیش از دیدن نتیجه بکش
در مسائل واقعی لحظه‌ای نیست که چراغی سبز شود و بگوید «تمام شد». بعضی مسئله‌ها فقط کمتر می‌شوند. بعضی همیشه مراقبت می‌خواهند. بعضی را تا جایی حل می‌کنیم که ادامه‌دادن دیگر به هزینه‌اش نمی‌ارزد.
برای همین، خط پایان را باید خودمان بکشیم. و مهم است که چه وقت آن را می‌کشیم.
فرض کنید تغییری منتشر کرده‌اید و بعد از یک ماه این داده‌ها می‌رسند:
- زمان انجام کار ۱۵٪ کمتر شده
- نرخ تکمیل تغییری نکرده
- تماس پشتیبانی ۸٪ بیشتر شده
- رضایت کاربران تقریباً ثابت است
تغییر موفق بوده؟
اگر از قبل چیزی ننوشته باشیم، هرکس عدد محبوب خودش را برمی‌دارد. یکی می‌گوید «۱۵٪ سریع‌تر شد، موفق بود». دیگری می‌گوید «تکمیل بالا نرفت، شکست خورد». سومی می‌گوید «تماس بیشتر شده، بدتر شد».
اما اگر پیش از تغییر نوشته باشیم:
هدف اصلی افزایش تکمیل است. زمان انجام نشانه‌ی دوم است و تماس پشتیبانی نباید بیشتر شود.
جواب روشن است: این دور موفق نبوده است.
خط پایان می‌تواند عدد هم داشته باشد:
اگر نرخ رهاکردن این مرحله از ۱۸٪ به کمتر از ۸٪ برسد، تماس‌های مرتبط بیشتر نشود و نرخ خطا ثابت بماند، این دور از کار را موفق می‌دانیم.
این جمله قطعی نیست و ممکن است با آموختن چیزهای تازه عوضش کنیم. اما یک فایده دارد: بعد از دیدن نتیجه، خط پایان را هر جا که دلمان خواست نمی‌کشیم.
همان موقع وضع موجود را هم ثبت کنید. اگر ندانیم پیش از تغییر چه خبر بوده، بعداً تقریباً هر عددی را می‌شود موفقیت نامید. مقایسه‌ی قبل و بعد هم همه‌چیز را ثابت نمی‌کند. شاید تماس‌ها کم شده‌اند چون فصل شلوغی تمام شده است. اما نداشتن نقطه‌ی شروع تقریباً همیشه بدتر است.
پیش از دیدن جواب، بنویس چه جوابی را موفقیت خواهی دانست.
برگردیم به تماس‌های پشتیبانی
حالا می‌توانیم مسئله‌ی اول را دوباره بنویسیم. به‌جای «تماس‌های پشتیبانی را ۳۰٪ کم کنیم»:
وضعیت مطلوب
کاربران بتوانند مشکل‌های معمولشان را بدون گیرکردن حل کنند، و وقتی واقعاً به کمک نیاز دارند، رسیدن به کمک سخت‌تر نشود.
نشانه‌ها
- نرخ کامل‌کردن کار بدون کمک
- تماس‌های مربوط به مشکل‌های معمول
- نرخ رهاکردن
- زمانی که کاربر تا حل مشکل صرف می‌کند
شرط‌های محافظ
- دسترسی به پشتیبانی سخت‌تر نشود
- حل مشکل‌های پیچیده کندتر نشود
- رضایت کاربران پایین نیاید
حالا اگر کسی پیشنهاد دهد «شماره‌ی تلفن را پنهان کنیم»، زود می‌بینیم که این تغییر یک نشانه را بهتر می‌کند و اولین شرط محافظ را می‌شکند.
و اگر پیشنهادی بیاید که یک مرحله‌ی گیج‌کننده‌ی محصول را حذف می‌کند، شاید تماس‌ها هم کم شوند. این بار کم‌شدن تماس نشانه‌ی حل مسئله است، نه خود هدف.
اکنون باید چه چیزی با شما بماند؟
پیش از حل مسئله دانستن اینکه چه چیزی بد است کافی نیست. باید بتوانیم بگوییم اگر مسئله حل شود چه چیزی فرق می‌کند. بعد برای دیدن آن تغییر نشانه‌هایی انتخاب می‌کنیم، و نشانه را با هدف یکی نمی‌گیریم.
راه‌حل وقتی تمام نشده که آن را ساخته‌ایم. وقتی هم تمام نشده که عددی سبز شده است. وقتی تمام شده که دلیلی داشته باشیم باور کنیم چیزی که از اول مهم بود بهتر شده است.
اگر از این برگه فقط یک جمله همراهتان می‌ماند، این سؤال باشد:
اگر این مسئله واقعاً حل شود، چه چیزی فرق می‌کند و از کجا می‌فهمم؟
تمرین‌ها
تمرین ۱ — مسئله حل شد؟
یک مدرسه می‌خواهد غیبت دانش‌آموزان را کم کند. مدیر اعلام می‌کند:
«هدف ترم بعد ۲۰٪ کاهش غیبت ثبت‌شده است.»
در پایان ترم غیبت ثبت‌شده ۲۵٪ کم شده است.
سه توضیح متفاوت پیدا کنید که در آن‌ها این عدد بهتر شده، اما مسئله‌ی واقعی لزوماً بهتر نشده باشد.
چند امکان
شاید:
- ثبت غیبت سخت‌تر شده باشد
- بعضی غیبت‌ها با عنوان دیگری ثبت شوند
- دانش‌آموز بیمار به مدرسه آمده باشد فقط برای اینکه غیبت نخورد
- دانش‌آموز سر کلاس باشد اما در عمل مشارکت نکند
حالا مسئله را بدون استفاده از عبارت «غیبت کمتر» دوباره تعریف کنید.
تمرین ۲ — خروجی یا پیامد؟
برای هر مورد مشخص کنید خروجی است یا پیامد:
۲۰ مقاله‌ی راهنما منتشر شد.
دوره‌ی آموزشی برای همه‌ی کارکنان برگزار شد.
کاربران کمتری در مرحله‌ی پرداخت گیر کردند.
قابلیت تازه منتشر شد.
خطاهای مربوط به کار آموزش‌داده‌شده کمتر شدند.
بعد برای یکی از خروجی‌ها دو پیامد متفاوت بنویسید: یکی مطلوب و یکی نامطلوب. مثلاً یک قابلیت تازه ممکن است کار با محصول را آسان‌تر کند، یا فقط آن را پیچیده‌تر کند.
تمرین ۳ — عدد را دور بزنید
یکی از این هدف‌ها را انتخاب کنید:
تعداد مشتریان فعال بیشتر شود.
جلسه‌ها کوتاه‌تر شوند.
درصد سفارش‌هایی که به‌موقع می‌رسند بالا برود.
هر دانش‌آموز در سال کتاب‌های بیشتری بخواند.
نقش کسی را بازی کنید که پاداشش فقط به همان عدد بستگی دارد. سه راه پیدا کنید که عدد بهتر شود و مسئله بهتر نشود.
بعد برای هر راه بپرسید:
چه نشانه‌ی دوم یا شرط محافظی این راه را آشکار می‌کرد؟
تمرین ۴ — «بدون اینکه…»
نیمه‌ی دوم هر جمله را بنویسید:
زمان تحویل کمتر شود، بدون اینکه…
ثبت‌نام ساده‌تر شود، بدون اینکه…
تعداد جلسه‌ها نصف شود، بدون اینکه…
نرم‌افزار زودبه‌زود منتشر شود، بدون اینکه…
تمرین ۵ — پایان یک مسئله‌ی واقعی
مسئله‌ای واقعی را که همین حالا روی آن کار می‌کنید انتخاب کنید. پیش از فکرکردن به راه‌حل، شش خط دفترچه‌ی همین برگه را برایش پر کنید.
بعد به راه‌حلی که در ذهن دارید نگاه کنید. آیا وضعیت مطلوبی را که نوشته‌اید نزدیک‌تر می‌کند؟ یا فقط چیزی است که می‌توانیم بسازیم؟
دفترچه‌ی مسئله
برای این برگه شش خط به دفترچه اضافه کنید:
مسئله: چه چیزی اکنون نامطلوب است؟
وضعیت مطلوب: اگر مسئله واقعاً حل شود، برای چه کسی چه چیزی فرق می‌کند؟
نشانه‌ها: از کجا می‌فهمم آن تغییر رخ داده؟
شرط‌های محافظ: چه چیزی نباید در راه بهترشدن خراب شود؟
راه دورزدن: چطور می‌شود نشانه‌ها بهتر شوند و مسئله بهتر نشود؟
خط پایان: چه نتیجه‌ای برای این دور کافی است؟
اگر جواب این‌ها را نمی‌دانیم، شاید هنوز برای انتخاب راه‌حل زود باشد.
منابع
- Charles A. E. Goodhart, “Problems of Monetary Management: The U.K. Experience”, Papers in Monetary Economics, Vol. I, Reserve Bank of Australia, 1975.
- Marilyn Strathern, “‘Improving Ratings’: Audit in the British University System”, European Review 5(3), 1997, pp. 305–321.
- Donald T. Campbell, “Assessing the Impact of Planned Social Change”, Evaluation and Program Planning 2(1), 1979, pp. 67–90.
- Gwyn Bevan & Christopher Hood, “What’s Measured Is What Matters: Targets and Gaming in the English Public Health Care System”, Public Administration 84(3), 2006, pp. 517–538.