أحيانًا نضحك عندما يقول مطوّر: “It’s not a bug, it’s a feature.” ليبرّر خللاً واضحًا في النظام.. لكنه في الحقيقة يخبرك بشيء أخطر!
ما تراه أنت خطأ، قد يكون صُمّم ليكون كذلك!! فماذا لو طبقنا هذه الفكرة على واقعنا؟
عندما تُسرَّب بيانات مواطنين بأرقامهم الوطنية وهواتفهم وأسمائهم وأرقام بطاقاتهم.. هل هو “خطأ تقني”؟ أم أن الإهمال المتكرر، وغياب المحاسبة، وانعدام الشفافية، كلها ليست أعطالاً طارئة.. بل تصميمًا ثابتًا؟
عندما تتكرر القرارات المرتبكة، والتصريحات المتناقضة، والمشاريع التي تبدأ بلا نهاية.. هل هي عشوائية؟ أم أننا أمام “نمط” مستقر؟
في عالم التقنية، إذا تكرر الخلل بنفس الشكل، وفي كل إصدار، ولم يُعالج، فغالبًا لم يعد bug.. صار behavior.؟ صار جزءًا من بنية النظام.
المشكلة أننا اعتدنا تفسير كل شيء على أنه سوء تقدير، أو جهل موظف، أو ظرف استثنائي.
لكن ماذا لو كان النظام نفسه مُصمَّمًا ليُنتج هذه النتائج؟
وماذا لو كان صراعنا اليومي مع بعضنا كمواطنين هو جزء من هذه “الميزة”؟
نغضب، نشتبك، نختلف، نستهلك طاقتنا في بعضنا… بينما يبقى التصميم كما هو.
في تجربة المستخدم، هناك قاعدة بسيطة، إذا لم يشتكِ المستخدم، اعتُبر السلوك مقبولًا، أما إذا اشتكى، أعيد تصنيفه على أنه خطأ يجب إصلاحه.
الفاصل إذن ليس في الخطأ نفسه، بل في وعي المستخدم.
إعادة النظر في الواقع تبدأ من هنا، أن نتوقف عن افتراض حسن النية بشكل تلقائي، وأن نتوقف عن تبرير كل نتيجة مؤذية بأنها “ظرف”، وأن نسأل: هل هذا خلل فعلاً، أم نتيجة طبيعية لنظام بُني بهذه الطريقة؟
حين ندرك ذلك، نخرج من الدائرة المغلقة، ونتوقف عن خدمة المسؤولين عبر انقساماتنا، ونبدأ بالمطالبة بتصميم مختلف، لا مجرد ترقيع أعطال.
أحيانًا أخطر ما في الأمر.. أن نقبل الميزة على أنها قدر.