מסמך אפיון מוצר לדוגמה: תבנית להורדה ודוגמה מלאה

שיחת ייעוץ בוואטסאפ

התשובה הקצרה

מסמך אפיון מוצר מתאר מה המוצר צריך לעשות, למי ולמה, לפני שמישהו כותב קוד. הוא בנוי מתשעה סעיפים: רקע ומטרה, משתמשים ותפקידים, תהליכים מרכזיים, דרישות, מה לא נכלל, נתונים ואינטגרציות, דרישות לא פונקציונליות, מדדי הצלחה ושאלות פתוחות. את המסמך כותב מי שמזמין את המוצר, לא בית התוכנה שיבנה אותו.

להורדת התבנית (קובץ Markdown, נפתח בכל עורך טקסט)


אפיון מוצר, אפיון מערכת, אפיון טכני: מה ההבדל

סוג עונה על השאלה מי כותב בדרך כלל מתי
אפיון מוצר מה בונים, למי ולמה, ומה ייחשב הצלחה מנהל או מנהלת המוצר, או המזמין לפני שמבקשים הצעות מחיר
אפיון מערכת (פונקציונלי) מה כל מסך ותהליך עושים, כולל חריגים ותנאי קבלה מנהל מוצר או מאפיין מערכות אחרי אפיון המוצר, לפני הפיתוח
אפיון טכני איך בונים: ארכיטקטורה, מסד נתונים, ממשקים ותשתית צוות הפיתוח אחרי אפיון המערכת

בפרויקט קטן אפיון המוצר ואפיון המערכת יושבים באותו מסמך, כמו בדוגמה למטה. את האפיון הטכני כותב מי שבונה, והמסמך הזה הוא הקלט שלו.


הדוגמה המלאה (מוצר בדוי)

שימו לב: המוצר, הרשת וכל הפרטים בדוגמה הזו בדויים, להמחשה בלבד.

פרטי המסמך: "תורן", מערכת לתיאום תורים לרשת בדויה של מרפאות פיזיותרפיה עם ארבעה סניפים. גרסה 1.0, נכתבה על ידי מנהלת התפעול של הרשת, מאושרת על ידי המנכ"ל.

1. רקע ומטרה

2. משתמשים ותפקידים

תפקיד מה עושה במערכת מה אסור לו
מטופל קובע, מזיז ומבטל תור, מקבל תזכורת לראות פרטים של מטופלים אחרים
מזכירה מנהלת את היומן של כל הסניפים, קובעת תורים בטלפון לשנות הגדרות והרשאות
מטפל רואה את היומן שלו, חוסם שעות לראות יומנים של מטפלים אחרים
מנהלת הרשת מגדירה סניפים, מטפלים, סוגי טיפול ושעות פעילות

3. תהליכים מרכזיים

תהליך: מטופל קובע תור

  1. המטופל בוחר סניף וסוג טיפול.
  2. המערכת מציגה שעות פנויות אצל מטפלים שמבצעים את הטיפול הזה.
  3. המטופל בוחר שעה ומזין שם וטלפון.
  4. המערכת שולחת קוד אימות בהודעת SMS.
  5. התור נשמר, והמטופל מקבל אישור עם קישור להזזה או ביטול.

מקרי קצה: שני מטופלים בוחרים את אותה שעה באותו רגע (השני מקבל הודעה שהשעה נתפסה, עם שעות חלופיות); מטופל בלי טלפון נייד (קובע דרך המזכירה); מטפל מנסה לחסום שעה שכבר יש בה תור (המערכת עוצרת ומבקשת להזיז קודם את התור).

4. דרישות פונקציונליות (מקוצר)

# דרישה תפקיד עדיפות תנאי קבלה
1 קביעת תור עצמית מטופל חובה תור נקבע מתחילתו ועד סופו בטלפון נייד, בלי עזרה
2 ביטול והזזה עד מועד שהרשת מגדירה מטופל חובה אחרי המועד הכפתור לא מוצג, ובמקומו הטלפון של הסניף
3 תזכורת לפני התור מטופל חובה נשלחת בזמן שהוגדר, עם קישור להזזה
4 יומן מאוחד לכל הסניפים מזכירה חובה סינון לפי סניף ומטפל במסך אחד
5 רשימת המתנה לתור שהתפנה מטופל רצוי
6 תשלום מראש מטופל לא בגרסה הזו

5. מה לא נכלל בגרסה הזו

6. נתונים ואינטגרציות

7. דרישות לא פונקציונליות

8. מדדי הצלחה

מדד איך מחשבים ערך בסיס מתי בודקים
חלק התורים שנקבעו בלי מזכירה תורים שנקבעו באתר חלקי כל התורים אפס, אין אפשרות כזו היום כל חודש
שיחות תיאום ביום לסניף ספירה ידנית במשך שבוע נספר בשבוע שלפני העלייה חודש אחרי העלייה
שיעור אי-הגעה תורים שהמטופל לא הגיע אליהם חלקי כל התורים נמדד מהיומנים לפני העלייה כל חודש

אין כאן יעד במספר. את היעד קובעים אחרי שיש ערך בסיס, לא לפני.

9. שאלות פתוחות

# שאלה מי עונה עד מתי
1 עד כמה זמן לפני התור מותר לבטל בלי לדבר עם הסניף? מנהלת הרשת לפני תחילת העיצוב
2 האם יש טיפולים שדורשים הפניה לפני קביעה, ואיך זה נבדק? מנהלת הרשת לפני האפיון הטכני
3 מי משלם על הודעות ה-SMS, ומאיזה תקציב? המנכ"ל לפני בחירת ספק

6 טעויות שחוזרות במסמכי אפיון

  1. לתאר פתרון במקום צורך. "כפתור ירוק בפינה" היא החלטת עיצוב. "המטופל צריך לבטל תור בלי להתקשר" היא דרישה.
  2. לדלג על מה שלא נכלל. בלי הסעיף הזה, כל בקשה חדשה באמצע הפיתוח נראית כאילו הייתה ברורה מההתחלה.
  3. לכתוב רק את המסלול התקין. רוב הוויכוחים עם בית התוכנה הם על חריגים שלא נכתבו.
  4. דרישות בלי תנאי קבלה. בלי "איך יודעים שזה עובד" אי אפשר לסגור דרישה.
  5. מדדים בלי ערך בסיס. אם לא מדדתם לפני העלייה, לא תדעו אם המערכת שינתה משהו.
  6. להשאיר את האפיון לבית התוכנה. מי שבונה נוטה לכתוב את מה שנוח לו לבנות. מי שמזמין צריך לכתוב מה הוא צריך.

לפני שמוסרים את המסמך לפיתוח

אם עוד לא ברור מה צריך לבנות, או שיש מוצר קיים ולא ברור מה לתקן בו קודם, אודיט המוצר עונה על זה לפני שכותבים אפיון. לאפיון חוויית המשתמש ולעיצוב: ייעוץ מוצר ו-UX.

לשיחה עם הצוות בוואטסאפ