لماذا تفشل مشاريع البرمجيات المخصصة: أنماط من تطوير المؤسسات

الحقيقة غير المريحة حول مشاريع البرمجيات

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

هذه المقالة ليست عن منهجيات التطوير أو هياكل الفريق. إنها عن الأنماط الأعمق التي تجعل المشاريع غير قابلة للصيانة أو غير قابلة للاستخدام أو مهجورة خلال 2-3 سنوات من الإطلاق.

نمط الفشل 1: المتطلبات لم تكن متطلبات حقاً

أكثر حالات الفشل شيوعاً التي رأيتها ليست تقنية—إنها تعريفية.

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

لماذا يحدث:

• "المتطلبات" كانت في الواقع تطلعات، وليست سير عمل موثقة
• لم يلاحظ أحد كيف يتم العمل فعلياً اليوم
• لم تُلتقط الحالات الحدية والاستثناءات
• أصحاب المصلحة المختلفون كانت لديهم افتراضات متعارضة لم تُوفق أبداً

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

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

نمط الفشل 2: قرارات تقنية اتُخذت للأسباب الخاطئة

ما يحدث: تُتخذ قرارات البنية بناءً على الاتجاهات أو علاقات الموردين أو ما يريد المطورون تعلمه—وليس بناءً على احتياجات المشروع الفعلية.

لماذا يحدث:

• فريق التطوير يريد استخدام تقنيات جديدة
• مورد يقدم خصماً أو شراكة
• شخص ما قرأ مقالاً عن الخدمات المصغرة
• "Netflix/Google/Amazon تستخدم هذا"

مثال حقيقي: عيادة صغيرة بـ 50 مريضاً يومياً استأجرت فريقاً بنى بنية خدمات مصغرة قائمة على Kubernetes. النظام تطلب مهندس DevOps للصيانة. العيادة لم تستطع تحمل دعم DevOps المستمر. هُجر النظام لصالح جدول بيانات خلال 18 شهراً.

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

نمط الفشل 3: لا خطة لما بعد الإطلاق

ما يحدث: كل الطاقة تذهب للإطلاق. لا أحد يخطط للصيانة أو التحديثات أو التغييرات الحتمية.

لماذا يحدث:

• الميزانيات مخصصة لـ "المشروع" وليس "المنتج"
• يُقاس النجاح بتاريخ الإطلاق، وليس الاستخدام طويل المدى
• فريق التطوير ينتقل للمشروع التالي
• التوثيق لم يكن جزءاً من النطاق

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

النمط: البرمجيات لا تنتهي أبداً. المشاريع التي لا تخصص ميزانية للصيانة المستمرة تخطط للفشل. النسبة يجب أن تكون تقريباً: 30% تطوير أولي، 70% صيانة وتطوير مستمر.

نمط الفشل 4: وهم التكامل

ما يحدث: خطة المشروع تفترض تكاملاً سلساً مع الأنظمة الموجودة. الواقع مختلف.

لماذا يحدث:

• الأنظمة القديمة لها سلوكيات غير موثقة
• APIs لا تعمل كما هو موثق
• تنسيقات البيانات بها تناقضات لم يكن أحد يعرف عنها
• تعاون المورد افتُرض لكن لم يُؤكد أبداً

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

نمط الفشل 5: المعرفة خرجت من الباب

ما يحدث: مطورون رئيسيون يغادرون. المعرفة الحرجة لم تُوثق. المشروع يصبح غير قابل للصيانة.

لماذا يحدث:

• التوثيق أُجل لتلبية المواعيد النهائية
• المعرفة كانت موجودة فقط في رؤوس المطورين
• لا عملية مراجعة كود لنشر الفهم
• "عامل الحافلة" كان شخصاً واحداً

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

نمط الفشل 6: النجاح خلق الفشل

ما يحدث: البرنامج يعمل. الاستخدام ينمو. النظام لا يستطيع التعامل مع النجاح.

لماذا يحدث:

• الأداء لم يُختبر على نطاق واسع
• تصميم قاعدة البيانات افترض حجماً منخفضاً
• خدمات الطرف الثالث لها حدود غير معلنة
• تكاليف البنية التحتية لم تُتوقع

النمط: سيناريوهات النجاح تحتاج للتخطيط بعناية مثل سيناريوهات الفشل. "ماذا لو نجح هذا؟" بنفس أهمية "ماذا لو فشل هذا؟"

ما يمنع الفشل فعلاً

بناءً على المشاريع التي نجحت طويل المدى، هذا ما يميزها:

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

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

3. الصيانة كانت جزءاً من العقد ميزانية المشروع شملت صراحة 12-24 شهراً من دعم ما بعد الإطلاق. فريق التطوير ظل متاحاً. التحديثات كانت متوقعة، وليست استثنائية.

4. التوثيق تم تسليمه قرارات البنية وإجراءات النشر ومنطق الأعمال وُثقت. مطور جديد يمكنه فهم النظام من التوثيق وحده.

5. العميل امتلك الكود الكود المصدري ونصوص النشر وبيانات الاعتماد كانت ملكية العميل من اليوم الأول. لم يكن هناك قفل مورد. العميل يمكنه تبديل فرق التطوير دون خسارة نظامه.

أسئلة يجب طرحها قبل بدء مشروع

إذا كنت تفكر في مشروع برمجيات مخصص، هذه الأسئلة تتنبأ بالنجاح:

1. هل وثقت كيف يتم العمل اليوم؟ ليس التطلعات—سير العمل الفعلية الحالية.

2. ما ميزانية الصيانة؟ إذا كانت صفراً، المشروع سيفشل.

3. من سيدعم هذا بعد سنتين؟ إذا كان الجواب "سنكتشف"، المشروع سيفشل.

4. لماذا برمجيات مخصصة؟ إذا كان حل جاهز موجوداً، استخدمه. التطوير المخصص يجب أن يكون الملاذ الأخير، وليس الخيار الأول.

5. ماذا يحدث إذا اختفى فريق التطوير؟ إذا كان المشروع يعتمد على أشخاص محددين، فهو بالفعل في خطر.

متى تنسحب

أحياناً القرار الصحيح هو عدم بناء برمجيات مخصصة:

• المتطلبات لا يمكن تعريفها بوضوح
• الميزانية تفترض تكلفة مرة واحدة فقط
• الجدول الزمني يتطلب التسرع في قرارات البنية
• المنظمة ليس لديها قدرة تقنية لتقييم العمل
• برمجيات مماثلة موجودة بالفعل ويمكن تخصيصها

أنجح المشاريع التي عملت عليها بدأت مع عملاء كانوا متشككين حول بناء برمجيات مخصصة. طرحوا أسئلة صعبة. خططوا للصيانة. أعطوا الأولوية للاستدامة على الميزات.

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

قراءة ذات صلة

• توظيف مهندسي البرمجيات: كيف تبدو العناية الواجبة التقنية
• متى تكون البرمجيات المخصصة الخيار الخاطئ
• تصميم البرمجيات للصيانة طويلة المدى