MVP چیست، چرا، چگونه!؟

هر زمان که قرار است پروژه جدیدی استارت بخورد یک نگرانی عمده وجود دارد : ”دقیقن چه چیزی باید ساخته شود!؟ ”اینکه محصول(یا سرویس) را به سریعترین شکل ممکن به دست کاربر واقعی(مارکت) برسانیم و با تکرارها و تصحیح‌هایی که بر اساس فیدبک(نظرات و نیازها) کاربران انجام میپذیرد(نه بر اساس تخیلات و حدسیات) یک محصول واقعن خوب بسازیم، ایده‌ای است که پشت MVP نشسته است. ما همه قبول داریم که هیچ تولیدکننده‌ای دوست ندارد محصولی ناقص(غیرکامل) را روانه بازار کند. پس چرا از Minimum Viable Product دفاع میکنیم؟ جواب ساده به این سوال این است که نباید زمان(ارزشمند) و منابع را بر روی ساخت چیزهایی صرف(یا حتی هدر) کرد که مشخص نیست کاربردی و مناسب هستند یا نه. از طرف دیگر هیچ محصولی(سرویسی) نیست که نتوان قابلیت دیگری به آن افزود و این داستان اضافه کردن قابلیت‌ها و امکانات پایانی ندارد. از طرف دیگر هیچ مشتری دوست ندارد که محصول(سرویس) ناکاملی را بخرد یا با آن سروکله بزند، پس چرا حاضر است MVP ما را تست کند(یا بخرد)؟ توجه داشته باشید که مشتری‌های ما در این فاز، مشتری محصول ما نیستند، بلکه مشتری دیدگاه(vision) ما هستند. این مشتری‌ها که استیو بلنک آنها را Earlyvangelists می‌خواند، ریسک استفاده از محصول یا سرویس ناکامل ما را پذیرفته‌اند. معمولن مشخصه این افراد چنین است:

  • آنها (حداقل) یک نیاز(مشکل) دارند.
  • آنها متوجه این نیازشان هستند.
  • آنها پیوسته به دنبال راه‌حل هستند.
  • آنها حاضر هستند به هر شکل(حتی موقت) مشکلشان را حل کنند، چون مشکلی آزار دهنده است.
  • آنها حاضرند بابت حل شدن مشکل هزینه کنند.

مشتریان اولیه ما باید از محصول یا سرویس ما لذت ببرند. این باعث می‌شود اشکالات و کم‌و‌کاستی‌های محصول را در این شرایط بپذیرند. محصول ما احتمالن باگ خواهد داشت، اطلاعات کاربران ممکن است از دست برود و … .پس باید مطمئن شویم با این مشتریان خوب برخورد میکنیم و نیازهای آنها را درک می‌کنیم. سعی کنیم با داشتن یک نقشه‌راه شفاف به آنها نشان دهیم که دیدگاه ما ارزش خریده شدن دارد. Minimum Viable Product به خوبی مفهوم مورد نظر خودش را می‌رساند. اما سوالی که مطرح می‌شود این است که کجا باید توقف کرد؟ حداقل امکاناتی که موردنیاز است چیست و چگونه مشخص می‌شود؟ کدام امکانات اساسی هستند و  باید در MVP حضور داشته باشند؟ جواب دادن به  این سوالات و سوالات مشابه واقعن سخت(یا شاید نشدنی) است، اما چند توصیه وجود دارد که میتواند در پاسخ به این سوالات راه‌گشا باشد:

  1. محصول یا سرویس باید ظاهر و حس یک محصول کامل و تمام شده را منتقل کند. محصول کامل طراحی شده باشد. باگ نداشته باشد. و هر چیزی که قابل مشاهده است(اعم از باتن‌ها، لینک‌ها و …) به درستی کار کند. همچنان در MVP نیز اولین تاثیر و ایجاد حس خوب در کاربر خیلی مهم است.
  2. کارکرد(هدف)های اصلی محصول باید به درستی کار کند. اگر محصول ما یک اپ موبایل اشتراک گذاری تصاویر است، باید قابلیت به اشتراک گذاری داشته باشد، اما نبود سرچ یا تگ‌گذاری عکس‌ها مسئله خاصی ایجاد نمی‌کند.
  3. اگر واقع بین باشیم، احتمال اینکه در یکی دو ماه اول ریلیز، کاربران ما تعداد زیادی باشند خیلی کم است. این فرصت خوبی است تا یک سری از پیچیدگی‌های فنی را کم کنیم. مثلن به جای طراحی یک فرم ارسال ایمیل و … برای ارتباط کاربران با ما و یک فرم دریافت فیدبک و … کافی است در یک بخش از اپ، ایمیل خود را بنویسیم و از کاربران بخواهیم با ما تماس بگیرند.
  4. تغییر قابلیت‌های فعلی و اضافه کردن قابلیت‌های جدید باید به شکلی ساده انجام بپذیرد. زمانی که فلسفه وجودی MVP را درک کنیم، حتمن می‌پذیریم که به سرعت باید به نظرات کاربران واکنش نشان دهیم و با توجه به رفتار آنها برنامه را توسعه دهیم. پس همیشه در نظر داشته باشیم که به گونه‌ای عمل کنیم که راه توسعه محصول در هر جهت باز باشد و به سرعت انجام پذیرد.همواره در این مسیر اشتباهاتی وجود دارد، آنها را بپذیریم و به این روند ادامه دهیم.
  1. اگر از ساختمان بیرون بزنیم و از هر مشتری احتمالی بپرسیم به ازای چه مشخصات و آپشن‌هایی در برنامه حاضر است به ما پول بدهد، احتمالن به ازای ده مشتری ده صفحه امکانات لیست شده داریم! این اشتباه است. ما باید به یک پاراگراف از نیازمندی برسیم که هزاران نفر بابت حل شدن آن مشتری ما می‌شوند.نکته‌ای که حتما باید به آن توجه کرد این است که MVP نباید تجربه‌کاربری محصول یا سرویس ما را خراب کند. ممکن است ما بر سر اینکه قابلیت ‘ریست پسورد’ را در نسخه MVP داشته باشیم یا نه بحث کنیم. اما اگر تصمیم گرفتیم این قابلیت را اضافه کنیم باید مطمئن باشیم که استانداردها(شامل استانداردهای UX و نه محدود به آن) را به خوبی رعایت کرده‌‌ایم. امکانات محصول می‌توانند پیچیدگی‌های متفاوتی داشته باشند. به طور مثال سیستم ریست پسورد می‌تواند شامل ۲ مرحله امنیتی باشد و سیستم لاگین فقط ۱ مرحله داشته باشد. اما کیفیت تجربه‌کاربری همه اینها باید یکسان باشد.
    اگر به این مبحث علاقه‌مند هستید پیشنهاد میکنم این ویدیوها را با دقت ببینید:

Minimum Viable Product - #leanstartup
Minimum viable product: Aardvark 1-2-3
Creating Your Minimum Viable Product

منابع
How to Build an App and Minimum Viable Product (MVP)
Perfection By Subtraction – The Minimum Feature Set
What happens to user experience in a minimum viable product?