feat: add chapter 04-idea-to-product specs
This commit is contained in:
86
chapters/04-idea-to-product/00-lesson-chapter-goals/spec.md
Normal file
86
chapters/04-idea-to-product/00-lesson-chapter-goals/spec.md
Normal file
@@ -0,0 +1,86 @@
|
|||||||
|
# مشخصات درس‌نامه: اهداف فصل چهارم (Chapter Goals)
|
||||||
|
- **شناسه در سیلابس:** `L4.1`
|
||||||
|
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||||||
|
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||||||
|
- **زمان تقریبی مطالعه:** ۵ دقیقه
|
||||||
|
- **پیش‌نیازهای مستقیم:** `L3.8` و آزمون `Q3.1`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||||||
|
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||||||
|
- [ ] **درک کند (Understand):** چرا شفاف‌سازی ایده، شناخت کاربر و تدوین نیازمندی‌ها قبل از شروع کدنویسی با هوش مصنوعی، مهم‌ترین عامل موفقیت یک محصول نرم‌افزاری است.
|
||||||
|
- [ ] **درک کند (Understand):** نقشه راه ۸ درس‌نامه مفهومی و مهندسی این فصل (از تبدیل ایده به مسئله، پرسونا، داستان کاربر و محدوده MVP تا معیارهای قبولی، تحلیل نیازمندی‌ها، تدوین PRD و شکستن تسک‌ها) چگونه او را به یک پروداکت منیجر توانمند تبدیل می‌کند.
|
||||||
|
- [ ] **درک کند (Understand):** پروژه محوری و پیوسته دوره یعنی «پورتفولیوی شخصی پویا همراه با پنل مدیریت، سیستم ورود و پنل تنظیمات سئو» چیست و چگونه در طول این فصل و فصل‌های آینده ساخته خواهد شد.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** تفاوت میان خروجی‌های سطحی و فاقد کاربرد با یک محصول هدفمند و دارای ارزش بیزنسی را در پروسه وایب کدینگ ارزیابی کند.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||||||
|
|
||||||
|
### آنچه باید پوشش داده شود (In-Scope):
|
||||||
|
1. **ورود به فاز تفکر محصولی (Product Thinking):**
|
||||||
|
* کدنویسی ارزان‌ترین بخش کار است؛ آنچه نرم‌افزار را ارزشمند می‌کند، تعریف درست مسئله و حل نیاز واقعی کاربر است.
|
||||||
|
2. **مرور سرفصل‌های فصل ۴:**
|
||||||
|
* درس ۴.۲: تبدیل ایده خام و مبهم به یک مسئله مشخص و حل‌شدنی.
|
||||||
|
* درس ۴.۳: کاربر هدف و پرسونای مخاطب (کیست و چه دردی دارد؟).
|
||||||
|
* درس ۴.۴: نوشتن داستان کاربر (User Story) برای بیان نیازمندی‌ها از نگاه انسان.
|
||||||
|
* درس ۴.۵: تعریف محدوده محصول و مرزهای هوشمندانه MVP (جلوگیری از Feature Creep).
|
||||||
|
* درس ۴.۶: تعریف دقیق فیچرها و معیارهای پذیرش شفاف (Acceptance Criteria).
|
||||||
|
* درس ۴.۷: تحلیل نیازمندی‌های کارکردی (Functional) و کیفی (Non-Functional).
|
||||||
|
* درس ۴.۸: هم‌آفرینی سند نیازمندی‌های محصول (PRD) در گفتگو با هوش مصنوعی.
|
||||||
|
* درس ۴.۹: تبدیل سند PRD به فهرست تسک‌های مهندسی، اتمیک و اولویت‌بندی‌شده.
|
||||||
|
3. **معرفی پروژه محوری و پیوسته دوره (Running Case Study):**
|
||||||
|
* معرفی پروژه «پورتفولیوی شخصی پویا (Dynamic Personal Portfolio)»:
|
||||||
|
* وب‌سایت عمومی برای نمایش تجربیات، نمونه‌کارها و مهارت‌ها با قابلیت فیلتر.
|
||||||
|
* پنل مدیریت ادمین محافظت‌شده با احراز هویت (Auth) برای افزودن، ویرایش و مدیریت پروژه‌ها بدون دست زدن به کد.
|
||||||
|
* پنل اختصاصی تنظیمات سئو (SEO Panel) برای مدیریت متا تگ‌ها، تایتل، توضیحات و شبکه‌های اجتماعی.
|
||||||
|
4. **کال‌اوت نکته کوئرا (`<details class="green">`):** لزوم عبور دقیق از این فصل به عنوان پایه‌ای‌ترین ریل‌گذاری موفقیت برای تمام پروژه‌های بعدی.
|
||||||
|
|
||||||
|
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||||||
|
- ورود به طراحی UI/UX با Figma یا پالت‌های رنگی (مبحث فصل ۵).
|
||||||
|
- نوشتن کدهای فرانت‌اند با Next.js یا نصب پکیج‌ها (مربوط به فصل ۶ به بعد).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||||||
|
|
||||||
|
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| Product Thinking | تفکر محصولی | نگرش به نرم‌افزار به عنوان راه‌حلی برای حل یک نیاز یا درد واقعی از کاربر |
|
||||||
|
| Dynamic Portfolio | پورتفولیوی پویا | وب‌سایت معرفی نمونه‌کارها که محتوای آن از طریق پنل مدیریت و دیتابیس بدون تغییر کد بروز می‌شود |
|
||||||
|
| Running Case Study | پروژه محوری پیوسته | پروژه نمونه واقعی که گام‌به‌گام از ایده تا دیپلوی نهایی در تمام فصول ساخته می‌شود |
|
||||||
|
| Spec-Driven Product Design | طراحی محصول مشخصات‌محور | روش استخراج شفاف خواسته‌ها پیش از ارسال پرامپت به هوش مصنوعی |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||||||
|
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||||||
|
|
||||||
|
1. **تصویر کاور درس:** `images/cover.png`
|
||||||
|
* **موضوع:** کاور مدرن با تم تیره و خطوط درخشان نئونی که تبدیل یک جرقه ایده خام را به ماکت یک محصول دیجیتال ساختاریافته نشان می‌دهد.
|
||||||
|
2. **نقشه راه یادگیری فصل ۴:** `images/chapter-4-roadmap.png`
|
||||||
|
* **موضوع:** اینفوگرافیک گام‌به‌گام: ایده $\rightarrow$ مسئله $\rightarrow$ پرسونا $\rightarrow$ داستان کاربر $\rightarrow$ محدوده MVP $\rightarrow$ معیارهای پذیرش $\rightarrow$ تحلیل نیازمندی‌ها $\rightarrow$ نگارش PRD $\rightarrow$ فهرست تسک‌ها.
|
||||||
|
3. **معرفی تصویری پروژه محوری (پورتفولیوی پویا):** `images/running-project-architecture.png`
|
||||||
|
* **موضوع:** دیاگرام بصری ۳ بخش پروژه: ۱. ویترین عمومی پورتفولیو $\rightarrow$ ۲. پنل مدیریت امن با لاگین $\rightarrow$ ۳. پنل اختصاصی سئو و متادیتا.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||||||
|
|
||||||
|
1. **تیتر اصلی:** `# اهداف فصل چهارم: از ایده تا محصول`
|
||||||
|
2. **مقدمه کوتاه و تحول‌آفرین:** چرا بزرگ‌ترین باگ نرم‌افزارها در کد نیست، بلکه در تعریف اشتباه نیاز است؟
|
||||||
|
3. **جدول کاور درس**
|
||||||
|
4. **سرفصل‌های کلیدی فصل در یک نگاه:** مرور ۸ ایستگاه طراحی و مهندسی محصول.
|
||||||
|
5. **جدول نقشه راه یادگیری فصل**
|
||||||
|
6. **رونمایی از پروژه محوری دوره: پورتفولیوی شخصی پویا:**
|
||||||
|
* چرا یک پورتفولیوی ایستا کافی نیست؟
|
||||||
|
* ارزش پنل مدیریت و پنل کنترل سئو برای توسعه‌دهنده آینده.
|
||||||
|
7. **کال‌اوت آرامش‌بخش Quera (`<details class="green">`):** ثبت دکمه «خواندم» و آغاز تفکر در قامت یک مدیر محصول.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||||||
|
- [ ] تمایز میان کدنویسی صرف و تفکر محصولی به زبان ساده تبیین شده باشد.
|
||||||
|
- [ ] معرفی پروژه محوری دوره (پورتفولیوی پویا با پنل ادمین و سئو) به صراحت انجام شده باشد.
|
||||||
|
- [ ] نقشه راه تمام درس‌های فصل ۴ با رعایت استانداردهای سیلابس پوشش داده شود.
|
||||||
@@ -0,0 +1,94 @@
|
|||||||
|
# مشخصات درس‌نامه: از ایده تا مسئله (From Idea to Problem Framing)
|
||||||
|
- **شناسه در سیلابس:** `L4.2`
|
||||||
|
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||||||
|
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||||||
|
- **زمان تقریبی مطالعه:** ۱۰ دقیقه
|
||||||
|
- **پیش‌نیازهای مستقیم:** `L4.1` (اهداف فصل چهارم)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||||||
|
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||||||
|
- [ ] **درک کند (Understand):** چرا یک ایده خام و مبهم («می‌خواهم یک سایت خفن برای کارهایم داشته باشم») نمی‌تواند مبنای یک پرامپت مهندسی یا محصول واقعی قرار گیرد.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** تفاوت میان «فکر کردن به راه‌حل» در برابر «کالبدشکافی مسئله واقعی کاربر» را درک و تفکیک کند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** فرمول چهاربخشی بیان مسئله (Problem Statement) را بر روی پروژه محوری دوره (پورتفولیوی پویا با پنل ادمین و سئو) پیاده کند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** از هوش مصنوعی به عنوان یک حریف تمرینی فکری (Sparring Partner) برای چالش کشیدن ایده و اجرای تکنیک ۵ چرا (5 Whys) استفاده کند.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||||||
|
|
||||||
|
### آنچه باید پوشش داده شود (In-Scope):
|
||||||
|
1. **تلهٔ ایده در توسعه نرم‌افزار:**
|
||||||
|
* ایده‌ها ارزان و فراوان هستند؛ آنچه ارزش خلق می‌کند، شفاف‌سازی درد و اصطکاکی است که نرم‌افزار قصد حل آن را دارد.
|
||||||
|
* چرا دادن یک ایده کلی و کلیشه‌ای به ایجنت هوش مصنوعی، خروجی‌های جنریک و بی‌کیفیت (AI Slop) تولید می‌کند.
|
||||||
|
2. **کالبدشکافی فرمول استاندارد بیان مسئله (Problem Statement Formula):**
|
||||||
|
* **۱. چه کسی درگیر مسئله است؟ (Who):** فریلنسرها، طراحان، مشاوران و کارآفرینان خلاق.
|
||||||
|
* **۲. درد و اصطکاک اصلی چیست؟ (What Pain):** برای اضافه کردن یک پروژه جدید، تغییر بیوگرافی یا تنظیم کلمات کلیدی گوگل، مجبورند کدها را دستکاری کنند یا ساعت‌ها درگیر استقرار مجدد شوند.
|
||||||
|
* **۳. چرا راه‌حل‌های فعلی ناکارآمدند؟ (Root Cause):** سایت‌های استاتیک نیازمند مهارت کدنویسی مداوم هستند، و پلتفرم‌های آماده بیرونی کارمزدهای سنگین می‌گیرند و اجازه کنترل کامل سئو و هویت برند را نمی‌دهند.
|
||||||
|
* **۴. پیامد و هزینه این مشکل چیست؟ (Impact):** از دست رفتن فرصت‌های شغلی و بی‌میلی در بروز نگه داشتن رزومه و پورتفولیو.
|
||||||
|
3. **تکنیک ۵ چرا (5 Whys) در تعامل با هوش مصنوعی:**
|
||||||
|
* عمیق شدن در لایه‌های پنهان نیاز:
|
||||||
|
* چرا یک وب‌سایت می‌خواهم؟ تا نمونه‌کارهایم را نشان دهم.
|
||||||
|
* چرا در لینکدین نمی‌گذاری؟ چون می‌خواهم کارفرما بدون مزاحمت و با برند اختصاصی کارم را ببیند.
|
||||||
|
* چرا سایت استاتیک نه؟ چون وقت ندارم برای هر تغییر ادیتور را باز کنم؛ نیاز به پنل ادمین سریع و ابری دارم.
|
||||||
|
4. **پرامپت طلایی برای تبدیل هوش مصنوعی به منتقد محصولی:**
|
||||||
|
* آموزش پرامپت پرسشگرانه: «من این ایده را در ذهن دارم؛ لطفاً در نقش یک مدیر محصول ارشد، ۵ سوال سخت از من بپرس تا نقاط مبهم و مسئله اصلی شفاف شود.»
|
||||||
|
5. **کال‌اوت‌های Quera:**
|
||||||
|
* `<details class="violet">`: قالب آماده فرمول بیان مسئله برای استفاده در هر پروژه نرم‌افزاری.
|
||||||
|
* `<details class="red">`: هشدار محصولی: عاشق راه‌حل نشوید؛ عاشق مسئله و دردی باشید که قرار است حل کنید.
|
||||||
|
|
||||||
|
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||||||
|
- ورود به تحلیل پرسونا و سناریوی دقیق داستان کاربر (درس‌های ۴.۳ و ۴.۴).
|
||||||
|
- تعیین لیست قطعی فیچرها یا استک فنی (درس‌های ۴.۵ تا ۴.۷).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||||||
|
|
||||||
|
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| Problem Framing | صورت‌بندی مسئله | فرایند تبدیل یک ایده مبهم به تعریف دقیق درد، نیاز و چالش کاربر |
|
||||||
|
| Friction Point | نقطه اصطکاک | مانع یا سختی آزاردهنده‌ای که کاربر در مسیر انجام هدفش با آن روبرو می‌شود |
|
||||||
|
| 5 Whys Technique | تکنیک ۵ چرا | پرسیدن مکرر چرایی یک اتفاق برای رسیدن به ریشه بنیادین مسئله |
|
||||||
|
| AI Sparring Partner | حریف تمرینی هوش مصنوعی | استفاده از مدل هوش مصنوعی در نقش منتقد و به چالش کشنده فرضیات ذهنی |
|
||||||
|
| Solution Bias | تعصب روی راه‌حل | اشتباه رایج پافشاری بر ساخت یک فیچر خاص بدون درک نیاز واقعی کاربر |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||||||
|
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||||||
|
|
||||||
|
1. **تصویر کاور درس:** `images/cover.png`
|
||||||
|
* **موضوع:** کاور مدرن نمایش‌دهنده یک لنز ذره‌بین دیجیتال که ابر مبهم یک ایده را روی هدف دقیق یک مسئله فوکوس می‌کند.
|
||||||
|
2. **ابر ایده در برابر لنز شفاف مسئله:** `images/idea-vs-problem-diagram.png`
|
||||||
|
* **موضوع:** تصویر مقایسه‌ای: سمت چپ ابر مه‌آلود («می‌خواهم یک سایت خفن بسازم») در برابر سمت راست بوم شفاف مسئله (چه کسی، چه دردی، چه ریشه‌ای، چه پیامدی).
|
||||||
|
3. **پلکان تکنیک ۵ چرا در پروژه پورتفولیو:** `images/five-whys-portfolio.png`
|
||||||
|
* **موضوع:** دیاگرام پلکانی ۵ سطح پرسش و پاسخ که چرایی ضرورت وجود پنل مدیریت و سئو را اثبات می‌کند.
|
||||||
|
4. **تعامل و چالش ایده با هوش مصنوعی:** `images/ai-sparring-chat.png`
|
||||||
|
* **موضوع:** نمایی از مکالمه ساخت‌یافته با ایجنت که ضعف‌های ایده اولیه را برملا کرده و به شفافیت نهایی می‌رسد.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||||||
|
|
||||||
|
1. **تیتر اصلی:** `# از ایده تا مسئله: چگونه قبل از ساختن، درست فکر کنیم؟`
|
||||||
|
2. **مقدمه:** چرا ۹۰٪ پروژه‌هایی که با هوش مصنوعی سریع ساخته می‌شوند، بی‌مصرف باقی می‌مانند؟
|
||||||
|
3. **جدول کاور درس**
|
||||||
|
4. **تلهٔ ایده در برابر قدرت صورت‌بندی مسئله:** تفاوت خیال‌پردازی با مهندسی نیاز.
|
||||||
|
5. **فرمول چهاربخشی تعریف مسئله (Problem Statement):**
|
||||||
|
* مخاطب، درد، ریشه، پیامد.
|
||||||
|
6. **پیاده‌سازی فرمول روی پروژه محوری (پورتفولیوی پویا):** بررسی دقیق ریشه نیاز به پنل ادمین و سئو.
|
||||||
|
7. **باکس فرمول طلایی Quera (`<details class="violet">`):** تمپلیت آماده برای بیان مسئله هر محصول.
|
||||||
|
8. **تکنیک ۵ چرا (5 Whys): کشف لایه‌های زیرین نیاز:** کاربرد تکنیک در پروژه پورتفولیو.
|
||||||
|
9. **هوش مصنوعی در نقش حریف تمرینی (Sparring Partner):** پرامپت نقد و چالش فرضیات.
|
||||||
|
10. **باکس هشدار Quera (`<details class="red">`):** تعصب روی راه‌حل؛ آفت بزرگ توسعه‌دهندگان نوآور.
|
||||||
|
11. **جمع‌بندی درس‌نامه:** تثبیت مسئله شفاف پورتفولیوی پویا و آماده‌سازی برای شناخت پرسونای مخاطب.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||||||
|
- [ ] گذار از ایده به صورت‌بندی مسئله با استدلال روشن و منطقی شرح داده شده باشد.
|
||||||
|
- [ ] فرمول چهاربخشی بر روی پروژه محوری (پورتفولیوی پویا با ادمین و سئو) اعمال و تحلیل شود.
|
||||||
|
- [ ] تکنیک ۵ چرا همراه با مثال ملموس پروژه تشریح شده باشد.
|
||||||
|
- [ ] پرامپت کاربردی جهت استفاده از AI به عنوان منتقد محصولی آموزش داده شود.
|
||||||
101
chapters/04-idea-to-product/02-lesson-user-stories/spec.md
Normal file
101
chapters/04-idea-to-product/02-lesson-user-stories/spec.md
Normal file
@@ -0,0 +1,101 @@
|
|||||||
|
# مشخصات درس‌نامه: داستان کاربر (User Stories)
|
||||||
|
- **شناسه در سیلابس:** `L4.3`
|
||||||
|
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||||||
|
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||||||
|
- **زمان تقریبی مطالعه:** ۱۲ دقیقه
|
||||||
|
- **پیش‌نیازهای مستقیم:** `L4.2` (از ایده تا مسئله)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||||||
|
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||||||
|
- [ ] **درک کند (Understand):** داستان کاربر (User Story) چیست و چرا بیان نیازمندی‌ها از دیدگاه انسان، کیفیت درک هوش مصنوعی از پروژه را چند برابر می‌کند.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** تفاوت میان «دستور فنی خشک» (مثل: یک جدول و سه اینپوت بساز) با «داستان کاربر هدفمند» (مثل: مدیر بتواند پروژه‌ها را به راحتی ویرایش کند تا اطلاعات بروز بماند) را تشخیص دهد.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** ساختار استاندارد سه‌بخشی داستان کاربر را بنویسد: **به عنوان [نقش کاربر]، می‌خواهم [اقدام و عمل] تا [ارزش و منفعت حاصل شود]**.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** داستان‌های کاربر پروژه محوری (پورتفولیوی پویا با ادمین و سئو) را در هر دو جبهه کاربر عمومی و مدیر پورتفولیو استخراج و دسته‌بندی کند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** اصول استاندارد INVEST را برای بررسی کوچک و تست‌پذیر بودن داستان‌ها به کار گیرد.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||||||
|
|
||||||
|
### آنچه باید پوشش داده شود (In-Scope):
|
||||||
|
1. **داستان کاربر چیست و چرا در وایب کدینگ حیاتی است؟**
|
||||||
|
* هوش مصنوعی بدون فهم هدف کاربر، کدهایی بی‌روح و فاقد تجربه کاربری مناسب می‌سازد.
|
||||||
|
* وقتی شما «علت و ارزش» یک فیچر را برای ایجنت توضیح می‌دهید، او بهترین استایل، پیام‌های خطا، حالت‌های بارگذاری و منطق دیتابیس را برای رسیدن به آن ارزش انتخاب می‌کند.
|
||||||
|
2. **کالبدشکافی فرمول استاندارد داستان کاربر:**
|
||||||
|
* **«به عنوان یک [کاربر مشخص]...»** (As a...) $\rightarrow$ تعیین زاویه دید و سطح دسترسی.
|
||||||
|
* **«می‌خواهم [یک کار مشخص انجام دهم]...»** (I want to...) $\rightarrow$ توصیف رفتار و عمل مورد نظر.
|
||||||
|
* **«تا اینکه [یک ارزش ملموس به دست آورم]...»** (So that...) $\rightarrow$ بیان انگیزه و دلیل وجودی فیچر.
|
||||||
|
3. **معیارهای سنجش یک داستان کاربر عالی (چارچوب INVEST):**
|
||||||
|
* مستقل (Independent)، قابل مذاکره (Negotiable)، ارزشمند (Valuable)، قابل تخمین (Estimable)، کوچک (Small)، و تست‌پذیر (Testable).
|
||||||
|
4. **استخراج داستان‌های کاربر پروژه محوری (پورتفولیوی پویا):**
|
||||||
|
* **داستان‌های سمت بازدیدکننده (Visitor / Recruiter):**
|
||||||
|
* «به عنوان یک کارفرما/مدیر استخدام، می‌خواهم پروژه‌ها را بر اساس مهارت یا تکنولوژی (مثل React یا AI) فیلتر کنم تا سریعاً متوجه شوم آیا این متخصص به درد پروژه من می‌خورد یا خیر.»
|
||||||
|
* «به عنوان یک بازدیدکننده، می‌خواهم با کلیک روی یک پروژه، جزئیات و تصاویر و لینک زنده آن را ببینم تا کیفیت کار واقعی را لمس کنم.»
|
||||||
|
* **داستان‌های سمت صاحب پورتفولیو (Admin / Creator):**
|
||||||
|
* «به عنوان صاحب پورتفولیو، می‌خواهم با رمز عبور وارد پنل شوم تا فقط خودم دسترسی تغییر اطلاعات را داشته باشم.»
|
||||||
|
* «به عنوان صاحب پورتفولیو، می‌خواهم بدون دستکاری کدهای برنامه، یک پروژه جدید را همراه با کاور و توضیحات اضافه یا ویرایش کنم تا رزومه‌ام همیشه بروز باشد.»
|
||||||
|
* «به عنوان صاحب پورتفولیو، می‌خواهم تایتل و توضیحات سئو و تصویر اشتراک‌گذاری (OG Image) را از پنل تنظیم کنم تا وب‌سایتم در لینکدین و گوگل حرفه‌ای نمایش داده شود.»
|
||||||
|
5. **هم‌آفرینی داستان‌های کاربر با هوش مصنوعی:**
|
||||||
|
* پرامپت آماده برای گرفتن یک ایده و تبدیل آن به ۱۰ داستان کاربر مرتب‌شده با ساختار استاندارد.
|
||||||
|
6. **کال‌اوت‌های Quera:**
|
||||||
|
* `<details class="violet">`: مقایسه یک دستور خشک تکنیکال با یک داستان کاربر زنده در هدایت خروجی ایجنت Cursor.
|
||||||
|
* `<details class="red">`: تله اپیک‌های غول‌پیکر (Epic Trap)؛ چرا داستان‌هایی که بیش از یک کار را طلب می‌کنند باید فوراً به داستان‌های کوچک‌تر شکسته شوند.
|
||||||
|
|
||||||
|
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||||||
|
- تعریف پرسونا با جزئیات جمعیت‌شناختی عمیق (درس بعدی ۴.۴).
|
||||||
|
- تعیین شروط دقیق تایید تست و معیارهای قبولی (درس ۴.۶).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||||||
|
|
||||||
|
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| User Story | داستان کاربر | شرح کوتاه و ساده از یک نیاز نرم‌افزاری از زاویه دید و زبان خود کاربر نهایی |
|
||||||
|
| Persona | پرسونا | کاراکتر فرضی نماینده گروهی از کاربران واقعی با اهداف و رفتارهای مشخص |
|
||||||
|
| INVEST Framework | چارچوب کیفیت داستان | چک‌لیست ۶ ویژگی ضروری برای اطمینان از کیفیت و قابلیت اجرای یک داستان کاربر |
|
||||||
|
| Epic | کلان‌داستان / اپیک | نیاز بزرگ و چندوجهی محصول که باید به چندین داستان کاربر کوچک شکسته شود |
|
||||||
|
| User Intent | نیت و قصد کاربر | انگیزه درونی کاربر از انجام یک عمل که هدایت‌گر طراحی نرم‌افزار است |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||||||
|
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||||||
|
|
||||||
|
1. **تصویر کاور درس:** `images/cover.png`
|
||||||
|
* **موضوع:** کاور مدرن با تم تیره و کارت‌های شیشه‌ای دیجیتال استیک نوت که اجزای یک داستان کاربر را در یک بوم محصول نشان می‌دهد.
|
||||||
|
2. **آناتومی فرمول داستان کاربر:** `images/user-story-anatomy.png`
|
||||||
|
* **موضوع:** تصویر شماتیک ۳ قطعه پازل رنگی: [نقش کاربر] + [عمل و خواسته] + [ارزش نهایی].
|
||||||
|
3. **چک‌لیست شاخص‌های INVEST:** `images/invest-framework-checklist.png`
|
||||||
|
* **موضوع:** اینفوگرافیک ۶ شاخص: مستقل، ارزشمند، کوچک، تست‌پذیر و ... با تیک‌های سبز بررسی.
|
||||||
|
4. **نقشه داستان‌های کاربر پورتفولیوی پویا:** `images/portfolio-story-map.png`
|
||||||
|
* **موضوع:** تفکیک بصری دو ستون اصلی: ستون بازدیدکننده (مشاهده، فیلتر، ارتباط) و ستون مدیر (ورود، مدیریت پروژه‌ها، تنظیمات سئو).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||||||
|
|
||||||
|
1. **تیتر اصلی:** `# داستان کاربر: بیان نیازمندی‌ها از نگاه انسان، نه کد!`
|
||||||
|
2. **مقدمه ملموس:** چرا گفتن «چه کدی بنویس» به هوش مصنوعی شکست می‌خورد و گفتن «کاربر چه می‌خواهد» معجزه می‌کند؟
|
||||||
|
3. **جدول کاور درس**
|
||||||
|
4. **ساختار استاندارد یک داستان کاربر طلایی:** تشریح فرمول سه‌بخشی (نقش، اقدام، ارزش).
|
||||||
|
5. **چرا هوش مصنوعی عاشق داستان کاربر است؟:** درک زمینه، ایجاد پیام‌های خطا و حالت‌های بصری متناسب.
|
||||||
|
6. **باکس نکته Quera (`<details class="violet">`):** مقایسه خروجی هوش مصنوعی با پرامپت دستوری در برابر پرامپت داستان کاربر.
|
||||||
|
7. **چارچوب INVEST: سنجه‌های سلامت یک داستان کاربر:** چگونه بفهمیم داستان ما آماده پیاده‌سازی است؟
|
||||||
|
8. **داستان‌های کاربر واقعی پروژه پورتفولیوی پویا:**
|
||||||
|
* داستان‌های سمت بازدیدکننده و استخدام‌کننده.
|
||||||
|
* داستان‌های سمت صاحب پورتفولیو و پنل ادمین.
|
||||||
|
* داستان‌های اختصاصی پنل سئو.
|
||||||
|
9. **همکاری با هوش مصنوعی در استخراج داستان‌ها:** پرامپت آماده ساخت User Storyها.
|
||||||
|
10. **باکس هشدار Quera (`<details class="red">`):** فرار از تله داستان‌های غول‌پیکر (Epic Trap).
|
||||||
|
11. **جمع‌بندی درس‌نامه:** مجهز شدن به لنز داستان کاربر و آماده‌سازی برای تعریف پرسونای دقیق مخاطب.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||||||
|
- [ ] فرمول استاندارد داستان کاربر و فلسفه پشت آن با زبان شفاف و رسا تبیین شده باشد.
|
||||||
|
- [ ] کاربرد داستان کاربر در هدایت هوشمند ایجنت‌های وایب کدینگ اثبات شود.
|
||||||
|
- [ ] داستان‌های کاربر پروژه محوری (پورتفولیوی پویا با ادمین و سئو) به تفکیک دو نقش اصلی در متن درج شوند.
|
||||||
|
- [ ] شاخص‌های INVEST برای راستی‌آزمایی کیفیت داستان‌ها معرفی گردند.
|
||||||
@@ -0,0 +1,97 @@
|
|||||||
|
# مشخصات درس‌نامه: کاربر هدف و پرسونا (Target User & Persona)
|
||||||
|
- **شناسه در سیلابس:** `L4.4`
|
||||||
|
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||||||
|
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||||||
|
- **زمان تقریبی مطالعه:** ۱۲ دقیقه
|
||||||
|
- **پیش‌نیازهای مستقیم:** `L4.3` (داستان کاربر)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||||||
|
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||||||
|
- [ ] **درک کند (Understand):** چرا مفهوم پرسونا (Persona) و کاربر هدف، قطب‌نمای تصمیم‌گیری در تمام مراحل طراحی، انتخاب ویژگی‌ها و پرامپت‌نویسی برای هوش مصنوعی است.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** خطر تلهٔ مرگبار «محصول من برای همه است!» را تحلیل کند و بداند چرا تمرکز روی یک گروه مخاطب شفاف، کلید تمایز و موفقیت نرم‌افزار است.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** پرسوناهای دوگانه پروژه محوری دوره (پرسونای بازدیدکننده/کارفرما در برابر پرسونای صاحب پورتفولیو/ادمین) را تدوین و مشخصات رفتاری، انگیزه‌ها و نقاط درد آن‌ها را مستند کند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** از هوش مصنوعی برای شبیه‌سازی نقش پرسونا (Roleplay Simulation) و مصاحبه مجازی پیش از ساخت نرم‌افزار بهره‌برداری کند.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||||||
|
|
||||||
|
### آنچه باید پوشش داده شود (In-Scope):
|
||||||
|
1. **پرسونا چیست؟ کاراکتری ملموس با اهداف واقعی:**
|
||||||
|
* پرسونا یک جدول داده خشک نیست؛ شخصیتی زنده با احساسات، کمبود زمان، ترجیحات و الگوهای رفتاری در وب است.
|
||||||
|
* چرا وقتی به هوش مصنوعی می‌گویید «این صفحه را برای یک مدیر استخدام پرمشغله بساز»، طراحی مینیمال‌تر و دکمه‌های واضح‌تری پیشنهاد می‌دهد.
|
||||||
|
2. **تلهٔ «این محصول به درد همه می‌خورد» (Targeting Fallacy):**
|
||||||
|
* اگر محصولی برای همه ساخته شود، در واقع برای هیچ‌کس جذاب نخواهد بود.
|
||||||
|
* ایجاد مرز شفاف میان کسانی که کاربر هدف ما هستند و کسانی که مخاطب اولویت‌دار نیستند.
|
||||||
|
3. **تدوین دو پرسونای کلیدی پروژه محوری (پورتفولیوی پویا با ادمین و سئو):**
|
||||||
|
* **پرسونای ۱: مریم (کارفرمای استارتاپی / مدیر استخدام در جستجوی استعداد):**
|
||||||
|
* سن: ۳۴ سال | زمان: بسیار محدود، در حال بررسی ۲۰ رزومه مختلف روی موبایل و لپ‌تاپ در پایان روز کاری.
|
||||||
|
* نیاز اصلی: دیدن فوری خروجی زنده پروژه‌ها، فیلتر کردن بر اساس تکنولوژی خاص (مثلاً Next.js یا AI)، بررسی سریع مهارت‌ها.
|
||||||
|
* نقاط اصطکاک (Pains): متن‌های طولانی و خسته‌کننده، لودینگ بیش از ۳ ثانیه، نبود لینک مستقیم به دموی واقعی کار.
|
||||||
|
* **پرسونای ۲: آرش (توسعه‌دهنده فریلنسر / سازنده مستقل - صاحب پورتفولیو):**
|
||||||
|
* سن: ۲۶ سال | فعالیت: تکمیل پروژه‌های جدید در هر ماه و نیاز مبرم به بستن قراردادهای دلاری یا ریالی بهتر.
|
||||||
|
* نیاز اصلی: پنل ادمین خلوت و سریع با موبایل یا دسکتاپ برای اضافه کردن سریع عکس و لینک پروژه‌ها؛ امکان تنظیم متاتگ‌های سئو برای بالا آمدن نامش در سرچ گوگل.
|
||||||
|
* نقاط اصطکاک (Pains): باز کردن VS Code و درگیر شدن با گیت فقط برای عوض کردن یک عنوان پروژه؛ بی‌توجهی ابزارهای سنتی به تنظیمات سئو.
|
||||||
|
4. **تکنیک شبیه‌سازی پرسونا با هوش مصنوعی (Persona Roleplay):**
|
||||||
|
* پرامپت طلایی برای قرار دادن هوش مصنوعی در نقش مریم (مدیر استخدام):
|
||||||
|
*«از این لحظه تو مریم هستی، یک مدیر استخدام کم‌حوصله. من این طرح پورتفولیو را به تو نشان می‌دهم؛ به من بگو در ۵ ثانیه اول چه چیزی نظرت را جلب می‌کند و چه چیزی باعث می‌شود صفحه را ببندی؟»*
|
||||||
|
5. **کال‌اوت‌های Quera:**
|
||||||
|
* `<details class="violet">`: شبیه‌سازی زنده مصاحبه با کاربر هدف توسط ایجنت؛ چگونه پیش از نوشتن حتی یک خط کد، بازخورد بگیریم؟
|
||||||
|
* `<details class="red">`: تله «من خودم کاربر محصولم هستم»؛ خطر قضاوت نیازهای کارفرما صرفاً بر اساس سلیقه شخصی سازنده.
|
||||||
|
|
||||||
|
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||||||
|
- طراحی گرافیکی آواتارها یا جزئیات روان‌شناسی عمیق خارج از فضای وب.
|
||||||
|
- ورود به جزئیات فنی پروتوتایپ یا فریم‌ورک‌ها (فصل‌های بعد).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||||||
|
|
||||||
|
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| Target Audience | مخاطب / جامعه هدف | گروه مشخصی از افراد که محصول دقیقاً برای حل نیاز آن‌ها طراحی و سفارشی‌سازی می‌شود |
|
||||||
|
| User Persona | پرسونای کاربر | نمایه ساختگی و مستند از یک کاربر ایده‌آل که رفتارها و اهداف واقعی مخاطبان را منعکس می‌کند |
|
||||||
|
| Pain Point | نقطه درد و رنج | مشکلی اساسی که کاربر در فرایند فعلی خود با آن دست به گریبان است و به دنبال راه خلاصی از آن می‌گردد |
|
||||||
|
| Roleplay Simulation | شبیه‌سازی نقش | تبدیل هوش مصنوعی به کاراکتر کاربر هدف برای ارزیابی حسی و منطقی رفتار محصول |
|
||||||
|
| Bounce Rate | نرخ پرش کاربر | درصد کاربرانی که پس از ورود به صفحه، بدون هیچ تعاملی فوراً از آن خارج می‌شوند |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||||||
|
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||||||
|
|
||||||
|
1. **تصویر کاور درس:** `images/cover.png`
|
||||||
|
* **موضوع:** کاور مدرن با تم تیره که دو کارت پروفایل هولوگرافیک دیجیتال را از دو کاربر متمایز با برچسب‌های نیازمندی و اهداف نشان می‌دهد.
|
||||||
|
2. **کارت‌های پرسونای مریم و آرش:** `images/persona-cards-maryam-arash.png`
|
||||||
|
* **موضوع:** اینفوگرافیک دونیمه‌ای جذاب: سمت چپ مریم (مدیر استخدام: اهداف، زمان، ترجیحات) و سمت راست آرش (صاحب پورتفولیو: مدیریت، سرعت، سئو).
|
||||||
|
3. **تله محصولی «همه کس یعنی هیچ‌کس»:** `images/targeting-funnel.png`
|
||||||
|
* **موضوع:** تصویر قیف بازاریابی که تفاوت هدف‌گیری بی‌هدف و پراکنده را با هدف‌گیری لیزری روی مخاطب اصلی نشان می‌دهد.
|
||||||
|
4. **شبیه‌سازی مصاحبه فرضی با هوش مصنوعی:** `images/persona-roleplay-chat.png`
|
||||||
|
* **موضوع:** نمایی از مکالمه پرامپتی که در آن مدل در نقش مریم به نقد ساختار پورتفولیو پرداخته و نکات طلایی ارائه می‌کند.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||||||
|
|
||||||
|
1. **تیتر اصلی:** `# کاربر هدف و پرسونا: دقیقاً برای چه کسی می‌سازیم؟`
|
||||||
|
2. **مقدمه:** چرا بدون شناخت پرسونا، پرامپت‌های شما به هوش مصنوعی خروجی‌هایی گنگ و بی‌اثر خواهند داشت؟
|
||||||
|
3. **جدول کاور درس**
|
||||||
|
4. **پرسونا چیست و چرا قلب طراحی نرم‌افزار است؟:** تعریف استانداردهای پرسونا.
|
||||||
|
5. **تلهٔ خطرناک «محصول من برای همه است!»:** بررسی دلایل شکست اپلیکیشن‌های بی‌هدف.
|
||||||
|
6. **معرفی پرسوناهای پروژه محوری (پورتفولیوی پویا):**
|
||||||
|
* پرسونای ۱: مریم (کارفرما و مدیر استخدام کم‌حوصله).
|
||||||
|
* پرسونای ۲: آرش (توسعه‌دهنده و صاحب پورتفولیو که به پنل مدیریت نیاز دارد).
|
||||||
|
7. **باکس نکته Quera (`<details class="violet">`):** تکنیک شبیه‌سازی مصاحبه فرضی با هوش مصنوعی (Persona Roleplay).
|
||||||
|
8. **تاثیر شناخت پرسونا در هدایت ایجنت‌های کدنویسی:** چگونه پرامپت‌ها را با زاویه دید پرسونا غنی کنیم؟
|
||||||
|
9. **باکس هشدار Quera (`<details class="red">`):** تعصب سلیقه فردی و خطر فرض کردن خود به عنوان تنها معیار سنجش.
|
||||||
|
10. **جمع‌بندی درس‌نامه:** تثبیت پرسونای پروژه و ورود به تعیین مرزهای هوشمندانه نسخه اولیه (MVP).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||||||
|
- [ ] مفهوم پرسونا به عنوان ابزار فکری و جهت‌دهنده به پرامپت‌های هوش مصنوعی شفاف شده باشد.
|
||||||
|
- [ ] دو پرسونای پروژه محوری (مریم و آرش) با جزئیات اهداف، نیازها و اصطکاک‌ها مستند شوند.
|
||||||
|
- [ ] تکنیک شبیه‌سازی نقش پرسونا با هوش مصنوعی همراه با پرامپت نمونه در متن گنجانده شود.
|
||||||
|
- [ ] تله هدف‌گیری همگانی و خطرات تعصب فردی صریحاً نقد شده باشد.
|
||||||
100
chapters/04-idea-to-product/04-lesson-mvp-scope/spec.md
Normal file
100
chapters/04-idea-to-product/04-lesson-mvp-scope/spec.md
Normal file
@@ -0,0 +1,100 @@
|
|||||||
|
# مشخصات درس‌نامه: محدوده محصول و تعریف 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 با تفکیک ۴ سطح برای پروژه محوری (پورتفولیوی پویا با ادمین و سئو) پیاده‌سازی شود.
|
||||||
|
- [ ] مفهوم قیدهای سلبی در پرامپت‌نویسی جهت مهار انحراف مدل آموزش داده شده باشد.
|
||||||
@@ -0,0 +1,103 @@
|
|||||||
|
# مشخصات درس‌نامه: فیچرها و معیارهای پذیرش (Features & Acceptance Criteria)
|
||||||
|
- **شناسه در سیلابس:** `L4.6`
|
||||||
|
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||||||
|
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||||||
|
- **زمان تقریبی مطالعه:** ۱۵ دقیقه
|
||||||
|
- **پیش‌نیازهای مستقیم:** `L4.5` (محدوده محصول و تعریف MVP)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||||||
|
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||||||
|
- [ ] **درک کند (Understand):** تفاوت اساسی میان یک ویژگی کلی (Feature) با معیارهای پذیرش شفاف و سنجش‌پذیر (Acceptance Criteria - AC) چیست.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** چرا ارائه معیارهای پذیرش دقیق به ایجنت‌های هوش مصنوعی، خطاهای پیاده‌سازی و نادیده گرفتن حالت‌های خطا (Edge Cases) را به حداقل می‌رساند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** الگوی استاندارد **Given-When-Then (فرض کنید - هنگامی که - آن‌گاه)** را برای توصیف سناریوهای آزمون فیچرها به کار گیرد.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** معیارهای پذیرش شفاف را برای فیچرهای کلیدی پروژه محوری (ورود ادمین، مدیریت پروژه‌ها و پنل متادیتا سئو) فرمول‌بندی کند.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** عبارات کیفی و مبهم (مانند «فرم زیبا باشد» یا «سرعت بالا باشد») را با شروط مشخص و قابل راستی‌آزمایی جایگزین کند.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||||||
|
|
||||||
|
### آنچه باید پوشش داده شود (In-Scope):
|
||||||
|
1. **معماری فیچر و راز پایان ابهام در وایب کدینگ:**
|
||||||
|
* وقتی به هوش مصنوعی می‌گویید «یک فرم برای اضافه کردن پروژه بساز»، او یک فرم ساده بدون اعتبارسنجی، بدون پیام خطا، بدون لودینگ و بدون تایید ذخیره می‌سازد!
|
||||||
|
* برای اینکه خروجی حرفه‌ای باشد، باید «معیار پذیرش» (شرط قبولی تحویل کار) را تعیین کنید.
|
||||||
|
2. **الگوی طلایی Given-When-Then (چارچوب رفتاری BDD):**
|
||||||
|
* **Given (فرض کنید):** وضعیت اولیه سیستم یا کاربر کجاست؟ (مثلاً: فرض کنید ادمین لاگین کرده و در پنل مدیریت است).
|
||||||
|
* **When (هنگامی که):** کاربر چه رویدادی را آغاز می‌کند؟ (مثلاً: فیلدهای عنوان و لینک را پر کرده و روی دکمه «ذخیره» کلیک می‌کند).
|
||||||
|
* **Then (آن‌گاه):** نتیجه دقیق و بدون ابهام چیست؟ (مثلاً: پیام توست سبز نمایش داده شود، فرم بسته شود و پروژه جدید به بالای لیست پروژه‌ها بدون رفرش صفحه اضافه گردد).
|
||||||
|
3. **تدوین معیارهای پذیرش سه فیچر کلیدی پروژه محوری (پورتفولیوی پویا):**
|
||||||
|
* **فیچر ۱: احراز هویت و ورود ادمین (Admin Auth):**
|
||||||
|
* شرط ۱: اگر رمز عبور اشتباه وارد شود $\rightarrow$ پیام خطای قرمزرنگ «رمز عبور نادرست است» نمایش داده شود و کاربر وارد نشود.
|
||||||
|
* شرط ۲: اگر رمز درست بود $\rightarrow$ کوکی سشن ایمن ست شود و کاربر به آدرس `/admin` هدایت گردد.
|
||||||
|
* شرط ۳: اگر کاربری بدون لاگین به آدرس `/admin` رفت $\rightarrow$ خودکار به صفحه لاگین ریدایرکت شود (Route Guard).
|
||||||
|
* **فیچر ۲: فرم ایجاد و ویرایش پروژه (Project Management):**
|
||||||
|
* شرط ۱: فیلدهای «عنوان» و «تصویر» الزامی باشند و در صورت خالی بودن دکمه ذخیره پیام هشدار بدهد.
|
||||||
|
* شرط ۲: امکان انتخاب چندین تگ مهارتی (مثل Next.js, Tailwind, Supabase) وجود داشته باشد.
|
||||||
|
* شرط ۳: دکمه حذف باید دارای پنجره تایید نهایی (Confirmation Modal) باشد تا از حذف تصادفی جلوگیری کند.
|
||||||
|
* **فیچر ۳: پنل تنظیمات سئو (SEO Management Panel):**
|
||||||
|
* شرط ۱: فرم دارای فیلدهای عنوان سئو (حداکثر ۶۰ کاراکتر)، توضیحات متا (حداکثر ۱۶۰ کاراکتر) و آدرس تصویر OG باشد.
|
||||||
|
* شرط ۲: شمارنده تعداد کاراکتر به صورت زنده نمایش داده شود و در صورت رد شدن از سقف رنگش قرمز شود.
|
||||||
|
* شرط ۳: با ذخیره تنظیمات، تگ‌های `<title>` و `<meta>` در سورس صفحه اصلی فوراً آپدیت شوند.
|
||||||
|
4. **پرامپت استخراج معیارهای پذیرش با هوش مصنوعی:**
|
||||||
|
* پرامپت حرفه‌ای: «این فیچر را در نظر بگیر؛ تمام حالت‌های مرزی (Edge Cases)، خطاهای اعتبارسنجی و سناریوهای کاربری را در قالب Given-When-Then برای من استخراج کن.»
|
||||||
|
5. **کال‌اوت‌های Quera:**
|
||||||
|
* `<details class="violet">`: قدرت الگوی Given-When-Then؛ چگونه بدون نوشتن یک خط کد تست، ایجنت را در ریل درست تست‌نویسی قرار دهیم؟
|
||||||
|
* `<details class="red">`: تله واژگان مبهم؛ هرگز در معیارهای پذیرش از کلمات «زیبا»، «سریع»، «مدرن» یا «راحت» استفاده نکنید؛ اعداد، رنگ‌ها و رفتارها را دقیق بنویسید.
|
||||||
|
|
||||||
|
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||||||
|
- تفکیک تفصیلی شاخص‌های معماری و نیازمندی‌های غیرکارکردی (درس بعدی ۴.۷).
|
||||||
|
- پیاده‌سازی کدهای اعتبارسنجی Zod یا React Hook Form (در فصل‌های ۶ و ۷).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||||||
|
|
||||||
|
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| Acceptance Criteria (AC) | معیارهای پذیرش | مجموعه‌ای از شروط شفاف و آزمون‌پذیر که یک فیچر برای تایید نهایی باید داشته باشد |
|
||||||
|
| Given-When-Then | فرض کنید - هنگامی که - آن‌گاه | الگوی ساخت‌یافته استاندارد برای بیان سناریوهای آزمون رفتار کاربر در نرم‌افزار |
|
||||||
|
| Edge Case | حالت مرزی | موقعیت خاص و استثنایی در اجرای نرم‌افزار (مانند ورودی نامعتبر، دیسکانکت شدن اینترنت) |
|
||||||
|
| Route Guard | محافظ مسیر / گیت دسترسی | سازوکاری که مانع ورود کاربران تاییدنشده به صفحات خصوصی و پنل ادمین می‌شود |
|
||||||
|
| Toast Notification | پیام اعلان توست | پیام کوچک و موقتی که در گوشه صفحه برای اعلام موفقیت یا خطای یک عملیات ظاهر می‌شود |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||||||
|
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||||||
|
|
||||||
|
1. **تصویر کاور درس:** `images/cover.png`
|
||||||
|
* **موضوع:** کاور مدرن با تم تیره و چک‌لیست سبز هولوگرافیک دیجیتال که مهر تایید قبولی (Approved) را روی کارت یک فیچر ثبت می‌کند.
|
||||||
|
2. **کالبدشکافی فیچر در برابر معیارهای پذیرش:** `images/feature-vs-ac-breakdown.png`
|
||||||
|
* **موضوع:** مقایسه دو کارت: کارت عنوان کلی فیچر («فرم ایجاد پروژه») در برابر لیست ۵ شرط قبولی شفاف و بدون ابهام.
|
||||||
|
3. **دیاگرام سه‌گانه Given-When-Then:** `images/given-when-then-loop.png`
|
||||||
|
* **موضوع:** اینفوگرافیک چرخشی ۳ رنگ: ۱. وضعیت اولیه (Given) $\rightarrow$ ۲. رویداد و کنش (When) $\rightarrow$ ۳. نتیجه قطعی (Then).
|
||||||
|
4. **معیارهای قبولی پنل سئو پورتفولیو در عمل:** `images/seo-ac-visual-card.png`
|
||||||
|
* **موضوع:** ماکت رابط پنل سئو با نمایش فیلد تایتل، شمارنده ۶۰ کاراکتر و فلش شرط‌های تایید سبز.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||||||
|
|
||||||
|
1. **تیتر اصلی:** `# فیچرها و معیارهای پذیرش: هنر شفاف‌سازی شروط قبولی`
|
||||||
|
2. **مقدمه:** چرا هوش مصنوعی بدون معیارهای پذیرش، خروجی‌های ناقص و پر از باگ تحویل می‌دهد؟
|
||||||
|
3. **جدول کاور درس**
|
||||||
|
4. **تفاوت بنیادین فیچر (ویژگی) با معیار پذیرش (AC):** از عنوان تا جزئیات آزمون‌پذیر.
|
||||||
|
5. **الگوی طلایی Given-When-Then:** چارچوب مهندسی برای نگارش شروط قبولی.
|
||||||
|
6. **باکس شگفت‌انگیز Quera (`<details class="violet">`):** چگونه با Given-When-Then رفتار ایجنت را قفل کنیم؟
|
||||||
|
7. **کالبدشکافی معیارهای قبولی در ۳ فیچر پورتفولیوی پویا:**
|
||||||
|
* فیچر ۱: سیستم لاگین و محافظت از پنل ادمین.
|
||||||
|
* فیچر ۲: فرم‌های مدیریت و ویرایش پروژه‌ها.
|
||||||
|
* فیچر ۳: پنل تنظیمات متا تگ‌های سئو همراه با شمارنده کاراکتر.
|
||||||
|
8. **استخراج شروط مرزی (Edge Cases) با کمک هوش مصنوعی:** پرامپت منتقد حالت‌های شکست.
|
||||||
|
9. **باکس هشدار Quera (`<details class="red">`):** مرگ بر صفت‌های مبهم! پرهیز از کلماتی مثل زیبا و سریع در تعریف معیار.
|
||||||
|
10. **جمع‌بندی درس‌نامه:** تسلط بر مهارت نگارش شرط‌های قبولی و آماده‌سازی برای تحلیل نیازمندی‌های کیفی و فنی.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||||||
|
- [ ] تمایز میان Feature و Acceptance Criteria با مثال‌های قابل درک روشن شده باشد.
|
||||||
|
- [ ] چارچوب Given-When-Then به همراه ساختار منطقی در متن آموزش داده شود.
|
||||||
|
- [ ] معیارهای قبولی برای ۳ بخش اصلی پروژه محوری (لاگین، مدیریت پروژه، پنل سئو) به طور کامل مستند شده باشد.
|
||||||
|
- [ ] نقد واژگان مبهم کیفی و لزوم شفافیت عددی و رفتاری به صراحت در متن حضور داشته باشد.
|
||||||
@@ -0,0 +1,98 @@
|
|||||||
|
# مشخصات درس‌نامه: تحلیل نیازمندی‌ها: کارکردی در برابر غیرکارکردی (Functional vs Non-Functional Requirements)
|
||||||
|
- **شناسه در سیلابس:** `L4.7`
|
||||||
|
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||||||
|
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||||||
|
- **زمان تقریبی مطالعه:** ۱۲ دقیقه
|
||||||
|
- **پیش‌نیازهای مستقیم:** `L4.6` (فیچرها و معیارهای پذیرش)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||||||
|
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||||||
|
- [ ] **درک کند (Understand):** تفاوت بنیادین میان نیازمندی‌های کارکردی (Functional Requirements - FR: سیستم چه کاری انجام می‌دهد) و نیازمندی‌های غیرکارکردی یا کیفی (Non-Functional Requirements - NFR: سیستم چگونه و با چه کیفیتی عمل می‌کند) چیست.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** چرا هوش مصنوعی به طور پیش‌فرض به نیازمندی‌های کیفی (پرفورمنس، امنیت، واکنش‌گرایی در موبایل) کم‌توجه است مگر اینکه صراحتاً به او دیکته شود.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** چهار ستون اصلی کیفیت نرم‌افزار (کاربردپذیری، پایداری، پرفورمنس، امنیت) را بر روی پروژه محوری (پورتفولیوی پویا) استخراج و مستند کند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** بلوک استانداردی از شروط غیرکارکردی (مانند سازگاری با موبایل، نمره بالای سئو، و محافظت از متغیرهای امنیتی) را برای درج در پرامپت‌ها و فایل قوانین ایجنت آماده سازد.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||||||
|
|
||||||
|
### آنچه باید پوشش داده شود (In-Scope):
|
||||||
|
1. **تفاوت دو جنس نیازمندی در مهندسی نرم‌افزار:**
|
||||||
|
* **نیازمندی‌های کارکردی (FR):** رفتارهای مستقیم، دکمه‌ها، فرم‌ها، عملیات ورود و خروج داده‌ها (پاسخ به سوال: *سیستم چه می‌کند؟*).
|
||||||
|
* **نیازمندی‌های غیرکارکردی (NFR):** ویژگی‌های کیفی و صفات سیستمی نظیر سرعت، مقاومت، امنیت، دسترسی‌پذیری و سئو (پاسخ به سوال: *سیستم با چه کیفیتی کار می‌کند؟*).
|
||||||
|
2. **چرا هوش مصنوعی بدون NFR کدهای فاجعه‌بار تولید می‌کند؟**
|
||||||
|
* هوش مصنوعی با پرامپت ساده کدی می‌نویسد که کار می‌کند، اما:
|
||||||
|
* تصاویر با حجم ۱۰ مگابایت لود می‌شوند و سرعت سایت را نابود می‌کنند.
|
||||||
|
* چیدمان در موبایل کاملاً به هم می‌ریزد.
|
||||||
|
* اطلاعات محرمانه در فرانت‌اند لو می‌روند.
|
||||||
|
3. **ستون‌های چهارگانه کیفیت محصول (چارچوب FURPS ساده‌شده):**
|
||||||
|
* **۱. کاربردپذیری (Usability):** تجربه کاربری روان، پیام‌های خطای فارسی و واضح، طراحی واکنش‌گرا (Responsive) از عرض ۳۲۰ پیکسل تا نمایشگرهای دسکتاپ.
|
||||||
|
* **۲. پایداری (Reliability):** ممانعت از کرش کردن برنامه در صورت قطعی ارتباط یا وارد کردن داده‌های ناقص.
|
||||||
|
* **۳. عملکرد و سرعت (Performance):** زمان بارگذاری اولیه زیر ۱.۵ ثانیه و کسب امتیاز لایت‌هاوس (Lighthouse) بالای ۹۰.
|
||||||
|
* **۴. امنیت و سئو (Security & SEO):** عدم دسترسی بدون لاگین به پنل `/admin`، استفاده از ساختار تگ‌های سمانتیک استاندارد (`<h1>` تا `<h6>`، متا تگ‌ها، Alt برای تصاویر).
|
||||||
|
4. **استخراج لیست تفکیک‌شده FR و NFR برای پروژه پورتفولیوی پویا:**
|
||||||
|
* جدول شفاف نیازمندی‌های کارکردی (نمایش کارت‌ها، فیلتر مهارت، لاگین ادمین، فرم ویرایش سئو).
|
||||||
|
* جدول شفاف نیازمندی‌های غیرکارکردی (سرعت لودینگ، ریسپانسیو بودن، محافظت از کلیدها، تگ‌های OpenGraph).
|
||||||
|
5. **روش تزریق NFR به پرامپت‌های ایجنت‌های وایب کدینگ:**
|
||||||
|
* نحوه افزودن بلوک «الزامات کیفی» در انتهای پرامپت برای مجبور کردن مدل به رعایت استانداردهای مهندسی.
|
||||||
|
6. **کال‌اوت‌های Quera:**
|
||||||
|
* `<details class="violet">`: چرا هوش مصنوعی به ذات خود نیازمندی‌های غیرکارکردی را فراموش می‌کند و چگونه با `.cursorrules` جلوی این نسیان را بگیریم؟
|
||||||
|
* `<details class="red">`: خطر امنیتی افشای کلیدها در کلاینت؛ مرز باریک میان کدهای اجرا شونده در سرور و کدهای لو رفته در مرورگر کاربر.
|
||||||
|
|
||||||
|
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||||||
|
- تست‌های مقیاس‌پذیری انترپرایز برای میلیون‌ها کاربر همزمان (در فصول آخر بررسی خواهد شد).
|
||||||
|
- تنظیمات سرورهای وب Nginx یا کلودفلر (فصل ۱۲ استقرار).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||||||
|
|
||||||
|
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| Functional Requirement (FR) | نیازمندی کارکردی | عمل و رفتار مشخصی که نرم‌افزار باید در پاسخ به ورودی کاربر انجام دهد |
|
||||||
|
| Non-Functional Requirement (NFR) | نیازمندی غیرکارکردی | صفت یا معیار کیفی که نحوه عملکرد، سرعت، پایداری و امنیت سیستم را توصیف می‌کند |
|
||||||
|
| Semantic HTML | ساختار معنایی وب | استفاده از تگ‌های استاندارد HTML که به موتورهای جستجو و ابزارها معنای محتوا را تفهیم می‌کنند |
|
||||||
|
| Lighthouse Audit | ارزیابی لایت‌هاوس | ابزار رسمی گوگل برای سنجش سرعت، سئو، دسترسی‌پذیری و استانداردهای وب‌سایت |
|
||||||
|
| Responsive Layout | چیدمان واکنش‌گرا | انطباق خودکار ابعاد و اجزای رابط کاربری با اندازه صفحه‌نمایش موبایل، تبلت و کامپیوتر |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||||||
|
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||||||
|
|
||||||
|
1. **تصویر کاور درس:** `images/cover.png`
|
||||||
|
* **موضوع:** کاور مدرن با تم تیره و ترازوی دیجیتالی نئونی که در یک کفه چرخ‌دنده‌های کارکردی (FR) و در کفه دیگر شاخص‌های سرعت، امنیت و سئو (NFR) را به توازن رسانده است.
|
||||||
|
2. **ترازوی نیازمندی‌های کارکردی در برابر غیرکارکردی:** `images/fr-vs-nfr-balance.png`
|
||||||
|
* **موضوع:** اینفوگرافیک مقایسه‌ای: ستون سبز (FR: چه کارهایی می‌کند) در برابر ستون آبی (NFR: با چه سرعتی، چه امنیتی و چگونه می‌کند).
|
||||||
|
3. **چهار ستون کیفیت نرم‌افزار:** `images/quality-pillars-diagram.png`
|
||||||
|
* **موضوع:** تصویر شماتیک ۴ ستون معبد کیفیت: کاربردپذیری، پایداری، عملکرد و سرعت، امنیت و سئو.
|
||||||
|
4. **چک‌لیست کیفی پروژه پورتفولیوی پویا:** `images/portfolio-nfr-checklist.png`
|
||||||
|
* **موضوع:** نمایش تصویری ۴ تیک سبز: تست در موبایل، سرعت لود زیر ۲ ثانیه، محافظت از پنل ادمین و تگ‌های سالم سئو.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||||||
|
|
||||||
|
1. **تیتر اصلی:** `# تحلیل نیازمندی‌ها: تفاوت کارهایی که نرم‌افزار می‌کند با کیفیتی که ارائه می‌دهد`
|
||||||
|
2. **مقدمه:** چرا یک برنامه با ده فیچر عالی اما سرعت حلزونی و باگ‌های موبایل، یک شکست کامل است؟
|
||||||
|
3. **جدول کاور درس**
|
||||||
|
4. **تعریف نیازمندی‌های کارکردی (FR): استخوان‌بندی کارها:** کارهایی که برنامه انجام می‌دهد.
|
||||||
|
5. **تعریف نیازمندی‌های غیرکارکردی (NFR): روح و کیفیت نرم‌افزار:** سرعت، امنیت و تجربه.
|
||||||
|
6. **باکس شگفت‌انگیز Quera (`<details class="violet">`):** چرا هوش مصنوعی به طور خودکار NFRها را دور می‌زند؟
|
||||||
|
7. **چهار ستون استاندارد کیفیت (FURPS):** کاربردپذیری، پایداری، پرفورمنس، امنیت و سئو.
|
||||||
|
8. **تفکیک FR و NFR در پروژه محوری (پورتفولیوی پویا):**
|
||||||
|
* لیست نیازمندی‌های کارکردی ویترین، ادمین و سئو.
|
||||||
|
* الزامات کیفی سرعت، نمایش در گوشی و حفظ متغیرهای امنیتی.
|
||||||
|
9. **فرمول تزریق الزامات کیفی به پرامپت‌ها و `.cursorrules`:** مهار هوش مصنوعی پیش از تولید کد بی‌کیفیت.
|
||||||
|
10. **باکس هشدار Quera (`<details class="red">`):** اشتباه نابخشودنی نشت کلیدهای خصوصی در محیط کلاینت.
|
||||||
|
11. **جمع‌بندی درس‌نامه:** تکمیل ابزارهای تفکر محصولی و آماده شدن برای تدوین سند نیازمندی‌های محصول (PRD).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||||||
|
- [ ] تمایز میان نیازمندی‌های کارکردی و غیرکارکردی با مثال‌های واضح تبیین شده باشد.
|
||||||
|
- [ ] پیامدهای غفلت هوش مصنوعی از NFRها (سرعت پایین، خرابی در موبایل، نشت اطلاعات) تشریح گردد.
|
||||||
|
- [ ] نیازمندی‌های کارکردی و کیفی پروژه پورتفولیو در دو جدول مجزا مستند شده باشند.
|
||||||
|
- [ ] شیوه هدایت ایجنت با لحاظ کردن الزامات کیفی در پرامپت‌ها آموزش داده شود.
|
||||||
@@ -0,0 +1,99 @@
|
|||||||
|
# مشخصات درس‌نامه: نوشتن PRD با AI (Writing PRD with AI)
|
||||||
|
- **شناسه در سیلابس:** `L4.8`
|
||||||
|
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||||||
|
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||||||
|
- **زمان تقریبی مطالعه:** ۱۵ دقیقه
|
||||||
|
- **پیش‌نیازهای مستقیم:** `L4.7` (تحلیل نیازمندی‌ها: کارکردی در برابر غیرکارکردی)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||||||
|
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||||||
|
- [ ] **درک کند (Understand):** سند نیازمندی‌های محصول (PRD) در دوران وایب کدینگ چیست و چرا اسناد قطور و سنتی جای خود را به اسناد چابک مارک‌داون (`PRD.md`) به عنوان منبع حقیقت داده‌اند.
|
||||||
|
- [ ] **درک کند (Understand):** ساختار استاندارد ۶ بخشی چارچوب PRD سبک و مهندسی‌شده (Lean Vibe PRD Framework) چگونه چیده می‌شود.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** چرخه هم‌آفرینی سه‌مرحله‌ای (پرامپت اولیه $\rightarrow$ نقد و پیرایش معمارانه انسان $\rightarrow$ خروجی تمیز) را برای تولید سند PRD با هوش مصنوعی اجرا کند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** بخش‌های کلیدی سند PRD پروژه محوری (پورتفولیوی پویا با پنل ادمین و سئو) را با استفاده از قطعه‌کدهای راهنما (Snippets) تکمیل و اعتبارسنجی کند.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** چرا قرار گرفتن فایل `PRD.md` در ریشه مخزن پروژه، خطای ایجنت در حالت‌های چندفایلی (Composer) را به شدت کاهش می‌دهد.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||||||
|
|
||||||
|
### آنچه باید پوشش داده شود (In-Scope):
|
||||||
|
1. **انقلاب در مفهوم PRD؛ از کتابچه‌های بایگانی تا مغز متفکر ایجنت:**
|
||||||
|
* در مهندسی سنتی، PRD سندی ۵۰ صفحه‌ای بود که ماه‌ها خاک می‌خورد.
|
||||||
|
* در وایب کدینگ، PRD یک فایل متنی فشرده و زنده به نام `PRD.md` در ریشه پروژه است که ایجنت با خواندن آن می‌فهمد کل پروژه چه می‌خواهد و چه مرزهایی دارد.
|
||||||
|
2. **کالبدشکافی چارچوب ۶ بخشی سند Lean Vibe PRD:**
|
||||||
|
* **بخش ۱: خلاصه و بیانیه مسئله (Overview & Problem Statement):** چرا این محصول ساخته می‌شود و چه دردی را حل می‌کند؟
|
||||||
|
* **بخش ۲: پرسونای هدف و مسیر کاربر (Personas & User Journeys):** مریم (کارفرما) و آرش (صاحب پورتفولیو).
|
||||||
|
* **بخش ۳: محدوده نسخه اول (MVP Scope via MoSCoW):** تعیین صریح موارد In-Scope و Out-of-Scope.
|
||||||
|
* **بخش ۴: ویژگی‌ها و معیارهای پذیرش (Features & Acceptance Criteria):** تعریف رفتارها در قالب Given-When-Then.
|
||||||
|
* **بخش ۵: نیازمندی‌های غیرکارکردی (NFRs):** سرعت، واکنش‌گرایی در موبایل، امنیت روت‌ها و ساختار متاتگ‌های سئو.
|
||||||
|
* **بخش ۶: فناوری‌ها و استک فنی (Tech Stack & Architecture):** چارچوب انتخابی (Next.js, Tailwind, Supabase).
|
||||||
|
3. **فرایند سه‌مرحله‌ای هم‌آفرینی سند با هوش مصنوعی (The Co-Authoring Loop):**
|
||||||
|
* **گام ۱ (پرامپت اولیه):** ارسال ایده، پرسونا و محدوده به هوش مصنوعی با پرامپت ساخت‌یافته.
|
||||||
|
* **گام ۲ (نقد و پیرایش توسط انسان):** حذف گزافه‌گویی‌های مدل، کوتاه کردن جملات، و شفاف‌سازی معیارهای پذیرش.
|
||||||
|
* **گام ۳ (ذخیره به عنوان منبع حقیقت):** ذخیره در فایل `PRD.md` برای رجوع مداوم ادیتور.
|
||||||
|
4. **نمونه‌های قطعه‌کد (Snippets) واقعی از PRD پروژه پورتفولیوی پویا:**
|
||||||
|
* ارائه قطعات متن آماده برای هر بخش از سند پورتفولیو (شامل تعریف پنل ادمین، احراز هویت، و بخش مدیریت سئو) به گونه‌ای که دانشجو شیوه نگارش را عمیقاً لمس کند.
|
||||||
|
5. **کال‌اوت‌های Quera:**
|
||||||
|
* `<details class="violet">`: نحوه ارجاع به فایل `PRD.md` در Cursor Composer با کاراکتر `@PRD.md` جهت تولید کدهای کاملاً هماهنگ.
|
||||||
|
* `<details class="red">`: تله «سند قطور و خسته‌کننده»؛ پرهیز جدی از تولید متون طولانی؛ سند باید فشرده، دقیق و خوانا برای مدل باشد.
|
||||||
|
|
||||||
|
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||||||
|
- تبدیل سند به ریزتسک‌های گام‌به‌گام برای اجرا (درس بعدی ۴.۹).
|
||||||
|
- ورود به جزئیات دیزاین سیستم یا فیگما (فصل ۵).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||||||
|
|
||||||
|
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| PRD (Product Requirements Document) | سند نیازمندی‌های محصول | سند مرجع مشخص‌کننده اهداف، رفتارها و معیارهای یک نرم‌افزار قبل از شروع ساخت |
|
||||||
|
| Lean PRD | سند چابک و سبک | ساختار فشرده و متمرکز از PRD متناسب با سرعت و ظرفیت پنجره بافت هوش مصنوعی |
|
||||||
|
| Single Source of Truth (SSOT) | منبع واحد حقیقت | مرجع متنی واحدی در پروژه که پاسخ تمامی ابهامات رفتاری و طراحی از روی آن استخراج می‌شود |
|
||||||
|
| Co-Authoring | هم‌آفرینی / تالیف مشترک | تعامل رفت‌وبرگشتی انسان و هوش مصنوعی برای تولید، نقد و پالایش اسناد مهندسی |
|
||||||
|
| Tech Stack | پشته فناوری | ترکیب فریم‌ورک‌ها، زبان‌ها، پایگاه داده و کتابخانه‌های مورد استفاده در ساخت نرم‌افزار |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||||||
|
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||||||
|
|
||||||
|
1. **تصویر کاور درس:** `images/cover.png`
|
||||||
|
* **موضوع:** کاور مدرن با تم تیره که سند درخشان `PRD.md` را در مرکز معماری دیجیتال پروژه با خطوط اتصال نوری به ادیتور و ایجنت نمایش می‌دهد.
|
||||||
|
2. **آناتومی چارچوب ۶ بخشی سند چابک:** `images/lean-prd-framework.png`
|
||||||
|
* **موضوع:** اینفوگرافیک ساختاری ۶ بلوک: ۱. بیان مسئله $\rightarrow$ ۲. پرسونا $\rightarrow$ ۳. محدوده $\rightarrow$ ۴. فیچرها $\rightarrow$ ۵. الزامات کیفی $\rightarrow$ ۶. استک فنی.
|
||||||
|
3. **چرخه سه‌مرحله‌ای هم‌آفرینی با هوش مصنوعی:** `images/co-authoring-prd-cycle.png`
|
||||||
|
* **موضوع:** دیاگرام تعاملی: پرامپت سازنده انسان $\rightarrow$ پیش‌نویس اولیه AI $\rightarrow$ نقد و پیرایش معمار انسان $\rightarrow$ سند نهایی در `PRD.md`.
|
||||||
|
4. **سند PRD در نقش قطب‌نمای ایجنت در ادیتور:** `images/prd-as-agent-compass.png`
|
||||||
|
* **موضوع:** اسکرین‌شات تمیز از فراخوانی `@PRD.md` در Composer محیط Cursor که مانع از انحراف مدل می‌شود.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||||||
|
|
||||||
|
1. **تیتر اصلی:** `# نوشتن PRD با AI: ساخت منبع واحد حقیقت برای ایجنت‌ها`
|
||||||
|
2. **مقدمه:** چرا نوشتن یک سند سبک و شفاف، تفاوت میان سردرگمی ایجنت و خروجی شگفت‌انگیز است؟
|
||||||
|
3. **جدول کاور درس**
|
||||||
|
4. **تغییر پارادایم: از اسناد قطور تا فایل زنده `PRD.md`:** فلسفه وجودی سند در وایب کدینگ.
|
||||||
|
5. **چارچوب ۶ بخشی Lean Vibe PRD:** تشریح ارکان شش‌گانه با زبان روشن.
|
||||||
|
6. **فرایند گام‌به‌گام هم‌آفرینی با هوش مصنوعی:**
|
||||||
|
* پرامپت استاندارد تولید پیش‌نویس اول.
|
||||||
|
* روش‌های پیرایش و حذف حاشیه‌های اضافی توسط معمار انسان.
|
||||||
|
7. **برش‌هایی از PRD واقعی پروژه محوری (پورتفولیوی پویا):**
|
||||||
|
* ارائه اسنیپت‌های بیانیه مسئله، پرسونا، محدوده MoSCoW.
|
||||||
|
* اسنیپت معیارهای قبولی ورود، ادمین و سئو.
|
||||||
|
* اسنیپت الزامات کیفی و استک فنی.
|
||||||
|
8. **باکس نکته طلایی Quera (`<details class="violet">`):** استفاده از دستور `@PRD.md` در محیط کامپوزر ادیتورها.
|
||||||
|
9. **باکس هشدار Quera (`<details class="red">`):** فرار از تله اسناد حجیم و غیرقابل خواندن برای مدل‌های زبانی.
|
||||||
|
10. **جمع‌بندی درس‌نامه:** تولد سند کامل پروژه و آماده‌سازی برای تبدیل آن به فهرست تسک‌های اجرایی.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||||||
|
- [ ] چارچوب استاندارد ۶ بخشی PRD چابک با منطق محکم ارائه شده باشد.
|
||||||
|
- [ ] فرایند تعاملی هم‌آفرینی (Co-Authoring) با هوش مصنوعی به جای کپی منفعلانه آموزش داده شود.
|
||||||
|
- [ ] قطعات نمونه (Snippets) مشخص از سند پورتفولیوی پویا در متن گنجانده شده باشد.
|
||||||
|
- [ ] اهمیت قرارگیری فایل `PRD.md` در ریشه پروژه و فراخوانی آن در ادیتور برجسته گردد.
|
||||||
102
chapters/04-idea-to-product/08-lesson-task-breakdown/spec.md
Normal file
102
chapters/04-idea-to-product/08-lesson-task-breakdown/spec.md
Normal file
@@ -0,0 +1,102 @@
|
|||||||
|
# مشخصات درس‌نامه: فهرست تسک و ترتیب ساخت (Task Breakdown & Sequencing)
|
||||||
|
- **شناسه در سیلابس:** `L4.9` (`L4.10` در شیت)
|
||||||
|
- **فصل:** فصل ۴: از ایده تا محصول (Ch 4)
|
||||||
|
- **نوع محتوا:** 📘 درس‌نامه متنی
|
||||||
|
- **زمان تقریبی مطالعه:** ۱۵ دقیقه
|
||||||
|
- **پیش‌نیازهای مستقیم:** `L4.8` (نوشتن PRD با AI)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۱. اهداف یادگیری (Learning Objectives - Bloom's Taxonomy)
|
||||||
|
دانشجو پس از مطالعهٔ این درس‌نامه باید بتواند:
|
||||||
|
- [ ] **درک کند (Understand):** چرا حتی با داشتن یک سند PRD عالی، فرستادن کل سند به یک‌باره به ایجنت باعث خفگی مدل و تولید کدهای آشفته می‌شود و چرا نیازمند فایل نقشه اقدام (`tasks.md`) هستیم.
|
||||||
|
- [ ] **تحلیل/ارزیابی کند (Evaluate):** تفاوت روش سنتی لایه‌بندی افقی (Horizontal Layering: ساخت تمام دیتابیس، سپس تمام بک‌اند، سپس فرانت‌اند) با روش مدرن وایب کدینگ یعنی برش عمودی (Vertical Slicing: ساخت تک‌تک بخش‌های کارآمد از ظاهر تا داده) را درک کند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** فازبندی منطقی و ترتیب صحیح ساخت پروژه محوری (پورتفولیوی پویا) را در ۷ فاز استاندارد پیاده‌سازی کند.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** ساختار استاندارد یک تسک اتمیک (شامل شناسه، هدف، فایل‌های درگیر، و شرط راستی‌آزمایی) را در فایل `tasks.md` تدوین نماید.
|
||||||
|
- [ ] **به‌کار ببندد (Apply):** از هوش مصنوعی برای تبدیل سند `PRD.md` به فهرست تسک‌های مهندسی‌شده با معیارهای راستی‌آزمایی صریح بهره‌برداری کند.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۲. محدوده و مرزهای محتوا (Scope & Boundaries)
|
||||||
|
|
||||||
|
### آنچه باید پوشش داده شود (In-Scope):
|
||||||
|
1. **پل میان نقشه محصول (PRD) و اجرای ایجنت (Execution):**
|
||||||
|
* سند PRD می‌گوید «چه چیزی می‌خواهیم»، اما فایل تسک‌ها (`tasks.md`) مشخص می‌کند «به چه ترتیبی و با چه گام‌های کوچکی ساخته شود».
|
||||||
|
* جلوگیری از انفجار مگاپرامپت با اجرای دانه‌به‌دانه تسک‌ها.
|
||||||
|
2. **استراتژی برش عمودی (Vertical Slicing):**
|
||||||
|
* چرا نباید ابتدا ۲ هفته دیتابیس بسازیم بدون اینکه چیزی روی صفحه دیده شود؟
|
||||||
|
* در وایب کدینگ، هر گام باید یک خروجی زنده در مرورگر داشته باشد که انگیزه و امکان تست فوری را فراهم کند.
|
||||||
|
3. **توالی هفت‌گانه فازهای ساخت پروژه پورتفولیوی پویا:**
|
||||||
|
* **فاز ۱: فونداسیون و اسکلت (Scaffold):** راه‌اندازی پروژه، سیستم رنگ و لی‌اوت پایه.
|
||||||
|
* **فاز ۲: ویترین عمومی با داده تستی (Public Showcase):** هدر، کارت‌های پروژه و پنجره جزئیات با Mock Data.
|
||||||
|
* **فاز ۳: پایگاه داده و زیرساخت (Database):** راه‌اندازی جداول پروژه‌ها و تنظیمات در Supabase.
|
||||||
|
* **فاز ۴: احراز هویت ادمین (Auth & Protection):** صفحه ورود، کوکی امن و محافظت از روت `/admin`.
|
||||||
|
* **فاز ۵: پنل مدیریت پروژه‌ها (Admin CRUD):** فرم‌های افزودن، ادیت، آپلود تصویر و حذف با تاییدیه.
|
||||||
|
* **فاز ۶: پنل تنظیمات سئو (SEO Controls):** فرم مدیریت متاتگ‌ها، اتصال به متادیتای پویا و تست تگ‌های OG.
|
||||||
|
* **فاز ۷: پولیش، بهینه‌سازی و انتشار (Ship):** چک‌لیست ریسپانسیو، تست لایت‌هاوس و استقرار نهایی.
|
||||||
|
4. **کالبدشکافی آناتومی یک تسک اتمیک در `tasks.md`:**
|
||||||
|
* **شناسه و باکس تیک:** `[ ] Task 2.1: ساخت کامپوننت کارت پروژه`
|
||||||
|
* **هدف و دامنه:** نمایش عکس، عنوان، تگ‌های مهارت و دکمه مشاهده.
|
||||||
|
* **فایل‌های درگیر:** `src/components/ProjectCard.tsx`
|
||||||
|
* **گام راستی‌آزمایی (Verification):** اجرای `npm run dev` و دیدن رندر شدن صحیح کارت با داده نمونه.
|
||||||
|
5. **چرخه پیشروی مهندسی (The Check-and-Commit Loop):**
|
||||||
|
* تسک را به ایجنت بسپارید $\rightarrow$ خروجی را بررسی و تایید کنید $\rightarrow$ تیک تسک را در `tasks.md` بزنید $\rightarrow$ یک کامیت در گیت ثبت کنید $\rightarrow$ سپس سراغ تسک بعد بروید!
|
||||||
|
6. **کال‌اوت‌های Quera:**
|
||||||
|
* `<details class="violet">`: مزیت جادویی برش عمودی (Vertical Slicing) در حفظ انگیزه و دیدن مداوم پیشرفت زنده.
|
||||||
|
* `<details class="green">`: قانون طلایی تیک و کامیت؛ هرگز تسک جدید را شروع نکنید تا زمانی که تسک قبلی تست و ذخیره نشده باشد.
|
||||||
|
|
||||||
|
### آنچه نباید وارد آن شویم (Out-of-Scope):
|
||||||
|
- نرم‌افزارهای اسکرام و جیرا در تیم‌های بزرگ سازمانی.
|
||||||
|
- شروع اجرای کدنویسی این تسک‌ها (این تسک‌ها در فصول ۵ تا ۱۴ به ترتیب اجرا خواهند شد).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۳. مفاهیم کلیدی و کلمات تخصصی (Key Concepts & Terms)
|
||||||
|
|
||||||
|
| اصطلاح انگلیسی | معادل فارسی مصوب | توضیح یک‌خطی ساده |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| Task Breakdown | شکستن تسک‌ها / ساختار شکست کار | تجزیه سند بزرگ نیازمندی‌ها به اقدامات کوچک، مشخص، مستقل و قابل‌اجرا |
|
||||||
|
| Vertical Slicing | برش عمودی | توسعه یک ویژگی کامل از رابط کاربری تا پایگاه داده به صورت همزمان به جای لایه‌بندی افقی |
|
||||||
|
| Atomic Task | تسک اتمیک / دانه‌بندی‌شده | وظیفه‌ای تک‌هدفه که معمولاً در کمتر از چند دقیقه توسط ایجنت پیاده و تست می‌شود |
|
||||||
|
| Verification Step | گام راستی‌آزمایی | عملی مشخص و آزمودنی برای اطمینان از صحت انجام تسک پیش از رفتن به مرحله بعد |
|
||||||
|
| tasks.md | فایل فهرست تسک‌ها | چک‌لیست مارک‌داون در ریشه پروژه که پیشرفت مرحله‌به‌مرحله را رصد می‌کند |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۴. جایگاه‌های تصاویر و نمودارها (Visual & Diagram Placeholders)
|
||||||
|
> **راهنمای ایجنت نویسنده:** تمام تصاویر باید در پوشهٔ `images/` قرار گرفته و در قالب جدول تک‌خانه‌ای وسط‌چین با کپشن تفصیلی درج شوند:
|
||||||
|
|
||||||
|
1. **تصویر کاور درس:** `images/cover.png`
|
||||||
|
* **موضوع:** کاور مدرن با تم تیره و یک چک‌لیست دیجیتال سه‌بعدی با تیک‌های نئونی سبز که پله‌های ساخت یک آسمان‌خراش نرم‌افزاری را نشان می‌دهد.
|
||||||
|
2. **برش افقی در برابر برش عمودی:** `images/horizontal-vs-vertical-slicing.png`
|
||||||
|
* **موضوع:** مقایسه دو رویکرد: لایه‌بندی افقی سنتی (هفته‌ها کار بدون دیدن خروجی) در برابر برش عمودی وایب کدینگ (دیدن یک فیچر زنده و کامل در هر گام).
|
||||||
|
3. **توالی هفت‌گانه ساخت پورتفولیوی پویا:** `images/portfolio-build-phases.png`
|
||||||
|
* **موضوع:** اینفوگرافیک گام‌به‌گام فازهای ۷ گانه: ۱. فونداسیون $\rightarrow$ ۲. ویترین $\rightarrow$ ۳. دیتابیس $\rightarrow$ ۴. احراز هویت $\rightarrow$ ۵. پنل ادمین $\rightarrow$ ۶. پنل سئو $\rightarrow$ ۷. انتشار.
|
||||||
|
4. **آناتومی یک تسک استاندارد در `tasks.md`:** `images/atomic-task-structure.png`
|
||||||
|
* **موضوع:** تصویر کادر تسک شامل باکس تیک، عنوان تسک، نام فایل و کادر شرط راستی‌آزمایی سبز.
|
||||||
|
5. **چرخه تیک زدن و کامیت در گیت:** `images/check-and-commit-loop.png`
|
||||||
|
* **موضوع:** فلوچارت دایره‌ای: پرامپت تسک $\rightarrow$ اجرای ایجنت $\rightarrow$ تست مرورگر $\rightarrow$ زدن تیک $\rightarrow$ گیت کامیت.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۵. بخش‌بندی و ساختار محتوایی پیشنهادی درس‌نامه (`README.md`)
|
||||||
|
|
||||||
|
1. **تیتر اصلی:** `# فهرست تسک و ترتیب ساخت: تبدیل نقشه به گام‌های عملیاتی`
|
||||||
|
2. **مقدمه:** چرا بدون شکستن کارها به تسک‌های اتمیک، بزرگ‌ترین PRDها هم در دست ایجنت متلاشی می‌شوند؟
|
||||||
|
3. **جدول کاور درس**
|
||||||
|
4. **چرا نیازمند فایل `tasks.md` هستیم؟:** تفکیک نقشه کلان از برنامه اقدام اجرایی.
|
||||||
|
5. **روش مهندسی برش عمودی (Vertical Slicing):** چرا وایب کدینگ با برش عمودی جان می‌گیرد؟
|
||||||
|
6. **باکس نکته Quera (`<details class="violet">`):** نجات از باتلاق توسعه با دیدن مداوم نتایج زنده.
|
||||||
|
7. **نقشه راه ۷ فاز ساخت پورتفولیوی پویا:** تشریح گام‌به‌گام از اسکلت اولیه تا پنل سئو و دیپلوی.
|
||||||
|
8. **کالبدشکافی یک تسک استاندارد:** فرمول نگارش تسک با فایل‌های درگیر و شرط تایید.
|
||||||
|
9. **همکاری با هوش مصنوعی در تولید `tasks.md`:** پرامپت تبدیل PRD به چک‌لیست اجرایی.
|
||||||
|
10. **باکس قانون طلایی Quera (`<details class="green">`):** چرخه تیک زدن و ثبت کامیت در گیت.
|
||||||
|
11. **جمع‌بندی فصل چهارم:** اعلام تکمیل فاز طراحی و آماده‌سازی برای ورود به فصل ۵ (طراحی تجربه کاربری و هویت بصری).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer)
|
||||||
|
- [ ] ضرورت شکستن PRD به تسک‌های اتمیک با دلایل محکم تشریح شده باشد.
|
||||||
|
- [ ] مفهوم برش عمودی (Vertical Slicing) به صورت بصری و مستند آموزش داده شود.
|
||||||
|
- [ ] توالی ۷ فاز ساخت پروژه پورتفولیوی پویا به روشنی دسته‌بندی و معرفی گردد.
|
||||||
|
- [ ] فرمت استاندارد تسک در `tasks.md` همراه با شرط راستی‌آزمایی در متن لحاظ شود.
|
||||||
Reference in New Issue
Block a user