תכנון ופיתוח של מוצרים אלקטרוניים לעומת מוצרים דיגיטליים

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

מה הפירוש של מוצר ל ...

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

כאשר מפתחי תוכנה החלו לבנות מוצרים דיגיטליים, לפני כ- 25 שנה, הם השתמשו בתהליכים וכלים דומים ששימשו לבניית מוצרים פיזיים. התהליך המוכח ביותר לניהול פרויקטים באותה תקופה היה מפל מים, שכן הוא הבטיח שלמות לאורך מחזור הפרויקט. אולם ככל שמנהלי פרויקטים דיגיטליים צברו ניסיון רב יותר ונכשלו כמעט במחצית מהפרויקטים, הם הבינו שהם צריכים שינוי. הם התחילו לבנות כלים משלהם וגילו את התהליכים הלא שגרתיים הייחודיים שלהם. בסביבות 2001, יותר ויותר צוותים החלו להשתמש בסרום וקאנבן והמניפסט הזריז צץ. גיטרה נוצרה על ידי לינוס טורוואלדס בשנת 2005, שהניחה את הבסיס לפרויקטים של קוד פתוח. אולי למוצרים דיגיטליים השלמות אינה חשובה כמו זריזות. כיום, כעבור 25 שנה, תהליכי הפיתוח, הכלים והתרבויות של שני צוותי המוצרים הם רחוקים זה מזה.

במהלך חמש השנים האחרונות, היה קל מאוד וזול להטמיע אלקטרוניקה במוצרים פיזיים ולחבר אותם לאינטרנט לאיזה סוג של אפליקציה - טרנד המכונה IOT (אינטרנט של דברים). זה עושה בערך 2 $ למוצר לעשות זאת, מה שמסביר מדוע אנו רואים כל כך הרבה מוצרי IOT חדשים צצים לאחרונה, חלקם די משעשעים ... ברמת צוות המוצר, מגמה זו מאגדת שני סוגים של תרבויות, שני סוגים של תהליכים ו שני סוגים של כלים. בכל פעם ששתי תרבויות מתנגשות, דברים מעניינים מתחילים לקרות. חומרת קוד פתוח נמצאת סביבנו כעת, ויש אנשים שהתחילו לקרוא לעצמם יצרנים. מה ההבדל בין יצרן ליצרן? האם אנו הולכים לראות התכנסות בין תהליכים אלה? או שאנחנו נידונים, כמנהלי מערכות ניהול ומנהלי IOT לגשר בין תרבויות אלה לנצח?

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

תפקידים ומיומנויות

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

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

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

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

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

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

ניהול פרוייקט

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

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

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

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

תכנון ואב-טיפוס

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

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

אבות-טיפוס: בעזרת מדפסות תלת מימד וטכנולוגיית VR / AR, קל מאוד להגיע עם אב-טיפוס מכני של המוצר הפיזי שלך. אתה יכול להראות לו את הלקוחות שלך, לשים עליו כמה מדבקות, לחבר כמה חוטים ונורות LED, הם יבינו מייד את מטרתם וייתכן שתוכל לשכנע אותם שהמוצר שלך מוכן ומסחרי. אתה יכול למקם אותו בסביבה האמיתית ולראות אם הוא מתאים מכנית ואם קל להחזיק אותו. אתה יכול ליצור עשר גרסאות ולהשוות ביניהן ולהחליט על התצורה הסופית. אין דבר חזק יותר מאשר לתת ללקוחות ולמשקיעים שלך משהו להחזיק בידם. אנשים אוהבים צעצועים ודברים מוחשיים ולמרות שהעיצוב המכני הוא לפעמים רק 1% מהתוצר הסופי מבחינת זמן פיתוח, אנשים יאמינו שכבר השלמתם 80% ממנו. עם טיפוס-טיפוס של תוכנה לא קל להגיע לרמה זו. סקיצה ו- InVision הם כלים נהדרים, אך המשתמשים מבינים מיד כי אין מדובר במוצר אמיתי. הנתונים הם סטטיים ולאינטראקציה שלהם אין השפעה עליהם. זו חלק מהסיבה שמנהלי מוצרים דיגיטליים אימצו את הגישה הזריזת ואת הרעיון של MVP. קשה מאוד לדמיין כיצד משתמשים יפעלו באינטראקציה ויאהבו את המוצר שלך לפני שיהיה מוכן ויש לו נתונים אמיתיים, כך שאתה רוצה לשלוח אותו כמה שיותר מהר ולהתחיל לאסוף משוב אמיתי.

אב טיפוס פיזי ודיגיטלי

התפתחות

להחלטות מוקדמות יש את ההשפעה הגדולה ביותר: בכל פעם שאני מתחיל פרויקט חדש, אני מתרגש. מה תהיה הארכיטקטורה הנכונה? איזו טכנולוגיה תהיה המתאימה ביותר לה? האם עלינו לבחור ב- MCU של 8 סיביות או במעבד 32 סיביות? האם מדובר בפרויקט טוב להצגת GraphQL, או שנחזיק שוב ב- REST? איזו טכנולוגיה אלחוטית מתאימה ביותר למקרה השימוש: Bluetooth 5 או IOT? מה המאגר הנכון לשימוש? PostgreSQL או אולי מסד נתונים גרפי הפעם? החלטות אלה חשובות כל כך להצלחת הפרויקט. לפעמים, אנו מקבלים החלטות טכניות מהר מדי ללא ניתוח נכון ואז שלושה חודשים אחר כך אנו מתחרטים עליהם, נעשה קשה וכואב מדי לשנות אותם, וקל יותר להסתכל על ההשקעה הטכנולוגית כנכס ולא כמחסם. זה נכון גם למוצרים אלקטרוניים וגם למוצרים דיגיטליים, אם כי שינוי סוג המעבד לאחר משלוח המוצרים שלך ללקוחות שלך הוא כמעט משימה בלתי אפשרית אם לא מביכה.

להחלטות מוקדמות יש את ההשפעה הגדולה ביותר

פיתוח: ישנם הבדלים רבים בין תהליך הפיתוח של מוצרים אלקטרוניים למוצרים דיגיטליים, ואין הרבה קווי דמיון. רוב זמן הפיתוח של לוח PCB עובר לבחירת הרכיבים הנכונים ולעיצוב הפריסה. חלק מהעבודה היא טכנית גרידא, ומחברת חוטים ממחסור U1 120 למרכיב U17 סיכה 12. וחלק מהמשימות דורשות אבות טיפוס מלאים סביב שלושה סוגים של חיישנים רק כדי למדוד את הרעש וצריכת החשמל של כל אחד מהם. קשה לבצע איתור באגים ולביצוע אופטימיזציה של פיתוח משובץ, זה די מקובל לראות מפתחים משובצים המשתמשים בסיכות GPIO כדי לזהות אם נקראה פונקציה וכדי למדוד כמה זמן לקח לרוץ. השימוש ב- FPGA במוצר האלקטרוני שלך הוא החלטה נועזת אך לעיתים היא הפיתרון היחיד להגיע ליעדי הביצועים / עלות שלך. פיתוח FPGA הוא טריטוריה שונה לחלוטין והוא נמצא איפשהו בין פיתוח ASIC, פיתוח לוח PCB ופיתוח משובץ. עבור מפתחי תוכנה, רוב הזמן מושקע ב ... כתיבת קוד. יש משהו מספק מאוד בהתבוננות בעבודה היומיומית שלך, כל אותם שורות קוד, קוד מתחייב ובקשות משיכה. זה נשמע די פשוט, אך כמות הקוד והשינויים הוא עצום, ולכן תהליך ניהול וביקורת נכון של התצורה חיוני בכדי לשמור על בסיס הקוד מסודר, להפחתת החוב הטכני ולהגדלת הידע בכל הצוות.

אלגוריתמים, פיסיקה ומדעי נתונים: בדרך כלל זהו המוח של המוצר, בו חברות נוטות לטעון שה- IP שלהם נמצא. מעצבי הלוח עובדים עם פיסיקאים כדי לבחור חיישנים, לעצב AFE (חזית אנלוגית) סביבם או לתכנן אנטנה מיוחדת. מפתחים משובצים עובדים עם מהנדסי DSP ומתמטיקאים כדי להטמיע אלגוריתמים של DSP בזמן אמת בתוכנה שלהם כדי לסנן אותות, לאתר דפוסים או ליישם איזו נוסחה מתמטית אופטימלית לעיבוד / קידוד הנתונים. זמן אמת פירושו שעליך להשלים את העיבוד בכמות מסוימת של מחזורי מעבד, אחרת לא תהיה מוכן לעבד את האות הבא ולהחמיץ אותו או שלא תוכל להפיק אירועים בטווח ההמתנה הנדרש. מפתחי Backend עובדים עם מדעני נתונים כדי ליישם תהליכי אצווה כדי להמליץ ​​על מוצרים חדשים, למצוא חריגות, להציע לחברים, להכשיר מודל למידה עמוקה, להשתמש ב- NLP לניתוח טקסט, ציון דפי אינטרנט וכו '. למפתחי Frontend יש את כל הכיף. הם מבצעים הדמיה של נתונים. בעזרת ספרייה כמו D3JS, הם יוצרים חזותיים מדהימים ומציגים את הנתונים למשתמשים באופן שימושי ומצטבר.

מעבר לערימה אנשים אלה יטפלו בהפחתת רעש, בשיפור האותות ובמציאת האיזון הנכון בין איתור פספוס (שלילי כוזב) לבין אזעקת שווא (שקר חיובי), הם יבכו שהם זקוקים ליותר נתונים או יבצעו יותר ניסויים, והם יקפצו בשמחה אם הם יצליחו לשפר את הביצועים ב -5%. החלטה מעניינת של המוצר היא להחליט כיצד לפצל את המשימות למדעי הנתונים על פני הערימה. כדוגמה, אלכסה כוללת מערך של מיקרופונים ברמת הלוח, קוד DSP כלשהו ברמת הקושחה ומדעי נתונים מתוחכמים ברמת backend כדי להכיר את הדיבור שלנו.

כלים: דמיינו מפתח קדמי ומפתח משובץ שמשווים את כלי הפיתוח שלהם זה לזה. היזם המשובץ יוביל את מפתח החזית לשולחן שלו ויציין את ההבדלים בין ספק כוח, אוסצילוסקופ ומנתח לוגי. לאחר מכן מפתח הפרונטנד ייקח את היזם המשובץ למקום הקפה הקרוב ביותר. הם יזמינו קפה וימצאו מקום שקט בו יוכלו לבלות יחד כמה שעות. לאחר מכן היא / היא יעבירו את דפדפן ה- Chrome שלהם למצב פיתוח ויציג למפתח המשובץ כיצד להסתכל על תנועת הרשת וכיצד לראות את סגנון ה- CSS של אלמנט HTML מסוים.

מה הפירוש של כלי עבודה ל ...

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

מה הפירוש של כלי ניפוי ובדיקה ל ...מפתחי תוכנה מוצאים את זה מאיים

QA ובדיקות

בדיקות סביבתיות: כאשר אנו בודקים את המוצר שלנו, אנו רוצים לאמת שהוא מתפקד כראוי בכל התצורות והסביבות השונות שהמשתמשים מצפים להשתמש בו. עבור מוצרים פיזיים, סביבה פירושה בדרך כלל טמפרטורה (קור קיצוני, חם במיוחד), רטט (דמיין מוצר רכב), הלם (נופל מידיך לרצפת בטון), לחות, קרינת UV ושמש, ESD (ברקים קטנים אלה שמגיעים מפריקה אלקטרו-סטטית), EMI / RFI וכו '. לסביבה של מוצרים דיגיטליים פירושו בדרך כלל סוג דפדפן (Chrome, Internet Explorer, Firefox ..), מערכת הפעלה (אנדרואיד, IOS, OSX, Windows), מכשיר (נייד, שולחן עבודה, ועידה) מסך) ורמת קישוריות רשת (4G, Wifi, לא מקוון). בדרך כלל אנו לא בודקים כל שילוב אפשרי מכיוון שלא ניתן יהיה לעשות זאת, ולכן אנו מציעים מערכת תצורה שתקווה לכסות מספיק תרחישים שיוכלו לאתר בעיות בתוך המפרט של המוצר.

מה הפירוש של סביבה חיצונית ל ...

אמינות / עמידות (מבחן מחזור חיים): אלה בדיקות שמנסות לדמות את מה שקורה למוצר במהלך כל חייו. זה רלוונטי יותר למוצרים פיזיים שבהם החומרים מגיעים לנקודות הכושלות שלהם. ישנם כללים מסוימים שהתעשייה המציאה אותם כדי לעזור לנו להאיץ את עידן המוצר על ידי חשיפתו לתנאים סביבתיים קיצוניים. בעיקרון, כדי לבדוק אם מוצר מתפקד כראוי לאחר חמש שנים בטמפרטורת החדר, נוכל לבדוק אותו ב 70 מעלות ו 10 גרם רטט למשך יום אחד (דוגמא בלבד !!!). אלה נקראים בדיקות HALT (מואצות מאוד בחיים)

בדיקות בתנאים קיצוניים (עומס, קצה): אלה בדיקות הבודקות את התנהגות המוצר בתנאי קיצון או קצה. לדוגמה, אם מוצר אלקטרוני עובד על 5 וולט, אנו נבדוק אותו על 4.5 וולט ו -5.5 וולט, אנו עשויים אפילו להזריק דוקרני מתח עד 25 וולט או -5 וולט כדי לבדוק אם המוצר עמיד בפני טעויות משתמשים או נחשולי חשמל. עבור מוצרים דיגיטליים אנו עשויים לאתגר שדות קלט עם ערכים בלתי סבירים. לדוגמאות אנו עשויים להזין שמות שאורכם 1000 תווים, או שיש להם סמלים חסרי משמעות. אם עיצבנו את המוצר לעומס מסוים (50 משתמשים במקביל), נבדוק את התנהגותו תחת 100 משתמשים במקביל. הרעיון של בדיקות אלה הוא בעיקר לחשוף מצבי כשל חדשים. אנו לא מצפים שהמוצר יעבוד בצורה מושלמת, אך אנו עשויים לגלות סוגיות חשובות, התנהגויות בלתי צפויות או צווארי בקבוק הרלוונטיים גם לתנאים רגילים.

בדיקות ציות / אבטחה: שני סוגי המוצרים נדרשים, לעיתים, לעמוד בתקנים ולהיות תואמים להם. מוצרים אלקטרוניים צריכים להיות בטוחים, מאובטחים ואמינים ולהגן על המשתמש מפני התחשמלות או התחממות יתר (UL, CE, FCC ..), הם גם צריכים לעמוד בתקנים אלחוטיים מסוימים כמו Wifi או Bluetooth. מוצרים דיגיטליים המטפלים במידע המאפשר זיהוי אישי (PII) כמו מספרי כרטיסי אשראי (PCI, ISO / IEC 27001, NIST) או מספרי ביטוח לאומי (GDPR) חייבים להגן על הנתונים מפני כל סוג של התקפות ורשלנות עובדים. עבור שני המוצרים, תהליך הציות הוא יקר וארוך, אך יש דרכים להפחית את העלות ולהשתמש במודולים ושירותים שאושרו מראש.

מה המשמעות של ציות ל ...

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

באופן דומה, עם תוכנה, שיטה טובה היא לכתוב קוד בדיקה המכסה לפחות 99% מהקוד שלך. לפני פריסת קוד חדש לסביבת הייצור, כלי אוטומציה מריץ את חבילת קוד הבדיקה ולאמת שמה שאי פעם עבד לפני כן, עדיין עובד. בשני המקרים שעובדים על כלי בדיקה אלה צריכים להתחיל יחד עם פיתוח המוצר (לפעמים אפילו לפני: TDD) ויש לקבל משאבים ראויים לכך.

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

ניהול תצורה: CM הנו הנוהג של טיפול בשינויים באופן שיטתי. הוא משמש לתיעוד גרסאות של המוצר ולעקוב אחר שינויים שחלו עליו בין גרסאות. מערכת ניהול תצורה טובה תאפשר לבנות ולבדוק כל גרסה של המוצר באמצעות רק חפצים שנמצאים בו ללא כל ידיעה חיצונית אחרת. מהנדסי DevOps משתמשים בכלי SCM (ניהול תצורת תוכנה) כמו GIT, Ansible, Terraform, Chef כדי לתעד את הקוד, התצורה והתשתית של המוצר. הם עשויים גם לקשור שינויים אלה לנושאי JIRA כדי לתעד את הקשר בין בקשת הבאג / פגם / תכונה לבין השינויים בפועל שנבעו מכך. מהנדסים אלקטרוניים משתמשים בכלים המכונים לפעמים PLM (ניהול מחזור חיים של מוצרים) ולעיתים HCM (ניהול תצורת חומרה). בעיקרו של דבר הם משרתים את אותה מטרה, אך הם כוללים שילובים ותהליכים שונים. לדוגמה, מערכת PLM עשויה גם להשתלב במערכת ה- ERP שלך כדי להראות אילו חלקים מ- BOM של המוצר נמצאים במלאי שלך.

ייצור והפקה

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

Lean Lean הוא כל מה שקשור לחיסכון בעלויות. עבור מוצרים פיזיים, רזה פירושו:

  • עיכוב אפס בכל שלבי קו הייצור
  • ליקויי שכר, האיכות הגבוהה ביותר עבור כל מוצר סופי
  • 100% מכונות / אנשים מנוצלים
  • משוב ידע: כל שיעור ותובנות משפרים את התהליך
  • ייצור בזמן בדיוק: כל מוצר נמכר ללא פסולת

עבור מוצרים דיגיטליים פירושו רזה:

  • קנה מידה אוטומטי: סולם משאבי חישוב המבוסס על העומס
  • שלם לשעה

ייצור צנרת: הגדרת קו הרכבה אינה שונה מדי מהגדרת צינור CI / CD תוכנה (אינטגרציה רציפה / מסירה רציפה). אם קראת את ספר הפרויקטים של פיניקס, סביר להניח שתזכור כיצד חלק מהמושגים רזים ו- DevOps נגזרו בספר מקו הייצור הפיזי. שתי הצינורות מטפלים בכל מה שנדרש כדי לבנות, לבדוק ולשלוח את המוצר שלך. ככל שתוסיפו אוטומציה נוספת, תוכלו לשלוח מהר יותר. עבור מוצרים אלקטרוניים פירוש הדבר הפחתת עלויות ופגמים ושיפור היכולת, עבור מוצרים דיגיטליים, משמעות הדבר היא בדיקת משתמשים מהירה יותר ועיצוב אדפטיבי.

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

נראה כי נוכחות כלל-עולמית קשה יותר למוצרים פיזיים, עם זאת, ויסות הגנה על נתונים ומיקום שפה דורשים גם מאמץ משמעותי

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

סיכום

ישנם הבדלים רבים בין תהליך הפיתוח של מוצרים אלקטרוניים לבין אלה הדיגיטליים, אך אם מסתכלים על זה מנקודת מבט של 20 שנה, מדהים לראות כמה עקרונות העיצוב והתהליכים של מוצרים דיגיטליים משמשים כיום על ידי מנהלי מוצרים פיזיים. AWS הודיעה לאחרונה על FreeRTOS למערכות משובצות. אני צופה שבעוד 10-20 שנים לא יהיה הבדל משמעותי בין תהליך הפיתוח של מוצר דיגיטלי לזה הפיזי.

אם תרצה לדעת יותר על המסע שלי ואיך לנהל צוות שחי בשני העולמות, אל תהסס לפנות אלי ישירות.