101 lines
10 KiB
Markdown
101 lines
10 KiB
Markdown
# مشخصات درس‌نامه: محدوده محصول و تعریف MVP (Product Scope & MVP Definition)
|
||
- **شناسه در سیلابس:** `L4.5`
|
||
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||
- **زمان تقریبی مطالعه:** ۱۲ دقیقه
|
||
- **پیش‌نیازهای مستقیم:** `L4.4` (کاربر هدف و پرسونا)
|
||
|
||
---
|
||
|
||
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||
- [ ] **درک کند (Understand):** کمینه محصول پذیرفتنی (MVP) چیست و استعاره مشهور «اسکیت‌برد در برابر چرخ بدون بدنه» چگونه مرزهای یک نسخه اولیه کاربردی را تبیین می‌کند.
|
||
- [ ] **تحلیل/ارزیابی کند (Evaluate):** پدیده خطرناک «تورم محدوده (Scope Creep)» در عصر هوش مصنوعی را شناسایی کند و بداند چرا اضافه کردن بی‌مهابای فیچرها پروژه را به سمت شکست و فرسودگی سوق می‌دهد.
|
||
- [ ] **به‌کار ببندد (Apply):** ماتریس اولویت‌بندی MoSCoW را بر روی تمام ایده‌های پروژه محوری (پورتفولیوی پویا) اعمال کرده و مرز دقیق نسخه اول را جدا کند.
|
||
- [ ] **به‌کار ببندد (Apply):** در پرامپت‌نویسی برای ایجنت، بخش «چه چیزهایی در این نسخه نباید ساخته شوند» (Negative Constraints) را لحاظ کند تا مدل از مسیر اصلی منحرف نشود.
|
||
|
||
---
|
||
|
||
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||
|
||
### آنچه باید پوشش داده شود (In-Scope):
|
||
1. **بازتعریف درست MVP: کوچک، اما کامل و کارآمد:**
|
||
* اشتباه بزرگ مبتدیان: ساخت یک اسکلت ناقص و بدون کارکرد (مثل یک تک‌چرخ از ماشین که حرکت نمی‌کند).
|
||
* تعریف اصولی: ساده‌ترین محصولی که ارزش محوری را از ابتدا تا انتها به سرانجام می‌رساند (مثل یک اسکیت‌برد که از نقطه A تا B حرکت می‌کند).
|
||
2. **تله تورم دامنه در وایب کدینگ (The AI Scope Creep Trap):**
|
||
* چون هوش مصنوعی سریع کد می‌زند، کاربر وسوسه می‌شود همه‌چیز را همزمان بخواهد: وبلاگ، سیستم چت زنده، درگاه پرداخت، ترجمه ۵ زبانه و سیستم هوش مصنوعی تحلیل رزومه!
|
||
* پیامد: کدهای حجیم، بافت فرسوده چت (Context Rot)، باگ‌های بی‌پایان و پروژه‌ای که هرگز به نقطه انتشار نمی‌رسد.
|
||
3. **ماتریس اولویت‌بندی MoSCoW برای پروژه محوری (پورتفولیوی پویا):**
|
||
* **باید باشد (Must-Have - قلب تپنده MVP):**
|
||
* ویترین عمومی: هدر با بیوگرافی و اطلاعات تماس، گرید نمایش پروژه‌ها با برچسب تکنولوژی، مودال/صفحه جزئیات هر پروژه با لینک زنده.
|
||
* پنل مدیریت ادمین: ورود با رمز عبور و فرم اضافه/ویرایش/حذف پروژه‌ها (CRUD).
|
||
* پنل کنترل سئو: فرم ذخیره و ویرایش تایتل صفحه، توضیحات متا و تصویر اشتراک‌گذاری (OpenGraph).
|
||
* **بهتر است باشد (Should-Have - فاز بعدی v1.1):**
|
||
* فیلتر کردن پروژه‌ها با تب‌های دسته‌بندی، سوییچ تم تیره و روشن (Dark/Light Mode).
|
||
* **می‌تواند باشد (Could-Have - فاز v2.0):**
|
||
* بخش بلاگ یا یادداشت‌ها، شمارنده بازدیدهای هر پروژه.
|
||
* **نباید باشد (Won't-Have - مرز ممنوعه فعلی):**
|
||
* سیستم ثبت‌نام چندکاربره (SaaS)، پرداخت آنلاین یا سیستم ایمیل مارکتینگ.
|
||
4. **هنر گفتن «نه» در پرامپت‌های مهندسی:**
|
||
* چگونگی درج لیست Out-of-Scope در ورودی به هوش مصنوعی: «فقط و فقط این فیچر را پیاده کن و وارد بخش‌های فیلتر یا وبلاگ نشو».
|
||
5. **کال‌اوت‌های Quera:**
|
||
* `<details class="violet">`: استعاره اسکیت‌برد در طراحی محصول؛ چرا تحویل یک چیز ساده و روان بهتر از یک شاهکار ناتمام است؟
|
||
* `<details class="red">`: وسوسه سرعت هوش مصنوعی؛ چرا سرعت بالای کدنویسی نباید جایگزین انضباط مهندسی در محدوده‌بندی شود.
|
||
|
||
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||
- فرمول‌بندی معیارهای دقیق پذیرش تست برای تک‌تک فیچرها (درس بعدی ۴.۶).
|
||
- نیازمندی‌های غیرکارکردی عمیق مانند امنیت پیشرفته یا پرفورمنس بالا (درس ۴.۷).
|
||
|
||
---
|
||
|
||
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||
|
||
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||
| :--- | :--- | :--- |
|
||
| MVP (Minimum Viable Product) | کمینه محصول پذیرفتنی | نسخه‌ای از محصول با حداقل امکانات لازم که ارزش اصلی را به طور کامل به کاربر تحویل می‌دهد |
|
||
| Scope Creep | تورم / خزش دامنه | گسترش کنترل‌نشده و مداوم فیچرهای یک پروژه که مانع از اتمام به موقع آن می‌شود |
|
||
| MoSCoW Method | روش اولویت‌بندی ماسکو | چارچوب دسته‌بندی امکانات به: باید باشد، بهتر است باشد، می‌تواند باشد و نباید باشد |
|
||
| Core Value Proposition | ارزش پیشنهادی اصلی | مهم‌ترین مشکلی که محصول بهتر، سریع‌تر یا راحت‌تر از روش‌های دیگر حل می‌کند |
|
||
| Negative Constraints | محدودیت‌های سلبی | تعیین صریح کارهایی که ایجنت هوش مصنوعی اجازه ورود یا کدنویسی در آن‌ها را ندارد |
|
||
|
||
---
|
||
|
||
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||
|
||
1. **تصویر کاور درس:** `images/cover.png`
|
||
* **موضوع:** کاور مدرن با تم تیره و یک تیغ جراحی دیجیتال نئونی که مرزهای دقیق یک هسته الماس‌گونه (MVP) را از انبوهی از ایده‌های حاشیه‌ای برش می‌زند.
|
||
2. **استعاره اسکیت‌برد در ساخت محصول:** `images/mvp-skateboard-concept.png`
|
||
* **موضوع:** مقایسه دو ردیف تصویری: ردیف غلط (چرخ ناتمام $\rightarrow$ بدنه $\rightarrow$ ماشین) در برابر ردیف درست (اسکیت‌برد متحرک $\rightarrow$ دوچرخه $\rightarrow$ موتور $\rightarrow$ اتومبیل).
|
||
3. **ماتریس MoSCoW پروژه پورتفولیوی پویا:** `images/moscow-portfolio-breakdown.png`
|
||
* **موضوع:** اینفوگرافیک ۴ مربعی رنگی با دسته‌بندی امکانات پورتفولیو (ویترین، پنل ادمین، سئو در هسته اصلی).
|
||
4. **تله بادکنک تورم دامنه (Scope Creep):** `images/scope-creep-balloon.png`
|
||
* **موضوع:** تصویر استعاری بادکنک پروژه‌ای که با تزریق مداوم فیچرهای بی‌موقع توسط کاربر در حال ترکیدن است.
|
||
|
||
---
|
||
|
||
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||
|
||
1. **تیتر اصلی:** `# محدوده محصول و تعریف MVP: هنر کمتر ساختن، ولی کامل ساختن!`
|
||
2. **مقدمه:** چرا سریع‌ترین راه برای کشتن یک پروژه با هوش مصنوعی، بزرگ تعریف کردن آن است؟
|
||
3. **جدول کاور درس**
|
||
4. **کمینه محصول پذیرفتنی (MVP) واقعاً چیست؟:** تشریح مرز اسکلت ناقص با محصول جمع‌وجور کاربردی.
|
||
5. **استعاره اسکیت‌برد: چگونه نسخه اولی بسازیم که راه برود؟:** تحلیل بصری چرخه ساخت ارزش.
|
||
6. **باکس نکته Quera (`<details class="violet">`):** درس‌های استارتاپی در درک فلسفه واقعی MVP.
|
||
7. **دام بزرگ در وایب کدینگ: توهم توانایی بی‌نهایت هوش مصنوعی:** خطرات افزودن فیچرهای وسوسه‌انگیز.
|
||
8. **چارچوب اولویت‌بندی MoSCoW روی پروژه پورتفولیوی پویا:**
|
||
* امکانات Must-Have: ویترین، ادمین، سئو.
|
||
* امکانات Should-Have و Could-Have.
|
||
* امکانات Won't-Have: خط قرمزهای نسخه اول.
|
||
9. **قدرت محدودیت‌های سلبی (Negative Constraints) در پرامپت‌ها:** نحوه مهار ایجنت.
|
||
10. **باکس هشدار Quera (`<details class="red">`):** اگر پروژه در کمتر از چند روز به نقطه انتشار نرسد، احتمال رها شدنش به ۸۰٪ می‌رسد!
|
||
11. **جمع‌بندی درس‌نامه:** مشخص شدن مرزهای دقیق پورتفولیو و آمادگی برای تعریف معیارهای پذیرش فیچرها.
|
||
|
||
---
|
||
|
||
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||
- [ ] تعریف MVP بر اساس اصول استاندارد محصول و استعاره اسکیت‌برد بدون سوءبرداشت تشریح شود.
|
||
- [ ] پدیده تورم دامنه (Scope Creep) با اشاره به خطرات مختص هوش مصنوعی نقد شده باشد.
|
||
- [ ] ماتریس MoSCoW با تفکیک ۴ سطح برای پروژه محوری (پورتفولیوی پویا با ادمین و سئو) پیاده‌سازی شود.
|
||
- [ ] مفهوم قیدهای سلبی در پرامپت‌نویسی جهت مهار انحراف مدل آموزش داده شده باشد.
|