तकनीकी ऋण आपके स्टार्टअप को ख़त्म कर रहा है। यहां बताया गया है कि इसे कैसे ठीक किया जाए।

आपके इंजीनियर खर्च करते हैंउनके कामकाजी घंटों का 42%तकनीकी ऋण और ख़राब कोड से निपटना। सुविधाओं का निर्माण नहीं. उत्पादों की शिपिंग नहीं. शॉर्टकट ठीक करना किसी ने छह महीने पहले अपनाया था क्योंकि समय सीमा कल थी।

एक स्टार्टअप के लिए जिसमें पांच डेवलपर प्रत्येक $100,000 कमाते हैं, इसका मोटे तौर पर मतलब है$125,000 प्रति वर्षइंजीनियरिंग में वेतन ऋण चुकाने की ओर जा रहा है। वैश्विक स्तर पर, तकनीकी ऋण कंपनियों पर प्रति वर्ष $2.4 ट्रिलियन से अधिक खर्च करता है। और कंपाउंडिंग बदतर हो जाती है: अप्रबंधित ऋण वाली टीमों में 12 महीनों के भीतर स्प्रिंट वेग में 30% की गिरावट देखी गई है।

तकनीकी ऋण कोई कोड समस्या नहीं है. यह एक व्यावसायिक समस्या है. और इसका समाधान है.

वास्तविक दुनिया में तकनीकी ऋण कैसा दिखता है

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

तकनीकी ऋण पूर्वानुमानित तरीकों से जमा होता है:

• गति-संचालित शॉर्टकट:आपने एक सुविधा बिना परीक्षण के भेज दी क्योंकि निवेशक डेमो शुक्रवार को था। सुविधा काम करती है, लेकिन कोई नहीं जानता कि अप्रत्याशित इनपुट मिलने पर क्या होता है।
• कोड कॉपी-पेस्ट करें:एक ही व्यवसाय नियम चार स्थानों पर मौजूद है। जब नियम बदलता है, तो कोई उनमें से तीन को अपडेट कर देता है और चौथा चूक जाता है।
• पुरानी निर्भरताएँ:आपका ढाँचा दो प्रमुख संस्करणों से पीछे है। आपके संस्करण के लिए सुरक्षा पैच पिछली तिमाही में बंद हो गए। अब अपग्रेड करने के लिए 40 फ़ाइलों को छूने की आवश्यकता है।
• कोई दस्तावेज नहीं:भुगतान प्रवाह को डिज़ाइन करने वाला इंजीनियर छह महीने पहले चला गया। कोड में शून्य टिप्पणियाँ हैं. नया इंजीनियर डेटाबेस क्वेरीज़ को पढ़कर प्रवाह को रिवर्स-इंजीनियर करता है।
• हार्डकोडेड मान:एपीआई कुंजियाँ, फ़ीचर फ़्लैग और व्यावसायिक नियम कॉन्फ़िगरेशन फ़ाइलों के बजाय सीधे स्रोत कोड में रहते हैं। मूल्य निर्धारण स्तर बदलने के लिए कोड परिनियोजन की आवश्यकता होती है।

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

स्टार्टअप्स किसी अन्य की तुलना में तेजी से कर्ज क्यों जमा करते हैं?

42% स्टार्टअप विफल हो जाते हैं क्योंकि उनके उत्पाद को बाज़ार की कोई आवश्यकता नहीं होती है। संस्थापक इस आँकड़े को जानते हैं। तो तर्कसंगत प्रतिक्रिया यह है: तेजी से जहाज भेजें, मांग की पुष्टि करें, बाद में कोड गुणवत्ता के बारे में चिंता करें। यह सही प्रवृत्ति है. एक पूरी तरह से तैयार किया गया उत्पाद जिसे कोई भी नहीं चाहता वह बेकार है।

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

इंजीनियर खर्च करते हैंप्रति माह 2 से 5 कार्य दिवसतकनीकी ऋण पर. यह आपके इंजीनियरिंग बजट का 25% तक आपके द्वारा लिए गए निर्णयों को बनाए रखने में खर्च होता है जब आपके पास कम जानकारी और कम समय होता था। पांच-व्यक्ति स्टार्टअप में, इसका मतलब है कि एक पूर्ण इंजीनियर का आउटपुट पूरी तरह से ऋण सेवा की ओर जाता है।

यौगिक प्रभाव हत्यारा है. तीसरे महीने में, कर्ज़ आपकी गति को 10% तक धीमा कर देता है। छठे महीने में यह 20% है। बारह महीने तक, आपकी स्प्रिंट गति अपने चरम से 30% कम हो गई है। जिन सुविधाओं के लिए एक स्प्रिंट की आवश्यकता होती है, अब उन्हें दो की आवश्यकता होती है। बग की गिनती बढ़ती है। अभियंताओं का मनोबल गिरा आपके सर्वश्रेष्ठ डेवलपर कहीं और साक्षात्कार लेना शुरू कर देते हैं क्योंकि वे उत्पाद बनाने के बजाय कोडबेस से लड़ते-लड़ते थक गए हैं।

चार प्रकार के तकनीकी ऋण (और कौन सा पहले ठीक करें)

सभी ऋण एक समान नहीं होते. इसे एक ही श्रेणी के रूप में मानने से या तो इसे अनदेखा कर दिया जाएगा या एक ही बार में सभी को ठीक करने का प्रयास किया जाएगा। कोई भी काम नहीं करता.

विचारशील और विवेकपूर्ण

"हम जानते हैं कि यह एक शॉर्टकट है, और लॉन्च के बाद हम इसे ठीक कर देंगे।" यह स्वस्थ ऋण है. आपने गति के लिए कोड गुणवत्ता का व्यापार करने का एक सूचित निर्णय लिया, और आपने इसे लॉग इन किया। मुख्य शब्द "लॉग्ड" है। यदि कोई शॉर्टकट को ट्रैक नहीं करता है, तो यह जानबूझकर नहीं है; इसे भुला दिया गया है.

जानबूझकर और लापरवाह

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

अनजाने और विवेकपूर्ण

"अब जब हमने संस्करण एक बना लिया है, तो हम समझते हैं कि इसे कैसे डिज़ाइन किया जाना चाहिए था।" यह ऋण अपरिहार्य है. आप निर्माण करके सीखते हैं। जो आर्किटेक्चर 100 उपयोगकर्ताओं पर समझ में आता है वह शायद ही कभी 10,000 उपयोगकर्ताओं पर समझ में आता है। इस प्रकार का ऋण विकास और सीखने का संकेत देता है, और इसे चुकाना सबसे फायदेमंद है क्योंकि टीम को पता है कि बेहतर समाधान कैसा दिखता है।

असावधान और लापरवाह

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

प्राथमिकता तय करें:जानबूझकर-लापरवाह ऋण ("परीक्षण के लिए समय नहीं" श्रेणी) से शुरुआत करें। इसमें सबसे अधिक जोखिम होता है और यह सबसे तेजी से बढ़ता है। फिर अनजाने-विवेकपूर्ण ऋण का समाधान करें, जहां आपकी टीम पहले से ही बेहतर समाधान जानती है। जानबूझकर-विवेकपूर्ण ऋण लॉग करें और इसे शेड्यूल करें। नियुक्ति और कोड समीक्षा मानकों के माध्यम से अनजाने-लापरवाह ऋण का समाधान करें।

फीचर कार्य को रोके बिना तकनीकी ऋण का भुगतान करने की एक प्रणाली

टीमों द्वारा की गई सबसे बड़ी गलती: "तकनीकी ऋण स्प्रिंट" शेड्यूल करना जहां सभी फीचर कार्य दो सप्ताह के लिए रुक जाते हैं। नेतृत्व इससे नफ़रत करता है क्योंकि इसमें कोई प्रगति नज़र नहीं आती। इंजीनियर इससे नफरत करते हैं क्योंकि छह महीने के संचित शॉर्टकट को ठीक करने के लिए दो सप्ताह पर्याप्त नहीं हैं। हर कोई हार जाता है.

यहां एक प्रणाली है जो काम करती है.

चरण 1: एक ऋण रजिस्टर बनाएं

चार कॉलमों के साथ एक साझा दस्तावेज़ या प्रोजेक्ट बोर्ड बनाएं (एक साधारण स्प्रेडशीट ठीक काम करती है): स्थान (फ़ाइल या मॉड्यूल), ऋण का विवरण, व्यावसायिक प्रभाव (यह क्या धीमा करता है या जोखिम में डालता है), और ठीक करने का अनुमानित प्रयास। टीम के प्रत्येक इंजीनियर को आइटम जोड़ने में एक घंटा लगाने को कहें। आपके पास 20-50 प्रविष्टियाँ होंगी। यह आपकी ऋण सूची है.

प्रत्येक आइटम को दो अक्षों पर स्कोर करें: जोखिम (यह किसी उत्पादन घटना का कारण बनने या किसी सुविधा को अवरुद्ध करने की कितनी संभावना है) और प्रयास (इसे ठीक करने में कितना समय लगता है)। उच्च जोखिम, कम प्रयास वाली वस्तुएँ सूची में सबसे ऊपर जाती हैं। कम-जोखिम, उच्च-प्रयास वाली वस्तुएँ नीचे तक जाती हैं। इसे साफ़ करने के लिए कोई बैकलॉग नहीं है; यह लगातार खींची जाने वाली प्राथमिकता वाली कतार है।

चरण 2: प्रत्येक स्प्रिंट का 10-20% ऋण कटौती के लिए आवंटित करें

पांच इंजीनियरों के साथ दो सप्ताह की दौड़ में, 10% का मतलब है कि एक इंजीनियर ऋण भुगतान पर पूरा एक दिन खर्च करता है। 20% का अर्थ है प्रति स्प्रिंट दो इंजीनियर-दिन। यह वैकल्पिक समय नहीं है; इसे फीचर कार्य की तरह शेड्यूल, असाइन और ट्रैक किया जाता है।

गणित: 15% ऋण आवंटन पर दो सप्ताह की दौड़ लगाने वाली पांच व्यक्तियों की टीम ऋण कटौती पर प्रति माह 7.5 इंजीनियर-दिन खर्च करती है। एक वर्ष में, यानी लक्षित सुधारों के 90 इंजीनियर-दिन। फीचर डिलीवरी को कभी भी रोके बिना कोडबेस को बदलने के लिए पर्याप्त है।

चरण 3: ऋण कार्य को फीचर कार्य से जोड़ें

कर्ज चुकाने का सबसे प्रभावी तरीका: जब आप पहले से ही क्षेत्र में काम कर रहे हों तो इसे ठीक करें। एक नई भुगतान सुविधा का निर्माण? जब आप वहां हों तो मौजूदा भुगतान मॉड्यूल को दोबारा तैयार करें। एक नया एपीआई एंडपॉइंट जोड़ा जा रहा है? उसी पुल अनुरोध के भाग के रूप में एपीआई रूटिंग परत को साफ़ करें।

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

चरण 4: ऋण मेट्रिक्स को मापें और रिपोर्ट करें

आप जिसे मापते नहीं उसे प्रबंधित नहीं कर सकते। मासिक रूप से तीन नंबर ट्रैक करें:

• ऋण अनुपात:ऋण कार्य बनाम फीचर कार्य पर खर्च की गई स्प्रिंट क्षमता का प्रतिशत। लक्ष्य: 10-20%. यदि यह 25% से अधिक है, तो कोडबेस को अधिक आक्रामक हस्तक्षेप की आवश्यकता है।
• समय चक्र:किसी सुविधा को "प्रगति पर" से "तैनात" होने में कितना समय लगता है। बढ़ते चक्र का समय ऋण संचय का संकेत देता है, तब भी जब कोई इसके बारे में शिकायत नहीं कर रहा हो।
• घटना की आवृत्ति:प्रति स्प्रिंट उत्पादन बग. प्रति स्प्रिंट में अधिक बग का अर्थ है अधिक ऋण-प्रेरित नाजुकता। यह देखने के लिए परिनियोजन आवृत्ति के साथ इसे ट्रैक करें कि शिपिंग गति टूट-फूट से संबंधित है या नहीं।

इन नंबरों की मासिक रिपोर्ट नेतृत्व को दें। तकनीकी ऋण व्यावसायिक लागत के साथ एक इंजीनियरिंग समस्या है। जब सीटीओ कह सकता है कि "हम इंजीनियरिंग का 12% समय ऋण रखरखाव पर खर्च करते हैं, जो छह महीने पहले 25% से कम है," बातचीत "इंजीनियर सुविधाओं का निर्माण क्यों नहीं कर रहे हैं" से "सिस्टम काम कर रहा है" में बदल जाती है।

रोकथाम: पहले दिन से कम कर्ज कैसे जमा करें

मौजूदा कर्ज चुकाना जरूरी है. कम नया कर्ज जमा करना बेहतर है. यहां निवेश पर उच्चतम रिटर्न वाली प्रथाएं दी गई हैं।

• प्रत्येक पुल अनुरोध पर कोड समीक्षा।आँखों का दूसरा जोड़ा विलीन होने से पहले शॉर्टकट पकड़ लेता है। समीक्षाओं का लंबा होना ज़रूरी नहीं है; 15 मिनट की समीक्षा में 80% ऋण-निर्माण पैटर्न का पता चलता है।
• पहले सप्ताह से स्वचालित परीक्षण।आपको 100% कवरेज की आवश्यकता नहीं है. अपने महत्वपूर्ण पथों पर एकीकरण परीक्षणों से शुरुआत करें: साइनअप, चेकआउट, आपके उत्पाद को निष्पादित करने के लिए मुख्य क्रिया। इसकी अग्रिम लागत 10-15% अधिक है और छह महीने में बग-फिक्सिंग समय में 3-5 गुना की बचत होती है।
• लिंटिंग और टाइप चेकिंग के साथ सीआई/सीडी पाइपलाइन।टाइपस्क्रिप्ट सख्त मोड, ईएसलिंट और हर पुश पर स्वचालित जांच। ये उपकरण उत्पादन तक पहुंचने से पहले बग की पूरी श्रेणियों को पकड़ लेते हैं। सेटअप में आधा दिन लगता है. वापसी स्थायी है.
• वास्तुशिल्प विकल्पों के लिए निर्णय रिकॉर्ड।जब आपकी टीम कैशिंग के लिए रेडिस का उपयोग करने या v1 में वेबसॉकेट समर्थन को छोड़ने का निर्णय लेती है, तो निर्णय और ट्रेडऑफ़ को समझाते हुए एक दो-पैराग्राफ नोट लिखें। छह महीने बाद, जब कोई पूछता है "हमने इसे इस तरह क्यों बनाया?", उत्तर मौजूद है और टीम किसी सुलझे हुए प्रश्न पर दोबारा बहस नहीं करती है।
• वरिष्ठ इंजीनियरों को नियुक्त करें.एक वरिष्ठ इंजीनियर सबसे पहले कम ऋण लिखता है। वे सही अमूर्तन चुनते हैं, स्केलिंग बाधाओं का अनुमान लगाते हैं, और शुरू से ही परीक्षण को ध्यान में रखते हुए निर्माण करते हैं। सावी में, हम 1-2 वरिष्ठ इंजीनियरों के साथ परियोजनाओं का स्टाफ रखते हैं, जिनके पास पूर्ण स्टैक का स्वामित्व होता है। उनके द्वारा भेजे गए कोड को कम रखरखाव की आवश्यकता होती है क्योंकि वास्तुशिल्प निर्णय पहले दिन से ही सही होते हैं।

ऋण का प्रत्येक घंटा जिसे आप रोकते हैं, वह एक घंटा है जिसे आप बचाते हैंचल रही सॉफ़्टवेयर रखरखाव लागत. परीक्षणों और ठोस वास्तुकला के साथ स्वच्छ कोड को बनाए रखने में प्रति वर्ष निर्माण का 15-20% खर्च होता है। कर्ज से लदे कोड की कीमत 30-50% होती है।

बाहरी सहायता के लिए कब कॉल करें

कुछ कोडबेस उस बिंदु से आगे हैं जहां आंतरिक स्प्रिंट समस्या को ठीक कर सकते हैं। यदि आपकी टीम अपना 30% से अधिक समय कर्ज में बिताती है, यदि तैनाती साप्ताहिक रूप से टूटती है, या यदि आपके इंजीनियर आपसे कहते हैं "हमें इसे फिर से लिखने की आवश्यकता है," तो आपको किसी ऐसे व्यक्ति से कोडबेस ऑडिट की आवश्यकता है जो पिछले वर्ष से कोड पर ध्यान नहीं दे रहा है।

एक बाहरी ऑडिट में 3-5 दिन लगते हैं और व्यावसायिक प्रभाव के आधार पर विशिष्ट फ़ाइलों, मॉड्यूल और वास्तुशिल्प परिवर्तनों के साथ प्राथमिकता वाली भुगतान योजना तैयार की जाती है। ऑडिटर 80% मंदी का कारण बनने वाले 20% ऋण की पहचान करता है और एक रोडमैप बनाता है जिसे आपकी टीम 8-12 सप्ताह में क्रियान्वित कर सकती है।

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

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

अक्सर पूछे जाने वाले प्रश्नों