توظيف مهندسي البرمجيات: كيف تبدو العناية الواجبة التقنية

مشكلة توظيف المطورين

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

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

هذا الدليل يشرح كيف تبدو العناية الواجبة التقنية فعلاً—حتى لو لم تكن تقنياً بنفسك.

ما تقيّمه فعلاً

عندما توظف مهندس برمجيات أو فريقاً، تقيّم أربعة أشياء:

1. هل يستطيعون بناء ما تحتاجه؟ القدرة التقنية لتنفيذ مشروعك المحدد—وليس قدرة البرمجة العامة.

2. هل ستكون النتيجة قابلة للصيانة؟ الكود الذي يعمل في اليوم الأول لكن لا يمكن تعديله لا قيمة له. تحتاج عملاً يمكن أن يتطور.

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

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

العلامات الحمراء التي تتنبأ بالفشل

قبل مناقشة ما تبحث عنه، إليك ما يجب تجنبه:

"نستطيع بناء أي شيء" المهندسون الجيدون محددون حول خبرتهم. من يدعي أنه خبير في كل شيء ليس خبيراً في أي شيء. التخصص إشارة إيجابية.

لا أسئلة عن عملك إذا لم يسأل المطور أسئلة مفصلة عن عملياتك وسير عملك ومستخدميك، فهم يخططون لبناء برمجيات عامة لن تناسب احتياجاتك.

عروض التكنولوجيا أولاً "سنستخدم React و Node.js و AWS..." قبل فهم متطلباتك يعني أنهم يبيعون مهاراتهم، وليس يحلون مشكلتك.

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

عدم الرغبة في مشاركة الكود المطورون الذين لن يظهروا عملاً سابقاً—حتى في شكل محرر—قد لا يكون لديهم شيء ليظهروه. اطلب عينات كود ووثائق بنية.

السعر أقل بشكل كبير إذا كان عرض أرخص 50% من الآخرين، شيء ما خاطئ. قد يكونون في الخارج مع تحديات تواصل، مطورين مبتدئين بدون إفصاح، أو يخططون لاختصار الجهد.

أسئلة تكشف الكفاءة

هذه الأسئلة تساعد في تقييم القدرة التقنية حتى لو لم تكن تقنياً:

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

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

"ما الذي لن تستخدمه لهذا المشروع؟" الحكم التقني يتعلق بمعرفة ما يجب تجنبه بقدر ما يتعلق بمعرفة ما يجب استخدامه.

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

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

تقييم ملف الأعمال

عند مراجعة الأعمال السابقة:

ابحث عن التعقيد، وليس الجمال موقع مذهل بصرياً قد يكون قالب WordPress. أداة داخلية قبيحة قد تمثل هندسة متطورة. اسأل عن التحديات التقنية، وليس التصميم المرئي.

اسأل عن مساهمتهم المحددة "عملت على نظام الدفع" مختلف عن "بنيت نظام الدفع." وضّح بالضبط ما فعلوه مقابل ما فعله الفريق.

اتصل بالمراجع، لكن اسأل الأسئلة الصحيحة لا تسأل "هل كانوا جيدين؟" اسأل:

• هل بقي المشروع ضمن الميزانية؟ بكم؟
• كم من الوقت بعد الإطلاق قدموا الدعم؟
• هل كانت هناك مشاكل كبيرة اكتُشفت بعد الإطلاق؟
• هل ستوظفهم مرة أخرى لمشروع مماثل؟

أحكام العقد التي تحميك

العناية الواجبة التقنية تمتد للعقد:

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

تسليم الكود المنتظم اطلب تسليم الكود إلى مستودعك أسبوعياً، وليس فقط في نهاية المشروع. هذا يمنع حالات "مكتمل 90%" التي لا تصل أبداً إلى 100%.

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

شروط الصيانة ضمّن شروط دعم ما بعد الإطلاق. ما وقت الاستجابة للمشاكل الحرجة؟ ما المشمول مقابل القابل للفوترة؟ كم مدة التزامهم بالتوافر؟

أحكام الخروج ماذا يحدث إذا احتجت لإنهاء العلاقة؟ العقد يجب أن يحدد إجراءات تسليم الكود وجلسات نقل المعرفة ودعم الانتقال.

العلاقة التي تعمل

أفضل علاقات التطوير التي رأيتها تشترك في هذه الخصائص:

• تواصل واضح ومتكرر (أسبوعياً على الأقل)
• قرارات ومبررات موثقة
• عروض عمل منتظمة
• نقاش صادق للمشاكل والمقايضات
• احترام متبادل وتوقعات معقولة
• تفكير طويل المدى بعد المشروع الأولي

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

قراءة ذات صلة

• لماذا تفشل مشاريع البرمجيات المخصصة
• متى تكون البرمجيات المخصصة الخيار الخاطئ
• كيف يجب على الأطباء تقييم الشركاء التقنيين