لماذا تفشل مشاريع البرمجيات؟ الأسباب الحقيقية ليست تقنية

غموض النطاق

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

غياب المالك

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

القرارات المؤجلة

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

سوء التقدير

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

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

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

1. لا شيء يعرض عاملا بعد أسابيع — عروض شرائح بدل نظام.
2. نسبة الإنجاز عالقة عند تسعين بالمئة أسابيع متتالية.
3. قائمة الأعطال تنمو أسرع مما تغلق.
4. الاجتماعات تناقش الحالة لا القرارات.
5. أعضاء الفريق يعبرون عن قلق ثم يصمتون.

وهذه العلامات تظهر مبكرا دائما. والمشكلة أنها تفسر بالتفاؤل حتى يفوت وقت التصحيح الرخيص.

أسئلة شائعة

ما أفضل طريقة لاكتشاف الانحراف مبكرا؟

التسليم على مراحل قصيرة يعرض فيها نظام يعمل لا تقرير نسبة إنجاز. فالبرنامج العامل هو المقياس الوحيد الذي لا يقبل التأويل.

هل تغيير النطاق سبب فشل دائما؟

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

كيف ننقذ مشروعا متعثرا؟

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