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