מה זה בעצם PRD ולמה הוא משמש?
נתחיל מהסוף, PRD – Product Requirements Document זה מסמך מגדיר בצורה ברורה 4 דברים:
- מה אנחנו בונים?
- למה אנחנו בונים את זה?
- למי זה נועד?
- ו-איך זה אמור לעבוד (פונקצינלית)?
במילים פשוטות זו מפת הדרכים של מוצר או אפליקציה שאנחנו מתכננים לבנות. PRD הוא כלי מרכזי בכל פרויקט טכנולוגי. הוא מאפשר למנהלי מוצר ולצוות הפרויקט הגדרה ברורה של: מה הבעיה שהמוצר אמור לפתור, מה הפונקציונליות שלו, מי קהל היעד, איזה אינטגרציות נדרשות ואיך המוצר אמור לעבוד.
זה נראה ככה 👇(אגב, אתם יכולים להוריד תבנית שהכנתי לכם ממש)
ממה חשוב לכלול במסמך דרישות (PRD)?
- סקירה קצרה של המוצר (Overview/Purpose) – תמצות הבעיה, ההזדמנות העסקית והיתרון הייחודי של המוצר.
- מטרות ויעדים ומדדי הצלחה (Goals & Objectives) – מטרות עסקיות, מטרות מוצר ו-KPI ברורים שניתנים למדידה.
- קהל יעד ופרסונות (Target Users/Personas) – ניתוח המשתמשים, הצרכים והכאבים שלהם
- תחום (Scope) – הגדרה ברורה מה כלול בתכולת ה-MVP ומה נשאר לשלבים מתקדמים יותר.
- סיפורי משתמש/Use Cases – מסעות לקוח (Customer Journeys) ותרחישי שימוש שמדגירים את הפונקציונליות של המוצר.
- דרישות פונקציונליות (Functional Requirements) – כל הדרישות ההכרחיות של המערכת ברמת הפיצ’ר, מה שהוא אמור לבצע ומה התוצאה הרצויה. בחלק מהמקרים משלבים גם ארכיטקטוריה.
- דרישות לא-פונקציונליות (Non-Functional Requirements) – דרישות אבטחה, ביצועים, חוויית משתמש, סקיילביליות, נגישות, וכד׳.
- UI/UX – הגדרת חווית משתמש שכולל עקרונות עיצוב מנחים, Wireframes של מסכים ואינטראקציות מרכזיות.
- תלותיות והנחות (Dependencies & Assumptions) – טכנולוגיות חיצוניות, אינטגרציות, הנחות מוגדרות מראש.
- לוחות זמנים ואבני דרך (Timeline/Milestones) – תכנית עבודה ויעדים לשלבים הראשוניים.
- מדדים וקריטריונים להצלחה (Metrics & Success Criteria) – איך תמדד הצלחת המוצר דרך KPI מוגדרים.
- סוגיות פתוחות וניהול סיכונים (Open Questions & Risks) – סוגיות המצריכות מענה, בעיות צפויות ודרכי התמודדות ראשוניות.
- בעלי עניין (Stakeholders) – מי הבעלים והמאשרים למסמך ולפיתוח בפועל.
- חומרים תומכים – מחקרים, דיאגרמות, השוואות מתחרים, השראות עיצוב וכו’.
למה זה חשוב בעבודה עם סוכני AI?
במוצרים מורכבים כמו אפליקציות עם הרבה פיצ’רים, כל אינטראקציה עם מודל שפה כוללת כמות גדולה של מידע. בגלל שלכל מודל יש מגבלת חלון הקשר (Context Window), ככל שהמידע מתארך או מתפזר, כך גדל הסיכוי שהמודל “יאבד” חלקים מהקונטקסט. ברגע שההקשר לא מדויק, גם התשובות הופכות לפחות ממוקדות ואנחנו מוצאים את עצמנו בסבבים של הסברים חוזרים ותיקונים. במקרים מורכבים, זה עלול להפוך ללולאה אינסופית של ניסוחים מחדש, שמבזבזת זמן מתסכלת ופוגעת ברצף הפיתוח.
כאן נכנס לתמונה מסמך ה-PRD, שיש לו חלק מרכזי בהנדסת הקשר (Context Engineering) בעבודה עם סוכני פיתוח כמו Claude Code או Codex. ה-PRD מספק למודל תמונה מאורגנת וברורה של הפרויקט, המטרות, גבולות הפיתוח, היכולות והשלב שבו נמצאים. ככה המודל מקבל תמונה שמאפשרת לו לייצר תוצאות מדויקות יותר, גם כשהשיחות מתמשכות.
ממה מורכבת ״הנדסת הקשר״?
הנדסת הקשר (Context Engineering) מורכבת מכמה שכבות שעובדות יחד כדי לאפשר למודל להבין לעומק את הפרויקט ואת הסיטואציה בכל שלב
- קונטקסט קבוע (Static Context) שכולל: מסמכי אפיון ו-PRD, ארכיטקטורה, דרישות, רשימות פיצ’רים, נהלים קבועים ומתודולוגיות עבודה. המידע הזה לא משתנה בין שיחות, ומשמש כ״זיכרון ארוך טווח״ של הפרויקט.
- קונטקסט זמני (Session Context) המידע שמצטבר תוך כדי העבודה השוטפת למשל: השיחות האחרונות, החלטות שהתקבלו בסשן הנוכחי, מצב הפיתוח העדכני. המטרה היא לשמר רצף לוגי לאורך אינטראקציות מרובות ולא “להתחיל מאפס” בכל שאלה.
- הוראות תפעול (Operational Instructions) שמגדירות למודל “איך לחשוב ולפעול”, למשל הגדרת תפקיד (“פעל כראש צוות פיתוח”), כללי עבודה ומתודולוגיה (Agile, TDD וכו’), סגנון קוד או כתיבה רצוי. ההוראות האלה משפיעות על סגנון ותהליך העבודה, לא רק על התוכן.
- קונטקסט דינמי ממוקד (Dynamic Scoped Context) עוזר להתמודד עם מגבלת חלון ההקשר, לא טוענים את כל המידע בכל שיחה, אלא רק את הרכיבים הרלוונטיים לאותו שלב או משימה. לדוגמה: כשכותבים פיצ׳ר מסוים, טוענים רק את האפיון הרלוונטי לאותו פיצ׳ר.
- מטה־הקשר (Meta Context) מסמך שהוא ממש רכיב ניהולי שמאפשר לסוכן להבין את המצב הכולל של הפרויקט: איזה משימות בוצעו, איזה פיצ׳רים ורכיבים קיימים ומה עוד צריך לפתח.
השילוב בין חמשת החלקים האלה מאפשר לנהל תהליך פיתוח מורכב עם מודל שפה מבלי לאבד מיקוד, לשמור על עקביות, ולצמצם דרמטית את כמות ההבהרות הידניות לאורך הדרך.
אז אם אתם רוצים להתחיל לעבוד עם קלוד-קוד בצורה חכמה ומסודרת, נסו לכתוב PRD לפרויקט הבא שלכם ולשלב אותו כחלק מהקונטקסט של הסוכן.