عندما لا تكون المشكلة في البرنامج، لكن الجميع يعتقد أنها خلل برمجي

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

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

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

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

للوهلة الأولى، كان من الممكن أن يبدو الأمر وكأنه خطأ برمجي. لكن بعد إجراء المزيد من الفحص، تبيّن أن حسابات البرنامج صحيحة، وأن المشكلة كانت في مكان آخر.

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

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

كانت لهذه التجربة دلالة مهمة بالنسبة لي:

أحيانًا لا يكون البرنامج هو من تسبب في المشكلة؛ بل يكون البرنامج هو الأداة التي تكشف مشكلة موجودة أصلًا في سير العمل.