حين يفشل مشروع برمجي، يلقي التحليل اللاحق باللوم على الأمر الظاهر. موعد نهائي فائت. مشكلة تقنية. مورّد صعب. لكن هذه أعراض، لا أسباب. أما الأسباب الحقيقية فكانت قابعة هناك من البداية تماماً، أمام أعين كل من يعرف أين ينظر. وتظل الحفنة نفسها تتكرر، عبر كل قطاع وكل حجم ميزانية.
والأرقام ليست جميلة أيضاً. فأبحاث CHAOS الطويلة الأمد من The Standish Group تجد أن نحو الثلث فقط من المشاريع البرمجية ينجح تماماً، بينما يصل نحو النصف متأخراً أو متجاوزاً للميزانية أو بنطاق منقوص، أما الباقي فيفشل صراحةً (Standish, via InfoQ). وكلما كبر المشروع ساءت الاحتمالات. فقد درست McKinsey، بالتعاون مع Oxford، أكثر من 5,400 مشروع تقني كبير، ووجدت أنها تتجاوز الميزانية بنسبة 45%، وتقدّم قيمة أقل بنسبة 56% مما وُعد به، وأن 17% منها يسوء إلى حدّ يهدّد الشركة نفسها (McKinsey).
وها هو الجزء الذي يفاجئ الناس. معظم الأمر يُحسم قبل أن يكتب أحد سطراً واحداً من الشيفرة.
وضعت الأسباب الستة المعتادة في رسم بياني واحد، مرتبةً بحسب قدر الضرر الذي تحدثه، ومقسّمةً إلى مجموعتين. الكبيرة في الأعلى تحدث قبل البناء: صوّبت نحو الهدف الخطأ، ولم تفهم المتطلبات فهماً حقيقياً قط، ولم يملك أحد النتيجة. أما الأصغر في الأسفل فتحدث أثناء البناء: التكامل والبيانات يعضّان أشد مما خُطّط له، وتُخفى المشكلات بدل إظهارها، والخطة لا تنثني حين يحضر الواقع. لاحظ الشكل. الأسباب الأبكر هي الأكبر.
قبل سطر من الشيفرة: حيث يكون معظم الضرر قد وقع بالفعل.
1. حللت المشكلة الخطأ، بإتقان. أكثر الإخفاقات كلفةً ليست رديئة البناء. إنها الشيء الخطأ مبنياً بإتقان. ويرجع ذلك إلى فكرة ضبابية غير مُختبَرة عن الغاية من المشروع أصلاً. سيبني المورّد بالضبط ما حددته. أما كون ذلك ما احتجته فهو على عاتق المواصفات، لا على عاتقه.
2. لم تُفهم المتطلبات فهماً حقيقياً قط. ابدأ مشروعاً على متطلبات غامضة أو مفترضة، فينجرف، ويتضخّم، ويخطئ الهدف. والوصول إلى ما يحتاجه الناس فعلاً، لا مجرد ما يقولونه أولاً، مهارة حقيقية. تخطّها وتكون قد ضمنت لنفسك كومة من إعادة العمل.
3. لم يملك أحد النتيجة. قسّم المسؤولية بين جهة عمل «تملك المتطلبات» ومورّد «يملك التسليم»، فتكون الفجوة بينهما هي بالضبط حيث تموت المشاريع. لا بد أن يملك أحدهم النتيجة، طوال الطريق.
أثناء البناء: حيث يختلّ باقي الأمر.
4. أُسيء تقدير التكامل والبيانات. افترضت الخطة بيانات نظيفة وأنظمة قائمة ودودة. أما الواقع فلم يسلّم أياً منهما، ولم يتعافَ الجدول الزمني قط. وهذا أكثر أجزاء التسليم المؤسسي نقصاً في الميزانية، في كل مرة.
5. أُخفيت المشكلات، لا أُظهرت. في مشروع متعثر، تسير الأخبار السيئة ببطء. تبقى الحالة خضراء حتى لا تعود قادرة على ذلك، وحين تظهر الحقيقة تكون النافذة الرخيصة لإصلاحها قد أُغلقت أصلاً.
6. لم تستوعب الخطة التغيير. المتطلبات تتغير دائماً. والخطة والبنية الصلبتان إلى حدّ الانكسار تحت ذلك التغيير كانتا ستفشلان لحظة حضور الواقع. وهو يحضر دائماً.
انظر إلى الرسم البياني مجدداً وسيكون النمط عسير الإغفال. معظم الفشل يُحسم باكراً، في كيفية تأطير المشكلة، وكيفية فهم المتطلبات، ومن يملك النتيجة حقاً، قبل وجود أي شيفرة بوقت طويل. ونادراً ما يكون التنفيذ التقني هو السبب الجذري.
وهذا في الواقع خبر سار. فالمشاريع التي تبدأ بمشكلة محددة بدقة، ومتطلبات تعمّقت فيها فعلاً، وملكية واضحة، ونظرة صادقة إلى مخاطر التكامل، تنجح في معظمها. أنماط الفشل قابلة للمعرفة، ولذلك فهي قابلة للتجنّب.
مشروع ينجرف نحو المتاعب، أو تخطط لمشروع لا تستطيع تحمّل إخفاقه؟ تراجع SDCG المشاريع المتعثرة بصدق وتساعد على نزع المخاطر عن الجديدة قبل أن تبدأ. نحن نملك النتائج من البداية إلى النهاية، فلا بد أن تصمد نصيحتنا في العالم الحقيقي، لا على شريحة عرض فحسب. احجز استشارة مجانية مدتها 30 دقيقة.
المصادر
- The Standish Group CHAOS research (InfoQ summary)
- McKinsey & University of Oxford: Delivering large-scale IT projects on time, on budget, and on value