تصميم وتطوير المنتجات الالكترونية مقابل المنتجات الرقمية

كنت محظوظًا بتطوير وإدارة تطوير المنتجات المادية والمنتجات الرقمية. عندما أشارك الحب والعاطفة لكليهما ، فكرت في تقديم آرائي وبعض الملاحظات حول الاختلافات والتشابهات بين عمليات التطوير الخاصة بهم.

ما معنى المنتج لـ ...

ما هو المنتج؟ شيء يتم تصنيعه وبيعه ، أو شيء ما يخلق قيمة للمستخدمين؟ ينطبق التعريف الأول فقط على المنتجات المادية ويعكس ما نقوم به مع المنتجات وكيفية بنائها. التعريف الثاني أكثر انفتاحًا وحداثة ويعكس سبب حاجتنا إلى المنتجات. المنتجات المادية ملموسة. يمكن للمستخدمين لمسهم ، رؤيتهم ، شمهم وشعورهم. لقد شاهدنا جميع مقاطع الفيديو الخاصة بالمصانع الضخمة ويمكننا أن نفهم مدى كلفتها وتعقدها. المنتجات الرقمية تعيش في السحابة أو في مراكز البيانات البعيدة. يصعب علينا فهم حجمها وتعقيدها وما يعنيه بناء واحد. على سبيل المثال ، إذا نظرنا إلى الواجهة الأمامية لبحث Google ، يمكننا فقط رؤية سطر بحث واحد ، ولكن خلف الكواليس ، في الخلفية ، هناك مئات الآلاف من الخوادم التي تعمل ومليارات من سطور الأكواد.

عندما بدأ مطورو البرامج في بناء منتجات رقمية ، قبل حوالي 25 عامًا ، استخدموا عمليات وأدوات مماثلة تم استخدامها لإنشاء منتجات مادية. كانت أكثر عملية أثبتت جدواها لإدارة المشروع ، في ذلك الوقت ، هي Waterfall لأنها ضمنت الكمال طوال دورة المشروع. ومع أن مديري المشاريع الرقمية اكتسبوا المزيد من الخبرة وفشلوا في نصف المشاريع تقريبًا ، فقد أدركوا أنهم بحاجة إلى التغيير. بدأوا في بناء أدواتهم الخاصة وتوصلوا إلى عمليات فريدة غير تقليدية. في حوالي عام 2001 ، بدأ عدد أكبر من الفرق في استخدام سكروم وكانبان وظهر البيان الرشيق. تم إنشاء Git بواسطة Linus Torvalds في عام 2005 والتي وضعت الأساس لمشاريع مفتوحة المصدر. ربما بالنسبة للمنتجات الرقمية الكمال لا يقل أهمية عن خفة الحركة. اليوم ، بعد مرور 25 عامًا ، أصبحت عمليات التطوير والأدوات والثقافات الخاصة بفرق المنتج بعيدة عن بعضها البعض.

خلال السنوات الخمس الماضية ، أصبح إدخال الإلكترونيات في المنتجات المادية سهلاً للغاية وغير مكلف للغاية وربطها بالإنترنت بشيء من أنواع التطبيقات - وهو اتجاه يطلق عليه IOT (إنترنت الأشياء). يتطلب الأمر القيام بحوالي 2 دولار لكل منتج ، وهذا ما يفسر سبب ظهور الكثير من منتجات IOT الجديدة في الآونة الأخيرة ، بعضها مثير للغاية ... على مستوى فريق المنتج ، يجمع هذا الاتجاه نوعين من الثقافات ونوعين من العمليات و نوعين من الأدوات. عندما تصطدم ثقافتان ، تبدأ أشياء مثيرة في الحدوث. الأجهزة مفتوحة المصدر موجودة حولنا الآن ، وبدأ بعض الأشخاص في تسمية أنفسهم صناع. ما هو الفرق بين صانع والشركة المصنعة؟ هل سنرى تقاربًا بين هذه العمليات؟ أم أننا محكوم علينا ، بوصفنا مديري CTOs ومديري منتجات IOT للربط بين هذه الثقافات للأبد؟

آمل أن تجد هذه المدونة ممتعة ومفيدة وأن تساعد المطورين من جميع أنحاء المجموعة على فهم تحديات بعضهم البعض.

الأدوار والمهارات

يوجد اتجاه حديث لمطوري البرامج لتطوير مجموعة البرامج الكاملة. هذا يعني أنهم يطورون كلاً من الكود الخلفي: الكود الذي يتم تشغيله على الخادم / السحابة ، والكود الأمامي: الكود الذي يتم تشغيله على الجهاز. قد يضطلعون بدور DevOps: المهندسين المسئولين عن إعداد النظام وتكوينه وتأمينه ثم أتمتة عملية التغيير. ليس من المستحيل على شخص واحد إنشاء وتشغيل تطبيق رقمي بسيط أو لعبة. ومع ذلك ، عند النظر إلى منتجات IOT التي تتضمن عادةً كلاً من جهاز إلكتروني وبعض أنواع التطبيقات ، يحتاج الفريق الفني إلى المزيد من المهارات والأدوار.

المطورين المضمنون هم المسئولون عن الكود الذي يتم تشغيله على الجهاز ، ويكون مصممو اللوحة مسؤولين عن تطوير اللوحة الإلكترونية.

على الرغم من اليوم ، وبمساعدة Espruino ، يمكن لمطوري Javascript تطوير نظريًا لجميع مستويات الشفرة الثلاثة: الكود الأمامي ، الكود الخلفي والرمز المضمن ، من المحتمل أنهم سوف يصارعون مع التصميم الصناعي واللوح الذي يتطلب أنواعًا مختلفة تمامًا من المهارات. لقد رأيت مطورين موهوبين يمثلون جميع المهن ، ويمكنهم الانتقال بسرعة من تعديل فئات CSS إلى كتابة نصوص الترحيل لقواعد البيانات الخاصة بهم. أنا شخصياً أعتقد أن المطورين المحترفين يجب أن يتقنوا في أي وقت من الأوقات طبقة واحدة فقط. الأمر لا يقتصر على امتلاك أفضل المهارات والتقنيات أو لتنفيذ الوظيفة المطلوبة ، بل يتعلق أيضًا بما يهمك وبأي حالة ذهنية تقوم بها في عملك.

لقد قمت بمحاولة لوصف مسؤوليات كل دور في الفريق. أقدر أنني دخلت منطقة خطرة لأن الأدوار قد تتغير قليلاً في فرق مختلفة ، لذا يرجى محاولة رؤية الغابة وليس الأشجار.

لماذا لا يهتم شخص واحد بهذا كله؟ نظرًا لوجود مفاضلات وتعارضات في تطوير المنتج ، وتريد أن تمثل كل حاجة بطريقة متوازنة ومتماثلة.

على مر السنين رأيت الاحترام بين أنواع مختلفة من المطورين ، ولكن أيضًا نقص المعرفة. لقد رأيت مطوري الواجهة الأمامية الذين يعتقدون أن الواجهة الخلفية سهلة ، والمطورين الذين يعتقدون أن الواجهة الأمامية مملة. لقد رأيت أيضًا مطورين مضمنين لا يعرفون ماهية REST. لقد ذكرت من قبل أنني لا أعتقد أن على المطورين والمهندسين المحترفين أن يتقنوا أكثر من طبقة واحدة. ومع ذلك ، فأنا أؤمن إيمانا راسخا بأنه ينبغي لهم أن يعرفوا ما يعنيه أن يكونوا واحداً ، بل وربما يخطوا خطوة أخرى ويعملون على مشروع بسيط يعرضهم للتحديات والعمليات المختلفة. يمكن أن تساعد المعرفة الواسعة في تحسين التواصل والاحترام والشفافية بين أعضاء الفريق ، وستزيد أيضًا من الإبداع والإنتاجية للفريق ككل.

ادارة مشروع

ما هو الفرق بين المشروع والمنتج؟ المشروع عبارة عن خطة للوصول إلى هدف معين أو نطاق معين خلال فترة زمنية معينة وقيود الموارد. المشروع له بداية ونهاية. إذا لم يكن لديك موعد نهائي للمشروع ، فمن المحتمل أنك لا تدير مشروعًا. عندما ينتهي المشروع ، يستمر المنتج في العيش.

تحليل المخاطر: دعونا نناقش الاختلافات والتشابهات بين إدارة مشروع منتج مادي ومنتج رقمي. أنا شخصياً أحب أن أفكر في إدارة المشروع كعملية تعتمد على المخاطر حيث أقوم دائمًا بتحديد أهم المخاطر وأحاول الخروج بخطة لتقليلها إلى الحد الأدنى. مخاطر المشروع هي أي شيء يؤثر على نجاح المشروع ، أي الفشل في تحقيق الهدف أو الموعد النهائي أو النطاق أو التكلفة أو الجودة النهائية للمنتجات. بالنسبة للمنتجات الرقمية ، يتمثل أحد أكبر المخاطر في إنشاء منتج لا يحتاجه المستخدمون أو يعجبهم. يتخيل مديرو المنتجات الرقمية قصة جيدة ، ويؤمنون بها ويتكهنون بها ، ولكن حتى يبدأ المستخدمون في التفاعل مع المنتج ، هذه مجرد افتراضات. لاختبار الافتراض ، يجب على مديري المنتجات شحن سريع واختبار فرضيتهم وتكون سريعة الحركة. بالنسبة للمنتجات المادية ، يتمثل الخطر الأكبر في العثور على مشكلة لا يمكن إصلاحها في مرحلة متأخرة للغاية ، بعد تصنيع مئات وآلاف المنتجات بالفعل. التصنيع يتطلب الكمال ، وبدون ذلك سوف يفشل المشروع. لتقليل هذا الخطر ، يقوم مدراء المشاريع المادية ببناء عملية مراجعة وتوقيع بين المراحل التي تسمى Waterfall.

تم تصميم كل طريقة لتقليل المخاطر المختلفة ، ويجب أن يقرر كل مدير مشروع خطة المشروع بناءً على تحليل المخاطر. في بعض الأحيان يكون الأفراد والتفاعلات أكثر أهمية من العمليات والأدوات ، وفي بعض الأحيان تكون العمليات أكثر أهمية. أحيانًا يكون برنامج العمل أكثر أهمية من الوثائق ، كما أن الوثائق في بعض الأحيان أكثر أهمية. في بعض الأحيان يكون تعاون العملاء أكثر أهمية من العقد المكتوب. وفي بعض الأحيان يمكن أن ينقذ العقد المكتوب شركتك. في بعض الأحيان تكون الاستجابة للتغيير مهمة ، ولكن في بعض الأحيان يكون اتباع الخطة أكثر أهمية. أنت تحصل على ما أعنيه.

الأدوات والاحتفالات الجماعية: يجب على مديري المشاريع استخدام الأدوات التي تنفذ العملية التي يريدون من خلالها إدارة المشاريع. يعتبر Microsoft Project أداة رائعة لمشاريع الشلال. تعد JIRA و Trello من الأدوات الرائعة للمشاريع الرشيقة وعمليات الدعم مثل Kanban و Scrum. مهما كانت الأداة ، تذكر أنها مجرد أداة وليست جوهرًا. الفرق لديها أيضا احتفالات مختلفة. في Waterfall ، تجتمع الفرق قبل كل خريف وتراجع الوثائق ، مخرجات CAD أو مواصفات الاختبار. قد يجتمع فريق Agile يوميًا في ستاندوب يوميًا وكل أسبوعين للتخطيط لسباق العدو. هذه الاحتفالات محاذاة أعضاء الفريق على الخطة وتحسين التواصل بين أعضاء الفريق.

التصميم والنماذج

التصميم: هل يوجد منتج اليوم لا يلعب فيه التصميم دورًا رئيسيًا في نجاحه؟ ما هو المنتج إن لم يكن شيء نريد بيعه؟ شيء يجب أن يكون جذابًا وجماليًا ، يمكننا أن نفخر به. لقد ولت الأيام التي كانت فيها الوظيفة والأداء الصحيح كان جيدا بما فيه الكفاية. بالنسبة للمنتجات الإلكترونية ، يجب أن يأخذ التصميم الصناعي في الاعتبار ليس فقط التفاعل البشري وإمكانية الاستخدام وتجربة العملاء ولكن أيضًا الظروف البيئية التي يتم فيها استخدام المنتج وعملية التصنيع (DFM: تصميم للتصنيع). بالنسبة للمنتجات الرقمية ، يجب أن يتناول التصميم أيضًا الأجهزة المختلفة التي قد يعمل عليها البرنامج (المحمول ، سطح المكتب ، الشاشات الكبيرة) وجميع أنواع الأدوار والمستخدمين الذين يتفاعلون معها.

تنطبق أنواع مختلفة من منهجية التصميم على أنواع مختلفة من المنتجات: ينظر تصميم التجربة إلى المنتج كجزء من تجربة ممتعة نرغب في إنشائها ، بمعنى "نحن لا نبيع لعبة ، نبيع تجربة عائلية مدتها ساعة واحدة". سيرى تصميم الخدمة المنتج كجزء من خدمة نهاية إلى نهاية بين مزود الخدمة والمستخدم. "منذ اللحظة التي قررت فيها السفر حتى تصل إلى وجهتك" ، "نحن لا نبيع كاميرا أمنية ، نحن نبيع لك الحماية على مدار الساعة".

النماذج الأولية: بمساعدة الطابعات ثلاثية الأبعاد وتقنية VR / AR ، من السهل للغاية تقديم نموذج أولي ميكانيكي للمنتج الفعلي. يمكنك إظهاره على عملائك ، ووضع بعض الملصقات عليه ، وتوصيل بعض الأسلاك ومصابيح LED ، وسوف يفهمون الغرض منه على الفور ، وقد تكون قادرًا على إقناعهم بأن منتجك جاهز وتجاري. يمكنك وضعها في بيئة حقيقية ومعرفة ما إذا كانت مناسبة ميكانيكياً وما إذا كان من السهل الاحتفاظ بها. يمكنك عمل عشرة إصدارات ومقارنتها وتحديد التكوين النهائي. لا يوجد شيء أقوى من إعطاء عملائك ومستثمريهم شيئًا يحتفظون به. يحب الأشخاص الألعاب والأشياء الملموسة ، وعلى الرغم من أن التصميم الميكانيكي لا يمثل أحيانًا سوى 1٪ من المنتج النهائي فيما يتعلق بوقت التطوير ، فإن الناس يعتقدون أنك قد أكملت بالفعل 80٪ منه. مع النماذج الأولية للبرنامج ، ليس من السهل الوصول إلى هذا المستوى. يعد Sketch و InVision من الأدوات الرائعة ، ولكن على الفور يدرك المستخدمون أن هذا ليس منتجًا حقيقيًا. البيانات ثابتة وتفاعلها ليس له أي تأثير عليه. هذا جزء من السبب في اعتماد مديري المنتجات الرقمية على النهج الرشيق ومفهوم MVP. من الصعب للغاية تخيل كيف سيتفاعل المستخدمون مع المنتج الخاص بك ويحبونه قبل أن يكون جاهزًا ولديه بيانات حقيقية لذلك تريد شحنه في أقرب وقت ممكن والبدء في جمع تعليقات حقيقية.

النماذج المادية والرقمية

تطوير

يكون للقرارات المبكرة أكبر الأثر: في كل مرة أبدأ فيها مشروعًا جديدًا ، فأنا متحمس. ماذا سيكون العمارة الصحيحة؟ ما هي التكنولوجيا التي ستكون الأنسب لذلك؟ يجب أن نختار MCU 8 بت أو وحدة المعالجة المركزية 32 بت؟ هل هذا مشروع جيد لتقديم GraphQL ، أم يجب علينا الالتزام بـ REST مرة أخرى؟ ما هي التقنية اللاسلكية التي تناسب حالة الاستخدام: Bluetooth 5 أو Narrowband IOT؟ ما هي قاعدة البيانات الصحيحة للاستخدام؟ PostgreSQL أو ربما قاعدة بيانات الرسم البياني هذه المرة؟ هذه القرارات مهمة جدًا لنجاح المشروع. في بعض الأحيان ، نتخذ قرارات تقنية بسرعة كبيرة دون إجراء تحليل مناسب ، وبعد ذلك بثلاثة أشهر نأسف عليها ، يصبح من الصعب للغاية ومؤلمة تغييرها ، ومن الأسهل النظر إلى الاستثمار في التكنولوجيا كأصل وليس كحاجز. هذا صحيح بالنسبة للمنتجات الإلكترونية والمنتجات الرقمية ، على الرغم من أن تغيير نوع المعالج بعد شحن منتجاتك إلى عملائك يكاد يكون مهمة مستحيلة إن لم تكن مهمة محرجة.

القرارات المبكرة لها أكبر الأثر

التطوير: هناك العديد من الاختلافات بين عملية تطوير المنتجات الإلكترونية والمنتجات الرقمية ، وليس هناك الكثير من أوجه التشابه. يذهب معظم وقت التطوير للوحة PCB إلى اختيار المكونات المناسبة وتصميم التخطيط. بعض الأعمال تقنية بحتة ، حيث تقوم بتوصيل الأسلاك من المكون U1 pin 120 إلى المكون U17 pin 12. وبعض المهام تتطلب نماذج أولية كاملة حول ثلاثة أنواع من أجهزة الاستشعار فقط لقياس الضوضاء واستهلاك الطاقة لكل واحد منها. يصعب تصحيح التطوير المضمن وتحسينه ، من الشائع جدًا رؤية المطورين المضمنين يستخدمون دبابيس GPIO لاكتشاف ما إذا تم استدعاء وظيفة وقياس الوقت المستغرق لتشغيلها. يعد استخدام FPGA في منتجك الإلكتروني قرارًا جريئًا ولكنه في بعض الأحيان هو الحل الوحيد للوصول إلى أهداف الأداء / التكلفة. يعد تطوير FPGA منطقة مختلفة تمامًا ويقع في مكان ما بين تطوير ASIC وتطوير لوحة PCB والتطوير المدمج. لمطوري البرمجيات ، يتم استثمار معظم الوقت في ... كتابة التعليمات البرمجية. هناك شيء مُرضٍ للغاية في النظر إلى عملك اليومي ، كل هذه الأسطر من التعليمات البرمجية ، أوامر الكود وطلبات السحب. هذا يبدو بسيطًا بما فيه الكفاية ، ولكن مقدار الكود والتغييرات ضخم ، لذا فإن إدارة التهيئة الصحيحة وعملية المراجعة ضرورية للحفاظ على قاعدة الكود منظمة ، وتقليل الدين الفني ، وزيادة المعرفة عبر الفريق.

الخوارزميات والفيزياء وعلوم البيانات: عادة ما يكون هذا هو عقل المنتج ، حيث تميل الشركات إلى المطالبة بأن IP الخاص بها موجود. يعمل مصممو اللوحة مع علماء الفيزياء لتحديد أجهزة الاستشعار ، لتصميم AFE (الواجهة الأمامية التناظرية) من حولهم أو لتصميم هوائي خاص. يعمل المطورون المضمنون مع مهندسي DSP وعلماء الرياضيات لتضمين خوارزميات DSP في الوقت الفعلي في برامجهم لتصفية الإشارات أو اكتشاف الأنماط أو لتنفيذ بعض المعادلات الرياضية المحسّنة لمعالجة / تشفير البيانات. في الوقت الفعلي يعني أنه يجب عليك إكمال المعالجة خلال فترة زمنية معينة من دورات وحدة المعالجة المركزية ، وإلا فلن تكون مستعدًا لمعالجة الإشارة التالية أو تفويتها أو لن تتمكن من إخراج الأحداث ضمن زمن الاستجابة المطلوب. يعمل مطورو Backend مع علماء البيانات لتنفيذ عمليات الدُفعات لاقتراح منتجات جديدة ، والعثور على الحالات الشاذة ، واقتراح الأصدقاء ، وتدريب نموذج التعلم العميق ، واستخدام البرمجة اللغوية العصبية (NLP) لتحليل النص ، وتسجيل صفحات الويب ، وما إلى ذلك. يفعلون التصور البيانات. باستخدام مكتبة مثل D3JS ، ينشئون صورًا مدهشة ويقدمون البيانات للمستخدمين بطريقة مفيدة ومجمعة.

عبر المكدس ، سوف يهتم هؤلاء الأشخاص بتقليل الضوضاء وتحسين الإشارات وإيجاد التوازن الصحيح بين الكشف عن الخطأ (السلبي الخاطئ) والإنذار الخاطئ (الإيجابي الخاطئ) ، وسوف يصرخون أنهم بحاجة إلى مزيد من البيانات أو إجراء المزيد من التجارب ، وسوف يقفزون لحسن الحظ إذا نجحوا في تحسين الأداء بنسبة 5 ٪. قرار منتج مثير للاهتمام هو أن تقرر كيفية تقسيم مهام علم البيانات عبر الحزمة. على سبيل المثال ، تتضمن Alexa مجموعة من الميكروفونات على مستوى اللوحة ، وبعض أكواد DSP على مستوى البرامج الثابتة وعلوم البيانات المتطورة على مستوى الواجهة الخلفية للتعرف على خطابنا.

الأدوات: تخيل أحد مطوري الواجهة الأمامية ومطور مضمن يقوم بمقارنة أدوات التطوير الخاصة بهما ببعضهما البعض. سيقوم المطور المضمّن بالسير على مطور الواجهة الأمامية إلى طاولته / صفحتها ويشير إلى الاختلافات بين مصدر الطاقة ومنظار الذبذبات ومحلل المنطق. سينتقل مطور الواجهة الأمامية للمطور المدمج إلى أقرب مكان لصنع القهوة. سيطلبون القهوة ويجدون مكانًا هادئًا حيث يمكنهم قضاء بضع ساعات معًا. عندها سيقوم / ستقوم بتحويل متصفح Chrome إلى وضع التطوير وإظهار للمطور المدمج كيفية النظر في حركة مرور الشبكة وكيفية رؤية نمط CSS لعنصر HTML معين.

ما معنى devtools إلى ...

تختلف أدوات تصحيح الأخطاء من مطور إلى مطور واستخدامها بكفاءة حيث تكمن التجربة الحقيقية. إن معرفة الغريزة أين تكمن المشكلة ، واستخدام أدواتك للالتحاق بها هو أهم مهارة للمطورين. لقد رأيت أن المطورين يقضون ساعات وأيام في تصحيح مشكلة ما ، ثم اطلب مساعدة من مطور متمرس يجد المشكلة في ثوانٍ. لا يمكنني التأكيد على ذلك بشكل كافٍ ، فامتلاك الأدوات المناسبة لكل مهمة هو معنى الاحتراف. وهذا صحيح لكل مهنة.

ما معنى أدوات التصحيح والاختبار لـ ...يجد مطورو البرمجيات هذا الأمر مخيفًا

ضمان الجودة والاختبار

الاختبارات البيئية: عندما نختبر منتجنا ، نريد التحقق من أنه يعمل بشكل صحيح في جميع التكوينات والبيئات المختلفة التي يتوقع المستخدمون استخدامها. بالنسبة للمنتجات المادية ، تعني البيئة عادة درجة الحرارة (البرد الشديد ، والساخنة للغاية) ، والاهتزاز (تخيل منتج السيارات) ، والصدمة (السقوط من يديك إلى أرضية خرسانية) ، والرطوبة ، والأشعة فوق البنفسجية والإشعاع الشمسي ، ESD (هذه الإضاءة الصغيرة التي تأتي من التفريغ الكهربائي الساكنة) ، EMI / RFI ، إلخ. بالنسبة للمنتجات الرقمية ، عادةً ما تعني بيئة المستعرض نوع المستعرض (Chrome ، Internet Explorer ، Firefox ..) ، نظام التشغيل (Android ، IOS ، OSX ، Windows) ، الجهاز (المحمول ، سطح المكتب ، المؤتمر الشاشة) ومستوى اتصال الشبكة (4G ، واي فاي ، غير متصل). نحن عادة لا نختبر كل مجموعة ممكنة لأنه سيكون من المستحيل القيام بذلك ، لذلك نأتي بمجموعة من التكوينات التي نأمل أن تغطي سيناريوهات كافية لاكتشاف المشكلات داخل مواصفات المنتج.

ما معنى البيئة الخارجية لـ ...

الموثوقية / المتانة (اختبار دورة الحياة): هذه هي الاختبارات التي تحاول محاكاة ما يحدث للمنتج خلال حياته بأكملها. إنها أكثر صلة بالمنتجات المادية حيث تصل المواد إلى نقاط قصورها. هناك بعض القواعد التي ابتكرتها الصناعة لمساعدتنا على تسريع عصر المنتج من خلال تعريضه للظروف البيئية القاسية. بشكل أساسي ، لاختبار ما إذا كان المنتج يعمل بشكل صحيح بعد خمس سنوات في درجة حرارة الغرفة ، يمكننا اختباره عند درجة حرارة 70 درجة و 10 غرامات لمدة يوم واحد (مثال فقط !!!). وتسمى هذه الاختبارات HALT (الحياة المتسارعة للغاية)

اختبارات الظروف القاسية (الحمل ، الحافة): هذه اختبارات تختبر سلوك المنتج في الظروف القاسية أو الحافة. على سبيل المثال ، إذا كان منتج إلكتروني يعمل على 5V ، فسنختبره عند 4.5V و 5.5V ، وقد نحقن حتى طفرات في الجهد تصل إلى 25V أو -5V لمعرفة ما إذا كان المنتج مرنًا لأخطاء المستخدم أو الزيادات الكهربائية. بالنسبة للمنتجات الرقمية ، قد نتحدى حقول الإدخال بقيم غير معقولة. على سبيل المثال ، قد نقوم بإدخال أسماء يبلغ طولها 1000 حرف ، أو لها رموز لا معنى لها. إذا قمنا بتصميم المنتج لتحميل معين (50 مستخدمًا متزامنًا) ، فسنختبر سلوكه تحت 100 مستخدم متزامن. فكرة هذه الاختبارات هي أساسًا الكشف عن أوضاع فشل جديدة. لا نتوقع أن يعمل المنتج بشكل مثالي ، لكننا قد نكتشف مشكلات مهمة أو سلوكيات غير متوقعة أو اختناقات ذات صلة أيضًا بالظروف العادية.

اختبارات الامتثال / الأمان: كلا النوعين من المنتجات مطلوبان ، في بعض الأحيان ، للوفاء بالمعايير والامتثال لها. يجب أن تكون المنتجات الإلكترونية آمنة ومأمونة وموثوقة وتحمي المستخدم من الصدمات الكهربائية أو ارتفاع درجة الحرارة (UL ، CE ، FCC ..) ، كما أنها بحاجة إلى الامتثال لمعايير لاسلكية معينة مثل Wifi أو Bluetooth. يجب أن تحمي المنتجات الرقمية التي تتعامل مع معلومات التعريف الشخصية (PII) مثل أرقام بطاقات الائتمان (PCI أو ISO / IEC 27001 أو NIST) أو أرقام الضمان الاجتماعي (GDPR) البيانات من كل أنواع الهجمات وإهمال الموظفين. بالنسبة إلى كلا المنتجين ، تكون عملية الامتثال مكلفة وطويلة ، ولكن هناك طرق لخفض التكلفة واستخدام الوحدات النمطية والخدمات المعتمدة مسبقًا.

ما معنى الامتثال لـ ...

تغطية الاختبار: كمصمم للوحة ، لا يمكنك أبدًا التأكد من أن عملية التصنيع كانت خالية من العيوب. في بعض الحالات ، توجد شورتات صغيرة بين آثار متجاورة لا يمكنك رؤيتها إلا باستخدام المجهر. في حالات أخرى ، لا تكون المكونات الإلكترونية موثوقة بدرجة كافية أو قد تكون مكونات مزيفة. كجزء من عملية الجودة ، يجب على مصممي الألواح والمطورين المضمنين العمل معًا لكتابة أدوات اختبار تتحقق من أن كل اتصال وكل مكون يعمل كما هو متوقع بتغطية 100٪. لقد عملت على اختبار أجهزة JIG التي تحاكي كل مستشعر وكل مدخلات على اللوحة للوصول إلى تغطية 100 ٪. من الممارسات الجيدة أيضًا إجراء هذه الاختبارات بالتوازي مع اختبارات الفحص السريعة (HASS) حيث تتعرض اللوحة للاهتزاز ودورات حرارية.

وبالمثل ، مع البرنامج ، من الممارسات الجيدة كتابة رمز اختبار يغطي 99٪ على الأقل من الشفرة. قبل نشر رمز جديد في بيئة الإنتاج ، تعمل أداة التشغيل الآلي على تشغيل مجموعة كود الاختبار والتحقق من أن ما كان يعمل من قبل ، لا يزال يعمل. في كلتا الحالتين ، يجب أن يبدأ العمل على أدوات الاختبار هذه مع تطوير المنتج (أحيانًا حتى قبل: TDD) ويجب توفير الموارد بشكل مناسب.

مراجعة التصميم / الرمز: يخطئ الناس. أي شخص يعتقد أنهم لا يفعلون ذلك ، إما أنه ليس لديهم خبرة كافية أو لديهم ذاكرة قصيرة. على وجه الخصوص ، عند تصميم لوحة PCB ووضع مكونات جديدة ، من السهل للغاية ارتكاب أخطاء فيما يتعلق بتكوين pinout والأبعاد المادية للمكونات الجديدة. الأخطاء سوف تجد بعد أسابيع أو أشهر فقط. يمكنك إلقاء نظرة على التصميم والتحقق منه مقابل ورقة البيانات ، والنظر مرة أخرى ، والتحقق مرة أخرى ، وفي كلتا الحالتين ، ستفتقده. لهذا السبب ، تعتبر المراجعة والتوقيع المستقلان ممارسة معيارية في تطوير المنتجات الإلكترونية. غالبًا ما يرتكب مطورو البرامج أخطاء فيما يتعلق بالأمان. على سبيل المثال ، غالبًا ما يضعون مفاتيح حساسة في مستودعات الأكواد العامة أو يتعرضون للعميل. طلب السحب هو وسيلة لإعلام أعضاء الفريق الآخرين عن تغييراتك قبل الالتزام بها. إنها تخدم أغراضًا متعددة: لاكتشاف العيوب والمشكلات ، وتحسين قابلية قراءة التعليمات البرمجية وتوثيقها ، ومشاركة المعرفة عبر الفريق. البرمجة الزوجية هي طريقة أخرى يستخدمها مطورو البرامج لمشاركة المعرفة ومراجعة كود بعضهم البعض.

إدارة التكوين: CM هي ممارسة التعامل مع التغييرات بشكل منتظم. يتم استخدامه لتوثيق إصدارات المنتج وتتبع التغييرات المطبقة عليه بين الإصدارات. سيسمح لك نظام إدارة التكوين الجيد ببناء واختبار أي إصدار من المنتج باستخدام المصنوعات اليدوية الموجودة فيه فقط دون أي معرفة خارجية أخرى. يستخدم مهندسو DevOps أدوات SCM (إدارة تكوين البرامج) مثل GIT و Ansible و Terraform و Chef لتسجيل رمز المنتج وتكوينه والبنية الأساسية له. قد تربط هذه التغييرات أيضًا بمشكلات JIRA لتوثيق العلاقة بين طلب علة / عيب / ميزة والتغييرات الفعلية الناتجة عن ذلك. يستخدم المهندسون الإلكترونيون أدوات تسمى أحيانًا PLM (إدارة دورة حياة المنتج) وأحيانًا HCM (إدارة تكوين الأجهزة). إنها تخدم في الأساس نفس الغرض ، ولكنها تشمل عمليات تكامل وعمليات مختلفة. على سبيل المثال ، قد يتم أيضًا دمج نظام PLM في نظام ERP الخاص بك لإظهار أي أجزاء من قائمة BOM الخاصة بالمنتج موجودة في مخزونك.

التصنيع والإنتاج

يجب أن تنظر إلى الشركة المصنعة كشريك لك وليس كمورد لك. بعد كل شيء ، أنت تعطي الشركة المصنعة أصولك الأكثر حساسية: كل ما هو مطلوب لبناء منتجك! سوف تساعدك الشركة المُصنّعة الخاصة بك على تقديم طرق تصنيع جديدة ، وتقليل العيوب ، وتحسين كفاءة العملية ، وستشارك بطريقة أو بأخرى بعض مخاطر ومزايا المنتج.

العجاف العجاف هو كل ما يتعلق بتوفير التكاليف. بالنسبة للمنتجات الفيزيائية ، يعني الدهن:

  • صفر تأخير خلال جميع مراحل خط الإنتاج
  • عيوب الدفع ، أعلى جودة لكل منتج نهائي
  • الآلات / الناس 100 ٪ المستخدمة
  • ردود الفعل المعرفة: كل درس والبصيرة تحسين العملية
  • في الوقت المناسب التصنيع: يتم بيع كل منتج ، لا النفايات

بالنسبة إلى المنتجات الرقمية ، يعني أن:

  • القياس التلقائي: مقياس الموارد الحسابية بناءً على الحمل
  • الدفع في الساعة

خطوط أنابيب التصنيع: لا يختلف إعداد خط التجميع عن إعداد خط أنابيب CI / CD (تكامل مستمر / تسليم مستمر). إذا كنت قد قرأت كتاب مشروع Phoenix ، فربما تتذكر كيف تم اشتقاق بعض مفاهيم العجاف و DevOps في الكتاب من خط التصنيع الفعلي. يتعامل كل من خطي الأنابيب مع كل ما هو مطلوب لإنشاء منتجك واختباره وشحنه. عند إضافة المزيد من الأتمتة ، يمكنك الشحن بشكل أسرع. وهذا يعني بالنسبة للمنتجات الإلكترونية تقليل التكاليف والعيوب وتحسين السعة ، بالنسبة للمنتجات الرقمية ، وهذا يعني اختبار المستخدم بشكل أسرع وتصميمه التكييفي.

التسليم في جميع أنحاء العالم: هناك تشابه مثير للاهتمام بين شبكات تسليم المحتوى (CDN) التي تُستخدم لتسليم أصول الويب إلى المستخدمين استنادًا إلى موقعهم الجغرافي ، وكيفية توزيع التصنيع في جميع أنحاء العالم لتقليل تكاليف الشحن وتعريب المنتجات. يمكن رؤية التخزين المؤقت للمحتوى على أنه مستودعات محلية أو خدمات تنفيذ مثل Amazon. بالنسبة لكلا النوعين من المنتجات ، يحسن التواجد المحلي من تجربة العملاء الشاملة في جميع أنحاء العالم

قد يبدو أن التواجد في جميع أنحاء العالم أصعب بالنسبة للمنتجات المادية ، ومع ذلك ، فإن تنظيم حماية البيانات وتوطين اللغة يتطلبان جهودًا كبيرة أيضًا

الخدمات السحابية: الخدمات السحابية رائعة ، يمكنك إنشاء منتجك الرقمي في ثوانٍ من خلال الاختيار من بين مئات خدمات الويب. بضع نقرات وسيتم تشغيله تلقائيًا على أكثر من 20 مركز بيانات في جميع أنحاء العالم وعلى نطاق واسع بناءً على الطلب. لا يوجد شيء من هذا القبيل في التصنيع ، ولكن قد تكون هذه هي الثورة الصناعية القادمة. تخيل منتجًا رقميًا حيث يمكنك إعداد خط أنابيب تصنيع باستخدام وحدات مسبقة التكوين مثل الطباعة ثلاثية الأبعاد وتصنيع ثنائي الفينيل متعدد الكلور ومصادر المكونات وتجميع الألواح والكابلات وإجراء الاختبارات والشحن مباشرة إلى عملائك من أرضية تصنيع آلية محلية. علاوة على ذلك ، ستسمح الخدمة للمستخدم النهائي بتخصيص لون المنتج والشكل وميزات التخصيص الأخرى. هذا يبدو وكأنه حلم ، لكنني متأكد من أن شركة Amazon تعمل في مكان ما حول العالم على مثل هذه الخدمة (على الأقل أتمنى أن يفعلوا ذلك).

استنتاج

هناك العديد من الاختلافات بين عملية تطوير المنتجات الإلكترونية والمنتجات الرقمية ، ولكن بالنظر إليها من منظور 20 عامًا ، من المدهش رؤية عدد مبادئ التصميم وعمليات المنتجات الرقمية التي يستخدمها الآن مدراء المنتجات المادية. أعلنت AWS مؤخرًا على FreeRTOS للأنظمة المدمجة. أتوقع أنه خلال 10-20 سنة لن يكون هناك أي فرق كبير بين عملية تطوير منتج رقمي ومنتج مادي.

إذا كنت ترغب في معرفة المزيد عن رحلتي ، وكيفية إدارة فريق يعيش في كلا العالمين ، فلا تتردد في التواصل معي مباشرة.