تفشل المشاريع البرمجية لأسباب كانت ظاهرة منذ اليوم الأول، ونادراً جداً للسبب المكتوب في التحليل اللاحق. يسمّي هذا المقال الأسباب الستة التي نراها تتكرر في كل قطاع وكل حجم ميزانية، ويبيّن لماذا تُحدث الأسباب الأبكر الضرر الأكبر، ويعطيك بوابة من ثلاثة أسئلة تمرّ بها قبل أن توقّع أي شيء.
يلقي التحليل اللاحق باللوم دائماً على الأمر الظاهر: موعد فائت، أو مشكلة تقنية، أو مورّد صعب. هذه أعراض. أما الأسباب فكانت قابعة في عرض الانطلاق، أمام أعين الجميع.
الاحتمالات بصدق
ابدأ بالمعدّل العام، لأنه يحدّد مدى جدّية ما يليه. تجد أبحاث CHAOS الطويلة الأمد من The Standish Group أن نحو 31% من المشاريع تنجح، ونحو 50% «متعثرة» (متأخرة أو متجاوزة للميزانية أو بنطاق منقوص)، ونحو 19% تفشل صراحةً، وأن المشاريع الصغيرة تنجح بمعدّل أعلى بكثير من الكبيرة (Standish Group via InfoQ, 2015).
وكلما كبر المشروع ساء الأمر. درست McKinsey مع جامعة Oxford أكثر من 5,400 مشروع تقني ووجدت أن المشاريع التقنية الكبيرة (بميزانية أولية تتجاوز 15 مليون دولار) تتجاوز الميزانية بنسبة 45% في المتوسط، وتتأخر عن الجدول بنسبة 7%، وتقدّم قيمة أقل بنسبة 56% مما كان متوقعاً، وأن 17% منها يسوء إلى حدّ يهدّد وجود الشركة نفسها (McKinsey, 2012).
تأمّل شكل نتيجة McKinsey هذه. تأخير 7% فقط في المتوسط، مقابل تجاوز 45% في الميزانية و56% نقصاً في القيمة. المشاريع تُسلَّم غالباً قريباً من موعدها. لكنها تُسلَّم أصغر وأغلى. وهذه بصمة نطاق لم يفهمه أحد في البداية، لا بصمة مهندسين بطيئين.
ستة أسباب، وأين يقع كلٌّ منها
وضعنا الأسباب الستة المعتادة في رسم بياني واحد، مرتّبةً بحسب قدر الضرر الذي تحدثه في خبرتنا (ترتيب نوعي لا مقيس) ومقسّمة إلى مجموعتين. الكبيرة تقع قبل البناء: هدف خاطئ، ومتطلبات لم يفهمها أحد، ولا مالك للنتيجة. والأصغر تقع أثناء البناء: التكامل والبيانات يعضّان أشد مما خُطّط له، والمشكلات تُخفى، والخطة لا تنثني حين يحضر الواقع.
قبل سطر من الشيفرة
- حللت المشكلة الخطأ، بإتقان. أكثر الإخفاقات كلفةً ليست رديئة البناء. إنها الشيء الخطأ مبنياً بإتقان، ويرجع ذلك إلى فكرة ضبابية غير مُختبَرة عن الغاية من المشروع. المورّد يبني بالضبط ما حدّدته. أما كون ذلك ما احتجته فهو على عاتق المواصفات، لا على عاتقه. والنسخة الحكومية من هذا هي منافسة على منصة اعتماد كُتبت حول نظام رآه أحدهم في مؤتمر، فجُمّد النطاق قبل أن يسأل أحد عمّا تعانيه الإدارة فعلاً.
- لم تُفهم المتطلبات فهماً حقيقياً قط. ابدأ على متطلبات غامضة أو مفترضة فينجرف المشروع ويتضخّم ويخطئ الهدف. والوصول إلى ما يحتاجه الناس، لا ما يقولونه أولاً، يعني الجلوس مع الموظف الذي سيستخدم الشاشة، لا مع المدير الذي يرعى المشروع فحسب. تخطَّ ذلك وتكون قد اشتريت كومة من إعادة العمل.
- لم يملك أحد النتيجة. قسّم المسؤولية بين جهة عمل «تملك المتطلبات» ومورّد «يملك التسليم»، فتكون الفجوة بينهما هي بالضبط حيث تموت المشاريع. لا بد أن يملك أحدهم النتيجة طوال الطريق: شخص واحد مسمّى يملك صلاحية قول «لا».
أثناء البناء
- أُسيء تقدير التكامل والبيانات. افترضت الخطة بيانات نظيفة وأنظمة قائمة ودودة. أما الواقع فلم يسلّم أياً منهما. هذا أكثر أجزاء التسليم المؤسسي نقصاً في الميزانية، وله في السعودية طبقة تنظيمية: بيانات شخصية يقيّدها نظام حماية البيانات الشخصية (PDPL) ولوائح النقل الصادرة عن سدايا (SDAIA)، وضوابط الأمن السيبراني الأساسية (ECC) من الهيئة الوطنية للأمن السيبراني (NCA) التي سيصرّ فريق الأمن عليها قبل الإطلاق. كلاهما رخيص إن صُمّم من البداية، وباهظ إن اكتُشف في الشهر التاسع.
- أُخفيت المشكلات، لا أُظهرت. في مشروع متعثر، تسير الأخبار السيئة ببطء. تبقى الحالة خضراء حتى لا تعود قادرة على ذلك، وحين تظهر الحقيقة تكون النافذة الرخيصة لإصلاحها قد أُغلقت. والآلية المعتادة تقرير حالة يعدّ الميزات المبنية بدل مسارات العمل التي تعمل من طرف إلى طرف.
- لم تستوعب الخطة التغيير. المتطلبات تتغير دائماً. والخطة والبنية الصلبتان إلى حدّ الانكسار تحت ذلك التغيير كانتا ستفشلان لحظة حضور الواقع. وقرارات البنية التي تكلّف الملايين لاحقاً هي عادةً القرارات التي جعلت التغيير باهظاً.
البوابة: ثلاثة أسئلة قبل التوقيع
ما دام معظم الضرر يقع قبل البناء، فالحل بوابة قبل العقد. ثلاثة أسئلة بالترتيب. أي «لا» على أيٍّ منها تعني أنك لست جاهزاً للتوقيع، مهما بدا العرض جيداً.
flowchart TD
A(["قبل أن توقّع"]) --> B{"هل تستطيع صياغة المشكلة في جملة واحدة يعرفها العميل أو الموظف؟"}
B -->|لا| X(["توقّف. أنت على وشك بناء الشيء الخطأ بإتقان."])
B -->|نعم| C{"هل جلس أحد مع من سيستخدمونه كل يوم؟"}
C -->|لا| X
C -->|نعم| D{"هل هناك شخص واحد مسمّى مسؤول عن النتيجة ويملك صلاحية قول لا؟"}
D -->|لا| X
D -->|نعم| E(["امضِ، مع اختبار تكامل في الشهر الأول"])
اختبار التكامل هو الحماية أثناء البناء. قبل بناء أي ميزة، يأخذ الفريق تصديراً حقيقياً من كل نظام سيتخاطب معه النظام الجديد ويثبت أن البيانات يمكن نقلها ومطابقتها. يكلّف ذلك بضعة أسابيع، ويكشف معرّفات العملاء المكرّرة، والحقول النصية الحرة التي كان ينبغي أن تكون رموزاً، وقيود توطين البيانات، بينما إصلاحها ما زال رخيصاً.
مثال محسوب بأرقام افتراضية
لنفترض أن شركة توزيع تكلّف مورّداً باستبدال نظام إدارة الطلبات بميزانية 3 ملايين ريال وخطة مدتها 12 شهراً. الأرقام افتراضية لتوضيح الشكل.
تمضي الأشهر من الأول إلى الرابع على ما يرام: تُبنى الميزات من المواصفات، ويُظهر التقرير الأسبوعي إنجاز 40%. في الشهر الخامس يسحب الفريق أول ملف عملاء حقيقي من النظام القديم (ERP) فيجد معرّفات مكرّرة وعناوين مكتوبة في حقل الملاحظات. تتحوّل الـ300 ساعة المرصودة للتكامل إلى 1,400 ساعة. تبقى الحالة خضراء لأنها تعدّ الميزات، وقد أُنجز الآن 70% منها. في الشهر العاشر يُجرى أول اختبار من طرف إلى طرف، فتفشل الطلبات في المطابقة مع العملاء، وتظهر الحقيقة. يتأخر الإطلاق ستة أشهر وتستقر التكلفة النهائية قرب 4.4 ملايين ريال، لنظام يفعل أقل مما وُعد به لأن النطاق قُلّص كي يُسلَّم أصلاً.
أمرِر المشروع نفسه عبر البوابة الآن. يكتشف اختبار التكامل في الشهر الأول المعرّفات المكرّرة نفسها حين تكلّف ثلاثة أسابيع من تنظيف البيانات، لا ثمانية أشهر من إعادة العمل. ويعدّ تقرير الحالة مسارات العمل التي تعمل من طرف إلى طرف، فلا يتفاجأ أحد في الشهر العاشر. قد يتأخر المشروع شهراً. لكنه لن يتجاوز الميزانية بما يقارب 50% بنصف القيمة.
أين يخطئ الإنقاذ
حين يكون المشروع متعثراً أصلاً، فإن الإصلاحات الغريزية تزيده سوءاً في الغالب.
- إضافة أشخاص إلى مشروع متأخر. يحتاج الجدد إلى تأهيل من الأشخاص المتأخرين أصلاً. فيكبر التأخير قبل أن ينكمش.
- تبديل المورّد. إن كانت المواصفات هي المشكلة، فالمورّد الجديد يرثها ويعيد العدّاد إلى الصفر. بدّل المورّد فقط حين يكون هو السبب فعلاً، وأعد تمرير البوابة أولاً.
- تشديد العقد بدل توضيح المتطلبات. بنود الغرامات لا تجعل النطاق الغامض واضحاً. إنها تجعل المورّد دفاعياً، والمورّد الدفاعي يخفي المشكلات مدة أطول.
- لوم التقنية وطلب إعادة البناء من الصفر. إعادة البناء تحمل كل سبب في القائمة مرة ثانية، مع تكلفة غارقة فوق ذلك.
- الإبقاء على تقرير الحالة نفسه. إن كانت «نسبة الميزات المبنية» هي ما أوصلتك إلى هنا، فلن تخرجك منه.
الإنقاذ الصادق ممل: جمّد النطاق، وشغّل اختباراً حقيقياً من طرف إلى طرف على بيانات حقيقية، وقرّر بناءً على ذلك الدليل إن كنت ستكمل أو تقلّص أو تتوقف.
كيف تبدأ مشروعاً لا يفشل
النمط الناجح ممل وموثوق: إيقاع «اختر، قِس، جرّب، توسّع» نفسه الذي نوصي به في أي مبادرة تقنية نراجعها.
- اختر مشكلة واحدة. اكتبها في جملة واحدة على صفحة واحدة، مسمّياً العملية التي تستبدلها. وإن كانت منافسة، فمكان تلك الجملة أعلى كراسة الشروط، وهذا جُلّ ما تدور حوله كتابة كراسة شروط تقنية تأتيك بالمورّد المناسب.
- قِس الوضع اليوم. كم تستغرق العملية، وكم مرة شهرياً، وما معدّل الخطأ. يصبح النجاح رقماً، لا شعوراً.
- جرّب قبل أن تلتزم. أجرِ استكشافاً مدته أسبوعان إلى أربعة مع المستخدمين اليوميين، مع اختبار التكامل على مقتطفات بيانات حقيقية. وقّع عقد البناء بعد ذلك، ودع نتائجه تحدّد النطاق.
- توسّع بمالك واحد وعروض أسبوعية من طرف إلى طرف. شخص واحد مسؤول، وعرض أسبوعي لمسار عمل حقيقي على بيانات حقيقية. وما عدا ذلك شريحة عرض.
وهذا هو الخبر السار. المشاريع التي تبدأ بمشكلة محددة بدقة، ومتطلبات تعمّق فيها أحد فعلاً، ومالك واحد، ونظرة صادقة إلى مخاطر التكامل، تنجح في معظمها. أنماط الفشل قابلة للمعرفة، ولذلك قابلة للتجنّب.
مشروع ينجرف نحو المتاعب، أو تخطط لمشروع لا تستطيع تحمّل إخفاقه؟ تراجع SDCG المشاريع المتعثرة بصدق وتنزع المخاطر عن الجديدة قبل أن تبدأ، ضمن أعمال التقييم التقني ومراجعة المشاريع. نحن نملك النتائج من البداية إلى النهاية، فلا بد أن تصمد نصيحتنا في العالم الحقيقي، لا على شريحة عرض فحسب. احجز استشارة مجانية مدتها 30 دقيقة.