لماذا تفشل بعض المشاريع التقنية قبل الإطلاق؟
ما قبل الإطلاق المشروع التقني نادرًا ما ينهار دفعة واحدة. يتعثّر تدريجيًا بسبب قرارات صغيرة أُجِّلت في الأسابيع الأولى، ثم ظهرت تكلفتها بعد أشهر على شكل تأخير أو نطاق يتمدد أو منتج لا أحد يريد استخدامه. هذا الدليل يفكّك سبعة…
ما قبل الإطلاق
المشروع التقني نادرًا ما ينهار دفعة واحدة. يتعثّر تدريجيًا بسبب قرارات صغيرة أُجِّلت في الأسابيع الأولى، ثم ظهرت تكلفتها بعد أشهر على شكل تأخير أو نطاق يتمدد أو منتج لا أحد يريد استخدامه. هذا الدليل يفكّك سبعة أنماط تسبق التعثر، ويوزّع المسؤولية بإنصاف بين صاحب المشروع وشركة التطوير.
ماذا ستخرج به
- سبعة أنماط تسبق التعثر، وأي طرف مسؤول عن كل منها.
- العلامة المبكرة التي تكشف كل نمط قبل أن يصبح مكلفًا.
- ما الذي يجب أن تحسمه مرحلة الاستكشاف بالضبط.
- لماذا لا يبدأ هذا الدليل بنسبة فشل، ولماذا يجب أن تشك في من يفعل.
لماذا لا يبدأ هذا الدليل برقم؟
ستجد في مقالات كثيرة جملة من نوع «نسبة كذا من المشاريع التقنية تفشل». تجاهلها ما لم تكن مصحوبة بتعريف الفشل ونوع المشاريع المدروسة.
السبب أن الدراسات المنشورة تقيس أشياء مختلفة تحت الاسم نفسه. بعضها يَعُدّ المشروع فاشلًا لمجرد تجاوزه الميزانية أو الجدول وإن أُطلق وعمل بنجاح. وبعضها يقصر الفشل على الإلغاء الكامل قبل التسليم. وبعضها لا يدرس مشاريع البرمجيات أصلًا، بل برامج التحول الرقمي على مستوى المؤسسة — وهي فئة أوسع بكثير ونتائجها لا تنطبق على تطبيق أو منصة واحدة.
فحين يُنقل رقم من فئة إلى أخرى، يتحول من نتيجة بحثية إلى عنوان مثير بلا معنى. والأسوأ أنه لا يساعدك في شيء: معرفة أن نسبة ما تفشل لا تخبرك أين يقف مشروعك أنت.
سبعة أنماط تسبق التعثر
الأنماط التالية مبنية على ممارسة هندسية شائعة في إدارة المشاريع البرمجية، لا على دراسة إحصائية. اعتبرها إشارات تستحق الفحص، لا قواعد تشخيص قاطعة. وقد وُزِّعت عمدًا بين الطرفين، لأن نسبة كبيرة من أدلة «لماذا تفشل المشاريع» تحمّل العميل وحده المسؤولية — وهذا وصف ناقص.
البدء بالتطوير قبل تثبيت المتطلبات
الحماس المشترك بين صاحب الفكرة والفريق يدفع الجميع نحو رؤية «شيء يعمل» بسرعة. فيبدأ الكود قبل أن يُحسم من هو المستخدم، وما المشكلة التي يحلها المنتج، وما الذي يجعله خيارًا أفضل من البديل القائم.
المشكلة ليست في السرعة بل في أن كل قرار معماري يُبنى على افتراض غير مثبت. وتصحيح الافتراض بعد شهرين يعني إعادة كتابة، لا تعديلًا. ويوضح المعيار الدولي ISO/IEC/IEEE 29148 لهندسة المتطلبات أن المتطلب الجيد يجب أن يكون غير غامض ومفردًا وقابلًا للتحقق، وأن مجموعة المتطلبات لا تُعدّ مكتملة ما دامت تحتوي على بنود مؤجلة من نوع «يُحدَّد لاحقًا».[1]
العلامة المبكرة: لا توجد وثيقة يمكن لثلاثة أشخاص قراءتها والخروج بالوصف نفسه للمنتج.غياب صلاحية الحسم
من يوافق على التصميم النهائي؟ ومن يحسم الخلاف بين المطوّر والمصمم؟ ومن يملك حق إلغاء ميزة من الإصدار الأول؟ في كثير من المشاريع لا توجد إجابة مكتوبة، فتُدار القرارات بالتوافق، والتوافق بطيء بطبيعته.
الأثر لا يظهر كخلاف صريح، بل كتأخير هادئ: مهمة تنتظر رأيًا، ورأي ينتظر اجتماعًا، واجتماع يُؤجَّل. وحين يتراكم ذلك عبر أسابيع يصبح الجدول الزمني غير قابل للإنقاذ دون قص النطاق.
العلامة المبكرة: قرار واحد بقي معلّقًا أكثر من أسبوع دون أن يعرف أحد من يملك حسمه.نطاق يحمل اسم MVP وحجم منتج كامل
الجميع يقول «سنبني MVP»، ثم تأتي القائمة بأربعين ميزة. هذا ليس منتجًا أوليًا، بل منتج كامل بجدول زمني متفائل.
المنتج الأولي الحقيقي هو أصغر نسخة تسمح بالتعلم من السوق بدل الافتراض. وتضخيم الإصدار الأول يضاعف مدة التطوير ويؤخر أول تغذية راجعة حقيقية — وهي التغذية التي كان يمكن أن توفّر بناء نصف المزايا. المسؤولية هنا مشتركة: العميل يطلب، والمورّد يوافق دون أن يشرح الأثر.
العلامة المبكرة: لا أحد يستطيع تسمية ميزة واحدة سيتم حذفها من الإصدار الأول.مورّد يقبل نطاقًا غامضًا دون أسئلة
هذا نمط يقع على جانب شركة التطوير، ونادرًا ما يُذكر في الأدلة التي تكتبها شركات التطوير نفسها. المورّد الذي يستلم وصفًا عامًا ويرسل عرضًا خلال ساعة دون سؤال واحد لم يقدّر مشروعك، بل قدّر افتراضاته عنه.
ويوضح «الدليل الاسترشادي لإعداد كراسات الشروط والمواصفات الخاصة بالمشاريع الرقمية»، الصادر عن هيئة الحكومة الرقمية بالتعاون مع هيئة كفاءة الإنفاق والمشروعات الحكومية، أن اختلاف فهم المواصفات الفنية بين المورّدين قد يؤدي إلى اختلاف في الأسعار والمخرجات.[2] الدليل موجّه إلى الجهات الحكومية، لكن الآلية نفسها تعمل في أي تعاقد.
العلامة المبكرة: عرض سعر وصلك دون أن يسألك أحد عن حالات الفشل أو الأدوار أو حجم البيانات.انحراف لا يظهر إلا عند التسليم
تقرير أسبوعي يقول «كل شيء يسير جيدًا» ليس تواصلًا، بل غياب تواصل بصيغة مطمئنة. والمشاريع لا تنحرف فجأة؛ تنحرف بمقدار صغير كل أسبوع حتى يصبح الفارق كبيرًا.
ما يكشف الانحراف مبكرًا ليس تكرار الاجتماعات، بل نوع المخرَج: نسخة قابلة للتجربة، ولو ناقصة، تُظهر ما بُني فعلًا. أما وصف التقدم بالنسب المئوية فيسمح بتأجيل الحقيقة إلى آخر لحظة. المسؤولية هنا على المورّد بالدرجة الأولى، وعلى العميل الذي يقبل تقارير بلا دليل ملموس.
العلامة المبكرة: مرّ شهر دون أن ترى نسخة تعمل، ولو جزئيًا.تأجيل قرارات البيانات والصلاحيات
من يرى ماذا؟ وما البيانات التي تُجمع، وأين تُخزَّن، وكم مدة الاحتفاظ بها؟ تبدو هذه أسئلة يمكن تأجيلها إلى مرحلة لاحقة، وهي ليست كذلك.
قرارات الصلاحيات ونمذجة البيانات تُبنى في المعمارية نفسها. وإضافة دور جديد أو تغيير سياسة احتفاظ بعد اكتمال البناء ليست إعدادًا يُضبط، بل تعديل في بنية النظام يمس شاشات ومنطقًا واختبارات. وكلما تأخر القرار ارتفعت كلفته بشكل غير خطي.
العلامة المبكرة: جملة «سنحدد الصلاحيات لاحقًا» موجودة في مستند المشروع.اختبار يبدأ في الأسبوع الأخير
الاختبار السريع قبل الإطلاق بيوم ليس اختبارًا. وهو نمط يقع غالبًا على المورّد، لأنه الطرف الذي يعرف متى يجب أن يبدأ الاختبار ومع ذلك يؤجّله لصالح إضافة مزايا.
الاختبار المتأخر لا يفشل في إيجاد الأخطاء، بل يجدها في أسوأ وقت: حين لا يبقى وقت لإصلاحها دون تأجيل الإطلاق أو حذف مزايا. والفرق بين اكتشاف خلل في الأسبوع الثالث واكتشافه في الأخير هو الفرق بين تعديل وإعادة تصميم.
العلامة المبكرة: لا توجد معايير قبول مكتوبة للرحلات الحرجة، ولا جدول اختبار قبل موعد التسليم.القاسم المشترك بين الأنماط السبعة
لو نظرت إليها مجتمعة، ستجد أنها كلها صورة واحدة: قرار كان يمكن حسمه مبكرًا بتكلفة منخفضة، فتُرك مفتوحًا حتى صار حسمه مكلفًا.
ولهذا فإن ترتيب الأنماط حسب «الأخطر» ليس مفيدًا. النمط الخطير في مشروعك هو الموجود فيه الآن، والذي لا أحد ينظر إليه لأن الفريق منشغل بالتنفيذ.
القرار يُكتب في وثيقة، ويُراجع، ويُعدَّل.
أقل كلفةالقرار يمسّ كودًا مكتوبًا واختبارات قائمة.
كلفة متوسطةالقرار يمسّ بيانات حقيقية ومستخدمين يعملون.
أعلى كلفةماذا يجب أن تحسمه مرحلة الاستكشاف؟
قبل التفصيل، إفصاح يستحق الذكر: نحن شركة تطوير، ومرحلة الاستكشاف خدمة تُشترى. فاقرأ هذا القسم بهذا الاعتبار. ولهذا كُتب بحيث يمكنك تنفيذ أغلبه بنفسك أو مع أي فريق آخر — فالقيمة في حسم القرارات، لا في من يديرها.
- وصف مكتوب للمستخدم وللمشكلة كما تُدار اليوم، لا كما نتمنى أن تكون.
- قائمة بما سيُنفَّذ في الإصدار الأول، وقائمة صريحة بما لن يُنفَّذ.
- جدول يحدد مالك القرار لكل نوع من القرارات، ومدة أقصاها للحسم.
- الأدوار والصلاحيات لكل نوع مستخدم.
- معايير قبول مكتوبة للرحلات الحرجة.
- مؤشر واحد أو اثنان يُقاس بهما النجاح بعد الإطلاق، من بيانات تملكها فعلًا.
لاحظ أن هذه المخرجات كلها نصوص وقرارات، لا تصاميم ولا كود. وهي تُنجَز في وقت قصير مقارنة بعمر المشروع، لكنها تحدد ما إذا كان باقي المشروع سيُبنى على أرض ثابتة.
فحص سريع: هل مشروعك يتجه إلى التعثر؟
ست علامات، كل واحدة منها مأخوذة من نمط أعلاه. وجود علامة أو اثنتين أمر طبيعي في أي مشروع نشط. ثلاث فأكثر تعني أن التعثر بدأ بالفعل وإن لم يظهر في الجدول بعد:
- لا توجد وثيقة يخرج منها ثلاثة قرّاء بالفهم نفسه.
- قرار معلّق منذ أكثر من أسبوع ولا أحد يعرف من يحسمه.
- لا يمكن تسمية ميزة واحدة قابلة للحذف من الإصدار الأول.
- مرّ شهر دون رؤية نسخة تعمل ولو جزئيًا.
- الصلاحيات ما زالت «تُحدَّد لاحقًا» بعد بدء البناء.
- لا توجد معايير قبول مكتوبة قبل أسبوعين من التسليم.
وإذا كان المشروع متعثرًا بالفعل؟
الأنماط أعلاه وقائية. أما إذا كان المنتج قائمًا ومتعثرًا فعلًا، فالقرار مختلف تمامًا: تشخيص ما تعطّل أولًا، ثم اختيار أصغر تدخل يعالجه — وقد يكون إصلاحًا محددًا أو إعادة هيكلة جزئية، لا إعادة بناء من الصفر بالضرورة.
وأيًّا كان القرار، فالخطوة الأولى واحدة: توقف عن إضافة مزايا جديدة إلى نظام لم تُشخَّص مشكلته بعد.
أسئلة متكررة
هل يعني ظهور أحد هذه الأنماط أن المشروع سيفشل؟
لا. هذه أنماط تستحق الفحص، لا نبوءات. أغلب المشاريع النشطة تحمل واحدًا منها في أي لحظة، والفرق بين مشروع سليم وآخر متعثر هو سرعة ملاحظة النمط ومعالجته، لا خلوّه منه.
ألا تُحمّل هذه الأدلة عادةً العميل وحده المسؤولية؟
غالبًا نعم، وهذا نقص حقيقي فيها. ثلاثة من الأنماط السبعة هنا تقع على شركة التطوير: قبول نطاق غامض دون أسئلة، وإخفاء الانحراف حتى التسليم، وتأجيل الاختبار. وهي أنماط يعرفها المورّد أكثر من العميل، ولذلك تقع مسؤوليتها عليه.
هل مرحلة الاستكشاف مجرد طريقة لبيع خدمة إضافية؟
قد تكون كذلك عند بعض المورّدين، والاختبار العملي بسيط: اطلب أن تكون مخرجات المرحلة مستندات تملكها أنت وتستطيع أخذها إلى أي فريق آخر. إن كانت المخرجات ملموسة وقابلة للنقل فهي عمل حقيقي. وإن كانت اجتماعات تنتهي بعرض تقديمي عام، فهي مقدمة بيع.
ما الفرق بين هذا وبين إدارة المشاريع التقليدية؟
إدارة المشاريع تتابع التنفيذ مقابل خطة. ما يناقشه هذا الدليل يسبق ذلك: هل الخطة نفسها مبنية على قرارات محسومة؟ يمكن أن تُدار خطة معيبة إدارة ممتازة وتصل في موعدها إلى منتج لا يحل المشكلة.
الخلاصة
المشاريع التقنية لا تفشل لأن الكود سيئ، بل لأن أسئلة رخيصة لم تُطرح في وقتها. وكل نمط من السبعة يمكن كشفه بسؤال واحد يُطرح في اجتماع، لا بأداة ولا بمنهجية.
راجع الفحص السريع أعلاه على مشروعك الحالي. إن ظهرت علامة واحدة فأنت في وضع طبيعي، وإن ظهرت ثلاث فالمشكلة قائمة الآن وليست احتمالًا مستقبليًا.
عندك مشروع في مرحلة التخطيط أو مشروع بدأ يتعثر؟
حسم المتطلبات ونطاق العمل قبل التنفيذ يكشف القرارات المؤجلة وهي ما زالت رخيصة. تبدأ المشاريع في SpinesTech بجلسة استكشاف مخرجاتها مستندات تملكها أنت: نطاق مكتوب، وأدوار محددة، ومعايير قبول.
المصادر
- ISO — ISO/IEC/IEEE 29148: Systems and software engineering — Requirements engineering.
- هيئة الحكومة الرقمية وهيئة كفاءة الإنفاق والمشروعات الحكومية — الدليل الاسترشادي لإعداد كراسات الشروط والمواصفات الخاصة بالمشاريع الرقمية، المملكة العربية السعودية.
الأنماط والعلامات المذكورة في هذا الدليل ممارسة هندسية شائعة وليست نتائج دراسة إحصائية، وقد وُضِّح ذلك في موضعه. المصدران أعلاه يدعمان الادعاءات المنسوبة إليهما تحديدًا.
