مرا اسکن کن!
کمینه محصول پذیرفتنی یا همان محصول با حداقل‌های قابل قبول (Minimum Viable product) به کارآفرینان کمک می‌کند که فرآیند یادگیری را هرچه سریعتر آغاز کنند.
استیو بلنک ام.وی.پی را اینگونه تعریف می کند:
«کمترین ویژگی‌هایی که می‌توان با کمک آن از مشتری بازخورد مناسب گرفت. »
و اریک رایس نویسنده کتاب «نوپای ناب» این مفهوم را اینگونه تعریف کرده:
«محصول حداقلی نسخه‌ای از محصول جدید است که به یک تیم کمک می‌کند حداکثر میزان یادگیری معتبر در مورد مشتریان را با حداقل تلاش به دست آورد.»
در واقع ام.وی.پی، حداقل چیزی است که می‌توانیم آن را به مشتری نشان دهیم و باز خوردها را مشاهده کنیم. سپس بر اساس این بازخوردها درستی یا نادرستی فرض های خودمان را بسنجیم.
بنابراین ام.وی.پی الزاما یک نسخه اولیه یا ناقص از محصول نهایی نیست.
با وجود مخالفت‌هایی که با لزوم رفتن هرچه سریعتر کسب و کارها به «فاز درآمد» وجود دارد، کمینه محصول پذیرفتنی میان مراحل ایده‌ی مفهومی محصول و همخوانی محصول-بازار تکامل پیدا می‌کند. اریک رایز می‌گوید «به همین دلیل است که کارآفرینی در شرکت استارتاپ ناب (Lean Startup) در‌واقع مجموعه‌ای از MVPهاست که هرکدام طراحی شده‌اند تا به یک پرسش (فرض) مشخص پاسخ دهند.»
MVP لزوماً کوچکترین محصول قابل تصور نیست، بلکه سریعتر راه برای پیمودن چرخه‌ی بساز- اندازه‌بگیر-یادبگیر (Build-Measure-Learn) با کمترین تلاش است.
درمقابل ساخت سنتی محصول، که معمولاً زمانبر و شامل رشد محصول از آغاز تا رسیدن به یک محصول کامل است، هدف MVP آغازکردن فرآیند یادگیری است نه پایان دادن به آن.
ما همه قبول داریم که هیچ تولیدکننده‌ای دوست ندارد محصولی ناقص(غیرکامل) را روانه بازار کند. پس چرا از Minimum Viable Product دفاع میکنیم؟ جواب ساده به این سوال این است که نباید زمان(ارزشمند) و منابع را بر روی ساخت چیزهایی صرف(یا حتی هدر) کرد که مشخص نیست کاربردی و مناسب هستند یا نه. از طرف دیگر هیچ محصولی(سرویسی) نیست که نتوان قابلیت دیگری به آن افزود و این داستان اضافه کردن قابلیت‌ها و امکانات پایانی ندارد.
از طرف دیگر هیچ مشتری دوست ندارد که محصول(سرویس) ناکاملی را بخرد یا با آن سروکله بزند، پس چرا حاضر است MVP ما را تست کند(یا بخرد)؟ توجه داشته باشید که مشتری‌های ما در این فاز، مشتری محصول ما نیستند، بلکه مشتری دیدگاه(vision) ما هستند. این مشتری‌ها که استیو بلنک آنها را Earlyvangelists می‌خواند، ریسک استفاده از محصول یا سرویس ناکامل ما را پذیرفته‌اند. معمولن مشخصه این افراد چنین است:
مشتریان اولیه ما باید از محصول یا سرویس ما لذت ببرند. این باعث می‌شود اشکالات و کم‌و‌کاستی‌های محصول را در این شرایط بپذیرند. محصول ما احتمالن باگ خواهد داشت، اطلاعات کاربران ممکن است از دست برود و … .پس باید مطمئن شویم با این مشتریان خوب برخورد میکنیم و نیازهای آنها را درک میکنیم. سعی کنیم با داشتن یک نقشه‌راه شفاف به آنها نشان دهیم که دیدگاه ما ارزش خریده شدن دارد.
Minimum Viable Product به خوبی مفهوم مورد نظر خودش را می‌رساند. اما سوالی که مطرح می‌شود این است که کجا باید توقف کرد؟ حداقل امکاناتی که موردنیاز است چیست و چگونه مشخص می‌شود؟ کدام امکانات اساسی هستند و باید در MVP حضور داشته باشند؟ جواب دادن به این سوالات و سوالات مشابه واقعن سخت(یا شاید نشدنی) است، اما چند توصیه وجود دارد که میتواند در پاسخ به این سوالات راه‌گشا باشد:
نمونه: Dropbox
موسسان Dropbox می‌خواستند بدانند واکنش مشتریان به سایت چه خواهد بود و اینکه آیا ایده‌شان پذیرفته می‌شود. همچنین آنها در توصیف ایده به سرمایه‌گذاران و قانع کردن آنها مشکل داشتند. مشکل از آنجا ناشی می‌شد که نشان دادن نرم‌افزاری که در حالت نمونه کار کند تقریباً غیر ممکن بود و نیاز به برنامه‌نویسی طولانی و نفس‌گیر به همراه ریسک بالا داشت.
موسسان به جای این کار یک ویدئو ساختند. یک ویدئو ساده دو دقیقه‌ای که فناوری و کارکرد آن را نشان می‌دهد. یکی از کارآفرینان خودش روی ویدئو صحبت کرد.
پس از کشاندن مخاطبات به سایت، لیست انتظار بتا آنها یک شبه از ۵۰۰۰ به ۷۵۰۰۰ نفر رسید و … .
امروز Dropbox یکی از شرکت‌های موفق سیلیکون ولی با‌ارزش تقریبی یک میلیلرد دلار است.
همواره در این مسیر اشتباهاتی وجود دارد، آنها را بپذیریم و به این روند ادامه دهیم.
اگر از ساختمان بیرون بزنیم و از هر مشتری احتمالی بپرسیم به ازای چه مشخصات و آپشن‌هایی در برنامه حاضر است به ما پول بدهد، احتمالن به ازای ده مشتری ده صفحه امکانات لیست شده داریم! این اشتباه است. ما باید به یک پاراگراف از نیازمندی برسیم که هزاران نفر بابت حل شدن آن مشتری ما می‌شوند.نکته‌ای که حتما باید به آن توجه کرد این است که MVP نباید تجربه‌کاربری محصول یا سرویس ما را خراب کند. ممکن است ما بر سر اینکه قابلیت ‘ریست پسورد’ را در نسخه MVP داشته باشیم یا نه بحث کنیم. اما اگر تصمیم گرفتیم این قابلیت را اضافه کنیم باید مطمئن باشیم که استانداردها(شامل استانداردهای UX و نه محدود به آن) را به خوبی رعایت کرده‌‌ایم. امکانات محصول می‌توانند پیچیدگی‌های متفاوتی داشته باشند. به طور مثال سیستم ریست پسورد میتواند شامل ۲ مرحله امنیتی باشد و سیستم لاگین فقط ۱ مرحله داشته باشد. اما کیفیت تجربه‌کاربری همه اینها باید یکسان باشد.
با توجه به مثال هایی که زده شد تفاوت محصول حداقلی روشن است.
ام.وی.پی ارزان و سریع ساخته می‌شود و
هدف اش آزمودن فرض‌های مدل کسب کسب وکار است.
می‌توانیم ام.وی.پی های مختلفی برای
آزمودن بخش‌های مختلف مدل کسب و کار داشته باشیم.
ممکن است ام.وی.پی که اعتبار ارزش پیشنهادی ما را می سنجد
الزاما فرضیه ارتباط با مشتری را نیازماید و
نیاز به ساخت ام.وی.پی دیگری برای آزمودن این فرض داشته باشیم.
بنابراین ام.وی.پی ها فقط برای اعتبارسنجی مدل کسب و کار،
یادگیری و اصلاح مدل ساخته می‌شوند.
نمونه اولیه (Prototype) محصول اصلی است که
به شکل دست ساز ساخته می‌شود تا
به سوالات فنی و طراحی محصول پاسخ دهد.
نمونه اولیه امکان پذیر بودن تولید محصول را بررسی می‌کند و
محور آن فناوری و ساخت است نه بازار.
نسخه نمایشی (Demo) برای آشنا شدن کاربر با محصول است.
نسخه نمایشی نمونه‌ای از محصول اصلی که
در اختیار مشتری قرار داده می‌شود تا
او با ظاهر و توانایی‌های محصول آشنا گردد.
هدف نسخه نمایشی، نشان دادن و بررسی ظاهر، ویژگی، توانایی و امکانات محصول اصلی است.
بنابراین فارغ از نحوه ساخت، ام.وی.پی، نمونه اولیه و نسخه نمایشی، این ها سه ابزار با سه هدف متفاوت هستند.
بدیهی است که هیچکدام جای دیگری را نمی‌گیرد.
وحید صمدیان
برچسب ها : آخرین اخبار دنیای وب
علوم رايانه هيچگاه شخصی را تبديل به يك برنامه نويس خوب نمي‌كنند همانطور كه مطالعه در مورد رنگ‌ها و قلم‌ها شما را تبديل به يك نقاش خوب نمیكند. 
