توظيف مبرمج ولا التعاقد مع شركة؟
حساب صريح للتكلفة والمخاطر في الاختيارين.
السؤال ده بيتسأل لما الشغل يكبر. والإجابة بتعتمد على استمرارية الشغل مش حجمه.
التوظيف يناسبك لو
- عندك شغل تطوير مستمر طول السنة
- المنتج التقني هو أساس شغلك
- تقدر تقيّم مستوى المبرمج فنياً
- مستعد لتكلفة كاملة: مرتب وتأمينات وأجهزة وإجازات
الشركة تناسبك لو
- المشروع له بداية ونهاية
- محتاج تخصصات مختلفة مش شخص واحد
- مش قادر تقيّم المستوى الفني بنفسك
- عايز تبدأ من غير دورة توظيف طويلة
خطر التوظيف الأكبر: مبرمج واحد بيبني نظام محدش غيره فاهمه. لو مشي، إنت في مشكلة.
حل وسط
شركة تبني النظام وتسلّمه موثّق، وموظف عندك يتابع التشغيل. ده بيجمع الاتنين.
قارن بالدليل مش باسم التقنية
الاختيار الصح بيتحدد بالمخاطر والملكية والتغييرات المتوقعة خلال سنتين، مش باسم التقنية وحده. قيّم كل بديل على نفس المتطلبات: سرعة الإطلاق، تخصيص دورة العمل، الأمان، ملكية المحتوى، الربط، الدعم وتكلفة الانتقال لاحقًا.
اطلب تجربة صغيرة لأصعب متطلب قبل التعاقد على المشروع كله. واتأكد مين يملك ملفات المصدر والدومين والحسابات وتصدير البيانات. السعر القليل في البداية بيبقى غالي لو الشركة مش قادرة تنقل محتواها أو بياناتها من غير ما تبدأ من الصفر.
- استخدم قائمة متطلبات واحدة مع كل بديل أو مقدم خدمة.
- اختبر أصعب Integration أو Workflow قبل الالتزام الكامل.
- احسب تكلفة الملكية لسنتين بما فيها الدعم والانتقال.
- اكتب الملكية والصلاحيات وشروط الخروج في العقد.
قائمة تنفيذ خاصة بالموضوع
- وظّف لما الشغل مستمر ومعرفة المجال بتتراكم والتنسيق اليومي أساسي.
- اعمل Outsource لما النطاق متخصص أو متغير أو محتاج فريقًا كاملًا لنتيجة محددة.
- قارن التوظيف والإدارة والأدوات والإجازات والاستبدال ونقل المعرفة بالجنيه المصري.
- في الحالتين خلي المعمارية والحسابات والتوثيق والاستلام تحت ملكية الشركة.
تفاصيل أغلب العروض بتفوتها
مقارنات الشركة أو التقنية بتفشل لما تقارن أسماء بدل سيناريوهات الفشل. الأسئلة الأصعب: مين يقدر يعدّل بأمان؟ العطل بيتشخّص في قد إيه؟ إيه البيانات اللي تتصدر؟ وإيه اللي يحصل لو الشخص أو المنصة الأصلية بقوا غير متاحين؟
- Requirement Scorecard موزونة حسب خطر البيزنس، مش عدد المميزات.
- Proof of Concept لأصعب Workflow أو Integration.
- ملكية واضحة للدومين والـRepository والـProduction وAnalytics وحسابات الموردين.
- Maintenance Map تحدد مين يحدث الكود والمحتوى والمكتبات والاستضافة.
- Exit Test يصدّر المحتوى والبيانات التشغيلية بصيغة مفيدة.
طبقة التنفيذ اللي بتفرق مع TechMate
TechMate بتعتبر استقلال العميل جزءًا من الجودة. المشروع بيتنظم بحيث العميل يملك الصلاحيات والقرارات، وفي نفس الوقت يفضل التوثيق والبيئات وتاريخ الإصدارات مفهومين لأي فريق مؤهل.
- مسؤول تسليم واحد يربط التصميم والمحتوى والبرمجة.
- Trade-offs مكتوبة بدل ادعاء إن كل اختيار مناسب لكل حالة.
- عرض كل مرحلة برحلة العميل، مش Screens منفصلة.
- Risk Register للربط والنقل وحدود الخدمات الخارجية.
- حدود الدعم ومسار التصعيد مكتوبين قبل الإطلاق.
مراحل تنفيذ تقلل المخاطرة
تعامل مع القرار كـDue Diligence صغيرة. ابدأ بالمخاطر صعبة الرجوع، واختبر أصعب متطلب، ووضح الملكية قبل مقارنة جمال العروض.
- اكتب النتائج الإلزامية والفشل غير المقبول.
- وزن المعايير حسب أثرها التشغيلي والمالي.
- اطلب دليلًا لأصعب متطلب.
- راجع الملكية والأمان والدعم وشروط الخروج.
- ابدأ بمرحلة مستقلة قابلة للاستلام.
أسئلة تكشف جودة التنفيذ
- مين يغطي الشخص الأساسي لو غاب؟
- هل فريق آخر يقدر ينشر من الـRepository المستلمة؟
- إيه Data Export اللي اتجربت فعلًا؟
- أنهي Limit غالبًا هيأثر على المشروع؟
- إيه الخارج صراحةً من الدعم بعد الإطلاق؟
سيناريو واقعي يوضح الفرق
مثال: شركة عملت Outsource للإطلاق من غير Product Owner داخلي. القرارات تتأخر والمعرفة تتفتت والمورد يبقى المالك بالصدفة. Outsource للتنفيذ مش معناه Outsource لمسؤولية البيزنس.
عندك سؤال المقال مردّش عليه؟
ابعتهولنا. بنرد بجد، سواء اشتغلت معانا في الآخر أو لأ.
