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