תקציב לפיתוח מערכת Web: מה מגדירים לפני הצעת מחיר?

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

מזהים את סוג המערכת

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

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

תרחישי היקף: תפקידים, ישויות, מסכים וחיבורים

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

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

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

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

אומדן ותלויות: ממה המספר תלוי

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

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

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

שאלון תכולה — למלא לפני שמבקשים הצעה

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

1. מי המשתמשים? רשימת תפקידים, כמה אנשים בכל תפקיד, והאם הם עובדים שלכם או משתמשים חיצוניים.
2. מה כל תפקיד עושה במערכת? שלוש עד חמש פעולות עיקריות לכל תפקיד, בשפה של העסק.
3. על אילו "דברים" המערכת עובדת? רשימת הישויות (הזמנה, לקוח, תיק, מסמך) ואילו מצבים יש לכל אחת.
4. איזה תהליך המערכת מחליפה, ואיך הוא מתבצע היום — גיליון, מייל, וואטסאפ, מערכת ישנה?
5. אילו מערכות אחרות צריכות לדבר עם המערכת החדשה? לכל אחת: לאיזה כיוון המידע זורם, ומי אחראי עליה.
6. מה מהנתונים הקיימים חייב לעבור? כמה רשומות, באיזו איכות, ומי יכול לנקות.
7. מה חייב להמשיך לעבוד ביום המעבר, בלי הפסקה אפילו של יום?
8. אילו דוחות או ייצוא נדרשים, למי, ובאיזו תדירות?
9. מי אצלכם יכריע בשאלות תוך כדי הפרויקט, וכמה זמן יש לו לזה?
10. מה לא ייכנס לגרסה הראשונה — גם אם זה ייכנס אחר כך?

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

מה אנחנו עושים בשלב הזה

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

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