तकनीकी ऋण का प्रबंधन डीएक्स और एआई के साथ

हर कंपनी, बड़ी और छोटी, तकनीकी ऋण के बारे में चिंतित है। गार्टनर का अनुमान है कि लगभग 40% इन्फ्रास्ट्रक्चर सिस्टम में यह समस्या है। सीआईओ के एक सर्वेक्षण में मैकिन्से द्वारा, लगभग एक तिहाई महसूस किया कि 20% से अधिक उनके नए उत्पाद बजट तकनीकी ऋण से संबंधित मुद्दों को हल करने के लिए गया था। लेकिन जैसा कि कई लोग मानते हैं, यह केवल एक कोडिंग समस्या नहीं है; यह एक डेवलपर अनुभव (डीएक्स) समस्या भी है। क्योंकि जब डेवलपर्स को अपर्याप्त आर्किटेक्चर, पुराने टूलिंग और खराब विकास कार्य प्रवाह के साथ काम करना पड़ता है, तो उत्पादकता, प्रदर्शन और मनोबल प्रभावित होते हैं।

तकनीकी ऋण को डेवलपर के दृष्टिकोण से प्राथमिकता देना, उनके काम के तरीके, उपयोग किए जाने वाले टूल और करियर में प्रगति पर ध्यान केंद्रित करना, टीमों को ध्यान केंद्रित करने और तेजी से शिपिंग में मदद करता है। यही कारण है कि कंपनियां तकनीकी ऋण को डीएक्स और एआई-संचालित टूलिंग पर बढ़ते ध्यान के साथ प्रबंधित करने के तरीके को बदल रही हैं।

डीएक्स का समर्थन

डेवलपर्स को अक्सर जिस तरह से ऑनबोर्ड किया जाता है, वह बहुत कुछ छोड़ देता है। किसी परियोजना में योगदान देने के लिए किसी को शुरू करने में कुछ हफ्ते लग सकते हैं। एक बार जब वे अंततः छोटी सुविधाएं या पैच जोड़ने में सक्षम हो जाते हैं, तो यह असामान्य नहीं है कि निरंतर एकीकरण (सीआई) सेवा उनके द्वारा किए गए परिवर्तनों से संबंधित कुछ भी नहीं होने के कारण विफल हो जाती है। यह मूल रूप से परीक्षण सूट की विफलता है जो खराब गुणवत्ता वाले मुद्दों के कारण होती है, और डेवलपर ने परिवर्तन करने के लिए कोई परिवर्तन नहीं किया है जो परीक्षण सूट को तोड़ देता है। यह एक फ्लैकी, खराब लिखा परीक्षण है जो केवल 90% समय काम करता है। मौजूदा टीम शायद इसके साथ ठीक है – यह केवल प्रक्रियाओं को धीमा करता है – लेकिन टूलिंग पुराना और किसी भी बाहरी व्यक्ति के लिए निराशाजनक हो सकता है।

यह डीएक्स को बाधित करने वाले कई उदाहरणों में से एक है। इसे रोकने का एक तरीका यह है कि आपकी सॉफ्टवेयर इंजीनियरिंग और विकास टीम में एक निर्दिष्ट चैंपियन हो। कई छोटे संगठनों में डीएक्स नेता नहीं होते हैं, लेकिन बड़े, सफल लोगों में होते हैं। ये पेशेवर उन चीजों पर नजर रखते हैं जैसे कि एक नए डेवलपर को वातावरण सेट करने में कितना समय लगता है। और यदि दो सप्ताह बहुत लंबा है, तो वे इस समय को आधा करने का तरीका निकालते हैं।

इससे मदद करने के लिए टूलिंग है, जैसे कि सर्कलसीआई, जिसमें मूल नेटिव सुविधाएं हैं जो एक परीक्षण सूट की फ्लैकीनेस को ट्रैक करेंगी। जो आवश्यक है वह कोई है जो नेतृत्व ले और हर स्प्रिंट के बाद रुक जाए ताकि भविष्य में कोड को बनाए रखने और काम करने में आसान बनाने के लिए कुछ परिवर्तनों को संबोधित किया जा सके। यह एक नेता को खोजने के लिए आता है जो डीएक्स को बेहतर बनाने में रुचि रखता है। ऐसा होने के लिए, एक वरिष्ठ स्तर के इंजीनियर की तलाश करें जो एक अपेक्षाकृत नए कर्मचारी के साथ है, जो संभावित अंतराल पर प्रतिक्रिया दे सकता है।

इसके अलावा, आईडीसी का अनुमान है कि एआई-संचालित सॉफ्टवेयर परीक्षण स्वचालन बाजार 2027 तक 31.2% की सीएजीआर से बढ़ना जारी रखेगा, इसलिए सुनिश्चित करें कि आप इस तकनीक का पूरी तरह से उपयोग कर रहे हैं।

मेट्रिक्स और चेतावनी संकेत

तकनीकी ऋण के प्रभाव का मूल्यांकन करते समय आपकी टीम पर ट्रैक करने के लिए कई मेट्रिक्स हैं। कुछ बुनियादी लोग “समय की मरम्मत” या “समय की सुविधा” हैं। कहें कि आप एक बग को देखते हैं और जानते हैं कि इसे कैसे ठीक किया जाए। कुछ टूल समय को ट्रैक कर सकते हैं जो कोड लिखने से लेकर उत्पादन तक बिताया जाता है। उदाहरण के लिए, आप देखेंगे कि एक बहुत छोटा पैच दो व्यावसायिक दिनों में ठीक हो गया और जहाज पर चढ़ाया गया, जब आपकी टीम को यह करने में घंटों का समय लगना चाहिए। आप अनुपात जैसे मेट्रिक्स को भी ट्रैक कर सकते हैं, जैसे कि बग फिक्स की संख्या बनाम पूर्ण सुविधाएं।

इसके अलावा, आपकी टीम के प्रदर्शन पर प्रभाव डालने वाले मनोबल मुद्दों की पहचान करने के तरीके हैं। डीएक्स नेता तिमाही सर्वेक्षण चला सकते हैं ताकि यह निर्धारित किया जा सके कि एक डेवलपर परियोजना या इसके एक टुकड़े पर काम करने में कितना खुश है। वे निर्दिष्ट क्षेत्रों जैसे सीआई प्रक्रिया के बारे में पूछ सकते हैं। और आप हमेशा अपनी टीम में चालू और मुड़ने को ट्रैक कर सकते हैं। यदि आप देखते हैं कि लोग लगातार छोड़ देते हैं, तो वे महसूस कर सकते हैं कि उनकी चिंताओं को सुना नहीं जा रहा है।

एआई के साथ टूलिंग

एआई टूलिंग का उदय डेवलपर्स और इंजीनियरों को अधिक उत्पादक और उत्पादों को तेजी से शिपिंग करने में मदद करने वाला है, लेकिन तकनीकी ऋण इसे धीमा कर देता है। कहें कि आप कोड परिवर्तन में मदद के लिए जीएचबी या कोपायलट जैसे टूल का उपयोग करते हैं, फिर पुल अनुरोध सबमिट करते हैं, और सीआई को आपको वापस आने में कुछ घंटे लगते हैं। इस बीच, क्या एक डेवलपर कुछ और पर काम करता है? ईमेल जांचता है? यह एक संदर्भ स्विच और उत्पादकता हत्यारा है।

डेवलपर्स उन उत्पादों पर काम करना चाहते हैं जहां वे केवल कोड पर ध्यान केंद्रित कर सकते हैं। टूलिंग उनकी मदद करने के लिए है ताकि वे इसे उत्पादन में ला सकें, न कि एक निरंतर रोडब्लॉक हो। एआई समय बचा सकता है, लेकिन यह इंजीनियरिंग टीमों पर निर्भर करता है कि वे स्वीकार्य जटिलता के मानकों को परिभाषित करें। ऐसा करने के लिए, पहले सुनिश्चित करें कि आपकी मुख्य शाखा में जोड़ा गया कोई भी कोड स्वीकार्य स्तर के तकनीकी ऋण के साथ है। इससे पहले, इंजीनियरिंग टीम से तकनीकी ऋण और कोड गुणवत्ता के स्वीकार्य प्रतिबंध पर खुली चर्चा करें और खरीदारी प्राप्त करें। सुनिश्चित करें कि हर कोई जानता है कि उस निशान से ऊपर जाने से तुरंत उपचार की आवश्यकता है। एक बार जब आप उन मानकों को परिभाषित कर लेते हैं, तो एआई खेल में आता है।

इंजीनियरों के साथ एआई एजेंटों के लिए एक मामला है जो ऑर्केस्ट्रेटर के रूप में कार्य करते हैं। कैपजेमिनी के 1,100 कार्यकारी अधिकारियों के एक सर्वेक्षण से पता चलता है कि 82% अगले तीन वर्षों में एआई एजेंटों को एकीकृत करने की योजना बना रहे हैं, और वे पहले से ही काम के भविष्य पर प्रभाव डाल रहे हैं। आप एक बग रिपोर्ट देख रहे होंगे और देखेंगे कि यह इतना छोटा है कि एआई एजेंट इसे स्वीकृति से शुरू करने से लेकर कोड समीक्षा तक संभाल सकता है, आपकी टीम को समय बचा सकता है और उन्हें अधिक जटिल काम करने के लिए मुक्त कर सकता है। हालांकि, कभी-कभी जब हम इन टूल्स का अनुसरण करते हैं, तो एआई को विचार करने में कठिनाई होती है।

यह तब होता है जब मानव राय निर्णायक कारक बन जाती है।

लक्ष्यों के साथ तकनीकी ऋण का संरेखण

आप तकनीकी ऋण को कम करने को कैसे अपने लक्ष्यों या मापने योग्य परिणामों के साथ संरेखित करते हैं? यह स्वीकार्य तकनीकी ऋण में वापस आता है, और कभी-कभी व्यवसाय में, आपको तेजी से शिपिंग करनी होती है। आप ऐसा कर सकते हैं जानते हुए कि उत्पाद स्केल नहीं करता है, और समय के साथ प्रदर्शन मुद्दे हो सकते हैं। अक्सर, एक डेवलपर एक नोट बनाता है कि वे बाद में इन मुद्दों को संबोधित करेंगे, जब उनके पास इन मुद्दों को संबोधित करने का समय होगा, लेकिन ऐसा शायद ही कभी होता है। और जब यह खराब संस्कृति अधिकार में ले लेती है, जिसमें आपको लगातार कल शिपिंग करनी होती है, तो ऋण का प्रभाव स्पष्ट हो जाता है।

यह एक स्टार्टअप के लिए समझ में आता है, लेकिन एक दशक से चल रहे व्यवसाय के लिए नहीं। आपको तकनीकी ऋण का प्रबंधन करने के लिए अपनी संस्कृति को जल्दी से बदलना शुरू करना होगा; अन्यथा, आप उत्पादन बग को ठीक करने या सुरक्षा और अनुपालन के बारे में चिंतित होने में बहुत पैसा खर्च करेंगे।

अंत में, तकनीकी ऋण को चुकाने या पुनर्गठन के मूल्य को हितधारकों के साथ संवाद करने में मदद करने के लिए मेट्रिक्स हैं। समय एक हो सकता है, उत्पादन में शुरू से लेकर, या पुल अनुरोध खोलने से लेकर उत्पादन में मर्ज और शिपिंग करने तक। एक और मीट्रिक मीन टाइम टू रिपेयर (एमटीटीआर) है। इस मामले में, आपको एक बग या एक टूटी हुई बिल्ड मिली होगी, और आप मापते हैं कि आपकी टीम को इसे ठीक करने में कितना समय लगता है। आप उत्पादन में बग की संख्या को भी ट्रैक कर सकते हैं। यदि आप देखते हैं कि यह संख्या बढ़ रही है, तो तकनीकी ऋण से संबंधित एक समस्या हो सकती है।

तकनीकी ऋण के साथ ब्याज

प्रत्येक संगठन अपने डीएक्स में सुधार करने के लिए प्रति सप्ताह कुछ घंटे समर्पित कर सकता है ताकि तकनीकी ऋण को कम किया जा सके। यदि नहीं, तो आप बाद में इसका भुगतान कर सकते हैं, जो धीमी गति से प्रदर्शन, विकास गति में काफी कमी, या सुरक्षा समस्याओं के कारण हो सकता है। उदाहरण के लिए, आपके इंजीनियरों और डेवलपर्स की टीम रूबी ऑन रेल्स के अपग्रेड को एक दशक से टाल रही थी। अचानक, एक परियोजना की लागत रूबी के चार पीढ़ियों पीछे संस्करण के कारण आधा मिलियन डॉलर से अधिक बढ़ जाती है, जिससे आपको कोड का एक बड़ा हिस्सा और पुराने निर्भरता मिलते हैं।

यदि आपने धीरे-धीरे अपग्रेड किया होता, तो आप इस स्थिति में नहीं होते। इसलिए, अपनी सॉफ्टवेयर विकास टीम का समर्थन करें और जैसे-जैसे आप जाते हैं। अन्यथा, वह तकनीकी ऋण आपको ब्याज के साथ परेशान करेगा।