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

الأسباب الشائعة للتعثر

١. نطاق غير واضح وملكية غير محددة

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

٢. غياب مدير مشروع واحد مسؤول

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

٣. ارتهان للمورّد دون توثيق

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

٤. لا بيئة تجريبية ولا تسليم منتظم

حين لا توجد بيئة تجريبية (staging) مطابقة للإنتاج، ولا آلية نشر مؤتمتة، يصبح كل إصدار عملية يدوية محفوفة بالمخاطر، فتتباعد الإصدارات، ويتراكم العمل غير المُسلَّم، ولا يرى المستفيدون شيئاً يعمل إلا في النهاية — حين يكون التصحيح مكلفاً.

٥. تقارير تُخفي المخاطر

تقرير الحالة الذي يقول «نسبة الإنجاز ٨٠٪» لا يقول شيئاً عن الـ٢٠٪ المتبقية، التي غالباً تكون الأصعب. وحين يُكافأ الفريق على الأخبار الجيدة ويُلام على السيئة، تتعلم التقارير أن تكون متفائلة، ويصل الخبر الحقيقي متأخراً.

علامات الإنذار المبكر

إن ظهرت ثلاث علامات أو أكثر من القائمة التالية، فالمشروع يحتاج مراجعة جادة الآن لا في الاجتماع الفصلي القادم:

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

تسلسل الإنقاذ

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

١. التجميد والتقييم

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

٢. إعادة تحديد خط الأساس

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

٣. إعادة الأصول إلى سيطرة المنشأة

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

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

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

٤. دورات تسليم قصيرة

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

٥. تقارير صادقة لمتخذي القرار

تقرير الحالة الموجّه للإدارة يجب أن يجيب عن أسئلة قليلة بوضوح:

السؤال ما يجب أن يظهر في التقرير
ما الذي سُلِّم فعلاً؟ ما يعمل ويمكن تجربته، لا نسبة إنجاز تقديرية
ما المخاطر الحالية؟ أهم المخاطر، واحتمالها، وأثرها، ومن يعالجها
ما القرارات المطلوبة؟ ما يحتاج قراراً من الإدارة، ومتى يصبح التأخير فيه مكلفاً
هل تغيّر الموعد أو الميزانية؟ التغيير وسببه بصراحة، فور معرفته لا في نهاية المرحلة

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

دور الإدارة في الإنقاذ

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

متى يكون الاستمرار أسوأ من التوقف؟

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

الخلاصة

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