כמה עולה לפתח מערכת ווב מותאמת אישית, ולמה הטווח כל כך רחב?

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

תוכן העניינים 7 פרקים ▾

מה נחשב מערכת ומה עדיין אתר

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

עמוד שירותים עם טופס יצירת קשר הוא אתר, גם אם הטופס שולח מייל. מסך שבו לקוח נכנס עם סיסמה, רואה רק את ההזמנות שלו, מוריד חשבונית ומעדכן פרטי משלוח, זו מערכת. הראשון נכנס תחת בניית אתרים ופיתוח וובי שמתומחר החל מ-₪3,800 חד-פעמי לפני מע״מ. השני נכנס תחת פיתוח מערכות WEB מורכבות, במחיר ₪8,000-₪80,000 חד-פעמי לפני מע״מ.

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

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

למה הטווח נמתח על פני עשרות אלפי שקלים

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

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

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

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

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

טבלת המשתנים שמזיזים את המחיר

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

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

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

מצבי קצה: החלק שאף אחד לא מתמחר בפגישה הראשונה

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

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

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

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

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

הרשאות וממשקים, שני הסעיפים היקרים ביותר

הרשאות

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

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

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

ממשקים למערכות אחרות

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

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

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

איך אפיון מוקדם מכווץ את הטווח

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

סדר העבודה שאני עובד לפיו:

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

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

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

מתי מוצר מדף מנצח פיתוח מותאם

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

• כשהתהליך שלכם דומה לתהליך של אחרים. ניהול לידים, חתימה דיגיטלית, יומן פגישות, הנפקת חשבוניות. בכל התחומים האלה קיימות מערכות בשלות במנוי חודשי, והן יעשו את העבודה טוב יותר ממה שאבנה לכם בתקציב סביר.
• כשאתם עדיין לא יודעים מה התהליך הנכון. אם עדיין מחפשים את דרך העבודה, אל תקבעו אותה בקוד. השתמשו בכלי גמיש, ורק כשהתהליך התייצב, בנו סביבו מערכת.
• כשמדובר בחנות. מסחר מקוון הוא תחום פתור. בניית חנות וירטואלית מתקדמת על WooCommerce או Shopify עולה ₪5,800-₪35,000 חד-פעמי לפני מע״מ, וזה כמעט תמיד עדיף על פיתוח מנוע מסחר מאפס.
• כשהדרישה זמנית. אם המערכת נועדה לפתור בעיה שתיעלם בעוד חצי שנה, כמו קמפיין או אירוע, פיתוח מותאם הוא השקעה שלא תספיק להחזיר את עצמה.
• כשאין מי שיתחזק. מערכת מותאמת דורשת מישהו שיתקן ויתאים אותה לאורך שנים. עסק שלא מתכוון להקצות לזה תקציב שוטף עדיף שיישאר על מנוי חודשי.

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

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

אם יש לכם רעיון למערכת ואתם לא בטוחים אם הוא פרויקט של ₪8,000-₪80,000 חד-פעמי לפני מע״מ או משהו שאפשר לפתור במנוי חודשי, שווה לשבת על זה חצי שעה לפני שמזמינים אפיון. שלחו לי בהודעת WhatsApp תיאור של התהליך שמעיק עליכם היום ומי משתתף בו, ואגיד לכם בכנות אם זה מקרה לפיתוח או לא. דברו איתי בוואטסאפ ←