🔍 كيف تكتشف المبرمج 'الهاوي' من الاجتماع الأول؟

أنت صاحب فكرة مشروع. بحثت ووجدت عشرات المبرمجين على المنصات. الأسعار متفاوتة والكل يكتب في ملفه "خبرة 5 سنوات" و"تنفيذ مشاريع احترافية". كيف تفرّق بين المحترف الحقيقي والهاوي الذي سيكلّفك وقتاً ومالاً وأعصاباً؟

هذا المقال ليس للتقليل من أحد — كلنا كنا مبتدئين يوماً ما. لكنه دليل عملي يساعد العميل على اتخاذ قرار واعٍ، ويساعد المبرمج المبتدئ على معرفة ما يحتاج تطويره.

المبرمج المحترف يسأل. كثيراً. يريد أن يفهم: ما هدف المشروع؟ من الجمهور المستهدف؟ هل هناك تصاميم جاهزة؟ ما الميزانية والوقت المتاح؟

المبرمج الهاوي يقول: "تمام، أرسل التفاصيل وأبدأ". يقبل المشروع بدون فهم كافٍ لأنه يخاف أن يخسر الفرصة.

من أشهر الأمثلة على عدم طرح الأسئلة الكافية: كارثة Knight Capital Group عام 2012. الشركة — وهي من أكبر شركات التداول في وول ستريت — نشرت تحديثاً برمجياً جديداً بدون اختبار كافٍ ولا أسئلة عن التوافق مع الكود القديم. حسب The New York Times وFortune، في 45 دقيقة فقط خسرت الشركة 440 مليون دولار — بمعدل 10 ملايين دولار في الدقيقة. انخفض سهمها 63% في يوم واحد. اعترف المدير التنفيذي توماس جويس لاحقاً بأن البرنامج "نُشر بشكل خاطئ وتعارض مع كود قديم". لو طرح أحد السؤال البسيط: "هل اختبرنا هذا مع النظام الحالي؟" — لتجنّبوا الكارثة.

"أسوّي لك تطبيق مثل أوبر في شهر" — هذه الجملة وحدها كافية لتهرب.

المبرمج المحترف يعرف حجم العمل الحقيقي. يعرف أن تطبيقاً بسيطاً يحتاج 2-3 أشهر على الأقل. ويعرف أن المشاريع تتأخر دائماً — فيضيف هامشاً.

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

المعيار البسيط: إذا كان الوعد أحلى من أن يكون حقيقياً — فهو غالباً ليس حقيقياً.

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

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

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

لست بحاجة أن تكون مبرمجاً لتختبره. اسأل أسئلة بسيطة:

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

- "كيف ستتعامل مع حالة كذا؟" (مثل: ماذا لو سجل 1000 شخص في نفس الوقت؟) — المحترف يناقش الاحتمالات. الهاوي يقول "ما بيصير مشكلة".

- "هل أستطيع رؤية الكود أو التقدم أثناء العمل؟" — المحترف يرحب. الهاوي يتردد لأنه يعرف أن كوده لن يصمد أمام مراجعة.

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

في عام 2001 — بعد أحداث 11 سبتمبر — بدأ مكتب التحقيقات الفيدرالي الأمريكي (FBI) مشروعاً لبناء نظام رقمي يُسمى Virtual Case File (VCF) لإدارة القضايا إلكترونياً بدلاً من الملفات الورقية.

المشروع أُسند لشركة SAIC بعقد قيمته 170 مليون دولار. بعد 3 سنوات من العمل أُلغي المشروع بالكامل ولم يُستخدم سطر واحد من الكود المكتوب. خسارة 170 مليون دولار من أموال دافعي الضرائب.

حسب تحقيق أجراه مكتب المفتش العام (OIG) التابع لوزارة العدل الأمريكية (2005)، الأسباب شملت: - مبرمجون عملوا بدون فهم كافٍ لاحتياجات المستخدمين (عملاء FBI). - غياب إدارة مشروع محترفة. - وعود بمواعيد تسليم غير واقعية. - عدم القدرة على توضيح التعقيد التقني لصانعي القرار.

الدرس: حتى على مستوى حكومي بميزانيات ضخمة، اختيار الفريق التقني الخطأ يُدمّر المشروع. والعلامات التحذيرية كانت موجودة من البداية — لكن لم يسأل أحد الأسئلة الصعبة.

تقرير CHAOS Report الذي تُصدره Standish Group منذ 1994 هو أشهر دراسة عالمية عن نجاح وفشل مشاريع تقنية المعلومات. نتائج التقرير لعام 2020 تكشف:

- 19% فقط من المشاريع تنجح بالكامل (تُنجز في الوقت والميزانية المحددين مع كل الميزات المطلوبة). - 50% من المشاريع تُعتبر "متعثرة" — تنتهي لكن بتأخير أو تجاوز ميزانية أو نقص في الميزات. - 31% من المشاريع تفشل تماماً — تُلغى أو لا تُستخدم أبداً.

العوامل الأكثر ارتباطاً بالفشل حسب التقرير: 1. عدم وضوح المتطلبات. 2. ضعف الكفاءة التقنية للفريق. 3. غياب مشاركة المستخدم/العميل.

هذه الأرقام تُثبت أن اختيار المبرمج المناسب ليس رفاهية — بل هو الفرق بين مشروع ناجح واستثمار ضائع.

إذا قرأت هذا المقال ووجدت نفسك في بعض هذه العلامات — لا تحبط. كل محترف مرّ بهذه المرحلة.

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

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

وفي سوقنا العربي، المشكلة لها بُعد إضافي. منصات مثل مستقل وخمسات مليئة بآلاف المبرمجين — الممتاز منهم والهاوي. تجربة سوق.كوم (Souq.com) التي أسسها رونالدو مشحور تُعلّمنا شيئاً مهماً: عندما بدأوا بناء المنصة في عمّان، لم يختاروا أرخص المبرمجين — اختاروا فريقاً يفهم السوق العربي وتحدياته التقنية (مثل دعم العربية RTL والدفع عند الاستلام). هذا الاستثمار في الفريق الصحيح هو جزء مما جعل Amazon تستحوذ عليهم بـ 580 مليون دولار عام 2017.

أو بالمصري: "مش كل مين قال أنا مبرمج يبقى فعلاً مبرمج — الشغل هو اللي بيتكلم!"

من مشروع FBI بـ 170 مليون دولار الذي لم يُنتج سطراً مفيداً، إلى 31% من المشاريع التقنية التي تفشل تماماً حسب Standish Group — الأرقام واضحة: اختيار المبرمج المناسب ليس مجرد قرار توظيف — إنه قرار مصيري لمشروعك. الأسئلة الصحيحة في الاجتماع الأول توفر عليك أشهراً من المعاناة وآلاف الدولارات من الخسائر. والمبرمج الحقيقي لن يزعجه أن تسأل — بل سيحترمك أكثر.