ההבדל בין מוצר שאפשר לתקן למוצר שאי אפשר
באג בתוכנה של מוצר שכבר נמכר הוא אירוע שונה לחלוטין בשני מצבים. במוצר שיודע לעדכן את עצמו – מפרסמים גרסה חדשה, וכעבור יומיים הבעיה נעלמה מכל היחידות בשטח. במוצר שאינו יודע – יש שתי אפשרויות: לחיות עם התקלה, או להחזיר יחידות לטיפול בעלות שעולה על הרווח שלהן.
מכיוון שאף מוצר לא יוצא לשוק ללא באגים, יכולת העדכון היא ביטוח – ובמוצרים מחוברים היא כבר סטנדרט מצופה.
מה מרוויחים מעבר לתיקונים
- שיפור לאחר מכירה. מוצר שמשתפר עם הזמן מייצר נאמנות ומצדיק מחיר גבוה יותר.
- יציאה מוקדמת לשוק. אפשר לשחרר עם פונקציות ליבה ולהוסיף בהמשך – גישה שנדונה בפיתוח חומרה בסטארט-אפ.
- עדכוני אבטחה. חובה מעשית, ובשווקים מסוימים גם דרישה רגולטורית – ראו אבטחת מידע במוצר מחובר.
- התאמה ללקוח גדול בלי לשנות חומרה.
מה נדרש בחומרה
עדכון מרחוק אינו תוספת תוכנתית – הוא דרישת חומרה שיש לקבוע בתחילת התכנון:
- זיכרון כפול. מקום לשתי גרסאות קושחה במקביל. זו הדרישה שמכתיבה את בחירת הרכיב, כמתואר בבחירת מיקרו-בקר למוצר.
- ערוץ תקשורת – ישיר לרשת, או דרך אפליקציה בטלפון.
- מנהל אתחול מוגן – קטע קוד קטן שאינו נדרס בעדכון ויודע לשחזר.
- אנרגיה מספקת – עדכון שנקטע באמצע בגלל סוללה ריקה חייב להיות בלתי אפשרי או הפיך.
הכלל שאין לוותר עליו: חזרה לאחור
המנגנון חייב להיות בנוי כך שגם עדכון שנכשל לא ישאיר את המוצר מת. השיטה המקובלת: כותבים את הגרסה החדשה למקום השני בזיכרון, בודקים את שלמותה, ורק אז מפעילים אותה. אם המוצר לא הצליח לעלות – חוזרים אוטומטית לגרסה הקודמת. בלי מנגנון כזה, עדכון פגום שיצא לאלפי יחידות הוא אירוע שאין ממנו דרך חזרה.
אבטחת העדכון
ערוץ עדכון הוא גם ערוץ תקיפה: מי שיכול להזין קוד למכשיר שולט בו לחלוטין. הדרישות המינימליות – חתימה דיגיטלית שהמכשיר מאמת לפני ההפעלה, הורדה בערוץ מוצפן, ומניעת התקנה של גרסה ישנה שיש בה חולשה ידועה. המפתח הציבורי לאימות מוטמע בייצור, וזה מקשר את הנושא לשלב הייצור עצמו – ראו בקרת איכות בייצור.
שחרור מדורג
אין לשחרר גרסה לכל היחידות בבת אחת. הנוהג המקובל: מפעילים על קבוצה קטנה, ממתינים, בודקים שאין עלייה בשיעור התקלות, ורק אז מרחיבים. לשם כך נדרש מנגנון דיווח מהמכשירים – ולו מינימלי – שמאפשר לדעת שהעדכון הצליח.
ניהול גרסאות בשטח
ברגע שמוצרים מתעדכנים בקצב שונה, קיימות בשטח כמה גרסאות במקביל. האפליקציה חייבת לתמוך בכולן, וזה מחזיר אותנו להגדרת הממשק ולתאימות לאחור – נושא שמפורט בממשק בין חומרה לתוכנה. מומלץ לתעד לאילו גרסאות קושחה תואמת כל גרסת אפליקציה, ולנהל זאת כחלק מתהליך השינויים המסודר – ראו ניהול שינויים הנדסי.
לתכנן את חוויית העדכון
הצד הטכני הוא רק חצי. הצד השני הוא מה המשתמש חווה, וכאן מתקבלות שלוש החלטות שמשפיעות ישירות על שיעור המכשירים שיתעדכנו בפועל:
- אוטומטי או מאושר. עדכון שקורה מעצמו מבטיח כיסוי גבוה, אך עלול להפתיע משתמש באמצע שימוש. עדכון שדורש אישור מכבד את המשתמש ומשאיר חלק מהמכשירים מאחור לנצח.
- מתי. מוצר שיודע לבחור רגע שבו אינו בשימוש – ומחובר לחשמל – מונע את רוב התקלות.
- מה רואים. חיווי ברור שהעדכון מתבצע, וכמה זמן הוא ייקח, מונע ניתוק באמצע. מכשיר שנראה תקוע מזמין את המשתמש לנתק אותו מהחשמל.
הכלל המנחה: עדכון אסור שיהיה פעולה שדורשת מהמשתמש להבין משהו. תכנון החיווי הוא חלק מהעיצוב ולא מהקושחה, כמתואר בפיתוח חווית משתמש עבור מוצר חדש.
מה זה עולה
הוספת היכולת מייקרת את הרכיב מעט ומוסיפה עבודת פיתוח ותשתית שרת. מנגד, החיסכון בקריאות שירות ובהחזרות מכסה זאת בדרך כלל כבר בסדרה הראשונה. שיקול העלות מול התועלת שייך לחישוב שמתואר בתמחיר מוצר ועלות ייצור, ולתמונה הרחבה של מוצרים מחוברים בהאינטרנט של הדברים.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
