מה כוללת תחזוקת אפליקציה ואיך מתכננים את התקציב?

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

ארבעת סוגי ההוצאה אחרי ההשקה

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

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

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

מה כולל שירות תחזוקה — ומה לא

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

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

איך מגדירים SLA — בלי מספרים

SLA (Service Level Agreement) הוא החלק בהסכם שאומר מה קורה כשמשהו נשבר. יש בו שלושה חלקים, וכולם צריכים להיות כתובים — אבל הערכים שבהם הם עניין להסכם, לא למדריך.

1. חלון השירות

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

2. דרגות חומרה

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

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

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

3. שלושה זמנים — לא אחד

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

דוח תחזוקה לדוגמה — מה צריך להיות בו

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

איך בונים את תקציב התחזוקה השנתי

לא מאחוז. מרשימה. סדר העבודה:

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

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

מה לבדוק לפני החלפת ספק תחזוקה

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

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

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

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

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