VQD-CTS Prediction Model: An AI-Driven Framework for Predicting Cost-to-Serve Using Engineering Velocity, Quality, and Developer Experience

تخيل أنك تدير متجراً ضخماً وصاخباً للبيتزا. لديك فريق من الطهاة (المطورون)، وفرن فاخر (التكنولوجيا)، وتدفق مستمر من الطلبات (ميزات البرمجيات). في الأيام الخوالي، إذا أردت معرفة تكلفة صنع بيتزا، كنت تكتفي بالتخمين بناءً على عدد البيتزا التي صنعتها في الأسبوع الماضي. لكن ذلك يشبه محاولة التنبؤ بالطقس من خلال النظر إلى تقويم الأمس؛ فهو يغفل عن السحب الرعدية، والرياح، وحقيقة أن فرنك قد يكون معطلاً.

في عالم البرمجيات، تواجه الشركات لغزاً مماثلاً. فهي تتبع مدى سرعة فرق عملها (السرعة - Velocity)، وعدد الأخطاء التي يرتكبونها (الجودة - Quality)، ومدى سعادة طهاتها بأدواتهم وبيئتهم (تجربة المطور - Developer Experience). ولكن لفترة طويلة، لم يستطع أحد تحديد كيف تترجم هذه الأشياء الثلاثة بالضبط إلى الفاتورة النهائية — "تكلفة الخدمة" (Cost-to-Serve). الأمر يشبه معرفة أنك استخدمت الكثير من الجبن وأن الطاهي كان سعيداً، لكنك لا تعرف ما إذا كان ذلك يعني أن بيتزا ستكلفك 10 دولارات أم 100 دولار. تحاول هذه الورقة البحثية حل هذا الغموض عبر بناء عقل حاسوبي فائق الذكاء (ذكاء اصطناعي) يمكنه النظر إلى كل تلك التفاصيل الفوضوية والتنبؤ بسعر التكلفة حتى قبل خبز البيتزا.

نموذج التنبؤ VQD-CTS: بلورة سحرية لتكاليف البرمجيات

قام الباحثان، باسافاراج تشونشور ومانتيش باتيل، ببناء أداة جديدة تسمى نموذج التنبؤ VQD-CTS. فكر في "VQD" كصلصة سرية مكونة من ثلاثة مكونات: السرعة (V - Velocity: مدى سرعة الفريق)، الجودة (Q - Quality: عدد الأخطاء التي يكتشفونها)، وتجربة المطور (D - Developer Experience: مدى سهولة أداء عملهم). أما "CTS" فهي ترمز إلى تكلفة الخدمة (Cost-to-Serve)، وهي الفاتورة الإجمالية لتقديم قطعة من البرمجيات للعميل، بما في ذلك كل شيء بدءاً من كهرباء الخوادم وصولاً إلى رواتب الأشخاص الذين يصلحون الأخطاء.

لم يعتمد الفريق على التخمين فحسب؛ بل غدوا ذكاءهم الاصطناعي بكتلة هائلة من البيانات الوهمية ولكن الواقعية — 10,000 سجل لمشاريع برمجية مختلفة — لتعليمه كيف تختلط هذه المكونات الثلاثة لتخلق تكلفة ما. إنه يشبه تدريب روبوت طباخ من خلال تركه يشاهد 10,000 سيناريو مختلف لصنع البيتزا، من السيناريوهات التي سارت بسلاسة إلى تلك التي اشتعل فيها النار في الفرن.

ماذا وجدوا؟

تبين أن الروبوت الطباخ بارع بشكل مفاجئ في عمله. فعندما اختبروه على بيانات جديدة لم يسبق له رؤيتها، حصل على درجة 0.885 (على مقي scale حيث 1.0 هو المثالي). وباللغة البسيطة، هذا يعني أن النموذج يفسر ما يقرب من 90% من الأسباب التي تؤدي لارتفاع أو انخفاض التكاليف. وفي المتوسط، كانت توقعاته للسعر بعيدة عن الواقع بمقدار 79.93 وحدة نقدية فقط (استخدمت الورقة وحدة عامة، لذا فكر فيها كـ "نقاط" على لوحة النتائج).

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

1. تعقيد الكود (Code Complexity): كان هذا هو الشرير الأكبر. إذا كان الكود فوضوياً ويصعب فهمه، فإن التكلفة ترتفع بجنون. الأمر يشبه محاولة بناء منزل بأسلاك متشابكة في كل مكان؛ يستغرق الأمر وقتاً طويلاً للإصلاح، وكلما لمست شيئاً، تعطل شيء آخر.
2. كثافة العيوب (Defect Density): هذه مجرد طريقة منمقة لقول "كم عدد الأخطاء المختبئة في الكود". كلما زادت الأخطاء، أصبح المشروع أكثر تكلفة بسبب كل عمليات إعادة العمل وشكاوى العملاء.
3. وقت الدورة (Cycle Time): هذا هو الوقت المستغرق للانتقال من مرحلة "لدي فكرة" إلى مرحلة "إنها تعمل على هاتفك". إذا طال هذا الوقت، تزداد التكلفة بسبب صداع التنسيق والفرص الضائعة.
4. حصة تكلفة البنية التحتية (Infrastructure Cost Share): هذه هي فاتورة خوادم السحاب والأدوات. ومع انتقال الشركات لمزيد من أعمالها إلى السحابة، يصبح هذا الجزء من الفاتورة جزءاً ضخماً من التكلفة الإجمالية.

الحقائق المفاجئة

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

مفاجأة أخرى كانت أن حجم الفريق لم يكن مهماً بقدر ما يعتقده الناس. الفريق الكبير ليس مكلفاً تلقائياً إذا كان منظماً وذا خبرة؛ يمكن للفريق الصغير أن يكون مكلفاً إذا كان تائهاً ومرتبكاً. الأمر لا يتعلق بعدد الطهاة، بل بمدى معرفتهم بالوصفة ومدى حدة سكاكينهم.

ما مدى ثقتهم؟

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

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

الخلاصة

نموذج VQD-CTS هو بمثابة نظام GPS لمديري البرمجيات. فبدلاً من القيادة بعماء والأمل في عدم نفاد الوقود (المال)، يمكنهم الآن النظر إلى سرعتهم، وحالة سيارتهم، ومزاج سائقهم للتنبؤ بدقة بتكلفة الرحلة. ويشير البحث إلى أنه إذا أردت توفير المال، فلا تكتفِ بإخبار فريقك "تحركوا بشكل أسرع". بدلاً من ذلك، نظف الكود الفوضوي، وأصلح الأخطاء مبكراً، وتأكد من أن المطورين لديهم الأدوات اللازمة ليكونوا سعداء. فهذا، كما تقترح الورقة، هو الوصفة الحقيقية لبيتزا أرخص وأفضل.