आप संगठनात्मक स्तर पर technical debt का प्रबंधन कैसे करते हैं?

Question

Accepted Answer

संगठन स्तर पर, technical debt एक **प्रबंधित किया जाने वाला portfolio** है, न कि समाप्त किया जाने वाला backlog। लक्ष्य शून्य debt नहीं है; लक्ष्य debt को ऐसे स्तर पर रखना है जहाँ वह velocity, reliability, या रणनीति को क्रियान्वित करने की क्षमता के लिए ख़तरा न बने।

## इसके बारे में कैसे सोचें

```text
MAKE DEBT VISIBLE AND PRIORITIZED
- Inventory the debt that actually hurts (slows delivery, causes incidents)
- Classify: strategic (deliberate) vs accidental vs decay/rot
- Quantify impact in business terms (velocity, downtime, churn risk)
- Allocate a steady % of capacity to paydown (commonly 15-25%)
```

हर debt को चुकाना ज़रूरी नहीं है। एक स्थिर, शायद ही कभी बदले जाने वाले system में debt को छोड़ा जा सकता है; एक सक्रिय, तेज़ी से बदलते क्षेत्र में debt को पहले चुकाया जाना चाहिए।

## ठोस उदाहरण

एक CTO यह नियम लागू करता है कि हर टीम की 20% capacity reliability और debt पर जाए, फिर उसे हर जगह पतला फैलाने के बजाय उन तीन systems पर केंद्रित करता है जो 80% incidents पैदा कर रहे हैं।

## ट्रेड-ऑफ़ और कमियाँ

- **कमी:** सारा debt साफ़ करने के लिए एक "big rewrite", जो आमतौर पर समय-सीमा पार कर जाता है और दोबारा debt पैदा कर देता है।
- **कमी:** इसे कभी न चुकाना, जब तक velocity ध्वस्त न हो जाए।
- debt को केवल engineering का सरोकार मानना विफल होता है; समर्थन हासिल करने के लिए इसे business परिणामों से जोड़ें।

## यह क्यों महत्वपूर्ण है

बिना प्रबंधित technical debt चुपचाप बढ़ती जाती है जब तक features में महीनों लगने लगते हैं और incidents बढ़ जाते हैं।

इसे एक सुविचारित portfolio के रूप में प्रबंधित करना संगठन को वर्षों तक तेज़ और विश्वसनीय बनाए रखता है, और एक अमूर्त engineering चिंता को एक मापे गए business ट्रेड-ऑफ़ में बदल देता है जिस पर नेतृत्व तर्क कर सकता है।