این فصل یک ایده‌ی کم ارزش‌دهی‌شده اما مشهور را بررسی می‌کند که در کتاب The Lean Startup اثر Eric Ries مطرح شده است. ایده این است که یک کمینه محصول پذیرفتنی (Minimum Viable Product) بسازید. MVP یک نسخه از محصول شما است که فقط شامل ضروری‌ترین فیچر محصول است. با این کار می‌توانید فرضیه‌های خود را آزمایش و اعتبارسنجی کنید، بدون اینکه زمان زیادی را صرف پیادهسازی فیچرهایی بکنید که کاربران شما ممکن است از آن‌ها استفاده نکنند. یاد می‌گیرید که چگونه با تمرکز بر روی فیچرهایی که می‌دانید کاربران شما می‌خواهند، از پیچیدگی در فرآیند توسعه‌ی نرم‌افزار کم کنید. در این فصل MVPها را با نگاه کردن به تله‌هایی که توسعه‌ی نرم‌افزار بدون استفاده از MVPها دارد، معرفی می‌کنیم.
دقت کنید که این مطلب ترجمه‌ی خط به خط کتاب نیست و فقط قسمت‌های مهم آن آورده شده است.
ایده‌ی پشت MVP این است که با مشکل‌هایی که به هنگام برنامه‌نویسی در حالت مخفی‌کاری رخ می‌دهد، مقابله کنیم. حالت مخفی‌کاری موقعی است که شما بر روی پروژه‌ای کار می‌کنید تا به اتمام برسد، بدون اینکه از کاربران فیدبکی دریافت کنید. فرض کنید به یک ایده‌ی فوق العاده رسیده‌اید که دنیا را تغییر می‌دهد: یک موتور جستجوی مبتنی بر ماشین لرنینگ که مناسب جستجوی کد است. به مدت چند شب با اشتیاق به برنامه‌نویسی می‌پردازید.
اما در عمل، نوشتن یکباره‌ی برنامه بسیار بسیار به ندرت به موفقیت منجر می‌شود. اینجا یک نتیجه‌ی محتمل برنامه‌نویسی در حالت مخفی‌کاری را می‌خوانیم:
سریع نسخه‌ی اولیه را توسعه دادید، اما وقتی موتور جستجوی خود را امتحان می‌کنید، می‌بینید که بسیاری از نتایج نشان داده شده اصلا مرتبط نیستند. وقتی درباره‌ی Quicksort جستجو انجام می‌دهید، در نتیجه یک کد MergeSort نشان داده می‌شود که این کامنت را دارد: # این کد Quicksort نیست.
این درست نیست. پس مدل را تنظیم می‌کنید اما هر بار که نتایج را برای یک کلمه بهتر می‌کنید، مشکلات جدیدی را برای دیگر نتایج جستجو ایجاد می‌کنید. هیچ وقت کامل از نتیجه راضی نیستید و فکر می‌کنید که نمی‌توانید کد خود را به دنیا معرفی کنید. به ۳ دلیل:
این افکار باعث می‌شوند که امید و انگیزه را از دست بدهید و پیشرفت شما بر روی این پروژه صفر خواهد شد.
این شکل نشان می‌دهد که در حالت مخفی‌کاری، چه اتفاق‌هایی بدی می‌تواند بیفتد:
اینجا ۶ مورد از تله‌هایی که کار کردن در حالت مخفی‌کاری دارد را بررسی می‌کنیم.
در حالت مخفی‌کاری، شما با ایده‌ی خود تنها هستید و شک‌ها به صورت منظم ظاهر می‌شوند. ابتدا در برابر شک‌ها مقابله می‌کنید چون اشتیاق اولیه‌ی شما برای پروژه به اندازه کافی بزرگ است اما هر چقدر بیشتر روی پروژه وقت می‌گذارید، شک‌های شما بزرگ‌تر می‌شوند.
در مقابل اگر یک ورژن اولیه از ابزارتان را منتشر کنید، جملات تشویق کننده از یک کاربر اولیه می‌تواند به شما انگیزه کافی بدهد تا ادامه دهید و فیدبک از کاربران می‌تواند به شما الهام ببخشد که ابزار را بهبود ببخشید و بر مشکلات غلبه کنید. شما انگیزه‌ی خارجی دارید.
وقتی در حالت مخفی‌کار به تنهایی کار می‌کنید، به سختی می‌توان از حواس‌پرتی‌های روزانه صرف نظر کرد. هر چقدر بیشتر در این حالت باشید، احتمال پرت شدن حواس قبل از تمام شدن پروژه نیز بیشتر می‌شود.
یک MVP می‌تواند با کم کردن زمان بین ایده و مارکت، و ساخت یک محیط که در آن سریع فیدبک دریافت می‌شود، از پرت شدن حواس جلوگیری کند و کمک می‌کند دوباره متمرکز شوید.
یک دشمن قدرتمند دیگر تمام کردن پروژه، برنامه‌ریزی معیوب است. فرض کنید پیش‌بینی کرده‌اید که محصول شما به 60 ساعت زمان برای تمام شدن احتیاج دارد. پس برنامه‌ریزی می‌کنید که روزانه 2 ساعت به مدت یک ماه کار کنید. اما به دلیل از بین رفتن انگیزه و حواس‌پرتی، به طور میانگین روزانه 1 ساعت کار می‌کنید. تاخیر های بعدی بخاطر تحقیقاتی که باید انجام دهید، باگ‌ها و اتفاقات غیرمنتظره‌ای که با آن‌ها روبرو می‌شوید، رخ می‌دهند.
بی‌نهایت دلیل برای زیاد شدن وقت پروژه و تعداد کمی دلیل برای کم شدن وقت آن وجود دارند. در پایان اولین ماه، اصلا به چیزی که برنامه‌ریزی کرده بودید نرسیدید و دوباره به حلقه‌ی از بین رفتن انگیزه باز می‌گردید.
یک MVP فقط شامل فیچرهای ضروری است. پس اشتباه‌های برنامه‌ی شما کمتر خواهد بود و پیشرفت شما قابل پیش‌بینی‌تر می‌شود. داشتن فیچرهای کمتر یعنی چیزهای کمتری ممکن است بد پیش برود و افراد بیشتری به موفقیت پروژه‌ی شما امیدوار خواهند بود. سرمایه‌گذاران عاشق قابل پیش‌بینی بودن هستند.
فرض کنیم شما بر نبود انگیزه غلبه کرده‌اید و محصول را به پایان رسانده‌اید. محصول را لانچ می‌کنید و هیچ اتفاقی نمی‌افتد. فقط تعداد کمی از کاربران آن را چک می‌کنند که آن‌ها هم ذوق و شوقی درباره‌ی آن ندارند. محتمل‌ترین اتفاق برای یک محصول نرم‌افزاری سکوت است؛ نبود فیدبک مثبت و منفی. یک دلیل رایج این است که محصول شما ارزش مخصوصی را که کاربر می‌خواهد، ارائه نمی‌دهد. در بار اول نمی‌توان محصولی را ساخت که مناسب مارکت باشد. اگر حین توسعه، فیدبکی از دنیای واقعی دریافت نکنید، از واقعیت دور خواهید شد و فیچرهایی تولید خواهید که کسی استفاده نخواهد کرد.
یک MVP کمک می‌کند تا محصول مناسب مارکت را زودتر پیدا کنید.
علت اصلی شکست در حالت مخفی‌کاری، مفروضات شماست. یک پروژه را با یک سری مفروضات شروع می‌کنید، مثلا کاربران چه کسانی خواهند بود و چقدر از محصول شما استفاده خواهند کرد. این مفروضات اغلب غلط هستند و بدون آزمایش خارجی، کورکورانه محصولی را تولید خواهید کرد که مخاطب واقعی شما آن را نمی‌خواهد.
فرض کنید یک محصول تولید کردید که شامل 4 فیچر است. شانس آورده‌اید و مارکت آن را قبول کرده است. زمان قابل توجهی را صرف پیادهسازی آن فیچرها کرده‌اید و فیدبک مثبت از کاربران دریافت می‌کنید. تمام نسخه‌های بعدی محصول شامل آن 4 فیچر + فیچرهای جدید خواهد بود.
اما با منتشر کردن 4 فیچر به یکباره، به جای منتشر کردن 1 یا 2 فیچر در هر بار، نمی‌دانید که آیا مارکت زیرمجموعه‌ای از فیچرها را قبول یا حتی ترجیح می‌دهد یا نه.
فیچر 1 ممکن است کاملا نامربوط باشد، اگر چه بیشترین زمان را از شما گرفته است. فیچر 4 ممکن است بسیار با ارزش باشد و مارکت آن را بخواهد. با داشتن n فیچر، 2 به توان n حالت مختلف برای فیچرهای محصول وجود دارد. اگر همه‌ی آن‌ها را با هم منتشر کنید، چطور می‌توانید بفهمید که کدام فیچر با ارزش و کدام وقت تلف کردن است؟
هزینه‌ی پیادهسازی فیچرهای غلط، به خودی خود بالا است. منتشر کردن چند فیچر غلط، هزینه‌ی تجمعی نگه‌داری از این فیچرهای غیرضروری را نیز تحمیل می‌کند:
پس اگر احتمال موفقیت برنامه‌نویسی در حالت مخفی کاری کم است، راه حل چیست ؟
راه حل ساده است: دنباله‌ای از MVPها بسازید. یک فرضیه‌ی شفاف بنویسید؛ مثلا کاربران از حل پازل‌های پایتون لذت می‌برند و یک محصول بسازید که فقط این فرضیه را اعتبارسنجی کند. تمام فیچرهایی که به اعتبارسنجی این فرضیه کمک نمی‌کنند، حذف کنید. یک MVP بر اساس این فیچر بسازید. با پیادهسازی تنها یک فیچر در هر انتشار، بیشتر می‌فهمید که مارکت چه فیچرهایی می‌خواهد و کدام فرضیه‌ها درست هستند. اما به هر قیمتی، از پیچیدگی دوری کنید. وقتی MVP را در دنیای واقعی آزمایش کردید، MVP دوم را می‌توانید بسازید که مهم‌ترین فیچر بعدی را اضافه می‌کند. اصطلاحی که برای توصیف این استراتژی که در آن محصول مناسب از طریق یک سری MVP جستجو می‌شود، نمونه‌سازی سریع (rapid prototyping) نام دارد. هر نمونه‌ی اولیه بر اساس چیزهایی است که از لانچ‌های قبلی یاد گرفته‌اید و هر کدام به گونه‌ای طراحی شده‌اند که حداکثر یادگیری را در حداقل زمان و با حداقل تلاش برای شما به ارمغان بیاورد.
در این شکل این استاندارد طلایی توسعه‌ی نرم‌افزار و خلق محصول را می‌بینیم.
ابتدا، یک محصول مناسب مارکت را با لانچ مرتب MVP ها پیدا می‌کنیم. لانچ زنجیره‌ای MVPها در طول زمان، علاقه ایجاد می‌کند و به شما اجازه می‌دهد که از فیدبک کاربران استفاده کنید و ایده‌ی اصلی نرم‌افزار خود را بهبود ببخشید. وقتی به محصول مناسب مارکت رسیدید، فیچرهای جدید اضافه می‌کنید. تنها فیچرهایی در محصول باقی می‌مانند که معیارهای کلیدی کاربران را بهبود می‌دهند.
در کتاب The Lean Startup می‌خوانیم که چطور شرکت میلیون دلاری Dropbox از رویکرد MVP استفاده کرده است. به جای صرف زمان و تلاش بر روی یک ایده‌ی آزمایش نشده برای پیادهسازی عملکرد پیچیده‌ی Dropbox در سینک کردن فولدرها در cloud، سازنده‌ها این ایده را با یک ویدئوی ساده از محصول اعتبارسنجی کردند، اگرچه که محصول داخل ویدئو هنوز وجود نداشت.
اگر مارکت به شما بگوید که کاربران ایده‌ی محصول شما را دوست دارند، شما با یک MVP ساده به یک محصول مناسب مارکت رسیده‌اید.
وقتی از رویکرد مبتنی بر MVP برای توسعه‌ی نرم‌افزار استفاده می‌کنید، مهم است که بدانید کدام فیچرها را نگه دارید و کدام‌ها را رد کنید. در ساخت نرم‌افزار با روش MVP، آخرین قدم Split Testing نام دارد. به جای اینکه هر نسخه از نرم‌افزار را برای تمام کاربران منتشر کنیم، محصول جدید را فقط برای کسری از کاربران منتشر می‌کنیم و به پاسخ‌ها توجه می‌کنیم. تنها در صورتی یک فیچر را نگه می‌دارید که از چیزی که می‌بینید راضی هستید؛ مثلا میانگین زمانی که کاربران در سایت شما سپری کردند، افزایش یافته است. در غیر این صورت آن فیچر را رد می‌کنید. این یعنی زمان و انرژی‌ای را که صرف آن فیچر کردید، باید فدا کنید اما این کار به شما اجازه می‌دهد که محصول خود را تا جای ممکن ساده نگه دارید.
وقتی بر اساس تفکر MVP اولین نرم‌افزار خود را می‌سازید، این ۴ پایه‌ی اصلی را در نظر داشته باشید:
عملکرد: محصول باید یک عملکرد واضح فرموله‌شده را برای کاربر فراهم کند و این کار را هم باید به خوبی انجام دهد.
طراحی: محصول به خوبی طراحی شده است و تمرکز دارد. طراحی آن از ارزشی پشتیبانی می‌کند که محصول شما برای کاربر فراهم می‌کند.
قابلیت اطمینان: اینکه محصول شما کمینه است به این معنی نیست که به آن نمی‌توان اطمینان کرد. مطمئن شوید که تست کیس نوشته‌اید و تمام عملکردها در کد شما آزمایش می‌شوند.
قابلیت استفاده: استفاده از MVP باید آسان باشد. کاربران نباید زمان زیادی را صرف فهمیدن نحوه‌ی کارکرد نرم‌افزار بکنند.
بسیاری از افراد فیچرهای MVP را اشتباه درک می‌کنند؛ آن‌ها فکر می‌کنند چون MVP یک نسخه‌ی مینیمال از محصول است پس باید در طراحی آن تنبلی کنند، محصول ارزش کمی تولید کند و به سختی بتوان از آن استفاده کرد. اما یک مینیمالیست می‌داند که خلاصه بودن MVP از روی تنبلی نیست بلکه بخاطر این است که تمرکز خود را روی یک عملکرد اصلی می‌گذاریم.
یک ضد استدلال رایج که در مقابل Rapid Prototyping استفاده می‌شود این است که برنامه‌نویسی مخفی‌کاری از ایده‌های شما محافظت می‌کند. مردم فکر می‌کنند که ایده‌های آن‌ها به قدری خاص و یکتا است که اگر آن را به صورت خام و به شکل MVP منتشر کنند، شرکت‌های بزرگ‌تر و قدرتمندتر آن را می‌دزدند و خیلی سریع‌تر آن را پیادهسازی می‌کنند. صادقانه بگویم، این یک اشتباه است. ایده‌ها ارزان هستند، این اجرای ایده‌ها است که اهمیت دارند. بعید است که یک ایده منحصر به فرد باشد، و یک احتمال قوی وجود دارد که همین الان شخص دیگری ایده‌ی شما را در ذهن دارد. برنامه‌نویسی در حالت مخفی‌کاری، به جای کم کردن رقابت، حتی شاید دیگران را تشویق کند که بر روی همان ایده کار کنند، چون همانند شما، آن‌ها هم فکر می‌کنند که آن ایده به ذهن کسی نرسیده است. برای اینکه یک ایده موفق شود، یک شخص باید آن را به واقعیت بیاورد. شخصی موفق می‌شود که سریع اقدام می‌کند، یک نسخه‌ی اولیه منتشر می‌کند، از کاربران واقعی فیدبک دریافت می‌کند و مدام محصول خود را بهبود می‌بخشد. با مخفی نگه داشتن ایده صرفا پتانسیل رشد آن را محدود می‌کنیم.
