الابتكار مع الأنظمة الحرجة للحياة

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

ولكن ماذا يحدث عندما تكون الأنظمة التي تحتاج إلى تعديلها أنظمة ضرورية للحياة ، حيث تعتمد سلامة الحياة على القدرة على استخدام النظام بشكل موثوق؟

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

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

• السيارات. هل تعمل في مشروع مع شركة تصنيع سيارات أو أي من مورديها؟ تم تجنيده خارج الجامعة من قبل شركة ناشئة للسيارات ذاتية القيادة؟ الكبح الأوتوماتيكي ، التحكم في السرعة ، التحكم في المسار ، رؤية الكمبيوتر ، التعرف على العوائق ، وحدات التحكم الإلكترونية في المحرك ، إلخ. كل واحد من هذه الأنظمة هو نظام مهم للحياة ، حيث يمكن أن يكون الفشل قاتلاً.
• طيران. عندما تكون 30000 قدم في الهواء ، فإن أي فشل في النظام تقريبًا يمكن أن يكون حرجًا لحياتك. بالنظر إلى الأحداث الأخيرة مع Boeing 737 MAX ، هناك أنظمة واضحة للحياة الحاسمة للطيار الآلي والتحكم في الطيران بالكمبيوتر ، ولكن هناك أيضًا الكثير من الأشياء التي قد لا تفكر فيها. في المنزل ، إذا فشلت المروحة الموجودة في نظام التدفئة والتهوية وتكييف الهواء (HVAC) ونتج عنها القليل من الدخان ، تفتح النافذة أو تخطو للخارج للحصول على بعض الهواء النقي. هل سبق لك أن حاولت فتح النافذة والخروج أثناء رحلة عبر المحيط الأطلسي؟ حتى أبسط الأنظمة ، من منافذ الطاقة في المطبخ إلى الفرامل على عجلات عربة المشروبات ، يمكن أن تكون بالغة الأهمية للحياة على متن الطائرة.
• مجال الاتصالات. سيعمل معظم المطورين أو المهندسين ، في مرحلة ما من حياتهم المهنية ، في مشروع نظام اتصالات بشكل أو بآخر. بالنسبة لكثير من الناس ، لا تبدو الاتصالات السلكية واللاسلكية ضرورية للحياة في البداية ؛ بعد كل شيء ، كان أداء الحضارة جيدًا قبل الهواتف والإنترنت. بصفتي شخصًا انتشر في مناطق الكوارث حيث تم تدمير البنية التحتية للاتصالات السلكية واللاسلكية ، دعني أخبرك بما يحدث بالفعل: يصاب الناس بمرض شديد أو مصابين ولا يمكنهم الاتصال بالرقم 911 ؛ لا يمكن للمقيمين المسنين الاتصال بأطفالهم لمطالبتهم باستلام الوصفات الطبية من الصيدلية ؛ لا يستطيع المستجيبون للطوارئ التواصل مع مرسليهم أو مع بعضهم البعض ؛ والأشخاص الذين لا يستطيعون الاتصال بأفراد أسرهم يصبحون قلقين ويضعون أنفسهم في مواقف خطيرة للغاية لمحاولة العثور عليهم. تعتبر أنظمة الاتصالات ضرورية للغاية للحياة.

في عالم اليوم الذي يعتمد بشدة على التكنولوجيا ، فإن المشاريع التي لم تفكر في أنها حتى شبه مهمة يمكن أن ينتهي بها الأمر إلى أن تكون مكونًا حيويًا لنظام حرج للحياة.

ولكن إذا لم ينكسر ، فلا تصلحه

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

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

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

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

إقناع النّحاس

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

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

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

انها ليست عنك

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

لنأخذ حالة الرحلة 447. في 1 يونيو 2009 ، كانت الطائرة إيرباص A330 فوق المحيط الأطلسي في طريقها من ريو دي جانيرو إلى باريس. سدت بلورات الجليد أنابيب البيتوت ، مما تسبب في تناقضات في قياسات سرعة الهواء. قام كمبيوتر الرحلة بفك ارتباط الطيار الآلي ، مدركًا أنه لا يمكن أن يطير بالطائرة نفسها بشكل موثوق به مع بيانات سرعة الهواء غير الصحيحة. ثم وضع نفسه في وضع "غلاف الطيران الممتد" ، والذي سمح للطيارين بأداء مناورات لا يسمح بها الكمبيوتر عادة. يمكنك أن تتخيل المهندسين الذين قاموا ببناء النظام وهم يفكرون "إذا قام الطيار الآلي بفك ارتباطه ، فمن المحتمل أن يكون ذلك بسبب وجود موقف قد يحتاج فيه الطيارون إلى مزيد من التحكم! "

هذا هو قطار الفكر الطبيعي للمهندسين ، الذين يفهمون أنواع الأشياء التي قد تتسبب في فك الطيار الآلي. بالنسبة للطيارين ، لم يكن الأمر كذلك. أجبروا الطائرة على الصعود إلى أعلى ، متجاهلين تحذيرات "STALL" ، حتى فقدت كل سرعتها الجوية وهبطت في المحيط. قُتل جميع الركاب وأفراد الطاقم البالغ عددهم 228 راكبًا. في حين أن هناك العديد من الأفكار حول الدافع الدقيق لأفعالهم ، فإن النظرية السائدة هي أن الطيارين افترضوا أن كمبيوتر الرحلة سيمنع مدخلات التحكم التي من شأنها أن تعطل الطائرة (وهذا صحيح بالنسبة لمغلف الرحلة العادي) ، ولم يدركوا ذلك لقد تحولت إلى وضع المغلف الممتد لأنهم لم يشاركوا النموذج العقلي للمهندسين للمنطق الذي دفع قرارات الكمبيوتر.

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

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

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

على الرغم من أن كل نظام معقد فريد من نوعه ، إلا أنني أود أن أذكر ثلاثة اعتبارات تصميمية ، على وجه الخصوص ، يجب تطبيقها عالميًا:

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

طرح أنظمة الحياة الحرجة خارج المتجر

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

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

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

تطبيع الانحراف

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

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

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

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

التدريب على الأداء تحت الضغط

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

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

خاتمة

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

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

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

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

اعمل بدقة ، ولا تكن مغرورًا ، وستجعل العالم مكانًا أفضل.