إنقاذ مشروع برمجي متوقف يسير بهذا الترتيب: أولًا أمّن الوصول (مستودع الكود، الخوادم، النطاق، حسابات متاجر التطبيقات)، ثم اطلب من فريق مستقل تدقيق الكود، وبعدها فقط قرّر بناءً على نتيجة التدقيق هل تستكمل أم تعيد الكتابة. أكثر خطأ نراه هو البدء بطلب عرض سعر من شركة جديدة لـ«إكمال ما تبقى»؛ فما دام أحد لم يفتح الكود فعلًا، فكل سعر مجرد تخمين. نشرح هنا الخطوات التي نتبعها نحن عندما نستلم مشروعًا من غيرنا.
لماذا تتوقف المشاريع البرمجية قبل اكتمالها؟
في المشاريع التي تصلنا نادرًا ما يكون السبب سوء نية واحدًا. غالبًا تتراكم عدة مشكلات: النطاق لم يُكتب، فيكبر العمل باستمرار، والسعر الثابت لا يحتمل هذا التوسع، فيبتعد المطوّر تدريجيًا عن مشروع يخسر فيه. وإذا كان شخص واحد فقط يفهم النظام، يكفي أن ينتقل إلى عمل آخر. وأحيانًا يكون الأساس التقني ضعيفًا لدرجة أن كل ميزة جديدة تكسر ميزتين قديمتين فيتوقف الفريق عن التقدم. معرفة السبب مهمة، لأنها الطريق لتجنب الفخ نفسه مع الفريق التالي.
ما الذي يجب تأمينه في أول 48 ساعة؟
إن لم تنقطع العلاقة تمامًا، فانقل الصلاحيات التالية إلى اسمك قبل أي نقاش تقني. وإن كان الجو متوترًا فاطلبها كلها في طلب مكتوب واحد على شكل قائمة:
- مستودع الكود: صلاحية المالك على GitHub أو GitLab أو Bitbucket. ملف مضغوط لا يكفي، فسجل الالتزامات يوضح كيف تطوّر الكود.
- الخوادم والحسابات السحابية: لوحة الاستضافة ومزوّد السحابة وقاعدة البيانات والنسخ الاحتياطية. وتحقق من البطاقة التي تُدفع منها الفواتير.
- النطاق وDNS: يجب أن يكون حساب مسجّل النطاق باسمك.
- حسابات المتاجر: App Store Connect وGoogle Play Console. إن كان التطبيق منشورًا في حساب المطوّر نفسه فخطط لعملية النقل كخطوة مستقلة.
- الخدمات الخارجية: مفاتيح الدفع والرسائل النصية والبريد والخرائط والإشعارات.
- متغيرات البيئة وملاحظات التثبيت وملفات التصميم إن وُجدت.
إذا كان الكود معك بينما الخادم والنطاق وحساب المتجر عند غيرك، فأنت لا تملك المنتج، بل نسخة منه فقط.
بعد استلام الصلاحيات غيّر كل كلمات المرور ومفاتيح API. هذا ليس اتهامًا بل خطوة تسليم معتادة. وإذا كان عقدك ينص على نقل الكود المصدري والحقوق المالية إليك، فسيكون الطلب أسهل بكثير؛ وقد شرحنا لماذا يجب وضع هذه البنود منذ البداية في مقالنا عن عقد تطوير البرمجيات. هذا المقال ليس استشارة قانونية؛ وفي حال النزاع استشر محاميًا.
كيف يجري تدقيق الكود؟
تدقيق الكود يعني أن يشغّل الفريق الجديد المشروع فعلًا وينظر في داخله. الرأي المبني على عرض تجريبي أو لقطات شاشة ليس تدقيقًا. التدقيق الجيد يجيب كتابيًا عن هذه الأسئلة:
- هل يمكن تثبيت المشروع وتشغيله على جهاز جديد باتباع التوثيق؟
- ما الميزات التي تعمل فعلًا، وما التي توجد على الشاشة فقط؟
- هل إصدارات المكتبات وإطار العمل حديثة، أم توجد مكونات انتهى دعمها؟
- هل بنية قاعدة البيانات منطقية، وهل توجد بيانات حقيقية في بيئة التشغيل، وكيف ستُحمى؟
- هل توجد ثغرات أمنية واضحة: كلمات مرور داخل الكود، أو واجهات API غير محمية، أو شاشات بلا تحقق من الصلاحيات؟
- هل توجد اختبارات وتسجيل للأخطاء ونشر آلي؟
ناتج التدقيق تصنيف واضح لكل وحدة، مثل «سليمة» أو «قابلة للإصلاح» أو «تحتاج إعادة كتابة». هذا التصنيف هو عمليًا خريطة الدين التقني في المشروع، والأساس الوحيد المعقول للقرار التالي. مدته تعتمد على حجم المشروع؛ المهم أن يُسعَّر التدقيق كعمل مستقل ومحدود، فتعرف وضعك دون أن تلتزم بعقد الاستكمال.
الاستكمال أم إعادة الكتابة؟
غريزة كل فريق جديد هي إعادة الكتابة، لأن قراءة كود الآخرين أصعب من كتابة كودك. لذلك اتخذ القرار بناءً على التدقيق لا على الانطباع. قاعدة تقريبية: إذا كان نموذج البيانات متينًا والمشكلات محصورة في وحدات بعينها، فالاستكمال على الكود الحالي أسرع في أغلب الأحيان. أما إذا كان نموذج البيانات معطوبًا، أو كان إطار العمل الأساسي على إصدار بلا دعم، أو كان أي تعديل يكسر شيئًا آخر، فإعادة الكتابة هي الخيار الأقل خطرًا.
وفي الغالب يكون الجواب الصحيح بين الاثنين: تُحفظ الأجزاء العاملة، وتُعاد كتابة الوحدة الأكثر إشكالًا أولًا، ويُحسَّن الباقي تدريجيًا. وإن كان هناك مستخدمون وبيانات حية، فالانتقال على مراحل أكثر أمانًا من التبديل في ليلة واحدة؛ والخطوات الواردة في مقالنا عن ترحيل البيانات من النظام القديم تنطبق هنا أيضًا.
كيف يتم التسليم إلى فريق جديد؟
اجعل العقد الأول مع الفريق الجديد صغيرًا: التدقيق مع أول الإصلاحات الحرجة. بذلك ترى طريقة عمل الفريق ولا تربط كل شيء بعقد واحد مرة أخرى. وللعمل المتبقي اطلب نطاقًا مكتوبًا ومعايير قبول ودفعات مقسمة على مراحل. يبقى المستودع في حسابك منذ اليوم الأول ويساهم فيه الفريق الجديد. جمعنا الأسئلة التي تطرحها عند اختيار المزوّد في دليلنا عن اختيار شركة البرمجيات.
ولكي لا تتكرر القصة، اكتسب مع التسليم ثلاث عادات: دليل تثبيت قصير يُحدَّث مع كل إصدار، ومراقبة الأخطاء وتسجيلها لتظهر المشكلات، وفريق يعرف المشروع فيه شخصان على الأقل.
الخلاصة
المشروع البرمجي المتوقف غالبًا ليس خسارة كما يبدو، لكن ترتيب الإنقاذ مهم: الوصول أولًا، ثم التدقيق، ثم القرار. لا تناقش السعر قبل التدقيق، ولا تقبل إعادة كتابة لم يبررها التدقيق. إن كان لديك مشروع نصف مكتمل، فسيفحصه فريق البرمجيات الخاصة لدينا أولًا ويقدّم لك تقييمًا مكتوبًا؛ وبعدها يمكنك طلب عرض سعر إن رغبت.