# خواسته‌های کیفی مشتری؛ چطور «سریع، خوب و قشنگ» را قابل‌سنجش کنیم؟ [منبع]() مدرس: سجاد ده شیری مشتری خیلی وقت‌ها دقیقاً می‌داند چه حسی از نتیجه می‌خواهد، اما نمی‌تواند آن را با یک معیار مشخص بیان کند\. می‌گوید: **«سایت سریع باشه\.»** **«ظاهرش قشنگ باشه\.»** **«کار حرفه‌ای دربیاد\.»** **«زود تحویلش بده\.»** مشکل این هست که این کلمات برای دو نفر الزاماً یک معنی ندارند\. «سریع» برای تو ممکن هست سه ثانیه باشد و برای مشتری یک ثانیه\. «زود» برای تو سه هفته باشد و برای او ده روز\. هدف این جلسه این هست که خواسته‌های مبهم مشتری را تا جای ممکن به **معیارهایی روشن و قابل‌ارزیابی** تبدیل کنیم؛ بدون اینکه برای هر چیزی عدد مصنوعی بسازیم\. ## اول معنی کلمه را روشن کن وقتی مشتری می‌گوید «سایت سریع باشه»، قبل از تعیین عدد باید بفهمی منظورش دقیقاً چیست\. ممکن هست صفحه اصلی دیر باز شود، فرایند خرید کند باشد، پنل مدیریت معطل کند یا کارمند فروش بعد از ثبت سفارش چند ثانیه منتظر بماند\. پس اولین سؤال این نیست که: **«چه عددی برای سرعت تعیین کنیم؟»** اول باید بفهمیم: **«مشتری دقیقاً درباره کدام تجربه حرف می‌زند؟»** بعد می‌توان برای همان تجربه معیار مناسب تعریف کرد\. ## «سریع» را به چیزی قابل‌اندازه‌گیری تبدیل کن سرعت نمونه خوبی از ویژگی‌هایی هست که معمولاً می‌شود آن را اندازه گرفت\. به‌جای: **«سایت باید سریع باشد\.»** می‌توان مشخص کرد: کدام صفحه؟ در چه شرایطی؟ با چه معیاری؟ و چه عددی نتیجه قابل‌قبول محسوب می‌شود؟ مثلاً به‌جای یک وعده کلی می‌توان گفت: **«نمایش محتوای اصلی صفحه محصول در شرایط مشخص باید در محدوده قابل‌قبول Core Web Vitals باشد\.»** در وب، معیارهایی مثل LCP تعریف مشخص دارند\. اما نکته مهم‌تر از خود عدد این هست که **روش سنجش و شرایط اندازه‌گیری هم روشن باشد\.** عدد بدون زمینه هنوز می‌تواند مبهم باشد\. ## عدد را از خودت اختراع نکن قابل‌سنجش‌کردن خواسته به این معنی نیست که برای هر موضوع یک عدد دلخواه انتخاب کنیم\. عدد باید به یکی از این‌ها تکیه کند: **نیاز واقعی مشتری، وضعیت فعلی، محدودیت پروژه، استاندارد معتبر یا توافق روشن دو طرف\.** اگر مشتری گفته «سایت سریع باشد»، اینکه خودمان تصمیم بگیریم «پس باید یک‌ثانیه‌ای باشد» الزاماً درست نیست\. ممکن هست نیاز واقعی او چیز دیگری باشد\. **عدد وقتی ارزش دارد که چیزی معنی‌دار را اندازه بگیرد\.** ## «زود تحویل بده» را دقیق کن زمان تحویل معمولاً ساده‌تر قابل‌تعریف هست\. به‌جای: **«خیلی سریع تحویل می‌دهم\.»** می‌توان گفت: **«نسخه اولیه تا هفت روز دیگر آماده بررسی هست و نسخه نهایی بعد از تأیید مرحله اول تحویل می‌شود\.»** حالا هر دو طرف می‌دانند چه چیزی و چه زمانی باید اتفاق بیفتد\. این فقط برای مدیریت پروژه نیست؛ برای **مدیریت انتظار مشتری** هم اهمیت دارد\. ## اما «قشنگ» را نمی‌شود مثل زمان اندازه گرفت همه خواسته‌های کیفی از یک جنس نیستند\. اگر مشتری بگوید: **«سایت قشنگ باشه\.»** نمی‌توانیم به‌سادگی بگوییم: **«زیبایی باید ۸ از ۱۰ باشد\.»** چنین عددی بدون روش معتبر اندازه‌گیری فقط ابهام قبلی را به شکل دیگری تکرار می‌کند\. برای این نوع خواسته‌ها بهتر هست به‌جای عددسازی، آن‌ها را **قابل‌مشاهده و قابل‌توافق** کنیم\. مثلاً: مشتری چه سایت‌هایی را زیبا می‌داند؟ چه سبک‌هایی را دوست ندارد؟ ظاهر رسمی می‌خواهد یا صمیمی؟ نمونه مرجع او چیست؟ چه کسی نسخه نهایی را تأیید می‌کند؟ اینجا هنوز «زیبایی» را اندازه نگرفته‌ایم، اما برداشت دو طرف به هم نزدیک‌تر شده\. ## قابل‌سنجش همیشه به معنی عددی نیست یک معیار ممکن هست **کمی** باشد: زمان بارگذاری، تاریخ تحویل، تعداد مراحل، یا زمان انجام یک کار\. و ممکن هست **قابل‌بررسی ولی غیرعددی** باشد: طرح نهایی با نمونه‌های مرجع مورد توافق هم‌راستا باشد، کاربر بتواند بدون آموزش مسیر مشخصی را پیدا کند، یا نسخه نهایی توسط فرد تصمیم‌گیرنده تأیید شود\. هدف این نیست که همه چیز را عددی کنیم\. هدف این هست که در پایان پروژه بتوانیم بپرسیم: **«آیا چیزی که درباره‌اش توافق کرده بودیم اتفاق افتاد یا نه؟»** ## وضعیت قبل و بعد را ثبت کن اگر می‌خواهی بهبود را نشان بدهی، فقط عدد نهایی کافی نیست\. باید نقطه شروع را هم بدانیم\. مثلاً: **۴٫۲ ثانیه → ۱٫۹ ثانیه** **۳۰ روز → ۱۴ روز** **۱۲ مرحله دستی → ۴ مرحله** **۲ ساعت کار روزانه → ۲۰ دقیقه** حالا مشتری فقط یک صفت نمی‌شنود؛ **تغییر واقعی را می‌بیند\.** این یکی از بهترین راه‌ها برای ملموس‌کردن ارزشی هست که ایجاد کرده‌ای\. ## عدد باید نتیجه مشتری را نشان بدهد همه اعداد ارزش یکسانی ندارند\. مثلاً: **«۳۵ فایل را تغییر دادم\.»** یا: **«۴۰۰۰ خط کد نوشتم\.»** ممکن هست حجم کار تو را نشان دهند، اما الزاماً چیزی درباره ارزش برای مشتری نمی‌گویند\. در مقابل: **«زمان آماده‌کردن گزارش هفتگی از یک ساعت به ده دقیقه رسید\.»** مستقیماً به نتیجه‌ای وصل هست که مشتری تجربه می‌کند\. عدد زمانی قدرتمندتر می‌شود که **اثر کار را نشان بدهد، نه فقط فعالیت تو را\.** ## «خوب» و «حرفه‌ای» را باز کن وقتی مشتری می‌گوید: **«کار حرفه‌ای می‌خوام\.»** هنوز Requirement مشخصی نداریم\. باید بفهمیم «حرفه‌ای» برای او چه معنی دارد\. ممکن هست منظورش این باشد که: ظاهر برند منسجم باشد، روی موبایل درست کار کند، خطاهای واضح وجود نداشته باشد، فرایند خرید ساده باشد، یا سایت از نظر بصری با کسب‌وکارهای معتبر حوزه خودش هم‌سطح دیده شود\. هرچه این کلمه را بیشتر باز کنی، فاصله بین انتظار مشتری و چیزی که تحویل می‌دهی کمتر می‌شود\. ## اول سؤال بپرس، بعد معیار بساز یکی از خطاها این هست که مشتری یک جمله مبهم بگوید و ما فوراً آن را به Requirement تبدیل کنیم\. ترتیب بهتر این هست: **ابتدا معنی را کشف کن، بعد معیار را تعریف کن\.** مثلاً اگر مشتری می‌گوید «سریع باشه»، اول بفهم منظورش کدام بخش تجربه هست\. بعد سراغ عدد یا معیار مناسب برو\. در ویدیوی این جلسه دقیقاً روی همین تبدیل کار می‌کنیم و می‌بینی چطور از یک جمله ساده مشتری به معیاری برسیم که هر دو طرف بتوانند درباره آن توافق کنند\. ## معیار خوب سه بخش دارد برای مواردی که واقعاً قابل‌اندازه‌گیری هستند، یک معیار خوب معمولاً سه بخش دارد: **معیار \+ هدف \+ شرایط سنجش** مثلاً فقط نگوییم: **«زمان پاسخ زیر دو ثانیه باشد\.»** بلکه روشن کنیم: دو ثانیه برای چه چیزی؟ در چه شرایطی؟ با چه ابزار یا روش سنجشی؟ این موضوع مخصوصاً در پروژه‌های فنی مهم هست، چون یک عدد تحت شرایط مختلف می‌تواند نتایج متفاوتی بدهد\. ## چرا این کار اختلاف آخر پروژه را کمتر می‌کند؟ اگر ابتدای پروژه فقط توافق کرده باشید: **«سایت قشنگ و سریع باشد\.»** ممکن هست در پایان، تو فکر کنی دقیقاً همان را تحویل داده‌ای و مشتری بگوید: **«نه، اون چیزی نبود که انتظار داشتم\.»** اینجا مشکل فقط کیفیت اجرا نیست؛ **تعریف موفقیت از ابتدا روشن نبوده\.** هرچه خواسته‌های مهم زودتر قابل‌ارزیابی شوند، احتمال اختلاف بر سر برداشت‌های شخصی کمتر می‌شود\. این یکی از کاربردهای مهم معیارهای روشن در تجربه مشتری هست: **انتظار را قبل از تحویل مدیریت می‌کنند، نه بعد از اختلاف\.** ## این موضوع چه ربطی به ارزش پیشنهادی دارد؟ در جلسات قبل گفتیم مشتری Feature نمی‌خرد؛ نتیجه‌ای را می‌خواهد که آن Feature برایش ایجاد می‌کند\. این جلسه یک مرحله جلوتر می‌رود\. وقتی می‌گویی: **«این کار باعث صرفه‌جویی در زمان می‌شود\.»** هنوز یک Gain را توضیح داده‌ای\. اما اگر بتوانی نشان بدهی: **«این فرایند قبلاً روزی ۶۰ دقیقه زمان می‌گرفت و حالا حدود ۱۵ دقیقه زمان می‌گیرد\.»** منفعت بسیار ملموس‌تر می‌شود\. پس قابل‌سنجش‌کردن فقط ابزار مدیریت پروژه نیست؛ می‌تواند **ارزش پیشنهادی را قابل‌فهم‌تر و قابل‌اثبات‌تر** کند\. ## در این جلسه چه چیزی یاد می‌گیری؟ در این جلسه یاد می‌گیری وقتی مشتری از کلماتی مثل **«سریع»، «خوب»، «قشنگ»، «حرفه‌ای» یا «زود»** استفاده می‌کند، آن‌ها را بدون سؤال بیشتر به‌عنوان Requirement نهایی نپذیری\. برای موارد قابل‌اندازه‌گیری، آن‌ها را به **معیار، هدف و شرایط سنجش** نزدیک می‌کنیم\. برای خواسته‌های ذهنی‌تر، از **نمونه مرجع، معیارهای قابل‌مشاهده و توافق روشن** استفاده می‌کنیم\. تمرین اصلی جلسه هم این هست: یکی از عبارت‌های مبهمی را که مشتری واقعاً به تو گفته انتخاب کن و آن را به چیزی تبدیل کن که در پایان پروژه بتوان درباره موفق‌شدن یا نشدنش صحبت کرد\. جلسه بعد سراغ سؤال مهم دیگری می‌رویم: **اگر تو و رقیبت هر دو بتوانید نتیجه خوبی تحویل بدهید، مشتری چرا باید تو را انتخاب کند؟** [دوره]()