«یک سایت می‌خواهیم که مشتری خودش وقت بگیرد و دیگر این‌همه تماس نداشته باشیم.» این پیام برای شروع گفت‌وگو خوب است، اما هنوز نمی‌شود از روی آن پروژه را برآورد کرد. شاید مسئله واقعاً رزرو آنلاین باشد؛ شاید هم بیشتر تماس‌ها برای پرسیدن آدرس، تغییر ساعت یا پیدا کردن نوبت لغوشده انجام می‌شوند. هرکدام از این حالت‌ها به محصول متفاوتی می‌رسد.
در اولین بخش این مجموعه، یک سامانه نوبت‌دهی فرضی را از همین پیام جلو می‌بریم. هدف این است که پیش از طراحی صفحه و انتخاب فناوری، مسئله‌ای بنویسیم که تیم بتواند درباره آن تصمیم بگیرد. پیش‌نیاز فنی خاصی لازم نیست؛ در پایان، یک صورت‌مسئله کوتاه، فهرست فرض‌ها و چند معیار پذیرش خواهیم داشت. این مثال مطالعه موردی آموزشی است و روایت پروژه واقعی یا نتیجه اندازه‌گیری‌شده برنا نیست.
درخواست اولیه را به چند سؤال قابل بررسی تبدیل کنیم
درخواست «سایت نوبت‌دهی» سه چیز را با هم مخلوط کرده است: مشکل کسب‌وکار، راه‌حل پیشنهادی و نتیجه مطلوب. مشکل را هنوز نمی‌دانیم؛ سایت راه‌حل پیشنهادی است و کم‌شدن تماس‌ها نتیجه‌ای است که باید دقیق‌تر تعریف شود. اولین کار جداکردن همین سه بخش است.
برای شروع جلسه، به‌جای پرسیدن «چه امکاناتی لازم دارید؟» بخواهید آخرین رزرو واقعی را تعریف کنند. مشتری از کجا با مجموعه آشنا شد؟ چه سؤالی پرسید؟ مسئول پذیرش کجا ساعت خالی را پیدا کرد؟ چه چیزی ثبت شد و بعد چه اتفاقی افتاد؟ دنبال یک روایت مشخص باشید؛ توصیف کلی فرایند معمولاً استثناهایی را حذف می‌کند که بعداً بخش سخت نرم‌افزار می‌شوند.
اگر مسئول پذیرش بگوید «تقریباً همه تماس‌ها برای گرفتن وقت است»، همان جمله را داده قطعی حساب نکنید. می‌توان چند روز علت تماس‌ها را بدون نام و شماره مشتری ثبت کرد. نتیجه شاید نشان بدهد بخش مهمی از تماس‌ها درباره هزینه یا تغییر زمان است. در این حالت، بهترکردن صفحه اطلاعات خدمات یا مسیر جابه‌جایی نوبت می‌تواند از یک تقویم پیچیده مؤثرتر باشد.
چه کسی دقیقاً چه کاری می‌خواهد انجام دهد؟
در مثال ما سه نقش وجود دارد: مراجعه‌کننده، مسئول پذیرش و ارائه‌دهنده خدمت. مراجعه‌کننده ساعت مناسب می‌خواهد؛ پذیرش باید بداند کدام ظرفیت واقعاً آزاد است؛ ارائه‌دهنده خدمت هم می‌خواهد برنامه‌ای داشته باشد که با مرخصی، تأخیر یا طول متفاوت خدمات ناسازگار نباشد. عبارت «کاربر سیستم» این تفاوت‌ها را پنهان می‌کند.
| نقش | کار اصلی | پرسش باز |
|---|---|---|
| مراجعه‌کننده | پیداکردن و رزرو زمان مناسب | آیا انتخاب شخص ارائه‌دهنده ضروری است؟ |
| پذیرش | ثبت و اصلاح رزروهای حضوری و تلفنی | رزرو تلفنی در کدام ابزار ثبت می‌شود؟ |
| ارائه‌دهنده خدمت | مشاهده برنامه و اعلام عدم حضور | چه کسی اجازه بستن ظرفیت را دارد؟ |
این جدول مدل دسترسی نهایی نیست. فعلاً کمک می‌کند مصاحبه فقط با سفارش‌دهنده محصول انجام نشود. کسی که هزینه را می‌پردازد ممکن است هرگز پشت میز پذیرش ننشسته باشد. مشاهده کار پذیرش، حتی در یک بازه کوتاه، جزئیاتی مثل تماس هم‌زمان یا ثبت رزرو روی کاغذ را آشکار می‌کند که در جلسه رسمی گفته نمی‌شوند.
مسیر فعلی را قبل از مسیر مطلوب بنویسیم
فرض کنیم در سناریوی آموزشی، زمان‌های خالی در یک فایل مشترک نگهداری می‌شوند. مراجعه‌کننده تماس می‌گیرد، پذیرش فایل را باز می‌کند، درباره نوع خدمت می‌پرسد و یک زمان پیشنهاد می‌دهد. تأیید نهایی شفاهی است و گاهی یادآوری با پیام‌رسان انجام می‌شود. این توصیف هنوز درباره خوب یا بد بودن فرایند قضاوت نمی‌کند؛ فقط وضع موجود را روشن می‌کند.
- مراجعه‌کننده خدمت موردنظر را بیان می‌کند.
- پذیرش مدت و ارائه‌دهنده مناسب را مشخص می‌کند.
- زمان آزاد پیدا و با مشتری هماهنگ می‌شود.
- اطلاعات رزرو ثبت می‌شود.
- تأیید و شرایط تغییر زمان به مشتری می‌رسد.
حالا می‌توان پرسید مشکل در کدام قدم رخ می‌دهد. اگر پیدا کردن زمان خالی آسان است ولی مشتری از قطعی‌بودن نوبت مطمئن نمی‌شود، باید روی تأیید رزرو تمرکز کنیم. اگر دو نفر هم‌زمان یک ساعت را می‌فروشند، مسئله اصلی یکپارچگی ظرفیت است. این دو مسئله ممکن است ظاهر یکسانی در شکایت مشتری داشته باشند، اما راه‌حل فنی‌شان یکی نیست.
پرسش‌هایی که بهتر است همین حالا بپرسیم
سؤال خوب به یک تصمیم مشخص کمک می‌کند. «آیا سیستم حرفه‌ای می‌خواهید؟» تقریباً هیچ چیزی را روشن نمی‌کند. در مقابل، پاسخ به «آیا مشتری می‌تواند پنج دقیقه قبل از نوبت آن را لغو کند؟» روی قواعد رزرو، پیام تأیید و حتی ظرفیت روز اثر مستقیم دارد.
- واحد رزرو چیست؟ یک فرد، یک اتاق، یک دستگاه یا ترکیبی از آن‌ها؟
- زمان خدمت ثابت است؟ رزرو نیم‌ساعته و خدمت چهل‌وپنج‌دقیقه‌ای را نمی‌شود بدون قاعده کنار هم چید.
- رزرو چه زمانی قطعی می‌شود؟ هنگام ثبت فرم، تأیید پذیرش یا پرداخت؟
- ورود بدون رزرو چه وضعی دارد؟ پذیرش باید بتواند آن را در همان منبع ظرفیت ثبت کند.
- تغییر برنامه چگونه انجام می‌شود؟ بستن یک بازه دارای رزرو باید با اطلاع‌رسانی و تعیین تکلیف همراه باشد.
- چه کسی از مسیر آنلاین جا می‌ماند؟ نداشتن گوشی مناسب یا دشواری استفاده نباید دسترسی به خدمت را ناممکن کند.
پاسخ همه سؤال‌ها لازم نیست در جلسه اول آماده باشد. مهم این است که مجهول‌ها با تصمیم‌های گرفته‌شده اشتباه نشوند. برای هر سؤال باز، یک مسئول پاسخ و یک زمان پیگیری ثبت کنید. عبارت «بعداً مشخص می‌شود» بدون این دو مورد معمولاً تا روز انتشار باقی می‌ماند.
فرض، مشاهده و تصمیم را در یک ستون ننویسیم
فرض کنید کسی می‌گوید «مشتری‌ها حساب کاربری نمی‌خواهند». این جمله ممکن است درست باشد، ولی تا وقتی شواهدی نداریم یک فرض است. می‌توان مسیر رزرو با شماره تماس را روی نمونه اولیه امتحان کرد و دید آیا برای پیگیری یا تغییر زمان کافی است. لازم نیست برای روشن‌شدن این موضوع ابتدا سامانه احراز هویت کامل بسازیم.
یک دفتر تصمیم کوچک کافی است: چه چیزی را می‌دانیم، چه چیزی را فرض کرده‌ایم و برای روشن‌شدن هر فرض چه کاری انجام می‌دهیم. مثلاً «پذیرش رزرو تلفنی دارد» مشاهده است؛ «بیشتر مشتری‌ها از موبایل می‌آیند» فرض است؛ «نسخه اول ثبت رزرو تلفنی را در پنل می‌پذیرد» تصمیم طراحی است. جداکردن این‌ها جلوی بحث‌های مبهم بعدی را می‌گیرد.
صورت‌مسئله‌ای بنویسیم که بتوان به آن رجوع کرد
حالا می‌توان مسئله مثال را این‌طور نوشت: «مراجعه‌کننده برای یافتن زمان آزاد و اطمینان از ثبت نوبت به تماس با پذیرش وابسته است. پذیرش نیز رزروهای چند مسیر را در ابزاری ثبت می‌کند که وضعیت ظرفیت را همیشه روشن نگه نمی‌دارد. نسخه نخست باید مشاهده زمان‌های قابل رزرو، ثبت نوبت و دریافت تأیید روشن را ممکن کند و ثبت تلفنی را در همان ظرفیت نگه دارد.»
این متن هنوز مشخصات کامل محصول نیست، اما مرجع مفیدی برای تصمیم‌هاست. هر قابلیت پیشنهادی را می‌توان با آن سنجید: آیا مشکل تعریف‌شده را حل می‌کند؟ اگر پیشنهاد باشگاه مشتریان مطرح شد، معلوم است که باید شواهد و اولویت جداگانه‌ای داشته باشد؛ صرف جذاب‌بودن یک قابلیت دلیل کافی برای ورود آن به نسخه اول نیست.
معیار موفقیت را از معیار پذیرش جدا کنیم
معیار موفقیت می‌گوید محصول چه تغییری در کار ایجاد کرده است؛ معیار پذیرش می‌گوید یک رفتار مشخص درست پیاده شده یا نه. برای مثال، سهم رزروهایی که بدون تماس تکمیل می‌شوند یک معیار محصول است. جلوگیری از قطعی‌شدن دو رزرو برای یک ظرفیت، قاعده‌ای است که باید مستقل از میزان استقبال کاربران درست کار کند.
- اگر زمان انتخابی هنوز آزاد باشد، ثبت موفق باید شناسه پیگیری و زمان قطعی را نمایش دهد.
- اگر ظرفیت در فاصله انتخاب تا تأیید پر شود، کاربر باید پیام روشن ببیند و بتواند زمان دیگری انتخاب کند.
- پذیرش باید بتواند رزرو تلفنی را در همان تقویم ثبت کند.
- خطای ارسال پیام تأیید نباید به کاربر القا کند رزرو ثبت نشده و باید دوباره ثبت کند.
برای هدف‌های عددی عجله نکنید. ابتدا خط مبنا را به دست آورید: امروز چند تماس داریم، علتشان چیست و ثبت یک نوبت معمولاً چقدر کار می‌برد؟ سپس هدف و بازه سنجش را با مسئول کسب‌وکار تعیین کنید. عددی که برای زیباترشدن ارائه انتخاب شده باشد، به تصمیم واقعی کمک نمی‌کند.
خروجی جلسه باید چه چیزی باشد؟
برای این مرحله یک سند کوتاه معمولاً از مجموعه طولانی اسکرین‌شات مفیدتر است. سند باید مسئله، نقش‌ها، مسیر فعلی، محدودیت‌ها، فرض‌های باز و مرز اولیه نسخه نخست را در دسترس تیم بگذارد. تاریخ و مسئول تصمیم‌ها را هم ثبت کنید تا دو هفته بعد معلوم باشد کدام بخش تغییر کرده است.
به‌عنوان تمرین، همان پیام ابتدای مقاله را بردارید و پنج سؤال بنویسید که پاسخ هرکدام یک تصمیم طراحی را عوض کند. سپس سه معیار پذیرش برای رزرو موفق، ظرفیت ازدست‌رفته و تغییر زمان بنویسید. اگر پاسخ سؤال‌ها هنوز روشن نیست، خروجی درست این مرحله فهرست مجهول‌های قابل پیگیری است؛ نیازی نیست آن‌ها را با انتخاب زودهنگام ابزار بپوشانیم.
در بخش بعد، این صورت‌مسئله را به نقشه سفر مراجعه‌کننده و پذیرش تبدیل می‌کنیم. آنجا مشخص می‌شود ثبت رزرو فقط یک فرم نیست و انتظار، تأیید، تغییر زمان و پیگیری چگونه به هم وصل می‌شوند.
برای مطالعه بیشتر
- راهنمای GOV.UK درباره شناخت نیاز کاربران؛ مرجع روش تحقیق و تفکیک نیاز از راه‌حل پیشنهادی.
- راهنمای مرحله کشف مسئله؛ برای تعریف محدوده تحقیق و شناسایی محدودیت‌ها.