- तकनीकी कर्ज़ को एक रणनीतिक साधन के रूप में देखने के लिए ज़रूरी बातें
- तकनीकी कर्ज़ को लेकर नकारात्मक धारणाओं को पहचानना और उनका समाधान करना
- तकनीकी कर्ज़ के 6 प्रकारों का वर्गीकरण और अलग-अलग प्रतिक्रिया
- तकनीकी कर्ज़ के पैमाने को समझना
- तकनीकी कर्ज़ की प्राथमिकता तय करने का तरीका
How to Not Manage Tech Debt
- 4 धारणाएँ जो तकनीकी कर्ज़ का गलत प्रबंधन कराती हैं
धारणा #1 : तकनीकी कर्ज़ = बुरी चीज़
- हर तकनीकी कर्ज़ को 'बुरा' नहीं मानना चाहिए
- हर कर्ज़ को नाम देकर और उसकी पीड़ा का स्तर मापकर तकनीकी कर्ज़ों को वर्गीकृत करना कहीं बेहतर है
- कुछ तकनीकी कर्ज़ ऐसे होते हैं जिन्हें रखना फायदेमंद होता है, और हर टीम के पास कुछ तकनीकी कर्ज़ होना चाहिए
- Twitter का उदाहरण, जहाँ 'अच्छा तकनीकी कर्ज़' था: पहले public storage का उपयोग किया, फिर अपना distributed DB Manhattan बनाया
- 'तकनीकी कर्ज़ = बुरी चीज़' इस धारणा का सामना करने के लिए सवाल
- अगर हम अभी यह तकनीकी कर्ज़ लें और अगले महीने इसे ठीक करें, तो हमें क्या मिलेगा?
- किन परिस्थितियों में management इस तकनीकी कर्ज़ में रुचि लेगा? CTO को management के सामने pitch करने में मदद करने वाली जानकारी कैसे दी जाए?
- यह initiative कंपनी की बड़ी vision या strategic direction से कैसे जुड़ सकता है?
धारणा #2 : हर तकनीकी कर्ज़ = जटिल काम
- तकनीकी कर्ज़ ही नहीं, हर कठिन काम की तरह जटिल कामों को संभालने के कई तरीके होते हैं
- खासकर तकनीकी कर्ज़ के मामले में Defined/Undefined कामों तक पहुँचने के अलग तरीके होते हैं
- Defined = काम की शुरुआत और अंत दोनों स्पष्ट हैं
- Undefined = काम की शुरुआत है, लेकिन अंत स्पष्ट नहीं है
- 'तकनीकी कर्ज़ = जटिल' इस धारणा का सामना करने के लिए
- पहले स्पष्ट करें कि सामने वाला तकनीकी कर्ज़ Defined है या Undefined
- Defined के मामले में काम पूरा होने का अनुमानित समय समझें और थोड़ा buffer time रखें
- Undefined के मामले में यह समझने के लिए कि काम जटिल क्यों है और इसकी clear end date क्यों नहीं है, अस्पष्ट हिस्सों की सूची बनाएं, stakeholders को बताएं, और आगे बढ़ने के सबसे अच्छे तरीके पर उनकी राय लें
- Undefined तकनीकी कर्ज़ को छोटे-छोटे, संभालने योग्य हिस्सों में बाँटकर कम जटिल बनाएं
- जब किसी जटिल बड़े काम को छोटे लेकिन executable कामों में बदला जाता है, तो टीम sprint/quarter की तय अवधि में तकनीकी कर्ज़ के कुछ हिस्से सुलझाने के लिए अधिक motivated हो सकती है
- 'तकनीकी कर्ज़ = जटिल काम' इस धारणा का सामना करने के लिए सवाल
- सिस्टम के बारे में हमारी गलत धारणाएँ क्या हैं?
- अगर इस क्षेत्र का कोई अनुभवी या परिचित व्यक्ति लाया जाए, तो कौन से सवाल ज़रूर पूछने चाहिए?
- क्या हमारी टीम के पास यह काम करने के लिए सही लोग और ज़रूरी ज्ञान है? अगर नहीं, तो information reallocation पर कैसे विचार करना चाहिए, और इस समस्या को हल करने का सबसे सही समय कब होगा?
- ऐसे व्यक्ति को, जिसे इस तकनीकी कर्ज़ की जटिलता की बिल्कुल समझ नहीं है, इसे समझाने का सबसे अच्छा तरीका क्या है?
धारणा #3 : तकनीकी कर्ज़ ≠ product work
- संगठन आमतौर पर इस बात पर स्पष्ट होते हैं कि product work कंपनी metrics को कैसे बेहतर करेगा
- लेकिन तकनीकी कर्ज़ अक्सर इस चर्चा से गायब होता है
- तकनीकी कर्ज़ को समय पर हल करना, भले ही उसे तुरंत quantify न किया जा सके, कंपनी की growth के लिए महत्वपूर्ण हो सकता है
- 'तकनीकी कर्ज़ ≠ product work' इस धारणा का सामना करने के लिए
- भले ही तकनीकी कर्ज़ का कोई हिस्सा सीधे metrics से न जुड़ा हो, यह किन user/product experiences को बेहतर बना सकता है, इस पर व्यापक रूप से सोचें
- सिर्फ technical benefits पर ज़ोर देने के बजाय, user और product को होने वाले लाभों पर बराबर ज़ोर देने से दूसरों के लिए यह समझना आसान होता है कि टीम को इस काम की परवाह क्यों करनी चाहिए
- business lead और tech lead एक ही समझ पर हैं या नहीं, यह सुनिश्चित करने के लिए समय दें
- 'तकनीकी कर्ज़ ≠ product work' इस धारणा का सामना करने के लिए सवाल
- अभी यह काम करना सबसे ज़रूरी क्यों है?
- इस काम के impact को किन लोगों को समझना चाहिए? उन्हें इसकी परवाह क्यों होनी चाहिए?
- मैं क्या कहना चाहता हूँ? क्या यह वही है जो stakeholders सुनना चाहते हैं? अगर नहीं, तो मैं उनकी समस्या कैसे हल कर सकता हूँ?
- मैं या मेरी टीम किसे reasonable result बनाम excellent result मानते हैं?
- क्या हम expected outcome के बारे में ज़रूरत से ज़्यादा वादा कर रहे हैं? क्या outcome को excellent और good में बाँटकर expectations को level किया जा सकता है?
धारणा #4 : व्यक्तिगत पीड़ा = संगठन की पीड़ा
- तकनीकी कर्ज़ के सबसे करीब काम करने वाले engineers अक्सर बार-बार कहते हैं कि तकनीकी कर्ज़ संभालना व्यक्तिगत रूप से बहुत पीड़ादायक है
- किसी कर्मचारी को यह दुनिया के अंत जैसा लग सकता है, लेकिन संगठन के बाकी लोग वही पीड़ा महसूस नहीं करते
- यह career की शुरुआती अवस्था के लोगों में आम है, और अक्सर व्यापक strategic context की कमी से पैदा होता है
- 'व्यक्तिगत पीड़ा = संगठन की पीड़ा' इस धारणा का सामना करने के लिए
- जब आप किसी उच्च-प्राथमिकता वाले तकनीकी कर्ज़ क्षेत्र से टकराएँ, तो थोड़ा रुककर देखें कि यह व्यक्तिगत स्तर का pain point है या संगठन-स्तर का
सामान्य तौर पर, संगठन-स्तर की समस्याएँ किसी न किसी रूप में सीधे customer या business को प्रभावित करती हैं
- अपने से ज़्यादा organizational context रखने वाले व्यक्ति के नज़रिए से सोचें। किसी दूसरे टीम के व्यक्ति को यह समझाना भी मददगार हो सकता है
- 'व्यक्तिगत पीड़ा = संगठन की पीड़ा' इस धारणा का सामना करने के लिए सवाल
- इस तकनीकी कर्ज़ को वर्गीकृत और हल करने से कितनी टीमों को लाभ होगा?
- कंपनी ने तकनीकी कर्ज़ का काम करने वाले लोगों को कब पहचाना या पुरस्कृत किया है? वह किस प्रकार का तकनीकी कर्ज़ था और उस समय उसकी ज़रूरत क्यों थी? क्या इस पर बात की जा सकती है कि उस व्यक्ति ने उस काम को कैसे position किया?
- क्या मेरा engineering manager तकनीकी कर्ज़ वाले काम की value समझता है? क्या वह performance review के दौरान इस काम में मेरे योगदान की वकालत करेगा?
तकनीकी कर्ज़ के 6 प्रकार
- Maintenance debt (मेंटेनेंस कर्ज़)
- जब टीम तकनीक के updates के साथ नहीं चल पाती
- इसमें experiments शुरू करने / feature rollout / deployment rollback आदि के बाद dead code न हटाना, library updates न करना, context code पर comments न जोड़ना, implementation decisions का documentation अपडेट न करना भी शामिल है
- उदाहरण) 'log in with Spotify' feature का experiment किया गया, फिर उसे बंद कर दिया गया, लेकिन संबंधित code नहीं हटाया गया
- Developer efficiency debt (डेवलपर efficiency कर्ज़)
- जब कंपनी के पास product के लिए उचित testing, monitoring और alerting systems नहीं होते
- engineering workflow बहुत inefficient होता है, deployment/build में कई घंटे या कई दिन लगते हैं, और developers production में जाने से पहले technical issues पकड़ नहीं पाते — यह इसी तरह का सामान्य कर्ज़ है
- उदाहरण) संगठन 1 साल में 15 लोगों से बढ़कर 50 लोगों का हो गया, और बहुत अधिक experiments चल रहे हैं। production में मिले bugs के fix releases 2-3 releases पीछे चल रहे हैं। purchase experience के लिए नए tests और पीछे छूटते जा रहे हैं
- Stability debt (स्थिरता कर्ज़)
- जब संगठन में कई प्रकार के तकनीकी कर्ज़ जमा होकर infrastructure की stability को प्रभावित करने लगते हैं
- on-call को proactively manage करने के बजाय, समस्या आने पर बाद में किसी expert को बुलाना पड़ता है, या पूरी टीम को on-call करना पड़ता है
- यह engineers और on-call rotation टीम के लिए बड़ा सिरदर्द है, लेकिन कंपनी के बाकी लोगों के लिए समस्या को समझना और समझाना तक मुश्किल हो सकता है
- स्थिरता कर्ज़ product reliability को भी प्रभावित करता है, जिससे customers को समस्याओं का सामना करना पड़ सकता है
- उदाहरण) mobile team में iOS developers ज़्यादा हैं, इसलिए Android app की तुलना में iOS को प्राथमिकता दी जाती है। नतीजतन Android app में business-critical flows के लिए product guidelines की कमी है, और third-party द्वारा शुरुआती दौर में लिखा गया कमजोर (Kryptonite) code भी मौजूद है। इसके कारण Android users पुराने features खोलते समय crash देखते हैं, और Google Play ratings खराब हो जाती हैं
- Security debt (सुरक्षा कर्ज़)
- जब ऐसा tech stack इस्तेमाल किया जाता है जिसमें brute-force password attempts, data leaks जैसी security vulnerabilities मौजूद हों
- क्योंकि लोगों के लिए संभावित (या संभवतः कभी न होने वाली) घटनाओं की योजना बनाना और उनका आकलन करना मुश्किल होता है, इसलिए कई संगठनों में security debt पैदा होता है
- उदाहरण) कंपनी की internal process समस्याओं के कारण समय पर updates नहीं हो पाए, known vulnerabilities patch नहीं हो सकीं, और customer personal data leak हो गया (छोटी कंपनियों से लेकर 14 करोड़ लोगों को प्रभावित करने वाली Equifax जैसी कंपनी तक)
- Technical product debt (तकनीकी product कर्ज़)
- जब product पर नकारात्मक प्रभाव साफ़ दिखाई देने लगे
- यह सबसे आसानी से पहचाना और हल किया जा सकने वाला कर्ज़ है, क्योंकि इसका असर users पर पड़ता है और संगठन की हर टीम को दिखता है कि इससे sales/revenue प्रभावित हो रहा है
- उदाहरण) product के भीतर किसी खास काम को करने में users को कई सेकंड लगते हैं। यह कई तरह के कर्ज़ के कारण हो सकता है, लेकिन यह user के core product experience को प्रभावित करता है
- Decision debt (निर्णय कर्ज़)
- जब पुराने technical decisions X% गलत साबित हुए हों, या scope, time, resources के स्तर पर trade-off किए गए हों, और अब उस निर्णय की लागत चुकानी पड़ रही हो
- यह तकनीकी कर्ज़ का सबसे आम रूप है
- उदाहरण) वेबसाइट पर किसी खास experiment के लिए third-party का उपयोग किया गया। कुछ वर्षों में कंपनी बहुत बढ़ी और अब लाखों users आते हैं। नतीजतन tech team, data team और product team को हर बार complex experiments चलाने में कठिनाई होती है।
यह decision debt इसलिए पैदा हुआ क्योंकि टीम ने third-party बनाम in-house development के बीच trade-off decision लिया था। उस समय वह सही फैसला रहा होगा, लेकिन अब उसका प्रभाव सामने आ रहा है
तकनीकी कर्ज़ का पैमाना तय करना : Acute vs Systemic
- तकनीकी कर्ज़ के प्रकार समझ लेने के बाद, उससे मिलने वाले लाभों की तुलना में उसकी लागत का पैमाना तय करना चाहिए
- जब टीम पूछती है, 'हमें तकनीकी कर्ज़ पर काम करने का समय कब मिलेगा?', तो समय, सोच और प्रयास के नज़रिए से यह छोटा है या बड़ा, समझना मुश्किल हो सकता है
- Acute (तीव्र) तकनीकी कर्ज़
- अपेक्षाकृत छोटा तकनीकी कर्ज़
- उदाहरण) नई feature देने के लिए कम-उपयोग वाले platform/browser के लिए काम छोड़ दिया गया। अगर और कोई काम न हो, तो इसे 1 दिन के भीतर आसानी से जोड़ा जा सकता है
- Systemic (प्रणालीगत) तकनीकी कर्ज़
- बड़े से लेकर बहुत विशाल पैमाने का तकनीकी कर्ज़
- उदाहरण) CTO/Founder ने 5 साल पहले product (और अप्रत्यक्ष रूप से तकनीक) के बारे में कोई निर्णय लिया था, और उसी आधार पर आगे काम हुआ। इसे बदलने से कई चीज़ों पर असर पड़ेगा।
यह तकनीकी कर्ज़ आसानी से हल नहीं किया जा सकता, और इसे बदलने में कई महीने से लेकर कई साल तक लग सकते हैं
रणनीतिक रूप से तकनीकी कर्ज़ की प्राथमिकता तय करना
- लचीले ढंग से विचार और मूल्यांकन करने की विधि
- Confidence : क्या यह गंभीर समस्या बनने की उच्च संभावना रखता है? कम/ज़्यादा
- Time : यह समस्या कब बनेगी? तत्काल नहीं/तत्काल
- Impact to User : अगर यह नहीं किया गया, तो क्या user experience में speed/quality की समस्या आएगी? कम/ज़्यादा
- Sequence : क्या यह किसी महत्वपूर्ण milestone तक पहुँचने में बाधा बनता है? छोटा प्रभाव/blocker
- Accumulated debt : हमने पहले से कितना कर्ज़ जमा करने का निर्णय लिया है? कम/ज़्यादा
कंपनी की growth stage के अनुसार रणनीतिक तकनीकी कर्ज़ portfolio
- Traction :
- Product-Market fit से पहले
- engineering decisions में accuracy, stability और process से ज़्यादा speed को प्राथमिकता देनी चाहिए। बड़े पैमाने का developer efficiency debt
- आमतौर पर इसका मतलब है कि Django, Rails, PHP जैसे full-stack frameworks चुनकर तेज़ी से development किया जाए
- Inflection :
- PMF के संकेत दिखने लगते हैं, और product scalable loop में बदलने लगता है
- टीम को एहसास होता है कि कुछ processes की ज़रूरत है (developer efficiency debt हल होना शुरू होता है), लेकिन internal process और user experience के बीच संतुलन बनाते हुए technical product debt बढ़ता है
- Scale :
- कंपनी की hyper-growth अवस्था
- internal practices/processes और user experience के बीच संतुलन बनते-बनते technical product debt और developer efficiency debt कम होकर स्थिर होने लगते हैं
- बहुत तेज़ growth के परिणामस्वरूप security debt, maintenance debt और decision debt बढ़ते हैं
- test automation, deployment systems, monitoring और alerting, logging और instrumentation, test और staging, ETL आदि में बहुत बदलाव और सुधार होते हैं
- Expansion :
- saturation की शुरुआत। business अधिक mature हो जाता है
- बड़ी मात्रा में पुराने code और decisions के कारण maintenance debt और decision debt लगातार बढ़ते रहते हैं
- टीम growth के लिए नए अवसर खोजती है, इसलिए developer efficiency debt फिर से बढ़ने लगता है
- technical product debt, security debt और stability debt पिछली अवस्था के बाद संतुलन में आने लगते हैं
तकनीकी कर्ज़ portfolio प्रबंधन के लिए टिप्स
- बनने वाले तकनीकी कर्ज़ को कम करने की processes
- तकनीकी कर्ज़ जमा करना रणनीतिक हो सकता है, लेकिन कई बार शुरुआत से ऐसी processes लागू करना सही होता है जो तकनीकी कर्ज़ बनने ही न दें
- खासकर Inflection और Scale चरणों में, जहाँ अधिक engineers जुड़ने के साथ developer efficiency debt कम होना चाहिए
- developer efficiency debt कम होने पर उसकी जगह decision debt और maintenance debt बढ़ सकते हैं
- ऐसी processes के उदाहरण: code/PR review, monitoring standards, QA approval और technical/design review
- खास प्रकार के कर्ज़ बनने से रोकने वाले tools
- बुनियादी tools में निवेश करने से कुछ प्रकार के कर्ज़ बनने से रोके जा सकते हैं
- Scale चरण में security issues (security debt), user experience को प्रभावित करने वाले bugs की रोकथाम (technical product debt), और code consistency (developer efficiency debt) के लिए यह खास तौर पर महत्वपूर्ण है
- ऐसे tools के उदाहरण: Linter और CI/CD pipeline
- Reactive & Acute तकनीकी कर्ज़ के लिए sprint work
- जब संगठन उस स्तर तक पहुँच जाए जहाँ on-call की ज़रूरत हो, तो on-call sprints को मौजूदा आग बुझाने या तकनीकी कर्ज़ से जुड़े response work पर खर्च किया जाना चाहिए
- इससे संगठन urgent तकनीकी कर्ज़ items को संभाल सकता है, और on-call टीम की मदद से मौजूदा/पिछली समस्याओं पर वास्तविक कार्रवाई कर सकता है
- response work के लिए on-call को सक्षम बनाना Scale/Expansion growth stages में खास तौर पर महत्वपूर्ण है। urgent तकनीकी कर्ज़ को संभालना इसलिए भी ज़रूरी है ताकि दूसरी टीमें नए features/products बनाते हुए अतिरिक्त कर्ज़ को संभाल सकें
- Proactive और Systemic तकनीकी कर्ज़ के लिए roadmap work
- तकनीकी कर्ज़ को roadmap में डालने के लिए कई टीमों के बीच alignment की ज़रूरत होती है
- roadmap में शामिल किए जाने वाले तकनीकी कर्ज़ के उदाहरण: बड़े पैमाने का rewrite, customers द्वारा मुख्य रूप से इस्तेमाल होने वाली features के data systems का पुनर्संतुलन, key paths के लिए alerts की परिभाषा और implementation, payment system migration आदि
तकनीकी कर्ज़ को बोझ से रणनीतिक साधन में कैसे बदलें
- जमा हुए तकनीकी कर्ज़ के आधार पर टीमें यह तय कर सकती हैं कि कौन-से initiatives किए जाएँ
- उन आम धारणाओं पर विचार करें जिनका टीम सामना करेगी। क्या आप "तकनीकी कर्ज़ = बुरी चीज़" या "तकनीकी कर्ज़ ≠ product work" जैसी बातों से असहमत हैं? क्या आप किसी सहकर्मी को "व्यक्तिगत पीड़ा = संगठन की पीड़ा" कहते सुन रहे हैं?
- "तकनीकी कर्ज़" जैसे व्यापक शब्द का उपयोग न करें। इसे maintenance debt, developer efficiency debt, stability debt, security debt, technical product debt, decision debt जैसे नाम दें
- अस्पष्टता कम करने के लिए तकनीकी कर्ज़ का पैमाना तय करें। क्या यह Acute है या Systemic?
- कंपनी के दूसरे क्षेत्रों की तुलना में रणनीतिक रूप से तकनीकी कर्ज़ की प्राथमिकता तय करें। confidence, time, user impact जैसे vectors के आधार पर प्राथमिकता दें
- कंपनी की growth के साथ बदलती ज़रूरतों के अनुसार तकनीकी कर्ज़ portfolio को evolve करें और संतुलित रखें
2 टिप्पणियां
मुझे लगता है कि सबसे बुनियादी और महत्वपूर्ण बात यह साफ़-साफ़ बताना है कि "यही आपकी पीड़ा है"। चाहे वह कोई संख्या हो या कुछ और।
अगर वह नहीं कर सकते, तो सच कहूँ तो शायद इस निष्कर्ष पर भी पहुँचा जा सकता है कि वह तकनीकी कर्ज़ था ही नहीं।