نکات کلیدی
- یک فرضیه، یک جریان و یک تصمیم مشخص برای دور بعد انتخاب کن.
- پاسشدن تست فنی، اثبات نیاز مشتری نیست.
- دامنه را کوچک کن؛ مسئولیت داده و دسترسی را حذف نکن.
- مصرف واقعی هر دور و معیار توقف را ثبت کن، نه هزینهٔ حدسی ثابت.
برای ساخت MVP با هوش مصنوعی، از یک فرضیه شروع کن، نه فهرست امکانات. کوچک‌ترین مسیری را انتخاب کن که بتوانی با مخاطب مناسب امتحانش کنی؛ قبل از ساخت هم بنویس چه نتیجه‌ای باعث ادامه، تغییر یا توقف می‌شود. هوش مصنوعی میتواند در ساخت نسخه کمک کند، اما جواب سؤال «آیا کسی به این راهحل نیاز دارد؟» را باید از مشاهدهٔ استفاده و بازخورد بگیری.
فرض کن می‌خواهی برای فروشنده‌های یک پیج، سایت ثبت سفارش بسازی. ایده زود بزرگ می‌شود: درگاه، پیامک، تخفیف، انبار و داشبورد. ولی شاید هنوز نمی‌دانی فروشنده اصلاً حاضر است سفارش را از دایرکت به این مسیر منتقل کند یا نه. نسخهٔ اول باید همین ابهام را کمتر کند.
در این راهنما با همان مسیر کوچک ثبت سفارش جلو می‌رویم: یک فرضیه، یک جریان و یک معیار پذیرش. در پایان، برگهٔ دامنه، آزمون، بازخورد و بودجه داری؛ نه یک وعدهٔ «محصول موفق در چند دقیقه».
اول فرضیه‌ای بنویس که بتوانی ردش کنی
«می‌خواهم یک فروشگاه با AI بسازم» توصیف ابزار است. یک فرضیهٔ مفید، مخاطب و مشکل را مشخص می‌کند: «فروشنده‌ای که سفارش را در چند پیام می‌گیرد، با جمع‌شدن اقلام و اطلاعات لازم در یک درخواست، کمتر به پرسیدن دوباره نیاز دارد.» این فرضیه هنوز درست فرض نشده است؛ باید آن را با فروشنده‌ای که چنین مشکلی دارد بررسی کنی.
قبل از ساخت، سه سؤال را جواب بده: چه کسی این مشکل را دارد؟ امروز چطور آن را حل می‌کند؟ چه رفتار قابل مشاهده‌ای می‌گوید مسیر پیشنهادی کمک کرده است؟ مثلاً ببین مالک میتواند با اطلاعات همان درخواست، اقدام بعدی را انجام دهد یا هنوز مجبور است اقلام را دوباره بپرسد.
از ابتدا در برگهٔ فرضیه و دامنه بنویس چه مشاهده‌ای نظرت را عوض می‌کند. تعداد گفتگوها و حد تصمیم را متناسب با آزمونت انتخاب کن؛ یک عدد ثابت، اثبات تناسب محصول و بازار نیست. اگر هنوز مشکل را نمی‌شناسی، گفتگو یا ارائهٔ دستی خدمت میتواند قبل از ساخت وب‌اپ به تو اطلاعات بدهد.
پروتوتایپ، MVP و محصول آمادهٔ استفاده را یکی نگیر
برای دیدن همهٔ ستون‌ها، جدول را افقی جابه‌جا کن.
| مرحله | سؤال اصلی | چه چیزی کافی نیست؟ |
|---|---|---|
| پروتوتایپ یا نمونهٔ اولیه | مخاطب مسیر را می‌فهمد؟ شکل راهحل مناسب است؟ | ظاهر خوب، اثبات ذخیره یا امنیت نیست |
| MVP برای یک آزمون مشخص | آیا همین نسخهٔ محدود، به مخاطب واقعی در مسئله‌اش کمک می‌کند؟ | پاسشدن تست فنی، بهتنهایی اعتبارسنجی تقاضا نیست |
| محصول قابل استفادهٔ عمومی | آیا استفاده، داده، دسترسی، خطا و پشتیبانی در شرایط واقعی قابل اتکاست؟ | برچسب MVP، مسئولیت داده و پرداخت را حذف نمی‌کند |
این مرزها به معنی سه پروژهٔ کاملاً جدا نیستند؛ راهی‌اند برای اینکه بدانی دربارهٔ چه چیزی مدرک داری. روش Lean Startup ساخت، اندازه‌گیری و یادگیری را یک چرخه می‌بیند. پس خروجی نسخهٔ اول فقط صفحه و کد نیست؛ باید چیزی دربارهٔ مسئله یا راهحل بفهمی.
پروندهٔ ما: یک درخواست سفارش، نه فروشگاه کامل
برای راهنمای ساخت سایت ثبت سفارش، یک نمونهٔ آموزشی محلی با سه کالای ساختگی داشتیم. این نمونه در تحریریه آماده شده؛ ضبط ساخت با موتور کُندا نیست. در ۷ آبان ۱۴۰۵، همان جریان را دوباره با دادهٔ غیرواقعی بررسی کردیم. این یک پروندهٔ داخلیِ نمونه‌سازی و بازبینی است؛ آزمایش با فروشنده یا مشتری واقعی انجام نشده است.
دامنه را روی یک مسیر بستیم: خریدار دو دفتر و یک لیوان انتخاب کند، درخواستش ثبت شود، مالک همان سفارش را ببیند و وضعیتش پس از بازکردن دوباره بماند. قیمت‌های تمرین ۱۸۰ هزار تومان برای دفتر و ۳۲۰ هزار تومان برای لیوان‌اند؛ با ۶۰ هزار تومان ارسال نمونه، جواب از قبل معلوم است: ۷۴۰ هزار تومان.
درگاه، پیامک، آپلود رسید، رزرو موجودی و ارسال کالا را کنار گذاشتیم. این‌ها برای همیشه بی‌اهمیت نیستند؛ فقط به سؤال محدود این بررسی کمک نمی‌کردند. ادعای «فروشگاه آمادهٔ فروش واقعی» هم نکردیم.
انتظار را قبل از دیدن نتیجه بنویس
معیار پذیرش فنی ما این بود: «یک درخواست ۷۴۰ هزار تومانی با اقلام درست، فقط یک بار ثبت شود؛ در حساب مجاز دیده شود و وضعیت مالک پس از بارگذاری مجدد باقی بماند.» این معیار را می‌توان بررسی کرد. عبارت «یک اپ حرفهای و روان» چنین امکانی نمی‌دهد.
برای دیدن همهٔ ستون‌ها، جدول را افقی جابه‌جا کن.
| بررسی | انتظار از قبل | مشاهده در نمونهٔ محلی |
|---|---|---|
| خطای ذخیرهٔ عمدی | سفارش تازه ساخته نشود | خطای شبیه‌سازی‌شده نمایش داده شد؛ رکوردی ایجاد نشد |
| ثبت موفق | دو دفتر، یک لیوان و ۷۴۰ هزار تومان | همان مبلغ و اقلام به پنل مالک رسید |
| بازکردن دوباره | همان شناسه و وضعیت برگردد | پس از تغییر به «در حال آماده‌سازی»، همان سفارش برگشت |
| حساب نامربوط و ارسال دوباره | سفارش دیگری افشا یا تکراری نشود | در آزمون مستقیم سرور محلی، دسترسی رد و درخواست تکراری به همان سفارش وصل شد |
| کم‌شدن رفت‌وبرگشت فروشنده | در استفادهٔ واقعی بررسی شود | هنوز سنجیده نشده است |
آزمون API در محیط جدا، ۲۵ بررسی مرتبط با دو نمونهٔ سفارش و گزارش را گذراند. این عدد به معنی ۲۵ کاربر، ۲۵ مشتری یا تأیید امنیت کل محصول نیست. نتیجهٔ مربوط به این جریان و محدودیت‌ها در دفتر شواهد آمده است.
نمای همان سفارش پیش از تغییر وضعیت را با تصویر پس از بازخوانی مقایسه کن؛ این تغییر وضعیت در یک جریان است، نه مدرک بهترشدن محصول برای مشتری.
پرامپت ساخت را از روی دامنه بنویس
حالا می‌توانی از هوش مصنوعی درخواست دقیق‌تری داشته باشی. هم مسیر اصلی را بگو، هم معیار نتیجه و چیزهایی را که فعلاً نمی‌خواهی. این پرامپت برای شروع پروژهٔ خودت پیشنهاد می‌شود؛ در این پرونده آن را به موتور ساخت نفرستادیم.
یک وب‌اپ فارسی دریافت درخواست سفارش بساز. فقط یک مسیر: مشتری کالا و تعداد را انتخاب کند، مبلغ را ببیند و درخواست ثبت کند؛ مدیر همان سفارش را ببیند و وضعیت را تغییر دهد. سه کالای ساختگی: دفتر ۱۸۰۰۰۰، کیف ۲۴۰۰۰۰ و لیوان ۳۲۰۰۰۰ تومان؛ ارسال نمونه ۶۰۰۰۰ تومان. دو دفتر و یک لیوان باید ۷۴۰۰۰۰ تومان شود. داده پس از بازکردن دوباره بماند؛ مشتری فقط سفارش خودش را ببیند و مجوزها روی سرور بررسی شوند. فرم ناقص، خطای ذخیره و درخواست تکراری را جدا مدیریت کن. درگاه، پیامک، رسید و انبارداری لازم نیست؛ بخش متصل‌نشده را آماده معرفی نکن.
اگر کار با کنترل‌های پنل را می‌خواهی یاد بگیری، آموزش وایب کدینگ در کُندا مسیر جداگانه‌ای دارد. کار این راهنما، انتخاب دامنه و تصمیم بعدی است. بعد از ساخت، برگهٔ پذیرش را با نتیجهٔ واقعی نسخهٔ خودت پر کن؛ به پاسخ «انجام شد» در گفتگو اکتفا نکن.
خطا را به سؤال تبدیل کن، نه درخواست امکانات بیشتر
در بازبینی، خطای ذخیره را عمداً فعال کردیم. پیام روشن گفت سفارش ساخته نشده است و اطلاعات واردشده در فرم ماند. این قطعی تصادفی شبکه نبود و داستان «باگ واقعی که AI حل کرد» از آن نمی‌سازیم. هدف، دیدن رفتار مورد انتظار هنگام شکست بود.
اگر نسخهٔ تو خطا دارد، اول کوچک‌ترین اقدام شکست‌خورده را بنویس: کدام حساب، کدام ورودی، چه انتظار و چه مشاهده‌ای؟ بعد یک اصلاح محدود بخواه. مثلاً: «در ارسال ناموفق، پیام موفقیت نشان نده؛ ورودی‌ها را نگه دار و امکان تلاش دوباره بده. جمع مبلغ و دسترسی سفارش‌ها تغییر نکند.»
تست نسخهٔ واقعی را به حالت موفق محدود نکن. فرم خالی، شکست ذخیره، بازکردن دوباره و حساب غیرمجاز بخشی از همان مسیر کوچک‌اند. دامنه را کوچک می‌کنی تا بررسی‌اش ممکن باشد، نه اینکه این مسئولیت‌ها را نادیده بگیری.
بازخوردی بگیر که تصمیم بعدی را عوض کند
در همین فرایند، بازخورد بازبینی تحریریه روشن بود: متن و تصویرهای اولیه، مسیر کار را به اندازهٔ کافی قابل فهم نشان نمی‌دادند. نسخهٔ راهنما از شرح‌های فنی پراکنده به روایت یک سفارش، قدم‌های مشتری و مدیر، و تصویرهای مرتبط بازنویسی شد. این بازخورد تحریریه بود، نه مصاحبهٔ مشتری و نه نتیجهٔ آزمون بازار.
برای دیدن همهٔ ستون‌ها، جدول را افقی جابه‌جا کن.
| قبل از بازبینی | تغییر انجام‌شده | چیزی که هنوز نمی‌دانیم |
|---|---|---|
| تأکید زیاد بر جزئیات فنی و نماهای پراکنده | توضیح همان سفارش از انتخاب تا پیگیری | آیا فروشندهٔ واقعی بدون کمک میتواند از نسخه استفاده کند؟ |
| مخلوط‌شدن ظاهر نمونه و نتیجهٔ فنی | جداکردن تصویر نمایشی، آزمون محلی و ادعای آماده‌بودن | آیا مسیر، رفت‌وبرگشت پیام‌ها را واقعاً کمتر می‌کند؟ |
برای آزمون بعدی، به مخاطب مناسب یک کار بده: «این سفارش آزمایشی را ثبت کن» یا «ببین اقدام بعدی برای این درخواست چیست». قبل از توضیح‌دادن، ببین کجا مکث می‌کند و چه چیزی را اشتباه می‌فهمد. از «خوب بود؟» به تنهایی تصمیم نگیر. در برگهٔ بازخورد و تصمیم مشاهده را از تفسیر جدا ثبت کن.
اگر کاربر مسیر را نمی‌فهمد، اول همان مرحله را اصلاح کن. اگر کار را انجام میدهد اما نیازی به استفادهٔ دوباره ندارد، افزودن نمودار یا پیامک لزوماً مسئله را حل نمی‌کند. راهنمای YC دربارهٔ آزمودن ایده هم بر مسئله، مخاطب مناسب و آمادگی برای تغییر راهحل تأکید دارد.
سقف زمان و هزینه را قبل از دور بعد مشخص کن
بودجه را فقط با هزینهٔ ساخت اول نسنج. برای هر دور، هدف تغییر، زمان بررسی، مصرف اعتبار ثبت‌شده در حساب، سرویس بیرونی و نتیجه را یادداشت کن. در این پرونده اجرای موتور کُندا نداشتیم؛ پس از آزمون محلی، عددی برای هزینه یا سرعت ساخت با کُندا استخراج نمی‌کنیم.
دفتر بودجهٔ قابل تکمیل عمداً عدد تخمینی فروش یا اعتبار ندارد. سقف هر دور را خودت متناسب با کاری که می‌خواهی یاد بگیری تعیین کن. اگر دربارهٔ اجزای هزینه تصمیم می‌گیری، راهنمای هزینهٔ ساخت اپ با هوش مصنوعی را ببین.
برای دیدن همهٔ ستون‌ها، جدول را افقی جابه‌جا کن.
| وضعیت | تصمیم پیشنهادی برای دور بعد |
|---|---|
| معیار فنی رد شده است | همان مشکل را محدود اصلاح و دوباره بررسی کن |
| معیار فنی پاس شده؛ ارزش برای مخاطب هنوز معلوم نیست | سراغ مشاهدهٔ استفاده برو، نه فهرست امکانات تازه |
| یک مانع روشن در همان جریان دیده شده | فقط تغییر لازم برای رفع همان مانع را بساز |
| سقف توافقشده تمام شده و یادگیری تازه‌ای نداری | توقف کن؛ فرضیه، مخاطب یا روش آزمون را بازنگری کن |
| داده، دسترسی یا پرداخت قابل اتکا نیست | آن بخش را آماده معرفی نکن و انتشار عمومی را عقب بینداز |
قدم بعد: یک تصمیم بهتر، نه یک نسخهٔ شلوغ‌تر
قبل از درخواست بعدی، این جمله را کامل کن: «برای این مخاطب، این مسیر را می‌سازم تا این رفتار را مشاهده کنم؛ اگر نتیجه این بود، ادامه می‌دهم و اگر نبود، این چیز را عوض می‌کنم.»
برای شروع می‌توانی قالب‌های کُندا را ببینی یا پرامپت همین صفحه را برای خودت ویرایش کنی. انتقال به داشبورد ساخت را خودکار شروع نمی‌کند؛ متن و شرایط حسابت را بازبینی می‌کنی. وقتی مسیر فنی کار کرد، هنوز یک سؤال باقی می‌ماند: آیا مخاطب واقعاً از آن سود می‌برد؟
پیش از عمومی‌کردن نسخه، تفاوت پیش‌نمایش و محصول قابل استفاده و چک‌لیست دسترسی را بررسی کن. اگر بخشی از فرضیه یا اتصال‌ها حل نشده، آن را در تصمیم بعدی بنویس؛ اسم MVP جای این شفافیت را نمی‌گیرد.
یک مثال از معیار پذیرش کوچک، ثبت‌نام کارگاه با ظرفیت مشخص است: هر پذیرش یک صندلی، تکرار همان درخواست بدون صندلی اضافه، و بررسی رقابت چند درخواست برای ظرفیت باقی‌مانده.
از خواندن به ساختن با کُندانسخهٔ اول را با یک معیار مشخص شروع کن
فرضیه و امکانات خارج از دامنه را روشن کن؛ متن را برای آزمون خودت تغییر بده و در داشبورد بازبینی کن. انتقال متن، ساخت را شروع نمی‌کند.
دامنه و معیار نمونهٔ آموزشی؛ فرضیهٔ ارزش هنوز آزموده نشده پرسش‌های پرتکرار
ساخت MVP با هوش مصنوعی از کجا شروع می‌شود؟
از شناخت یک مخاطب و مسئلهٔ مشخص، نوشتن فرضیهٔ قابل رد و انتخاب یک مسیر کوچک برای آزمون. قبل از ساخت، معیار نتیجه و تصمیم ادامه، تغییر یا توقف را بنویس.
پروتوتایپ با MVP چه فرقی دارد؟
پروتوتایپ میتواند برای فهم مسیر یا شکل راهحل باشد. MVP باید در یک آزمون مشخص از مخاطب و مسئله یادگیری بدهد؛ ظاهر خوب یا پاسشدن تست فنی بهتنهایی اعتبارسنجی تقاضا نیست.
پروندهٔ این مقاله با مشتری واقعی اعتبارسنجی شده است؟
خیر. یک نمونهٔ آموزشی محلی، آزمونهای فنی و بازخورد بازبینی تحریریه بررسی شدهاند. اجرای موتور کُندا یا آزمون با فروشنده و مشتری واقعی ثبت نشده و ادعای تناسب محصول و بازار نداریم.
معیار پذیرش مناسب چه شکلی است؟
به جای «حرفهای و سریع»، حساب، ورودی، اقدام و نتیجهٔ قابل مشاهده را مشخص کن؛ مثلاً همان سفارش با مبلغ معلوم بعد از بازکردن دوباره در حساب مجاز دیده شود.
ساخت MVP با کُندا چند اعتبار هزینه دارد؟
این پرونده اجرای ساخت با کُندا ندارد و عدد ثابتی برای مصرف اعتبار نمی‌دهد. دامنه و اصلاح‌ها را محدود کن و مصرف واقعی هر دور، زمان بررسی و سرویس‌های بیرونی را در دفتر بودجه ثبت کن.
چه زمانی قابلیت تازه اضافه کنیم یا متوقف شویم؟
وقتی مشاهدهٔ استفاده یک مانع روشن در همان جریان نشان میدهد، تغییر محدود تعریف کن. اگر سقف توافقشده تمام شده یا یادگیری تازه نداری، قبل از امکانات بیشتر فرضیه، مخاطب یا روش آزمون را بازنگری کن.
بنیان‌گذار کُندا و راوی تجربهٔ ساخت.
