محصول حداقلیِ قابل دوام (MVP) برای هر کسی که در سال ۲۰۲۶ با یک پلتفرم هوش مصنوعی میسازد، توصیهٔ بدی است. نه دقیقاً توصیهٔ اشتباه — توصیهای از دنیایی که دیگر وجود ندارد، اما همچنان تکرار میشود چون قافیه دارد و روی یک اسلاید جا میشود.
اریک ریس ایدهٔ MVP را در سال ۲۰۱۱ برای تیمهایی نوشت که گلوگاهشان ساعتکاریِ مهندسان بود. اگر ساختن یک قابلیت سه هفته طول میکشید و مطمئن نبودید کسی آن را میخواهد، کوچککردنِ دامنه تنها اقدام منطقی بود — داشتید منبعی واقعاً کمیاب را جیرهبندی میکردید. همین محدودیت بود که کلمهٔ «حداقل» در آن عبارت را معنادار میکرد. این یک فلسفه دربارهٔ سلیقهٔ محصول نبود. این جیرهبندی تحت یک ساختار هزینه بود که در آن ساختن گران بود و فهمیدنِ نتیجه فقط در صورتی ارزان بود که ابتدا کمتر میساختید.
ساختار هزینه معکوس شد
وقتی از طریق یک خط لولهٔ گفتوگو-به-برنامه-به-اجرا میسازید بهجای یک تختهٔ اسپرینت، قابلیتِ حاشیهای دیگر سه هفته هزینه ندارد. یک پرامپت و یک دور بررسی هزینه دارد. چیزی که قبلاً گران بود — نوشتن کد — حالا تقریباً رایگان است. چیزی که هنوز واقعاً گران است، فهمیدن اینکه چه باید ساخت، و استخراجِ سیگنال از رفتار پرنوفزِ کاربران پس از انتشار است. نظریهٔ MVP برای محدودیت اول بهینه شده بود. تقریباً هیچکس که روی یک پلتفرم هوش مصنوعی میسازد دیگر با آن گلوگاه مواجه نیست.
پس وقتی یک بنیانگذار یک صفحهٔ ورود و یک قابلیت را عرضه میکند و آن را MVP مینامد «تا سریع یاد بگیرد»، معمولاً چیزی را جیرهبندی نمیکند. دارد با الگوی توصیهای که برای اقتصادی دیگر معنا داشت تطبیق پیدا میکند، و در این فرآیند، چیزی خیلی نازک عرضه میکند که سیگنال واقعی تولید نمیکند. پنج نفر یک اپ تکقابلیتی را امتحان میکنند، سه نفر فوراً میروند، و شما تقریباً چیزی یاد نگرفتهاید جز اینکه یک اپ لخت، لخت به نظر میرسد. این ناب نیست. این فقط کوچک است.
| محدودیت سال ۲۰۱۱ | محدودیت سال ۲۰۲۶ (سازندهٔ هوش مصنوعی) | |
|---|---|---|
| منبع کمیاب | ساعتکاریِ مهندسان برای نوشتن و تست کد | زمان برای تعیین دامنهٔ درست و خواندن نتایج |
| هزینهٔ حاشیهای قابلیت | چند روز تا چند هفته | یک چرخهٔ ساخت، تقریباً چند دقیقه تا چند ساعت |
| ریسک ساختنِ بیش از حد | بالا — هزینهٔ ازدسترفته در صورت اشتباه | پایین — هزینهٔ حذف یا بازسازی تقریباً همان هزینهٔ افزودن است |
| ریسک ساختنِ خیلی کم | پایین — در اسپرینت بعدی دوباره عرضه میکنید | بالا — اپهای نازک، سیگنال نازک و مبهم تولید میکنند |
| «حداقل» از چه چیزی محافظت میکرد | زمان تیم شما | دیگر هیچچیز — حالا هزینهاش را از جیب کیفیت دادههایتان میپردازید |
آن سطر آخر را دوباره بخوانید. کل توجیه مینیمالیسم این بود که از منبعی محافظت کنید که در حال حاضر برای شما کمیاب نیست. شما دارید هزینهی قانون قدیمی را میپردازید — سطح تست نازکتر، سیگنال نگهداشت ضعیفتر، کاربرانی که به این دلیل میروند که اپلیکیشن ناتمام بهنظر میرسیده نه به این دلیل که ایده بد بوده — بدون اینکه فایدهای را که آن قانون قبلاً برایتان میخرید، به دست بیاورید.
منظور واقعی از «گستردهتر بسازید» چیست
منظورم این نیست که هر چیزی را که در تصورتان میگنجد بسازید. منظورم این است که پیش از رفتن به دنبال کاربران، شکل کامل و بدیهیِ محصول را بسازید — فرایند آنبوردینگ، حلقهی اصلی، آن یک ویژگی مکمل که همه در دستهی شما دارند، صفحهی تنظیماتی که حس نرمافزار واقعی میدهد نه یک نمونهی اولیه. اگر دارید یک ابزار ردیابی عادت میسازید، یعنی رشتهی روزها، یادآوریها و نمای تاریخچه، نه فقط رشتهی روزها بهتنهایی. اگر دارید یک بازارچهی نیچ میسازید، یعنی آگهیها، پیامرسانی و یک سیگنال اعتماد (نظرات، تأیید هویت، یا چیزی مشابه)، نه فقط آگهی با یک فرم تماس ساده.
معیار این نیست که «چقدر میتوانم این را کوچک کنم». معیار این است که «کوچکترین نسخهای که یک غریبه آن را با یک محصول تمامشده اشتباه بگیرد چیست؟» این معیار متفاوتی است و معمولاً سه یا چهار ویژگی میطلبد، نه یک ویژگی. در پلتفرمی که هر یک از این ویژگیها یک مرحلهی برنامهریزی و یک بار بررسی است نه یک تصمیم استخدام، رسیدن به این معیار در هفتهی اول واقعبینانه است، طوری که در سال ۲۰۱۱ بههیچوجه نبود.
یک نسخه از این ماجرا هست که خودم زودتر از آن ضربه خوردم. یک ابزار کوچک برای استودیوی یک دوست ساختم — یک صفحه، یک کار، سریع تمام شده، بسیار مینیمال. هیچکس از آن استفاده نکرد و به خودم گفتم این حرف بازار است. نبود. مسئله این بود که این ابزار در کنار سه تبی که بقیهی گردشکارشان داشت، ناتمام بهنظر میرسید، پس هیچکس به آن اندازهی کافی اعتماد نکرد که آن را عادت خودش کند. ایده مشکلی نداشت. شکلِ محصول شکستخورده بود، و من دقیقاً به این دلیل نازک عرضه کرده بودم که فکر میکردم نازک بودن فضیلت است.
جایی که منتقدان حق دارند
کسانی که با این حرف مخالفت میکنند نکتهی درستی دارند، البته نه دربارهی هزینهی مهندسی — بلکه دربارهی توجه است. ساختن پنج ویژگی دیگر هزینهی هفتههای توسعهدهنده را از شما نمیگیرد، اما همچنان هزینهی هفتههای تصمیمگیری میگیرد و هزینهی درک را از کاربرانتان میگیرد. نسخهی اول گستردهتر یعنی سطح بیشتری برای بررسی، جاهای بیشتری برای پنهان شدن باگ، آنبوردینگ بیشتری برای نوشتن، و چیزهای بیشتری که کاربر جدید باید یاد بگیرد تا حلقهی اصلی برایش جا بیفتد. اگر گسترده بسازید و حلقهی اصلی اشتباه از آب دربیاید، حالا سیگنالتان را در پنج ویژگی بهجای یک ویژگی گیج کردهاید، و باز کردن اینکه کدامیک نگهداشت را کشته زمان بیشتری از یک تست تمیز و منفرد میبرد. انضباط در دامنه هنوز اهمیت دارد — فقط حالا هدفش تغییر کرده است. حداقلِ محصولِ قدیمی زمان ساخت شما را منضبط میکرد. نسخهای که با این اقتصاد جدید سازگار است، زمان تصمیمگیری شما را منضبط میکند: تعداد محدودی ویژگی را انتخاب کنید که محصول را واقعی جلوه دهد، هر چیز فراتر از آن را بیرحمانه حذف کنید و در برابر وسوسهی افزودن مداوم فقط به این دلیل که ارزان است، مقاومت کنید. ارزان بودن ساخت به معنای رایگان بودن نگهداری، توضیح دادن، یا استدلال کردن دربارهی آن هنگام خرابی نیست.
پس گستردهتر از آنچه غریزهتان میگوید بسازید، چون محدودیتی که کلمهی «حداقل» را درست جلوه میداد دیگر وجود ندارد. اما آن انضباطی را که MVP را ایدهی خوبی میکرد حفظ کنید — فقط آن را بهجای نسخهی اول، به سمت افزایش دامنه پس از عرضه هدایت کنید.
