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