MVP چیست و چرا استارتاپ‌ها با آن شروع میکنند؟
MVP مخفف Minimum Viable Product است. «حداقل» یعنی فقط امکاناتی که بدون آن‌ها محصول معنا ندارد. «پذیرفتنی» یعنی همین نسخه کوچک باید واقعاً کار کند و مشکلی را برای کاربر حل کند. MVP نسخه خراب یا نیمه‌کاره محصول نیست؛ نسخه کوچک و سالم آن است.
اصطلاح MVP را فرانک رابینسون ساخت و اریک ریس، نویسندهٔ کتاب «استارتاپ ناب» (The Lean Startup)، آن را رایج کرد (ویکی‌پدیا: کمینه محصول پذیرفتنی، Atlassian). در نگاه ریس، MVP نسخهای است که با کمترین تلاش، بیشترین یادگیری دربارهٔ مشتری را به دست می‌دهد. پس MVP یعنی چی؟ به زبان ساده: کوچک‌ترین چیزی که بسازید و از رفتار کاربر واقعی چیزی یاد بگیرید.
دلیل اصلی شروع با محصول اولیه، کم‌کردن ریسک است. هر ایده روی چند فرض بنا شده: اینکه مشکل واقعی است، اینکه مردم برای حل آن پول یا وقت می‌گذارند و اینکه راه‌حل شما را به روش فعلی‌شان ترجیح میدهند. تا وقتی محصول به دست کاربر نرسیده، این‌ها فقط حدس‌اند.
MVP استارتاپ این حدس‌ها را با هزینه چند هفته کار می‌آزماید، نه چند ماه. در خدمات ساخت MVP تکنوراه کار را از همین نقطه شروع می‌کنیم: اول مشخص می‌کنیم چه چیزی باید ثابت شود، بعد تصمیم می‌گیریم چه چیزی ساخته شود.
تفاوت MVP با پروتوتایپ و PoC
این سه اصطلاح زیاد به‌جای هم به کار می‌روند، اما هر کدام به پرسش متفاوتی جواب میدهند. PoC یا اثبات امکان‌پذیری می‌پرسد «اصلاً میشود این را ساخت؟»، پروتوتایپ می‌پرسد «کاربر با این طرح راحت است؟» و MVP می‌پرسد «کسی واقعاً از این استفاده می‌کند؟».
| PoC (اثبات امکان‌پذیری) | پروتوتایپ (نمونه اولیه) | MVP (حداقل محصول پذیرفتنی) | |
|---|---|---|---|
| پرسش اصلی | از نظر فنی شدنی است؟ | ظاهر و مسیر کاربر درست است؟ | بازار این محصول را میخواهد؟ |
| مخاطب | تیم فنی و تصمیم‌گیران داخلی | طراحان، چند کاربر آزمایشی، سرمایه‌گذار | کاربران واقعی |
| خروجی | یک آزمایش فنی کوچک | طرح قابل کلیک، بدون سیستم واقعی پشت آن | محصول واقعی و قابل استفاده با امکانات محدود |
| زمان معمول | چند روز تا چند هفته | چند روز تا چند هفته | معمولاً ۶ تا ۱۰ هفته |
| بعد از آن | معمولاً کنار گذاشته میشود | مبنای طراحی محصول میشود | پایه نسخههای بعدی میشود |
انواع MVP: همیشه لازم نیست برنامه بنویسید
نسخهٔ MVP لزوماً یک اپ کامل نیست. بسته به اینکه چه فرضی را می‌خواهید بسنجید، شکل‌های ساده‌تری هم جواب میدهند:
| نوع | چه چیزی ساخته میشود | چه چیزی را میسنجد | کِی مناسب است |
|---|---|---|---|
| صفحهٔ فرود | یک صفحهٔ معرفی با فرم ثبت‌نام انتظار | آیا کسی به وعدهٔ محصول علاقه دارد | پیش از هر ساختی |
| MVP دستی (Concierge) | هیچ سیستمی؛ خدمت را خودتان دستی و با اطلاع مشتری انجام می‌دهید | آیا مشتری برای حل مشکل پول یا وقت می‌گذارد | خدمات و بازارهای کوچک |
| «جادوگر اُز» (Wizard of Oz) | ظاهری که خودکار به نظر می‌رسد، با کار دستی پشت صحنه | آیا کاربر از تجربهٔ نهایی استفاده می‌کند | وقتی بخش خودکار گران است |
| MVP تک‌امکانی | فقط یک کار اصلی، واقعاً ساخته‌شده | آیا همان کار اصلی ارزش برگشتن دارد | وقتی تقاضا تا حدی روشن است |
| وب‌اپ یا PWA به‌جای اپ موبایل | نسخهٔ تحت وب که روی گوشی هم باز میشود | آیا کاربر محصول را مرتب استفاده می‌کند | وقتی نصب از استور لازم نیست |
روایت زاپوس که پایین‌تر در «نمونه‌های شناخته‌شده» آمده، نمونهٔ «جادوگر اُز» است: مشتری سایت فروش کفش می‌دید، ولی خرید و ارسال دستی انجام می‌شد. برای انتخاب بین وب‌اپ و اپ موبایل، PWA یا اپلیکیشن نیتیو را ببینید؛ PWA وب‌اپی است که مثل اپ روی گوشی نصب میشود.
مثال فرضی: یک کسب‌وکار خدمات منزل اول با یک فرم ساده و هماهنگی تلفنی سفارش می‌گیرد. اگر سفارش‌ها مرتب تکرار شد، تازه اپ مشتری را با همان مسیری می‌سازد که در این مدت جواب داده است.
چطور امکانات MVP را انتخاب کنیم؟
سخت‌ترین بخش ساخت MVP، کدنویسی نیست؛ حذف‌کردن است. هر امکانی که اضافه میشود زمان، هزینه و احتمال خطا را بالا میبرد و آزمودن فرض اصلی را عقب می‌اندازد.
یک روش ساده برای اولویتبندی، روش MoSCoW است. در این روش هر امکان را در یکی از چهار دسته می‌گذارید:
- باید باشد: بدون آن محصول کار اصلی‌اش را انجام نمی‌دهد؛ مثل ثبت سفارش در یک اپ سفارش غذا.
- بهتر است باشد: مهم است، اما نبودنش در نسخه اول محصول را از کار نمی‌اندازد.
- اگر شد باشد: خوشایند است و اثر کمی روی هدف اصلی دارد.
- فعلاً نباشد: آگاهانه به نسخههای بعد منتقل میشود.
MVP فقط از دسته اول ساخته میشود. برای هر امکان بپرسید: اگر این نباشد، آیا هنوز می‌توانم فرض اصلی را بسنجم؟ اگر جواب «بله» است، جای آن در نسخه اول نیست. نوشتن هر امکان در قالب داستان کاربر هم کمک می‌کند ارزش واقعی‌اش روشن شود؛ روش آن را در مقاله یوزر استوری چیست توضیح داده‌ایم.
اگر بودجه محدود است و می‌خواهید نسخه اول را کوچک نگه دارید، مقاله کاهش هزینه ساخت اپلیکیشن را هم ببینید.
مراحل ساخت MVP گام‌به‌گام
فرض اصلی را بنویسید
یک جمله روشن: چه کسی، چه مشکلی دارد و چرا راه‌حل شما را انتخاب می‌کند.
معیار موفقیت را پیش از ساخت تعیین کنید
چه عددی یا چه رفتاری نشان می‌دهد فرض درست بوده است؟
محدوده را ببندید
امکانات ضروری را در یک مستند نیازمندی کوتاه بنویسید. راهنمای نوشتن PRD در این مرحله به کارتان میآید.
مسیر اصلی کاربر را طراحی کنید
فقط همان چند صفحه‌ای که کاربر را از ورود به نتیجه می‌رساند.
بسازید و هر هفته نسخه قابل استفاده ببینید
با معماری ساده، اما تمیز و قابل توسعه.
برای گروه کوچکی منتشر کنید
چند ده کاربر واقعی از صدها بازدیدکننده بی‌هدف ارزشمندترند.
بسنجید و تصمیم بگیرید
ادامه، تغییر مسیر یا توقف.
در طول ساخت، بزرگ‌ترین خطر اضافه‌شدن تدریجی امکانات تازه است؛ پدیده‌ای که به آن خزش محدوده می‌گویند و در مقاله Scope Creep چیست و چطور مهارش کنیم به آن پرداخته‌ایم.
نمونه‌های شناخته‌شده از محصول اولیه
MVP همیشه به معنای نوشتن نرمافزار نیست. طبق روایت‌های مشهور، دراپ‌باکس پیش از کامل‌کردن محصول، با یک ویدئوی کوتاه توضیحی سنجید که آیا مردم چنین ابزاری می‌خواهند. بنیان‌گذار زاپوس هم در ابتدا عکس کفش‌های مغازه‌ها را روی سایت گذاشت و سفارش‌ها را دستی تهیه می‌کرد تا بفهمد کسی حاضر است کفش را اینترنتی بخرد یا نه. درس مشترک هر دو: اول تقاضا را بسنجید، بعد سیستم بسازید.
اشتباه‌های رایج در ساخت MVP
- ساختن امکانات زیاد از ترس اینکه محصول «کم» به نظر برسد
- فداکردن کیفیت؛ MVP باید کوچک باشد، نه پر از خطا و کند
- شروع بدون معیار موفقیت، طوری که بعد از انتشار معلوم نیست نتیجه خوب بوده یا بد
- انتشار برای همه به‌جای یک گروه مشخص و قابل پیگیری
- معماری یک‌بارمصرف که با اولین رشد باید از نو نوشته شود
- نداشتن مالکیت کد منبع و دسترسی سرور از روز اول
MVP، نسخهٔ ارزان همهٔ امکانات نیست
در درخواست‌هایی که از فرم برآورد به ما می‌رسد، بارها دیده‌ایم کسی گزینهٔ بودجهٔ MVP را انتخاب می‌کند و هم‌زمان پرداخت آنلاین، چت، نقشه و امتیازدهی را از روز اول میخواهد. این همان سوءبرداشت رایج است: MVP را نسخهٔ ارزان محصول کامل می‌دانند.
MVP کوچک است چون فقط یک فرض را میسنجد، نه چون همه‌چیز را ارزان‌تر می‌سازد. هر امکان اضافه، زمان و خطا را بالا میبرد. نسخهای با درگاه پرداخت یا چرخهٔ کامل سفارش، دیگر MVP ساده (۶ تا ۱۰ هفته) نیست و در حد اپ متوسط، ۳ تا ۴ ماه است (زمان ساخت اپلیکیشن).
راه انتخاب یک امکان اصلی: بپرسید کاربر برای کدام کار حاضر است برگردد. مثال فرضی: در اپ سفارش غذا، «ثبت سفارش» امکان اصلی است؛ پرداخت می‌تواند اول در محل باشد و امتیازدهی به فاز بعد برود. راه‌های بیشتر برای کوچک نگه داشتن نسخهٔ اول در کاهش هزینه ساخت اپلیکیشن آمده و برای جلوگیری از اضافه شدن تدریجی امکانات، Scope Creep چیست را بخوانید.
MVP با «فاز ۱» هم یکی نیست. فاز ۱ اولین بخش از نقشه‌ای است که ساختنش قطعی شده؛ MVP برای این است که بفهمید آن نقشه درست است یا نه. در تیم‌های چابک (Agile؛ روشی که محصول را در دوره‌های کوتاه می‌سازد و هر دوره نسخهٔ قابل استفاده تحویل می‌دهد)، MVP اولین نسخهای است که به دست کاربر واقعی می‌رسد و دوره‌های بعد بر اساس بازخورد همان کاربران برنامه‌ریزی می‌شوند.
بعد از انتشار چه چیزهایی را بسنجیم؟
تعداد نصب یا ثبت‌نام به‌تنهایی چیز زیادی نمی‌گوید. آنچه اهمیت دارد رفتار کاربر بعد از ورود است. این چند شاخص برای بیشتر محصولات اولیه کافی است:
- فعال‌سازی: چند نفر از ثبت‌نام‌کنندگان کار اصلی محصول را دست‌کم یک بار انجام داده‌اند؟
- بازگشت: چند نفر هفته بعد دوباره برگشته‌اند؟
- تمایل به پرداخت: آیا کسی حاضر است برای آن پول بدهد یا پیش‌خرید کند؟
- معرفی به دیگران: آیا کاربران خودشان محصول را به کسی پیشنهاد میکنند؟
- بازخورد کیفی: در گفت‌وگوی مستقیم، کاربران چه چیزی را کم دارند و از چه چیزی استفاده نمی‌کنند؟
اعداد را با معیاری که پیش از ساخت تعیین کرده بودید مقایسه کنید، نه با حس‌وحال روز انتشار.
چه زمانی از MVP به نسخه دوم برویم؟
وقت نسخه دوم زمانی است که نشانه‌های روشن دارید: گروهی از کاربران مرتب برمی‌گردند، درخواست‌هایشان تکراری و مشخص شده و می‌دانید کدام بخش محصول ارزش اصلی را می‌سازد.
اگر کاربران می‌آیند و برنمی‌گردند، افزودن امکانات مشکل را حل نمی‌کند. در این حالت باید به فرض اصلی برگردید و مخاطب، مسئله یا راه‌حل را بازبینی کنید.
تصمیم‌های فنی این مرحله، مثل نگه‌داشتن یا بازنویسی بخشی از کد و برنامه‌ریزی برای رشد، اثر بلندمدت دارند. اگر در تیم خود مدیر فنی ندارید، خدمت مدیر فنی (CTO) به‌عنوان سرویس می‌تواند این جای خالی را پر کند.
کاربرگ شروع MVP: پیش از اولین جلسه با تیم فنی
پیش از تماس با هر تیم فنی، این هفت خانه را در یک صفحه پر کنید. جواب‌ها کوتاه باشند؛ یک جمله یا یک فهرست کوتاه کافی است.
- فرض اصلی در یک جمله: چه کسی، چه مشکلی دارد و چرا راه‌حل شما را انتخاب می‌کند.
- نشانهٔ درستی فرض: یک عدد یا رفتار، مثلاً «کاربرها هفتهٔ دوم هم سفارش میدهند».
- حداکثر ۳ امکان «باید باشد»: اگر بیشتر شد، فهرست را دوباره ببینید. برای نوشتن دقیق‌تر هر امکان، سند نیازمندی نرمافزار کمک می‌کند.
- امکاناتی که آگاهانه به فاز بعد می‌روند.
- اولین گروه کاربر: چند نفر و از کجا پیدایشان می‌کنید.
- شکل محصول: اپ موبایل، وب‌اپ یا بدون کد.
- مسئول بازخورد: چه کسی بعد از انتشار بازخورد جمع می‌کند و هر چند وقت تصمیم می‌گیرید.
کاربرگ را پر کردید؟ همین را در فرم برآورد بفرستید تا بگوییم نسخهٔ اول شما چه اندازه است.
مثال فرضی پرشده برای یک اپ نوبت‌دهی آرایشگاه: فرض «مشتری‌های ثابت ترجیح میدهند بدون تلفن نوبت بگیرند»؛ نشانه «بیشتر نوبت‌های هفتهٔ سوم آنلاین گرفته شود»؛ امکان‌های اصلی «دیدن ساعت‌های خالی، رزرو، یادآوری پیامکی»؛ فاز بعد «پرداخت و امتیاز»؛ کاربرها «مشتری‌های ثابت یک شعبه»؛ شکل «وب‌اپ»؛ مسئول «مدیر شعبه، هر دو هفته».
جمع‌بندی: نسخهٔ اول شما چه باید ثابت کند؟
برای شروع، فرض اصلی کسب‌وکارتان و سه تا پنج امکانی را که بدون آن‌ها محصول معنا ندارد بنویسید. با همین فهرست می‌توانید در ماشین‌حساب برآورد هزینه اپلیکیشن تصویری اولیه از بودجه بگیرید. هزینه نهایی به تعداد امکانات، نوع محصول (وب، موبایل یا هر دو) و سطح طراحی بستگی دارد. اگر به‌جای اپ، نرمافزار سفارشی می‌سازید، عوامل قیمت را در مقاله هزینه ساخت نرمافزار سفارشی ببینید.
اگر می‌خواهید این مسیر را با یک تیم فنی طی کنید، صفحه ساخت MVP در تکنوراه را ببینید و یک جلسه مشاوره رایگان ۱۵ دقیقه‌ای رزرو کنید. در این جلسه به امکاناتی که توجیه کسب‌وکاری ندارند صریح «نه» می‌گوییم، و کد منبع و دسترسی سرور از روز اول در اختیار شماست.
سوالات متداول
ساخت MVP چقدر زمان میبرد؟
در بیشتر پروژهها بین ۶ تا ۱۰ هفته. زمان دقیق به تعداد امکانات ضروری، نوع محصول و سرعت تصمیمگیری شما بستگی دارد. اگر برآورد از این بازه خیلی بیشتر شد، معمولاً نشانه این است که محدوده بزرگتر از یک MVP تعریف شده و باید دوباره امکانات را اولویتبندی کنید. نسخهای که مثلاً درگاه پرداخت یا چرخهٔ کامل سفارش دارد، دیگر MVP ساده نیست و در حد اپ متوسط، یعنی ۳ تا ۴ ماه است؛ جزئیاتش را در مقالهٔ زمان ساخت اپلیکیشن آوردهایم.
هزینه ساخت MVP چقدر است؟
عدد ثابتی وجود ندارد، چون هزینه به تعداد و پیچیدگی امکانات، نیاز به اپ موبایل یا وب، سطح طراحی و اتصال به سرویس‌های بیرونی مثل درگاه پرداخت بستگی دارد. برای برآورد اولیه از ابزار محاسبه هزینه ساخت اپلیکیشن در سایت تکنوراه استفاده کنید و برای عدد دقیق‌تر، فهرست امکانات ضروری را در یک جلسه مشاوره با ما مرور کنید.
آیا MVP فقط برای استارتاپهاست؟
نه. شرکتهای جاافتاده هم برای آزمودن یک محصول جدید، ورود به بازار تازه یا ساخت نرمافزار داخلی از همین روش استفاده میکنند. هر جا عدمقطعیت بالاست و نمیدانید کاربران چه واکنشی نشان میدهند، شروع با یک نسخه کوچک و سنجیدن نتیجه، از سرمایهگذاری یکباره روی نسخه کامل کمخطرتر است.
MVP در برنامهنویسی یعنی چه؟ کدش بعداً دور ریخته میشود؟
در برنامهنویسی، MVP اولین نسخهٔ نرمافزار است که فقط کارکرد اصلی را دارد، ولی با کد تمیز و قابل توسعه ساخته میشود. پس کدش لزوماً دور ریخته نمیشود: اگر معماری درست باشد، پایهٔ نسخههای بعدی میشود و فقط بخشهایی بهمرور بازنویسی میشود. دورریختن کامل معمولاً وقتی پیش میآید که نسخهٔ اول با عجله و بدون ساختار نوشته شده باشد.
فرق MVP با نسخهٔ بتا چیست؟
MVP میسنجد که آیا بازار اصلاً این محصول را میخواهد. نسخهٔ بتا معمولاً محصولی تقریباً کامل است که پیش از انتشار عمومی، کیفیت و خطاهایش با گروهی از کاربران سنجیده میشود. MVP دربارهٔ «چه بسازیم» است و بتا دربارهٔ «درست ساختهایم یا نه».