diff --git a/chapters/04-idea-to-product/00-lesson-chapter-goals/spec.md b/chapters/04-idea-to-product/00-lesson-chapter-goals/spec.md new file mode 100644 index 0000000..cffd674 --- /dev/null +++ b/chapters/04-idea-to-product/00-lesson-chapter-goals/spec.md @@ -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. **کال‌اوت نکته کوئرا (`
`):** لزوم عبور دقیق از این فصل به عنوان پایه‌ای‌ترین ریل‌گذاری موفقیت برای تمام پروژه‌های بعدی. + +### آنچه نباید وارد آن شویم (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 (`
`):** ثبت دکمه «خواندم» و آغاز تفکر در قامت یک مدیر محصول. + +--- + +## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer) +- [ ] تمایز میان کدنویسی صرف و تفکر محصولی به زبان ساده تبیین شده باشد. +- [ ] معرفی پروژه محوری دوره (پورتفولیوی پویا با پنل ادمین و سئو) به صراحت انجام شده باشد. +- [ ] نقشه راه تمام درس‌های فصل ۴ با رعایت استانداردهای سیلابس پوشش داده شود. diff --git a/chapters/04-idea-to-product/01-lesson-idea-to-problem/spec.md b/chapters/04-idea-to-product/01-lesson-idea-to-problem/spec.md new file mode 100644 index 0000000..a29deff --- /dev/null +++ b/chapters/04-idea-to-product/01-lesson-idea-to-problem/spec.md @@ -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:** + * `
`: قالب آماده فرمول بیان مسئله برای استفاده در هر پروژه نرم‌افزاری. + * `
`: هشدار محصولی: عاشق راه‌حل نشوید؛ عاشق مسئله و دردی باشید که قرار است حل کنید. + +### آنچه نباید وارد آن شویم (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 (`
`):** تمپلیت آماده برای بیان مسئله هر محصول. +8. **تکنیک ۵ چرا (5 Whys): کشف لایه‌های زیرین نیاز:** کاربرد تکنیک در پروژه پورتفولیو. +9. **هوش مصنوعی در نقش حریف تمرینی (Sparring Partner):** پرامپت نقد و چالش فرضیات. +10. **باکس هشدار Quera (`
`):** تعصب روی راه‌حل؛ آفت بزرگ توسعه‌دهندگان نوآور. +11. **جمع‌بندی درس‌نامه:** تثبیت مسئله شفاف پورتفولیوی پویا و آماده‌سازی برای شناخت پرسونای مخاطب. + +--- + +## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer) +- [ ] گذار از ایده به صورت‌بندی مسئله با استدلال روشن و منطقی شرح داده شده باشد. +- [ ] فرمول چهاربخشی بر روی پروژه محوری (پورتفولیوی پویا با ادمین و سئو) اعمال و تحلیل شود. +- [ ] تکنیک ۵ چرا همراه با مثال ملموس پروژه تشریح شده باشد. +- [ ] پرامپت کاربردی جهت استفاده از AI به عنوان منتقد محصولی آموزش داده شود. diff --git a/chapters/04-idea-to-product/02-lesson-user-stories/spec.md b/chapters/04-idea-to-product/02-lesson-user-stories/spec.md new file mode 100644 index 0000000..c5a8cae --- /dev/null +++ b/chapters/04-idea-to-product/02-lesson-user-stories/spec.md @@ -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:** + * `
`: مقایسه یک دستور خشک تکنیکال با یک داستان کاربر زنده در هدایت خروجی ایجنت Cursor. + * `
`: تله اپیک‌های غول‌پیکر (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 (`
`):** مقایسه خروجی هوش مصنوعی با پرامپت دستوری در برابر پرامپت داستان کاربر. +7. **چارچوب INVEST: سنجه‌های سلامت یک داستان کاربر:** چگونه بفهمیم داستان ما آماده پیاده‌سازی است؟ +8. **داستان‌های کاربر واقعی پروژه پورتفولیوی پویا:** + * داستان‌های سمت بازدیدکننده و استخدام‌کننده. + * داستان‌های سمت صاحب پورتفولیو و پنل ادمین. + * داستان‌های اختصاصی پنل سئو. +9. **همکاری با هوش مصنوعی در استخراج داستان‌ها:** پرامپت آماده ساخت User Storyها. +10. **باکس هشدار Quera (`
`):** فرار از تله داستان‌های غول‌پیکر (Epic Trap). +11. **جمع‌بندی درس‌نامه:** مجهز شدن به لنز داستان کاربر و آماده‌سازی برای تعریف پرسونای دقیق مخاطب. + +--- + +## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer) +- [ ] فرمول استاندارد داستان کاربر و فلسفه پشت آن با زبان شفاف و رسا تبیین شده باشد. +- [ ] کاربرد داستان کاربر در هدایت هوشمند ایجنت‌های وایب کدینگ اثبات شود. +- [ ] داستان‌های کاربر پروژه محوری (پورتفولیوی پویا با ادمین و سئو) به تفکیک دو نقش اصلی در متن درج شوند. +- [ ] شاخص‌های INVEST برای راستی‌آزمایی کیفیت داستان‌ها معرفی گردند. diff --git a/chapters/04-idea-to-product/03-lesson-target-user-persona/spec.md b/chapters/04-idea-to-product/03-lesson-target-user-persona/spec.md new file mode 100644 index 0000000..a3a578c --- /dev/null +++ b/chapters/04-idea-to-product/03-lesson-target-user-persona/spec.md @@ -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:** + * `
`: شبیه‌سازی زنده مصاحبه با کاربر هدف توسط ایجنت؛ چگونه پیش از نوشتن حتی یک خط کد، بازخورد بگیریم؟ + * `
`: تله «من خودم کاربر محصولم هستم»؛ خطر قضاوت نیازهای کارفرما صرفاً بر اساس سلیقه شخصی سازنده. + +### آنچه نباید وارد آن شویم (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 (`
`):** تکنیک شبیه‌سازی مصاحبه فرضی با هوش مصنوعی (Persona Roleplay). +8. **تاثیر شناخت پرسونا در هدایت ایجنت‌های کدنویسی:** چگونه پرامپت‌ها را با زاویه دید پرسونا غنی کنیم؟ +9. **باکس هشدار Quera (`
`):** تعصب سلیقه فردی و خطر فرض کردن خود به عنوان تنها معیار سنجش. +10. **جمع‌بندی درس‌نامه:** تثبیت پرسونای پروژه و ورود به تعیین مرزهای هوشمندانه نسخه اولیه (MVP). + +--- + +## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer) +- [ ] مفهوم پرسونا به عنوان ابزار فکری و جهت‌دهنده به پرامپت‌های هوش مصنوعی شفاف شده باشد. +- [ ] دو پرسونای پروژه محوری (مریم و آرش) با جزئیات اهداف، نیازها و اصطکاک‌ها مستند شوند. +- [ ] تکنیک شبیه‌سازی نقش پرسونا با هوش مصنوعی همراه با پرامپت نمونه در متن گنجانده شود. +- [ ] تله هدف‌گیری همگانی و خطرات تعصب فردی صریحاً نقد شده باشد. diff --git a/chapters/04-idea-to-product/04-lesson-mvp-scope/spec.md b/chapters/04-idea-to-product/04-lesson-mvp-scope/spec.md new file mode 100644 index 0000000..49b32e2 --- /dev/null +++ b/chapters/04-idea-to-product/04-lesson-mvp-scope/spec.md @@ -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:** + * `
`: استعاره اسکیت‌برد در طراحی محصول؛ چرا تحویل یک چیز ساده و روان بهتر از یک شاهکار ناتمام است؟ + * `
`: وسوسه سرعت هوش مصنوعی؛ چرا سرعت بالای کدنویسی نباید جایگزین انضباط مهندسی در محدوده‌بندی شود. + +### آنچه نباید وارد آن شویم (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 (`
`):** درس‌های استارتاپی در درک فلسفه واقعی MVP. +7. **دام بزرگ در وایب کدینگ: توهم توانایی بی‌نهایت هوش مصنوعی:** خطرات افزودن فیچرهای وسوسه‌انگیز. +8. **چارچوب اولویت‌بندی MoSCoW روی پروژه پورتفولیوی پویا:** + * امکانات Must-Have: ویترین، ادمین، سئو. + * امکانات Should-Have و Could-Have. + * امکانات Won't-Have: خط قرمزهای نسخه اول. +9. **قدرت محدودیت‌های سلبی (Negative Constraints) در پرامپت‌ها:** نحوه مهار ایجنت. +10. **باکس هشدار Quera (`
`):** اگر پروژه در کمتر از چند روز به نقطه انتشار نرسد، احتمال رها شدنش به ۸۰٪ می‌رسد! +11. **جمع‌بندی درس‌نامه:** مشخص شدن مرزهای دقیق پورتفولیو و آمادگی برای تعریف معیارهای پذیرش فیچرها. + +--- + +## ۶. معیارهای پذیرش (Acceptance Criteria for Reviewer) +- [ ] تعریف MVP بر اساس اصول استاندارد محصول و استعاره اسکیت‌برد بدون سوءبرداشت تشریح شود. +- [ ] پدیده تورم دامنه (Scope Creep) با اشاره به خطرات مختص هوش مصنوعی نقد شده باشد. +- [ ] ماتریس MoSCoW با تفکیک ۴ سطح برای پروژه محوری (پورتفولیوی پویا با ادمین و سئو) پیاده‌سازی شود. +- [ ] مفهوم قیدهای سلبی در پرامپت‌نویسی جهت مهار انحراف مدل آموزش داده شده باشد. diff --git a/chapters/04-idea-to-product/05-lesson-features-and-acceptance-criteria/spec.md b/chapters/04-idea-to-product/05-lesson-features-and-acceptance-criteria/spec.md new file mode 100644 index 0000000..ae0b9a3 --- /dev/null +++ b/chapters/04-idea-to-product/05-lesson-features-and-acceptance-criteria/spec.md @@ -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 باشد. + * شرط ۲: شمارنده تعداد کاراکتر به صورت زنده نمایش داده شود و در صورت رد شدن از سقف رنگش قرمز شود. + * شرط ۳: با ذخیره تنظیمات، تگ‌های `` و `<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 به همراه ساختار منطقی در متن آموزش داده شود. +- [ ] معیارهای قبولی برای ۳ بخش اصلی پروژه محوری (لاگین، مدیریت پروژه، پنل سئو) به طور کامل مستند شده باشد. +- [ ] نقد واژگان مبهم کیفی و لزوم شفافیت عددی و رفتاری به صراحت در متن حضور داشته باشد. diff --git a/chapters/04-idea-to-product/06-lesson-functional-nonfunctional-requirements/spec.md b/chapters/04-idea-to-product/06-lesson-functional-nonfunctional-requirements/spec.md new file mode 100644 index 0000000..01103eb --- /dev/null +++ b/chapters/04-idea-to-product/06-lesson-functional-nonfunctional-requirements/spec.md @@ -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ها (سرعت پایین، خرابی در موبایل، نشت اطلاعات) تشریح گردد. +- [ ] نیازمندی‌های کارکردی و کیفی پروژه پورتفولیو در دو جدول مجزا مستند شده باشند. +- [ ] شیوه هدایت ایجنت با لحاظ کردن الزامات کیفی در پرامپت‌ها آموزش داده شود. diff --git a/chapters/04-idea-to-product/07-lesson-writing-prd-with-ai/spec.md b/chapters/04-idea-to-product/07-lesson-writing-prd-with-ai/spec.md new file mode 100644 index 0000000..087f6ac --- /dev/null +++ b/chapters/04-idea-to-product/07-lesson-writing-prd-with-ai/spec.md @@ -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` در ریشه پروژه و فراخوانی آن در ادیتور برجسته گردد. diff --git a/chapters/04-idea-to-product/08-lesson-task-breakdown/spec.md b/chapters/04-idea-to-product/08-lesson-task-breakdown/spec.md new file mode 100644 index 0000000..014eaed --- /dev/null +++ b/chapters/04-idea-to-product/08-lesson-task-breakdown/spec.md @@ -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` همراه با شرط راستی‌آزمایی در متن لحاظ شود.