معظم مشاريع البرمجيات تفشل — ونادراً ما يكون الكود هو السبب. لماذا النطاق هو ما يُغرقها.

ثمّة حكايةٌ مُريحةٌ يرويها أصحاب الأعمال لأنفسهم حين يتعثّر مشروع برمجي: المطوّرون لم يكونوا أكفاء بما يكفي. وظِّف فريقاً أفضل — هكذا يجري التفكير — وسينجح البناء التالي. لكنّ البيانات لا تدعم الحكاية. فعبر 50 ألف مشروعٍ درستها مجموعة ستانديش، نجح 31 بالمئة فقط — أي شُحنت في موعدها وضمن الميزانية وبالمزايا الموعودة. ونصفها كان «متعثّراً» (سُلّم لكن فوق الميزانية أو متأخّراً أو بمزايا محذوفة)، و19 بالمئة أُلغيت تماماً [1]. أي إنّ اثنين من كل ثلاثة مشاريع برمجية لا يُسلّمان ما خرجا لأجله. هذا ليس نقصاً في الموهبة، بل خللٌ بنيوي.

ويزداد الأمر سوءاً كلّما ارتفعت الرهانات. تُظهر الأبحاث نفسها أن المشاريع الصغيرة تنجح نحو 90 بالمئة من الوقت، بينما تنجح الكبيرة أقلّ من 10 بالمئة [1][5]. ووجدت دراسةٌ منفصلةٌ لأكثر من 5,400 مشروع تقنيٍّ كبيرٍ أجرتها ماكينزي وجامعة أكسفورد أنها تجاوزت ميزانياتها وسطياً بـ 45 بالمئة وسلّمت قيمةً أقلّ بـ 56 بالمئة ممّا وُعِد به — مع 17 بالمئة ساءت إلى حدٍّ هدّد وجود الشركة التي كلّفت بها [2]. النمط ثابت: كلّما كبرت القفزة التي تأخذها دفعةً واحدة، قلّت احتمالات هبوطها بسلام.

فإن لم يكن الكود، فما هو؟ حين تتعقّب المشاريع الفاشلة إلى سببها الجذري، يكون الجرح دائماً تقريباً أعلى من السطر الأول المكتوب. فنحو النصف — 47 بالمئة — من المشاريع الفاشلة تفشل بسبب متطلّباتٍ غير دقيقة [3]، و52 بالمئة من كل المشاريع تعاني «زحف النطاق»، ذلك التضخّم البطيء غير المُدرَج في الميزانية لما كان يُفترض بناؤه [4]. هذه القطعة عن ذلك الجرح الأعلى: من أين يأتي، ولماذا «سنُدبّر التفاصيل ونحن نمضي» أغلى جملةٍ في البرمجيات، وكيف يُكلَّف بالمشروع بحيث يُشحَن فعلاً.

ابدأ بالرقم الذي يُعيد تأطير كل شيء: 31 بالمئة فقط من المشاريع في بيانات ستانديش تنجح بالتعريف الصارم — في الموعد، وضمن الميزانية، وبالمزايا المتّفق عليها ^[1]. والشريحة الأكبر، 50 بالمئة، «متعثّرة»: البرمجية موجودة، لكنها وصلت متأخّرةً، أو كلّفت أكثر من المخطّط، أو شُحنت وقد حُذف نصف النطاق الموعود بهدوءٍ لإدراك الموعد. والـ 19 بالمئة الباقية تُلغى ببساطة، غالباً بعد إنفاق مالٍ حقيقي ^[1]. والدرس العملي لصاحب العمل أن «فشل» نادراً ما تكون ثنائيةً نظيفة. النتيجة الشائعة ليست انهياراً — بل خيبةً بطيئةً جزئيةً استنزفت مع ذلك الميزانية والتقويم. تلك هي النتيجة الأكثر شيوعاً للتكليف بالبرمجيات، وهي التي لا يخطّط لها معظم الناس.

وأثر الحجم هو أكثر النتائج قابليةً للتطبيق في المجال. المشاريع الصغيرة تنجح نحو 90 بالمئة من الوقت؛ والكبيرة أقلّ من 10 بالمئة ^[1][5]. وهذا ليس لأن الفرق الكبيرة أسوأ — بل لأن النطاق الكبير يُخفي مجاهيل أكثر، وتبعيّات أكثر، ومواضع أكثر يكون فيها الموجز الأصلي خاطئاً. ودراسة ماكينزي–أكسفورد لـ 5,400 مشروعٍ كبيرٍ تضع له ثمناً: تجاوزٌ وسطيٌّ للميزانية بـ 45 بالمئة، وقيمةٌ أقلّ بـ 56 بالمئة ممّا وُعِد، وذيلٌ طويلٌ من مشاريع «البجعة السوداء» — 17 بالمئة — تجاوزت إلى حدٍّ وضع العمل نفسه في خطر ^[2]. والخلاصة ليست «لا تبنِ شيئاً كبيراً». بل «لا تبنِ شيئاً كبيراً في قفزةٍ واحدةٍ غير مقسّمة». فالنتيجة الكبيرة المُدرَكة عبر شرائح صغيرة مشحونة تتصرّف كسلسلةٍ من المشاريع الصغيرة، أي تتصرّف كعمود الـ 90 بالمئة.

والآن السبب الجذري. حين يسأل الباحثون لماذا أخفقت المشاريع المتعثّرة والملغاة، تكون الإجابة في الغالب الساحق أعلى من الهندسة. وجد معهد إدارة المشاريع أن 47 بالمئة من المشاريع الفاشلة تُخفق في بلوغ أهدافها بسبب إدارة متطلّباتٍ غير دقيقة — الموجز كان خاطئاً أو ناقصاً أو لم يُتّفق عليه حقاً ^[3]. ووجد العمل نفسه أن 52 بالمئة من كل المشاريع تشهد زحف النطاق: التوسّع المطّرد غير المُدرَج في الميزانية لـ «هل يمكنك أيضاً أن تضيف فقط…» الذي يحوّل بناءً من ثلاثة أشهرٍ إلى عام ^[4]. لاحظ ما يغيب عن رأس تلك القائمة: كودٌ سيّئ، خوادم بطيئة، لغة برمجةٍ خاطئة. تلك حقيقيّة، لكنها نادراً ما تُغرق المشروع. ما يُغرقه هدفٌ تحرّك، أو لم يُرسَم بوضوحٍ قطّ.

لماذا يخطئ الموجز بهذه الموثوقية؟ لأن لحظة الجهل الأقصى بنظامٍ ما هي اللحظة التي يُطلب منك فيها تحديده بالكامل — البداية ذاتها. لا أحد يعرف عن وظيفة البرمجية أقلّ ممّا يعرفه في اليوم الأول، ومع ذلك اليوم الأول هو حين يُوقَّع النطاق الثابت والسعر الثابت. والاستجابة الصادقة لذلك الجهل ليست وثيقة متطلّباتٍ أطول؛ بل مرحلة اكتشافٍ قصيرةٍ مدفوعةٍ تحوّل الافتراضات إلى خطّةٍ مُختبَرةٍ قبل أن يلتزم البناء المُكلِف، وإيقاع تسليمٍ يشحن شريحةً صالحةً للاستخدام كل بضعة أسابيع كي يُصحَّح الموجز إزاء الواقع بدل أن يُدافَع عنه. المشاريع التي تنجح ليست تلك ذات أكثر المواصفات المُسبقة تفصيلاً، بل تلك المبنيّة بزياداتٍ صغيرةٍ بما يكفي ليكون الخطأ رخيصاً وقابلاً للإصلاح.

ولصاحب العمل، يتلخّص هذا في قائمةٍ قصيرةٍ لا علاقة لها بمدى ذكاء المطوّرين. هل كانت ثمّة مرحلة اكتشافٍ حقيقية، أم بدأ البناء على موجزٍ غامضٍ وسعرٍ ثابت؟ هل العمل مقسّمٌ بحيث يُشحن شيءٌ صالحٌ للاستخدام في أسابيع، لا في نهاية نفقٍ مظلمٍ من ستة أشهر؟ هل ثمّة مالكٌ واحدٌ مُسمّى للنطاق في جانبك يقدر على قول لا لـ «وما دمنا في الأمر»؟ هل ترى برمجيةً عاملةً مبكّراً وكثيراً، أم تقرير حالةٍ فقط؟ أتقِن تلك الأربعة، تكن قد نقلت مشروعك خارج الاثنين من كل ثلاثةٍ الذين يخيّبون، وإلى العمود الذي يُشحن — لا بتوظيف مهندسين أفضل، بل برفض التكليف بنوع المشروع الذي تقول البيانات إنه يفشل. لم يكن الكود قطّ هو الخطر. كان النطاق دائماً.