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