שלב 2
מעבר מ-BRD ל-PRD הנדסי
אחרי שחתמנו על ה-BRD והסכמנו *למה* עושים את זה, הגיע הזמן להגדיר *מה* בדיוק צוותי הפיתוח צריכים לבנות. PRD (Product Requirements Document) טוב לא מחליף את הארכיטקט, אלא משרטט גבולות גזרה פונקציונליים. נלמד איך לקחת את ה-BRD ולתרגם אותו לחוקים עסקיים קשיחים ותרחישי שימוש (User Flows).
01מתי משתמשים
- אחרי שיש אישור עסקי (BRD) לפרויקט או לפיצ'ר
- כשצריך להעביר מקל לצוות הפיתוח, ה-UX וה-QA כדי שיתחילו לתכנן ולעצב
- כשיש צורך להסכים על מקרי קצה (Edge Cases) ושגיאות לפני שורת הקוד הראשונה
02דוגמה מעשית
ה-BRD קבע יעד של "מערכת ביטול טיסות עצמאי ללקוחות". ה-PRD יפרק את זה: מי רשאי לבטל? עד מתי מותר לבטל (Business Rule: 24 שעות לפני הטיסה)? מה ה-Flow של המשתמש? ומה קורה אם המערכת של חברת התעופה למטה באותו רגע (Edge Case)?
03 פרומפט
מתודולוגיהמתקדם
פרומפט לתרגום BRD ל-Product Requirements Document (PRD)
המרה של מסמך יעדים עסקי לאפיון התנהגותי ממוקד מפתחים עם חוקים עסקיים ומקרי קצה
PRDאפיון מוצרEdge Cases
פלט צפוי
פלט צפוי
אפיון PRD בשמונה סעיפים: User Flows בבולטים, Business Rules קשיחים, Edge Cases & Error Handling כולל הודעות שגיאה ספציפיות, Anti-KPIs (מה אסור שייפגע תוך כדי המהלך, כמו זמן טעינה או פניות תמיכה), נתונים ופרטיות (מה נאסף ואילו השלכות רגולטוריות כמו GDPR - רק אם רלוונטי), דרישות מבוססות AI (מה המודל אמור לעשות, Fallback כשהוא טועה, וזמן תגובה מצופה - רק אם רלוונטי), Open Questions לחסמים שהצוות חייב לפצח ב-Kickoff, וסעיף סוגר "מה חסר לי כדי לדייק": כל פרט חסר בבקשה המקורית (Business Rule לא ברור, נתון שלא הועבר) מסומן `[חסר: ...]` במקום כתיבת Edge Case מומצא, ובסעיף הזה מוסבר למה הוא נדרש, איפה סביר למצוא אותו (מי בארגון, איזה מסמך), ורק כמוצא אחרון - הצעת ברירת מחדל המסומנת במפורש כהצעה הדורשת אישור.
טעויות נפוצות
טעויות נפוצות
- הכתבת פתרונות טכנולוגיים למפתחים (איזה Database לבחור) במקום דרישות התנהגות פונקציונליות
- שכחת Edge Cases ושגיאות (מה שמוביל לבאגים קריטיים בפרודקשן)
- כתיבת מסמך ארוך כמו ספר במקום בולטים קצרים, ברורים וממוספרים
- לוותר על Anti-KPIs - בלי לכתוב מפורשות מה אסור שייפגע (זמן טעינה, פניות תמיכה), אף אחד לא שם לב שהפיצ'ר החדש "שיפר" מדד אחד תוך שהוא הרג מדד אחר
תרגול עצמי
תרגול עצמי
קח את ה-BRD שיצרת בשיעור 6, זרוק אותו למודל יחד עם הפרומפט שבשיעור זה, ובדוק אילו מקרי קצה (Edge Cases) המודל זיהה שאתה (או ההנהלה) שכחתם להגדיר. בדוק גם אם הוא הוסיף Anti-KPIs שלא חשבת עליהם.
תוצרים
- טיוטת PRD להצגה ב-Kickoff טכני
- רשימת Business Rules ו-Edge Cases ברורה
- רשימת Anti-KPIs ו-Open Questions לצוות הפיתוח