🧠 התשובה המלאה
בניית מוצר טוב דורשת מחקר מקיף ותכנון נכון. אבל מאיפה מתחילים? ובכן, ארגונים, חברות ומנהלי מוצר נוטים להתחיל קודם כל עם מסמך דרישות מסודר, ה-PRD.
מסמך PRD (ראשי תיבות של Product Requirements Document), לעיתים גם נקרא בעברית מסמך דרישות/אפיון מוצר, הוא מסמך המתאר את מוצר מסוים על כל תכולתו: המטרות העסקיות, הפיצ׳רים, חווית המשתמש (UX), מסכים עיקריים (UI), אינטרקציות, אינגרציות ועוד - כל פיסת מידע הכרחית על מנת לתאר כל פרט במוצר לפני שמתחילים את תהליך הפיתוח.
מדוע מסמך PRD הוא חשוב?
ראשית, הימצאותו של מסמך המציג תמונה שלמה של כל ההתרחשויות הוא תמיד נוח.
מסמך דרישות מוצר (PRD) נותן סקירה כללית של החלקים החשובים לפיתוח הפרויקט ומשרת המעורבים בפרויקט: הצוותים העסקיים, הטכניים, השיווק, הלקוח (במידה ומדובר בפרויקט חיצוני) ועוד. המסמך משמש כמעין ״מצפן״ עבור הגורמים השונים המעורבים בפרויקט ולמעשה דואג שכולם יהיו ״מיושרים״ על המטרות של הפרויקט ותכולתו.
שנית, מסמך PRD (טוב), עשוי לעורר שיח ופידבק חיוני מכל המעורבים בפרויקט ולגלות טעויות וכשלים עתידיים ביישום הפרויקט, כל זאת עוד לפני שמתחילים לעבוד עליו במלוא הכוח (ומבזבזים זמן וכסף יקר). הדבר הזה בפני עצמו הוא קריטי לכל פרויקט באשר הוא.
השימוש במסמך דרישות מוצר (PRD) נפוץ בעיקר בשתי סיטואציות עסקיות:
פנים ארגונית
מסמך PRD דואג לסנכרון בין כל הצוותים השונים בארגון בנוגע לתכולת הפרויקט והמטרות העסקיות שלו. לרוב נעשה שימוש במסמך PRD בחברות וארגונים העובדים על פי מודל ״מפל המים״, אם כי גם בארגונים הפועלים במודל אג׳ייל (Agile) יש העושים בו שימוש. במקרה הזה, מנהל המוצר או המוביל שהפרויקט יוצר PRD עבור הפיתוח הספציפי (פיצ׳ר, פרויקט חדש וכדומה) ומעביר אותו הלאה לשאר הצוותים הרלוונטים (צוותי הפיתוח בעיקר) על מנת להתניע את הפיתוח שלו בפועל. לרוב יעשה שימוש בכלים ייעודים לניהול פרויקטים כמו Monday או Asana וכדומה.
לקוחות חיצוניים
חברות המספקות מוצר ללקוחות חיצוניים (לדוגמא, חברות פרויקטים הבונות אפליקציות ללקוחות), דואגות ליצור מסמך PRD המציג את כל הדרישות אשר נאספו מהלקוח ומציג אותן בצורה מסודרת על מנת שיהיה אפשר לצאת לדרך לקראת פיתוח והשקת המוצר. המסמך דואג שגם ללקוח וגם לחברה עצמה ברור מה התכולה של הפרויקט - איפה הוא מתחיל ואיפה הוא נגמר.
מה כלול במסמך PRD?
בעיקרון, כל מסמך PRD הוא ייחודי ו״תפור״ לכל פרויקט/יוזמה באופן אישי. אממה, ישנם מספר מרכיבי מפתח אשר בדרך מצויים במסמך:
- מטרות ויעדים: תחילה, נותנים רקע לגבי המוצר האמור להיבנות - למה צריך אותו, איזו בעיות הוא פותר, מי קהל היעד וכו׳. המטרה בחלק זה היא להציג בצורה ברורה מהי ״הצעת הערך״ של המוצר והסיבה לקיום שלו בעולם.
- אבני דרך (Timeline): מה התכנון להוצאת הפרויקט לפועל מבחינת זמנים, אבני דרך מרכזיים ועוד.
- יכולות (Features): הסבר על היכולות, הרכיבים והפונקציונאליות של המוצר - מה הוא עושה ומה אפשר לעשות איתו.
- חווית משתמש ועיצוב (User Flow): הסבר על החוויה הכללית של המשתמש המשתמש במוצר. בדרך כלל מגובה באמצעות סקיצות ראשונות (Wireframes), תרשים זרימה של מסכים מוקאפים ואלמנטים ויזואלים תומכים אחרים.
- דרישות מערכת: רשימה של דרישות טכניות הכרחיות על מנת שהמוצר יוכל לתפקד כמו שצריך אצל המשתמש קצה. החל מדברים כמו מכשור ספציפי שדרוש להפעלה (״חייב אייפון בשביל להריץ את האפליקציה״) ועד למפרטים טכניים כמו סוג דפדפן, זיכרון, כוח עיבוד וכדומה.
- אנליטיקה (Analytics): הגדרת המדדים שאיתם נעבוד על מנת למדוד את ההצלחה (או חוסר הצלחה) של המוצר (מדדי הצלחה או KPI), וכמו כן את אופן השימוש שלו ע״י המשתמשים - כיצד הם משתמשים במוצר, מה הם עושים איתו ומה הם לא.
איך לכתוב מסמך PRD (טוב)?
מטרת מסמך ה-PRD הוא ראשית ליישר קו בין כל המעורבים בפרויקט, לכן חשוב מאוד להעביר אותו בצורה שמאזנת בין מידע חיוני לבין העמסת יתר של מידע לא הכרחי.
במידה ואתם בתפקיד אשר אחראי על כתיבת מסמך דרישות, להלן כמה צעדים מומלצים ״לתקוף״ את מסמך ה-PRD בצורה כזו שבאמת מממשת את מלוא הפוטנציאל שלו עבור עבודה עם הצוותים והלקוחות שלכם:
1. התחילו מסקירה כללית על הפרויקט עצמו
אנחנו ממליצים להתחיל את מהמסמך מפירוט כללי הפרויקט ולמי הוא רלוונטי:
- משתתפים: מי המעורבים בפרויקט? הגדירו תפקידים ואחראויות (Ownership) ברורים בין כולם.
- סטטוס נוכחי: מה המצב הנוכחי של הפרויקט? עיכובים, אילוצי זמנים, סיכונים וכו׳.
- תאריך השקה: מתי מתוכנן לסיים עם הפרויקט ולהשיק אותו?
2. הציגו רקע כללי, מטרות ויעדים
מה אנחנו עושים? למה אנחנו עושים את מה שאנחנו עושים? איך זה מסתדר עם שאר המטרות העסקיות של הארגון? מה התוצאות או עם מה אנחנו מצפים לסיים בסוף הפרויקט?
3. הנחות יסוד, אילוצים ותלויות
פרויקטים הם לא דבר וודאי, ולפעמים מופיעים אירועים בלתי מתוכננים, אך זה לא אומר שאתם לא יכולים לצפות להם. כחלק מהמסמך PRD, גם אין לכם פתרון לכל דבר שעשוי לצוץ, כדאי לתת להם התייחסות וליידע את כולם בנוגע אליהם.
הנחות יסוד (Assumptions) - כחלק מהדרישות מערכת, הציגו הנחות מסוימות שקשורות למוצר כחלק מהשימושיות שלו. חלק מהן עשויות להיות ברורות מאליהן, אבל תמיד כדאי לתת להן התייחסויות על מנת שאולי תקבלו עליהן פידבק מהצוות. לדוגמא, הנחה יסוד יכולה להיות שללקוח יהיה חיבור לאינטרנט על מנת שהאפליקציה תעבוד לו בטלפון הנייד.
אילוצים (Constraints) - הציגו כל דבר אשר עשוי לצוץ כאילוץ אפשרי אשר עשוי לשבש את הפרויקט: אילוצי תקציב, אילוצים טכניים, העדר ידע בתחום מסוים והכרחי לביצוע הפרויקט וכדומה. התייחסו לכל אילוץ והציגו פתרונות אפשריים או ״פלסטרים״ אשר הצוותים השונים יכולים להשתמש בהם על מנת להתגבר על אותם מכשולים.
4. הציגו את ה-User Flow
תארו ברשימה בצורה שיטטית מה הם היכולות והפיצ׳רים של המוצר - ת׳כלס, מה משתמש יכול לעשות איתו.
גבו את הנאמר באמצעות ויזואליציה וחסכו בהסברים מיותרים - בני אדם מבינים טוב יותר כשהם רואים על מה אתם מדברים. השתמשו בעיצובים ותרשימי זרימה המציגים את האינטרקציה של המשתמש במוצר - שלב אחר שלב, מסך אחר מסך.
5. התייחסו לשאלות פתוחותֿ
הצוות והמעורבים בפרויקט מבינים מה הבעיה שאתם מנסים לפתור, אבל כנראה שיהיה להם שאלות בנוגע לדברים מסוימים. צרו טבלה של ״דברים שאנחנו צריכים להחליט בנוגע אליהם או לחקור״ והעזרו בצוות על מנת לסגור קצוות פתוחים בנוגע למימוש של חלקים מסוימים בפרויקט.
6. הסבירו מה אתם לא עושים
לכולם ברור עד כה מה עושים, אבל תמיד טוב להסביר גם ״מה אנחנו לא עושים״ על מנת להשאיר את הצוות מפוקס על העבודה שכן צריכה להעשות. סמנו באופן ברור מה הם הדברים שהם מחוץ לתכולה (ל-Scope) כרגע, ומה כנראה יכנס באיטרציות עתידיות של עבודה.
דוגמאות למסמך PRD
כאמור, PRD עשויים להיות שונים מפרויקט לפרויקט ומארגון לארגון. לדוגמא, מסמך דרישות עבור פיצ׳ר בודד בתוך אפליקציה יהיה שונה בגודלו וברמת פירוטו מאשר PRD המתאר אפליקציה שלמה מאפס.
PRD Template להורדה
אספנו עבורכם מספר טמפלייטים למסמכי דרישות לדוגמא. השתמשו בהם בתור ״שלד״ או רפרנס למסמך דרישות שלכם.
