استلام مشروع برمجي متعثر: كيف تُكمل مشروعاً غير مكتمل مع شركة جديدة؟ (دليل 2026)

«المبرمج اختفى والمشروع نصّه خلص — هل تستطيعون إكماله؟» رسالة تصلنا بصيغ مختلفة من أصحاب شركات في القاهرة والإسكندرية والرياض وجدة. أحياناً يكون المطور فريلانسر توقف عن الرد، وأحياناً شركة صغيرة أغلقت أو انشغلت بعميل أكبر، وأحياناً فريق ما زال يرد ويَعِد لكن لا شيء جديد يعمل منذ أشهر. والنتيجة واحدة: دفعات خرجت، ومواعيد إطلاق فاتت، ونسخة تجريبية لا يمكن عرضها على عميل، وصاحب مشروع لا يعرف هل يملك أصلاً ما دفع ثمنه.

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

هذا الدليل مكتوب لصاحب العمل لا للمبرمج. نغطي فيه علامات أن المشروع متعثر فعلاً، وما يجب فعله في أول 72 ساعة لتأمين حساباتك وكودك وبياناتك، وما يشمله التدقيق الفني للكود، وإطار القرار بين الإنقاذ وإعادة الكتابة وإعادة البناء الجزئية، وكيف يستلم فريق جديد المشروع، وما يجب أن يتضمنه العقد الجديد، وكيف تمنع تكرار ما حدث. نحن في جاد للتطوير الرقمي (Jad Digital) نستلم مشاريع متعثرة من فرق أخرى منذ سنوات، وسنقول بصراحة متى يكون الإكمال منطقياً ومتى لا يكون.

التأخير وحده ليس دليلاً على التعثر؛ المشاريع البرمجية تتأخر كثيراً لأسباب مشروعة مثل تغيّر المتطلبات أو تأخر محتوى من جانبك. لكن هناك أنماطاً تتكرر في المشاريع التي توقفت فعلاً، وإذا اجتمع منها اثنان أو ثلاثة فأنت أمام مشكلة حقيقية:

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

• لا يوجد عرض فعلي منذ أسابيع. التحديثات كلها رسائل نصية من نوع «شغالين عليها» أو لقطات شاشة، دون رابط تجريبي تستطيع فتحه وتجربته بنفسك.
• الإصلاح يكسر شيئاً آخر. كل مرة يُصلح فيها خطأ يظهر خطأ جديد في مكان لا علاقة له به، وهي علامة كلاسيكية على كود بلا بنية ولا اختبارات.
• لا أحد يعطيك صلاحية على المستودع. تطلب الوصول إلى الكود على GitHub أو GitLab فتسمع «بعد ما نخلص» أو «مش هتفهم منه حاجة».
• المواعيد تتحرك ولا تقترب. كل اجتماع يحدد موعداً جديداً، والنسبة المنجزة المعلنة لا تتغير منذ فترة.
• الأسئلة البسيطة بلا إجابة. أين يستضاف التطبيق؟ ما قاعدة البيانات المستخدمة؟ من يملك حساب Apple Developer؟ إن لم يستطع الفريق الإجابة بوضوح فالمشكلة أعمق من التأخير.
• طلبات دفع قبل التسليم. الضغط لدفع دفعة جديدة مقابل وعد بإنجاز لم يُعرض، لا مقابل شيء رأيته يعمل.
• تغيّر الأشخاص باستمرار. كل شهر مطور جديد يبدأ بفهم المشروع من أوله، ولا أحد يحمل الصورة الكاملة.

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

القاعدة البسيطة: كل حساب يتعلق بمشروعك يجب أن يكون مملوكاً لشركتك أو باسمك، مع منح الفريق صلاحيات عليه، لا العكس. راجع القائمة التالية بنداً بنداً:

• الدومين. ادخل إلى لوحة مسجّل الدومين وتأكد أن الحساب باسمك وبريدك، وأن قفل النقل مفعّل، وأن تاريخ التجديد لم يقترب دون علمك.
• الاستضافة والسيرفرات. حساب الاستضافة أو السحابة (AWS أو Google Cloud أو أي مزود آخر) ومن يملك وسيلة الدفع المرتبطة به. إن كان باسم المطور فاطلب نقله أو على الأقل إضافتك مالكاً.
• مستودع الكود. مستودع على GitHub أو GitLab أو Bitbucket تملكه منظمتك أنت، والفريق مدعو إليه. اطلب نسخة كاملة بالتاريخ (history) لا ملف مضغوط فقط.
• قواعد البيانات. نسخة احتياطية حديثة من قاعدة البيانات الإنتاجية والتجريبية، مع بيانات الوصول، ومعرفة أين تُخزَّن الملفات المرفوعة والصور.
• حسابات متاجر التطبيقات. حساب Apple Developer وحساب Google Play Console يجب أن يكونا باسم الشركة. نقل تطبيق منشور بين الحسابات ممكن لكنه إجراء له خطوات، وأسهل بكثير وأنت تملك الحساب من البداية.
• مفاتيح الخدمات الخارجية. بوابات الدفع، وخدمات الرسائل والإشعارات، وWhatsApp Business API، وخرائط جوجل، وخدمات البريد، وأي API مدفوع. اعرف أين هي، ومن يملك الحساب، وغيّر المفاتيح الحساسة بعد خروج الفريق القديم.
• التحليلات وأدوات التسويق. Google Analytics وSearch Console وحسابات الإعلانات وأي بكسل تتبع.- التصميمات والمستندات. ملفات Figma أو أي أداة تصميم، ومستندات المتطلبات، وأي توثيق موجود.

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

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

بعد تأمين الأصول، لا تطلب من الشركة الجديدة عرض سعر لـ«إكمال المشروع» مباشرة. أي شركة تعطيك رقماً قبل أن تقرأ الكود إما تخمّن أو تبيع. الخطوة الصحيحة هي تدقيق فني محدد النطاق، وهو أشبه بالكشف الطبي قبل قرار العملية. التدقيق الجاد يغطي عادةً:

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

• هل يعمل المشروع أصلاً؟ هل يمكن تشغيل الكود على جهاز جديد من التعليمات الموجودة؟ مشاريع كثيرة لا تعمل إلا على جهاز المطور الأصلي بسبب إعدادات لم تُوثَّق.
• مطابقة الكود لما وُعدت به. قائمة بالشاشات والوظائف المطلوبة، وأمام كل منها: مكتملة، أو جزئية، أو غير موجودة، أو موجودة شكلياً بلا منطق خلفها.
• البنية والتقنيات. هل التقنيات المستخدمة حديثة ومدعومة؟ هل الكود منظم في طبقات واضحة أم كتلة واحدة متشابكة؟ هل هناك اعتماديات قديمة أو مهجورة؟
• قاعدة البيانات. هل تصميم الجداول والعلاقات يحتمل نمو البيانات؟ هل هناك بيانات حقيقية يجب الحفاظ عليها؟
• الأمان. كلمات مرور أو مفاتيح مكتوبة داخل الكود، وثغرات واضحة في تسجيل الدخول والصلاحيات، وبيانات حساسة غير محمية.
• الاختبارات والجودة. هل توجد اختبارات آلية؟ ما مستوى تكرار الكود؟ هل التسمية مفهومة لمطور جديد؟
• الأداء. صفحات بطيئة، واستعلامات ثقيلة، وتطبيق يستهلك البطارية أو يتجمد.
• البيئات والنشر. هل توجد بيئة تجريبية (staging) منفصلة عن الإنتاج؟ كيف يُنشر التحديث؟ يدوياً عبر نسخ ملفات أم بخط نشر واضح؟
• التوثيق. هل يوجد ملف يشرح التشغيل والإعدادات والمتغيرات؟ أم أن المعرفة كلها كانت في رأس شخص واحد؟

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

الإنقاذ يعني الاحتفاظ بالكود الحالي وإكماله وإصلاح عيوبه. يكون منطقياً حين تجتمع هذه الشروط:

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

• التقنيات المستخدمة حديثة ومعروفة ويسهل إيجاد مطورين لها.
• البنية الأساسية سليمة حتى لو كانت هناك أخطاء في التفاصيل.
• جزء كبير من الوظائف يعمل فعلاً ويمكن اختباره.
• هناك مستخدمون أو بيانات حقيقية على النظام، وإيقافه له تكلفة على عملك.

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

والنقطة التي يغفلها كثيرون: إعادة الكتابة لا تعني أن كل ما دفعته ضاع. المتطلبات التي اتضحت، والتصميمات، ومعرفتك الأدق بما يريده عملاؤك، كلها أصول تختصر البناء الجديد.

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

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

حتى لو كان الفريق القديم متعاوناً، فإن نقل مشروع برمجي بين فريقين عملية لها خطوات. التسليم الجيد يشمل:

وإن لم يتعاون الفريق القديم إطلاقاً، فالمشروع لا يزال قابلاً للاستلام غالباً ما دام الكود والحسابات في يدك، لكن مرحلة الاستكشاف ستكون أطول لأن الفريق الجديد سيعيد اكتشاف ما لم يُوثَّق.

وأول ما يفعله فريق محترف بعد الاستلام هو ألا يغيّر شيئاً في الإنتاج. يُنشئ أولاً بيئة تجريبية تطابق الإنتاج، ويضع نظام نسخ احتياطي، ثم يبدأ التعديل هناك. أي فريق يبدأ بتعديلات مباشرة على النظام الحي في أسبوعه الأول يكرر نمط الفوضى نفسه.

• الكود الكامل بتاريخه في مستودع تملكه، مع كل الفروع (branches) لا الفرع الرئيسي فقط.
• ملف تشغيل وإعدادات يشرح كيف يُشغَّل المشروع محلياً، والمتغيرات المطلوبة، والخدمات الخارجية التي يعتمد عليها.
• وصف البيئات: أين الإنتاج، وأين البيئة التجريبية إن وجدت، وكيف يتم النشر.
• قاعدة البيانات: نسخة احتياطية، ومخطط الجداول، وأي سكريبتات ترحيل (migrations).
• قائمة بالمشاكل المعروفة والأعمال غير المكتملة، حتى لو كانت مكتوبة على عجل.
• الحسابات والمفاتيح كما في قائمة الـ72 ساعة، منقولة إلى ملكيتك.
• جلسة نقل معرفة إن أمكن، ولو ساعة أو ساعتين مع المطور السابق، تُسجَّل لمن يحتاجها لاحقاً.

المشروع المتعثر غالباً بدأ بعقد ضعيف أو بلا عقد أصلاً. لا تكرر ذلك مع الفريق الجديد. العقد الجيد للمرحلة التالية يوضح:

البند الأخير تحديداً هو ما كان سيحميك في المرة الأولى. اكتبه وأنت والفريق على وفاق، لا بعد أن تبدأ المشاكل.

• ملكية الكود والملكية الفكرية: تنتقل إليك بالكامل مع كل دفعة أو عند التسليم، بما في ذلك التصميمات والتوثيق.
• وضع الكود القديم: أن الفريق الجديد يعمل على أصل تملكه أنت، وأن مسؤوليته تبدأ من تاريخ الاستلام لا عن عيوب سابقة لم يكتشفها التدقيق.
• نطاق العمل بمراحل: كل مرحلة بمخرجات قابلة للاختبار، ومعايير قبول واضحة.
• الدفع مقابل المخرجات: لا دفعات مقابل «نسبة إنجاز» معلنة، بل مقابل مرحلة رأيتها تعمل.
• الوصول المستمر: حقك في الوصول إلى المستودع والبيئة التجريبية طوال المشروع.
• السرية: حماية بياناتك وبيانات عملائك.
• الضمان والدعم بعد الإطلاق: فترة إصلاح عيوب محددة، وما بعدها يخضع لاتفاق صيانة منفصل كما نشرح في صيانة الموقع بعد الإطلاق.
• إنهاء العلاقة: ماذا يحدث إن قررت التوقف، وكيف تُسلَّم الأصول حينها.

لن نعطيك أرقاماً هنا، لأن تكلفة إكمال مشروع متعثر تتحدد بعوامل لا يمكن معرفتها قبل التدقيق. لكن هذه هي العوامل التي تحدد حجم العمل فعلاً:

والطريقة الأذكى للتخطيط هي تقسيم ما تبقى إلى مراحل قصيرة: مرحلة استكشاف وتدقيق محددة، ثم مرحلة تثبيت، ثم مراحل إكمال كل منها تنتهي بنسخة تعمل. هكذا تقيس جدية الفريق الجديد بسرعة، وتحتفظ بحق التوقف إن لم تتحقق النتائج. وإن لم تكن متطلباتك مكتوبة بوضوح، فهذا وقت كتابتها؛ دليلنا عن كتابة Brief لمشروع برمجي يساعدك على تحويل ما في رأسك إلى وثيقة يمكن التسعير عليها.

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

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

• الوصول إلى المستودع من اليوم الأول. لست مضطراً لقراءة الكود، لكن وجودك في المستودع يعني أن الكود موجود ويتحرك، وأنك تملكه.
• عرض أسبوعي أو كل أسبوعين على بيئة تجريبية تفتحها بنفسك. القاعدة: ما لم تجربه بيدك لم يُنجز.
• مراحل قصيرة بمعايير قبول. بدل دفعة كبيرة مقابل «النسخة الأولى»، مراحل صغيرة تنتهي كل منها بشيء يعمل.
• الحسابات باسمك دائماً. الدومين والاستضافة ومتاجر التطبيقات تُنشأ باسم شركتك من البداية.
• توثيق مستمر. اطلب ملف تشغيل محدّثاً كبند تسليم في كل مرحلة.
• شخص مسؤول من جانبك. يحضر العروض، ويختبر، ويوافق على المراحل، ويكون نقطة التواصل الوحيدة.

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

معايير اختيار الشركة نفسها نفصّلها في 7 معايير تُحسم قبل توقيع العقد وفي الدليل الشامل عن اختيار أفضل شركة برمجة في مصر. وإن كان مشروعك في السعودية فراجع دليل اختيار شركة برمجة في السعودية؛ العمل عن بُعد مع فريق في القاهرة ممكن تماماً بشرط وضوح التواصل والعروض الدورية.

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

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

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

نستلم مشاريع المواقع والأنظمة عبر خدمة تطوير المواقع والأنظمة، وتطبيقات الجوال عبر برمجة تطبيقات الموبايل، لعملاء في مصر والسعودية.