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

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

מה זה אפיון אתר, ולמה הוא קובע את המחיר

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

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

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

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

מי כותב את האפיון: אתם, יועץ או הספק

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

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

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

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

מטרות, מדדי הצלחה וקהלים

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

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

מפת אתר ומודל תוכן

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

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

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

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

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

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

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

אינטגרציות וממשקים

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

לכל ממשק כתבו כרטיס קצר עם השדות האלה:

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

נגישות: ת״י 5568 ו-WCAG בכתב

דרישת הנגישות היא אחת הדרישות היחידות באפיון שיש לה מקור משפטי ישיר. תקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות), התשע״ג-2013 קובעות בתקנה 35א שנותן שירות באינטרנט יעמוד בתקן הנגישות לאינטרנט ברמה AA, בכפוף לחריגים שבתקנות. התקן הוא ת״י 5568, ובתקנה 35ה נקבעה חובה לפרסם הצהרת נגישות. יש בתקנות גם פטורים והקלות, ולכן את ההיקף המדויק שחל עליכם בודקים עם יועץ הנגישות ועם היועץ המשפטי.

ת״י 5568 מחולק היום לשני חלקים. לפי עמוד התקן במכון התקנים, חלק 1, נגישות אתרי אינטרנט, פורסם במהדורה מספטמבר 2023 שהחליפה את מהדורת 2021, וחלק 2 עוסק במסמכים דיגיטליים שמפורסמים באינטרנט, כמו קבצי PDF להורדה (נכון לאוקטובר 2026). התקן נשען על הנחיות WCAG של W3C. לפי W3C, הגרסה העדכנית היא WCAG 2.2, ו-WCAG 3 עדיין בשלב טיוטה.

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

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

אבטחת מידע ופרטיות

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

שתי מסגרות שימושיות כאן. לארגון כולו, תורת ההגנה בסייבר לארגון של מערך הסייבר הלאומי בונה תוכנית הגנה לפי הערכת סיכונים, ובין פרקי הבקרות שלה יש גם אבטחת שרשרת אספקה ומיקור חוץ ואבטחה ברכש ובפיתוח. המערך פרסם גרסה מעודכנת שלה ב-2021. לאפליקציה עצמה, תקן OWASP ASVS, שגרסה 5.0 שלו פורסמה במאי 2025 (נכון לאוקטובר 2026), נותן רשימת דרישות אבטחה שאפשר להפנות אליה ולבדוק מולה. את הרמה המתאימה ואת הבקרות שחלות עליכם קובע ממונה אבטחת המידע.

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

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

ביצועים, אחסון ורמת שירות

"האתר יהיה מהיר" היא משאלה. דרישת ביצועים טובה מצטטת את מדדי הליבה של גוגל, שמודדים את החוויה של גולשים אמיתיים: LCP, הזמן עד שהרכיב הגדול בעמוד נטען, עד 2.5 שניות. INP, הזמן עד שהעמוד מגיב לפעולה, עד 200 אלפיות שנייה. CLS, כמה העמוד קופץ בזמן הטעינה, עד 0.1. הספים נמדדים באחוזון ה-75 של הטעינות, בנפרד לנייד ולמחשב (נכון לאוקטובר 2026).

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

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

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

העברת תוכן בלי לאבד את גוגל

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

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

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

תפקידים, אישורים ובדיקות קבלה

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

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

בדיקות הקבלה הן המקום שבו כל מה שנכתב עד עכשיו מתממש. פרק הקבלה באפיון מגדיר:

בעלות על קוד, חשבונות ותוכן, ותוכנית יציאה

זה הסעיף שאף אחד לא קורא בזמן החתימה ושכולם מחפשים ביום הפרידה. ויש לו בסיס משפטי שכדאי להכיר. לפי חוק זכות יוצרים, התשס״ח-2007, ביצירה שנוצרה לפי הזמנה הבעלים הראשון של זכות היוצרים הוא היוצר, אלא אם הוסכם אחרת בין המזמין ליוצר (סעיף 35). למדינה יש הוראה משלה, ולפיה היא הבעלים של יצירה שנוצרה או שהוזמנה על ידה, אלא אם הוסכם אחרת (סעיף 36). וחוזה להעברת זכות יוצרים טעון מסמך בכתב (סעיף 37). המשמעות המעשית לחברה או לרשות: אם לא כתבתם בהסכם מי הבעלים של הקוד, של העיצוב ושל התוכן, ייתכן שהם לא שלכם. את הנוסח ואת ההחלה על הגוף שלכם בודק היועץ המשפטי.

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

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

ותוכנית היציאה היא רשימה של מה נמסר כשההתקשרות מסתיימת, מכל סיבה:

תבנית מסמך אפיון להעתקה

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

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

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

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

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

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

מה עושים עכשיו

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

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

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