إدارة الديون الفنية مع DX و AI

تقلق كل شركة، كبيرة أو صغيرة، بشأن الديون الفنية. تقدر شركة Gartner أن حوالي 40% من أنظمة البنية التحتية لديها هذه المشكلة. في استطلاع للمديرين التنفيذيين لشركة McKinsey، شعر ما يقرب من ثلثهم بأن أكثر من 20% من ميزانية المنتج الجديد ذهبت إلى حل المشكلات المتعلقة بالديون الفنية. ولكن على عكس ما يعتقد الكثيرون، هذه ليست مشكلة ترميز فقط؛ إنها أيضًا مشكلة تجربة المطور (DX). لأن عندما يضطر المطورون إلى العمل مع بنية تحتية غير كافية، وأدوات قديمة، وعمليات تطوير رديئة، تعاني الإنتاجية والأداء والروح المعنوية.

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

دعم DX

الطريقة التي يتم بها تمهيد المطورين غالبًا ما تترك الكثير لتكون مرغوبة. قد يستغرق الأمر أسبوعين لشخص ما أن يبدأ في المساهمة في مشروع. مرة واحدة وقد تمكنوا أخيرًا من إضافة ميزات صغيرة أو تصحيحات، فمن غير المعتاد أن نرى خدمة التكامل المستمر (CI) تفشل بسبب شيء完全 غير مرتبط بالتغييرات التي عملوا عليها. هذا هو أساسًا فشل حزمة الاختبار بسبب مشاكل جودة رديئة، ولم ي提交 المطور أي تغييرات لجعل حزمة الاختبار تفشل. إنها اختبار متقلب مكتوب بشكل سيئ يعمل فقط 90% من الوقت. الفريق الحالي ربما يكون على ما يرام معه – إنه يبطئ فقط العمليات – ولكن الأدوات قد تكون قديمة ومخزية لأي شخص خارج المنظمة.

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

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

كما تتنبأ IDC بأن سوق اختبار البرمجيات التلقائي القائم على الذكاء الاصطناعي سيستمر النمو بمعدل نمو سنوي مركب يبلغ 31.2% حتى عام 2027، لذا تأكد من استغلال هذه التكنولوجيا بشكل كامل.

المقاييس و علامات التحذير

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

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

اللعب مع الأدوات القائمة على الذكاء الاصطناعي

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

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

هناك حالة لوكلاء الذكاء الاصطناعي مع مهندسي التصرف كالمنسقين. كشفت دراسة قام بها Capgemini على 1100 مسؤول تنفيذي في الشركات الكبيرة أن 82% يخططون لتكامل وكلاء الذكاء الاصطناعي في течение ثلاث سنوات القادمة، وهم يؤثرون بالفعل على مستقبل العمل. قد تكون تنظر إلى تقرير خطأ وترى أنه صغير بدرجة كافية لوكيل الذكاء الاصطناعي لت扱ه من البداية إلى المراجعة الكودية، وبالتالي توفير وقت فريقك وتحريرهم لمعالجة عمل أكثر تعقيدًا. ومع ذلك، في بعض الأحيان، عندما نتبع هذه الأدوات بشكل أعمى، هناك تنازلات يصعب على الذكاء الاصطناعي النظر فيها.

هنا يأتي الحكم البشري كعامل حاسم.

تناغم الديون الفنية مع الأهداف

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

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

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

الديون الفنية مع الفائدة

يمكن لكل منظمة تخصيص بضع ساعات كل أسبوع لتحسين DX الخاص بها لمساعدة خفض الديون الفنية. إذا لم تفعل، قد تدفع ثمن ذلك فيما بعد، على الأرجح بسبب أداء بطيء، أو تباطؤ كبير في سرعة التطوير، أو مشاكل أمنية. على سبيل المثال، قد يكون فريق مهندسيك ومطوريك قد أرجأوا تحديثات Ruby on Rails لمدة عقد من الزمن. فجأة، يزيد تكلفة المشروع بنصف مليون دولار لأن إصدار Ruby متأخر بأربعة أجيال، تاركًا لك كتلة من الشفرة والاعتماديات القديمة.

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