פיתוח מוצר חומרה ותוכנה: למה דווקא השילוב הוא הבעיה

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

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

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

הגדרת ממשקים: המסמך שמציל את הפרויקט

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

מי מתאם בין הצוותים

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

אבני דרך משולבות, לא נפרדות

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

שורה תחתונה: לקנות אינטגרציה, לא רכיבים

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

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