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