أعطال البرامج التي يمكن تجنبها تكلف تريليونات

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

في عام 2005 بعنوان “لماذا تفشل البرامج”، في IEEE الطيف، وهو مقال أساسي يوثق الأسباب الكامنة وراء فشل البرامج على نطاق واسع، أشار شاريت إلى أن “المأساة الأكبر هي أن فشل البرامج في معظمه يمكن التنبؤ به وتجنبه. لسوء الحظ، لا ترى معظم المنظمات أن منع الفشل مسألة ملحة، على الرغم من أن وجهة النظر هذه تخاطر بإيذاء المنظمة وربما حتى تدميرها. إن فهم سبب استمرار هذا الموقف ليس مجرد تمرين أكاديمي؛ بل له آثار هائلة على الأعمال التجارية والمجتمع.”

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

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

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

“البرمجيات لا تقل أهمية عن الكهرباء. لن نتحمل أبدًا انقطاع الكهرباء كل يوم، لكننا على يقين من أنه ليس لدينا أي مشكلة في تعطل خدمات AWS.” —روبرت ن. شاريت

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

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

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

تقول شاريت: “إن البرمجيات لا تقل أهمية عن الكهرباء”. “لن نتحمل أبدًا انقطاع الكهرباء كل يوم، لكننا على يقين من أنه ليس لدينا مشكلة في قبول انقطاع خدمات AWS أو انقطاع شركات الاتصالات أو البنوك.” إنه يطلق تنهيدة ثقيلة تستحق AA Milne’s Eeyore. “الناس يهزون أكتافهم نوعًا ما.”