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

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

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

המוצר לדוגמה: אפליקציית קריאות שירות

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

מדדי מוצר מוצעים

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

המשתמשים וההרשאות

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

התהליך המרכזי

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

מצבי הקריאה

new → scheduled → accepted → in_progress → pending_review → closed. מצבים חריגים: cancelled לביטול, waiting_parts כשחסר חלק. מעבר בין מצבים כפוף לתפקיד: טכנאי לא סוגר קריאה, מתאם לא מאשר סיכום. ביטול לא מוחק היסטוריה. רשימת המצבים הזאת היא מה שהמפתח יהפוך למודל נתונים, להתראות ולדוחות — ולכן היא שווה יותר מעשר שורות של "המערכת תאפשר".

תכולת הגרסה הראשונה

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

מחוץ לתכולה הראשונית

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

מסכים לדוגמה — כולל מצב ריק וכשל

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

דרישה מלאה לדוגמה: REQ-01 שליחת סיכום ביקור

כך נראית דרישה אחת כשהיא כתובה עד הסוף. שימו לב שרוב השורות עוסקות במה שקורה כשמשהו לא לפי התוכנית — זה בדיוק מה שמפריד בין הצעה ריאלית להצעה שתתייקר באמצע.

“כטכנאי שהוקצה לקריאה, אני רוצה לשלוח סיכום ביקור, כדי שמנהל השירות יוכל לאשר סגירה.”

— REQ-01 — ניסוח הדרישה

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

קריטריוני קבלה

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

REQ-02 שינוי שיבוץ (בקצרה)

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

גבולות שצריך לכתוב במפורש

רשת ונתונים

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

אינטגרציות ותלויות

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

חבילת המסירה

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

שאלות שנשארות פתוחות לאפיון

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

• כמה חברות או יחידות תפעול נכללות, והאם נדרשת הפרדת נתונים ביניהן?
• האם נדרשת אפליקציה בחנויות, או שאפשר להתחיל מממשק Web מותאם למובייל?
• באילו מכשירים ותנאי רשת עובדים הטכנאים בפועל?
• אילו שדות בסיכום באמת דרושים, מי מאשר, ומה תהליך התיקון?
• אילו נתונים קיימים היום ואיך מעבירים אותם?
• מה היקף התמיכה הנדרש ואיך מטפלים במקרה חירום?

איך משתמשים במסמך כדי לקבל הצעות מחיר שאפשר להשוות

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

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

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