שני קהלים, שני צרכים — אפליקציה אחת?

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

מה בעצם צריכה אפליקציית טכנאי לעשות

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

הפתרון החסכוני: מצב טכנאי מוסתר

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

מתי נכון להפריד לשתי אפליקציות

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

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

העלות האמיתית: לא הפיתוח, התחזוקה

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

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

ההחלטה נופלת באפיון

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

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