הדור השני יצא — והדור הראשון עדיין אצל הלקוחות
זה קורה לכל מוצר חומרה מצליח: יוצאת גרסה משופרת, עם חיישן חדש ויכולות נוספות — אבל אלפי יחידות מהדור הקודם ממשיכות לעבוד בשטח, ולקוחות ששילמו עליהן כסף טוב מצפים שהאפליקציה תמשיך לשרת אותם. תאימות אפליקציה לגרסאות מוצר היא בדיוק האתגר הזה: אפליקציה אחת בחנות, שמולה שלושה דורות חומרה, חמש גרסאות קושחה ואינספור שילובים ביניהם. מי שלא מתכנן לזה מראש מגלה את הבעיה בדרך הקשה — עדכון אפליקציה ששובר את המוצר אצל חלק מהמשתמשים, וגל ביקורות של כוכב אחד.
למה השילובים מתרבים כל כך מהר
- דורות חומרה. רכיב שהוחלף בגלל מחסור, חיישן ששודרג, מיקרו-בקר חדש — גם שינוי "שקוף" מייצר הבדלי התנהגות.
- גרסאות קושחה. לא כל המשתמשים מעדכנים: חלק מהמכשירים בשטח ירוצו על קושחה ישנה עוד שנים.
- קצב עדכון שונה. אפליקציה מתעדכנת בלחיצת כפתור; קושחה דורשת תהליך DFU שלא כולם משלימים — כמו שתיארנו במאמר על עדכון קושחת המוצר מהאפליקציה.
- מערכות ההפעלה זזות תחת הרגליים. גם iOS ואנדרואיד משתנים כל הזמן — הרשאות בלוטות', מדיניות ריצה ברקע וכללי חנויות מוסיפים ממד רביעי למטריצת השילובים.
עקרון הזהב: לשאול את המוצר מה הוא יודע, לא מי הוא
הטעות הקלאסית היא קוד מלא תנאים בסגנון "אם זה דגם 2 — תעשה כך". הגישה הנכונה היא גילוי יכולות (Capability Discovery): בתחילת החיבור האפליקציה שואלת את המוצר אילו יכולות הוא תומך — והממשק נבנה לפי התשובה, לא לפי מספר הדגם. כמה כללים שחוסכים שנים של כאב:
- גרסה לפרוטוקול, מהיום הראשון. כל הודעה בין האפליקציה למוצר נושאת מספר גרסה, ושני הצדדים יודעים להתעלם משדות לא מוכרים — כך אפשר להוסיף יכולות בלי לשבור ישנים.
- שכבת הפשטה למכשיר. קוד המסכים לא מדבר עם הבלוטות' ישירות אלא עם ממשק אחיד; ההבדלים בין הדורות סגורים במימוש אחד מרוכז ולא מפוזרים בכל האפליקציה.
- Feature Flags בממשק. כפתור של יכולת שלא קיימת בדור הישן פשוט לא מוצג — במקום להציג ולהיכשל.
- גרסת מינימום מוגדרת. האפליקציה יודעת לזהות קושחה עתיקה מדי, ולהוביל את המשתמש לעדכון מסודר במקום לקרוס.
בדיקות: מטריצה במקום מכשיר אחד על השולחן
אי אפשר לדבר על תאימות בלי לדבר על בדיקות. הצוות חייב להחזיק ארון מכשירים אמיתי — יחידה מכל דור חומרה, ועליה גרסאות הקושחה הנפוצות בשטח — ולהריץ עליו את תרחישי הליבה לפני כל שחרור. איך בונים תהליך כזה בצורה שיטתית תיארנו במאמר על איך בודקים אפליקציה מול חומרה אמיתית. בצד המוצר, ניהול מסודר של מה שרץ בשטח הוא תנאי מקדים — על כך במאמר על ניהול גרסאות קושחה בייצור ובשטח. ונתוני אנליטיקה מהאפליקציה — אילו דורות ואילו גרסאות באמת פעילים — הם שמאפשרים להחליט על סמך מציאות ולא ניחוש, כמו שהסברנו במאמר על מדידה ואנליטיקה באפליקציה.
מתי מפסיקים לתמוך בדור ישן
תמיכה לנצח בכל דור היא לא מטרה — היא עול שמאט כל פיתוח עתידי. מוצר בוגר צריך מדיניות סוף-חיים מוצהרת: כמה זמן דור מקבל עדכונים, מה קורה אחר כך, ואיך מודיעים ללקוחות מראש. ההחלטה הזו היא חלק מתמונת העלות הכוללת של חיי האפליקציה, שפירטנו במאמר על תחזוקת אפליקציה אחרי ההשקה. כלל אצבע הוגן: מודיעים מראש תקופה מוגדרת, מציעים ללקוחות פעילים מסלול שדרוג, ומשאירים את יכולות הליבה לעבוד גם אחרי הפסקת העדכונים — הפסקת תמיכה היא לא כיבוי המוצר של הלקוח.
לתכנן את הדור הבא כבר בדור הראשון
ההבדל בין מוצר שמזדקן בכבוד למוצר שנשבר בכל שדרוג נקבע בהחלטות הארכיטקטורה של הגרסה הראשונה. אנחנו בפרוג'קטס האוס מתכננים את שכבת התקשורת והאפליקציה מראש לריבוי דורות — כי כל מוצר מצליח יגיע לשם. המחיר של התכנון הזה בגרסה הראשונה נמדד בימים ספורים; המחיר של תיקון בדיעבד, כשאלפי מכשירים כבר בשטח, נמדד בחודשים. מדריכים נוספים מחכים לכם באשכול פיתוח אפליקציות.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
