حين يأتيني عميل من الكويت يسأل عن شركة تطوير برمجيات، أول سؤال أطرحه عليه ليس "كم التكلفة؟" أو "كم المدة؟". أسأل: "هل رأيت كودهم الفعلي؟ هل سألتهم عن نسبة تغطية الاختبارات؟". المقولة القديمة صحيحة: الشركات الجيدة لا تختبئ وراء عروضها التقديمية.
ابدأ بأسئلة تقنية صريحة: لا تتردد
معظم أصحاب الأعمال يخجلون من طرح أسئلة تقنية عميقة. يقولون: "أنا لست مهندساً". لكنك لا تحتاج أن تكون مهندساً لتطرح الأسئلة الصحيحة. تحتاج فقط إلى فهم ماذا تسأل، وماذا تتوقع من الإجابة.
اسأل شركة التطوير الأسئلة التالية مباشرة:
- "كيف تكتبون الاختبارات (unit tests)؟ وما نسبة تغطية الاختبارات في مشاريعكم؟", الإجابة الجيدة: "نحن نستهدف 70% على الأقل، والوحدات الحساسة 90%+". الإجابة السيئة: "نحتبر برنامج قبل الإطلاق" (هذا ليس اختبار آلي).
- "هل تستخدمون version control؟ وكيف تدير فريقكم الـ code reviews؟", الإجابة الجيدة: "كل التغييرات تمر عبر Git، وكل pull request يُراجعه فريق قبل الدمج". الإجابة السيئة: "كل واحد يشتغل على نسخته الخاصة".
- "ماذا عن التوثيق؟ هل الكود موثّق؟ هل عندكم documentation للمعمارية؟", الفريق الاحترافي عنده README واضح، والهندسة معمارية موثّقة، حتى لو بسيطة.
أبدِ رأيك واسأل. الشركة الحقيقية ستصرّح بثقة عن عملياتها.
اطلب نموذج من الكود الفعلي: هذا الاختبار الحقيقي
"أريد أن أرى مثالاً من مشروع سابق". جملة بسيطة، لكنها قوية جداً. الفريق الاحترافي سيعطيك نموذج كود حقيقي (أو يشرح لماذا لا يستطيع, ربما保密 العميل).
حين تنظر إلى الكود، ابحث عن:
- الوضوح: هل تستطيع أن تفهم ما يفعله السطر البرمجي دون جهد كبير؟
- عدم التكرار (DRY): هل الكود يكرر نفسه بلا ضرورة؟ أم أنهم استخلصوا الأنماط المشتركة؟
- المرونة: لو أضفت feature جديد، هل يسهل تعديل الكود أم سيحتاج إلى إعادة كتابة كاملة؟
رأيت مشاريع كويتية كثيرة بنيت بدون أي هيكل هندسي حقيقي, كود واحد ضخم، بدون layers واضحة، بدون فصل الاهتمامات. بعد عام، عندما يريدون إضافة feature جديد، يكتشفون أنهم محاصرون. تجنب هذا: اسأل عن المعمارية.
ملاحظة من الميدان: الكود الوسخ يكلفك أضعافاً مضاعفة
عميل كويتي دفع 8,000 دينار لتطبيق موبايل من شركة لم يفحص جودة الكود. بعد عام، أراد إضافة feature بسيطة (push notifications). استغرقت 3 أسابيع بسبب معمارية الكود السيئة. الآن يندم: لو أنفق 2,000 دينار إضافي على فريق محترف من البداية، ما كان احتاج لهذا. الجودة رخيصة في البداية، مكلفة جداً في النهاية.
المعمارية والتصميم: اسأل عن الرؤية الكبيرة
بعض الشركات في الكويت تبني تطبيقات دون خطة طويلة الأمد. هل تحتاج أن توسّع التطبيق لاحقاً؟ هل ستضيف features جديدة؟ هل تتوقع نمو في عدد المستخدمين؟
الفريق الجيد سيناقش معك:
- هندسة قابلة للتوسع (scalability)
- كيفية إدارة البيانات عندما تكبر
- الأمان والحماية من البداية
- الأداء وسرعة التطبيق
إذا قالوا: "نبني أولاً، ننظف لاحقاً"، توقف. هذا نص حمراء كبير. من تجربتي، "لاحقاً" لا يأتي أبداً.
تحقق من معايير الجودة برقم واحد: نسبة التغطية (Coverage)
إذا طلبت فقط متري واحد، أطلب: "ما نسبة تغطية الاختبارات في آخر مشروع أنهيتموه؟"
نسبة التغطية البطالة: أقل من 40%
نسبة التغطية المقبولة: 50-70%
نسبة التغطية الاحترافية: 75%+
لا تترجم هذا ترجمة حرفية, ليس كل 1% من التغطية حقيقي. لكن الفريق الذي يستهدف 80% يقضي وقتاً أكبر بكثير على الجودة من الفريق الذي يقول: "الاختبار مسؤولية الـ QA فقط".
الأداء والأمان: علامات قد تفصل الاحترافيين عن الهواة
اسأل: "كيف تختبرون الأداء؟ هل عندكم monitoring لسرعة التطبيق في الإنتاج؟ كيف تتعاملون مع الأمان وحماية البيانات؟"
الفريق الاحترافي:
- يستخدم أدوات monitoring (مثل Sentry، New Relic، أو DataDog)
- يقيس زمن التحميل والأداء بشكل مستمر
- عنده عملية واضحة لمراجعة الأمان, لا يخزن كلمات السر بصيغة واضحة، يستخدم encryption، يحمي من SQL injection
الفريق الضعيف:
- يقول: "التطبيق سريع" دون قياسات حقيقية
- لا يهتم بالأمان حتى يتعرض للهجوم الأول
- لا يوجد monitoring, لا يعرف إذا كان التطبيق slow أو crashed
العلامات التحذيرية التي يجب أن تفر منها
الخمس علامات الحمراء التي رأيتها تغرق المشاريع
1. "سنستخدم التكنولوجيا الجديدة (X) فقط لأنها حلوة":" الفريق الحكيم يختار التكنولوجيا بناءً على احتياجاتك، لا بناءً على trend.
2. "لا نحتاج unit tests، الـ QA سيختبر كل شيء":" هذا نص حمراء كبيرة جداً. التكنولوجيا الحديثة تتطلب اختبار برمجي آلي.
3. "معظم الفريق سيكونون freelancers من أماكن مختلفة":" لا بأس بـ freelancers، لكن بدون فريق core مستقر، الجودة تنخفض والتواصل يصبح سيئاً.
4. "سعرنا منخفض جداً لأننا شركة startup":" الجودة تكلف. إذا كانوا يقدمون سعر نصف السوق، اسأل: لماذا؟
5. "لا نملك team lead تقني يراجع الكود":" بدون قيادة تقنية قوية، التطبيق سيصبح chaos. هذا حتمي.
الخطوات الملموسة قبل التوقيع
قبل أن توقّع على أي عقد، ترتيب هذه الخطوات:
- جلسة تقنية عميقة: اجلس مع الـ technical lead للشركة (ليس sales rep)، واسأل أسئلة معمارية حقيقية. إذا لم يستطع أن يجيب بوضوح، علم حمراء.
- طلب أمثلة من الكود: قل: "أريد أن أرى مثالاً من مشروع سابق مشابه ليّ." إذا رفضوا (بدون سبب保密 واضح)، حذر.
- التحقق من التجارب السابقة: اطلب أسماء عملاء سابقين وتواصل معهم مباشرة. سؤال واحد مهم: "هل العمل نُسلِّم في الموعد والجودة اللي توقعت؟" إذا قالوا "لا"، استمع.
- محادثة عن التوقعات الطويلة الأمد: حتى لو كان المشروع الأول بسيطاً، ناقش كيف ستدعم الشركة التطبيق لاحقاً. هل هناك رسوم صيانة؟ هل سيتركونك بكود فقط؟ هل يمكنك توظيف مهندسين آخرين للعمل عليه؟
الخلاصة: الجودة ليست خياراً فاخراً
قد تشعر أن هذا كله معقد ومحبط. لكن أخبركم بسر: الشركات الاحترافية ترحب بهذه الأسئلة. لأن جودة عملهم تتحدث عن نفسها. الشركات الضعيفة هي من تحاول تجنب الأسئلة التقنية.
في الكويت والخليج، لدينا خيارات كثيرة من شركات التطوير. استخدم هذه الحرية. اختر الفريق الذي يأخذ جودة الكود بجدية. لأن بعد التوقيع، صاحب العمل هو الذي يدفع ثمن الأخطاء, بأموال وبوقت وبتوتر. لا تتركها للصدفة.