10 أسئلة اسألها قبل ما تتعاقد مع شركة برمجة
الأسئلة اللي إجاباتها بتكشف الشركة الجادة من اللي هتضيّع وقتك.
أغلب المشاكل بتحصل بسبب حاجات مااتسألتش من الأول. الأسئلة دي بتوفر عليك شهور.
عن المشروع
- إيه اللي داخل في السعر بالظبط، وإيه اللي برة؟
- كام جولة تعديلات مشمولة؟
- الجدول الزمني إيه، وإيه اللي بيحصل لو اتأخر؟
- مين هيكتب المحتوى ويجيب الصور؟
عن الملكية
- الكود والدومين والاستضافة هيبقوا باسمي أنا ولا باسمكم؟
- لو قررت أشتغل مع حد تاني، هستلم إيه؟
السؤالين دول أهم اتنين في القايمة. فيه ناس كتير اكتشفت متأخر إن موقعها مش ملكها.
عن اللي بعد التسليم
- فترة الدعم قد إيه وبتغطي إيه؟
- التعديلات بعد كده بتتحسب إزاي؟
- لو الموقع وقع الساعة 11 بالليل، أعمل إيه؟
- ممكن أشوف مشروع سلمتوه وأكلم صاحبه؟
السؤال الأخير هو الفلتر الحقيقي. الشركة الواثقة هتوصّلك بعميل من غير تردد.
قارن بالدليل مش باسم التقنية
الاختيار الصح بيتحدد بالمخاطر والملكية والتغييرات المتوقعة خلال سنتين، مش باسم التقنية وحده. قيّم كل بديل على نفس المتطلبات: سرعة الإطلاق، تخصيص دورة العمل، الأمان، ملكية المحتوى، الربط، الدعم وتكلفة الانتقال لاحقًا.
اطلب تجربة صغيرة لأصعب متطلب قبل التعاقد على المشروع كله. واتأكد مين يملك ملفات المصدر والدومين والحسابات وتصدير البيانات. السعر القليل في البداية بيبقى غالي لو الشركة مش قادرة تنقل محتواها أو بياناتها من غير ما تبدأ من الصفر.
- استخدم قائمة متطلبات واحدة مع كل بديل أو مقدم خدمة.
- اختبر أصعب Integration أو Workflow قبل الالتزام الكامل.
- احسب تكلفة الملكية لسنتين بما فيها الدعم والانتقال.
- اكتب الملكية والصلاحيات وشروط الخروج في العقد.
قائمة تنفيذ خاصة بالموضوع
- اطلب مشروعًا مشابهًا ومعايير استلامه، مش Screenshot في Portfolio فقط.
- حدد مدير المشروع ومسار الموافقات وزمن الرد المتوقع من الطرفين.
- اتأكد إن الـRepository والدومين وAnalytics وحسابات الـProduction باسم العميل.
- اكتب تسعير Change Requests وضمان العيوب بعد الإطلاق قبل البداية.
تفاصيل أغلب العروض بتفوتها
مقارنات الشركة أو التقنية بتفشل لما تقارن أسماء بدل سيناريوهات الفشل. الأسئلة الأصعب: مين يقدر يعدّل بأمان؟ العطل بيتشخّص في قد إيه؟ إيه البيانات اللي تتصدر؟ وإيه اللي يحصل لو الشخص أو المنصة الأصلية بقوا غير متاحين؟
- 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 غالبًا هيأثر على المشروع؟
- إيه الخارج صراحةً من الدعم بعد الإطلاق؟
سيناريو واقعي يوضح الفرق
مثال: اطلب من مقدم الخدمة يعرض فشل إرسال Form، مش النجاح بس. إجابته تكشف طريقة التفكير في Validation ورسالة الخطأ والـLogs والملكية والدعم أكتر من Portfolio لامع.
عندك سؤال المقال مردّش عليه؟
ابعتهولنا. بنرد بجد، سواء اشتغلت معانا في الآخر أو لأ.
