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