תחזוקת תוכנה: כמה זה עולה ומה קורה בלעדיה

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

למה מערכת שעובדת בכלל צריכה תחזוקה

זו שאלה הוגנת. המערכת נבדקה, היא עובדת, למה שמשהו ישתנה.

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

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

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

מה נחשב תחזוקה ומה כבר פיתוח חדש

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

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

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

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

טווחי מחירים בשוק הישראלי

הכלל המקובל בתעשייה הוא 15 עד 20 אחוז מעלות הפיתוח בשנה. הוא לא מדויק אבל הוא נקודת פתיחה סבירה. בפועל:

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

SLA: המספרים שקובעים את איכות השירות

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

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

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

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

מה באמת קורה כשמוותרים

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

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

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

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

איך בוחרים חבילה

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

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

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

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

שאלות נפוצות