🪄 وهم 'الزر السحري'

"بس أبي تضيف زر هنا". يقولها العميل وهو يتوقع أن الأمر سيأخذ عشر دقائق. المبرمج يسكت لحظة ثم يرد: "هذا يحتاج 3-4 أيام عمل". العميل يعتقد أن المبرمج يبالغ أو يستغله. المبرمج يعرف أن وراء هذا "الزر البسيط" جبلاً من العمل الخفي.

هذا واحد من أكثر مصادر سوء الفهم بين العميل والمبرمج. والمشكلة أن كلاهما على حق من منظوره.

العميل يرى الواجهة فقط — ما يظهر على الشاشة. يرى زراً ونصاً وصورة. من وجهة نظره، إضافة زر تعني: ارسم مربعاً، اكتب فيه كلمة، خلاص.

هذا ليس غباءً — هذا منطقي تماماً. نحن كلنا نفعل ذلك مع التخصصات الأخرى. تذهب للمرّكز وتقول: "بس أبي تغيّر الفلتر" — لا تعرف أن الوصول للفلتر يعني فك نصف المحرك.

المبدأ: البساطة في المظهر لا تعني البساطة في التنفيذ. أبسط الأشياء التي تراها على هاتفك — مثل زر "إضافة للمفضلة" — وراءه عشرات الأسطر من الكود.

لنأخذ مثالاً حقيقياً: عميل يطلب إضافة زر "مشاركة المشروع" في تطبيق إدارة مشاريع.

ما يراه العميل: زر واحد.

ما يفعله المبرمج:

1. التصميم: أين يوضع الزر؟ كيف يبدو على الجوال والكمبيوتر؟ ما الذي يحدث عند الضغط؟ نافذة منبثقة؟ صفحة جديدة؟

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

3. الأمان: يجب التأكد أن الرابط لا يُعرّض بيانات خاصة. يجب إضافة حماية من الاستخدام الخاطئ.

4. الإشعارات: عند مشاركة مشروع، هل يُرسل إشعار للطرف الآخر؟ بريد إلكتروني؟ إشعار داخل التطبيق؟

5. الاختبار: يجب اختبار كل الحالات: ماذا لو أرسل لشخص غير مسجل؟ ماذا لو ألغى المشاركة؟ ماذا لو فتح الرابط من جهاز مختلف?

تخيّل أنك تطلب من مهندس معماري: "بس أبي تضيف باب هنا في الجدار". يبدو طلباً بسيطاً — باب.

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

"باب" في نظرك. "مشروع هندسي" في نظره. نفس الأمر مع "الزر" في البرمجة.

الكود مثل المبنى — كل جزء متصل بأجزاء أخرى. تحريك لبنة واحدة قد يعني إعادة ترتيب عشرات اللبنات حولها.

في أكتوبر 2013، أطلقت الحكومة الأمريكية موقع Healthcare.gov — منصة التأمين الصحي المركزية ضمن قانون أوباما للرعاية الصحية. الموقع بدا بسيطاً من الخارج: نموذج تسجيل، مقارنة خطط، واختيار.

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

ما الذي حدث؟ حسب تقرير Government Accountability Office (GAO): - الموقع كان يتصل بقواعد بيانات أكثر من 300 جهة حكومية ومؤسسة تأمين. - كل "زر" في النموذج كان يُشغّل عمليات تحقق معقدة في الخلفية. - فريق المشروع قلّل من تقدير التعقيد التقني بشكل كبير. - التكلفة النهائية وصلت لـ 1.7 مليار دولار حسب Bloomberg بعد أن كانت مخططة بـ 93 مليون.

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

في عالم هندسة البرمجيات هناك مفهوم شهير يُسمى نموذج الجبل الجليدي (Iceberg Model): ما يراه المستخدم على الشاشة هو 10% فقط من العمل — مثل قمة الجبل الجليدي. الـ 90% المتبقية مخفية تحت السطح: قواعد بيانات، خوادم، أمان، معالجة أخطاء، اختبارات، تكامل مع أنظمة أخرى.

هذا المفهوم وصفه فريد بروكس في كتابه الشهير "The Mythical Man-Month" (1975) — أحد أهم كتب هندسة البرمجيات في التاريخ. بروكس كان مدير مشروع نظام التشغيل OS/360 في IBM، واكتشف قانوناً صادماً: إضافة مبرمجين لمشروع متأخر يجعله أكثر تأخراً.

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

الدرس للعميل: عندما يقول المبرمج "هذا يحتاج وقتاً"، فهو لا يبالغ — بل يرى الـ 90% التي لا تراها أنت. وعندما يقترح حلاً مختلفاً عما طلبته، ربما لأنه يعرف أن ما طلبته سيكلّف 10 أضعاف ما تتخيل.

للمبرمج — اشرح ولا تتذمر: - بدلاً من "هذا صعب"، قل: "هذا الزر يحتاج 3 خطوات: كذا وكذا وكذا. كل خطوة تحتاج يوم تقريباً". - استخدم تشبيهات بسيطة كتشبيه المبنى أو السيارة أو الجبل الجليدي. - لا تفترض أن العميل يستغلك — غالباً هو فعلاً لا يعرف. - شارك أمثلة حقيقية: "مشروع Healthcare.gov بدا بسيطاً وكلّف مليارات" — القصص تُقنع أكثر من الشرح التقني.

للعميل — اسأل ولا تحكم: - قبل أن تقول "ليش غالي؟"، اسأل "وش اللي يخلي هذا التعديل يحتاج وقت؟". - تذكّر أنك تدفع مقابل خبرة تقنية لا تملكها. إذا كان الأمر بسيطاً فعلاً لما احتجت مبرمجاً. - اطلب تفصيلاً: "ممكن تشرح لي الخطوات؟" — هذا يبني ثقة ويمنع سوء الفهم.

لا يوجد "زر سحري" في البرمجة. أو كما يقولون بالشامي: "يا زلمة، ما في شي اسمو سهل بالبرمجة — في شي بيبان سهل بس!"

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

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