non-technical பார்வையாளர்களுக்கு technical debt-ஐ எப்படி விளக்குகிறீர்கள்?

Question

Accepted Answer

**நான் tech debt-ஐ பார்வையாளர்கள் ஏற்கனவே பயன்படுத்தும் மொழியில் மொழிபெயர்க்கிறேன்: பணம், வேகம், மற்றும் risk.** ஒரு non-technical stakeholder coupling அல்லது test coverage பற்றி கவலைப்படுவதில்லை; features ship செய்ய மெதுவாகவும் அதிக விலையாகவும் ஆகிறது என்பதில் அவர்கள் கவலைப்படுகிறார்கள். எனவே debt-ஐ ஒரு code பிரச்சினையாக அல்ல, ஒரு நிதி மற்றும் delivery பிரச்சினையாக வடிவமைக்கிறேன்.

## நான் பயன்படுத்தும் framing

- **நிதி உருவகம், கவனமாகப் பயன்படுத்தப்படுகிறது.** "வேகமாக ship செய்ய ஒரு குறுக்குவழியை எடுத்தோம், ஒரு கடன் எடுப்பது போல. அது வேலை செய்தது, இப்போது ஒவ்வொரு sprint-இலும் அதற்கான வட்டியைச் செலுத்துகிறோம். இந்த பகுதியில் ஒவ்வொரு புதிய feature-ம் அந்த வட்டியால் அதிக செலவாகிறது." எல்லோரும் debt மற்றும் interest-ஐ புரிந்துகொள்வதால் இது பொருந்துகிறது.
- **அவர்களின் metrics-உடன் அதை concrete ஆக்குங்கள்.** "code குழப்பமானது" அல்ல, ஆனால் "இந்த feature மூன்று வாரங்கள் எடுத்தது; இரண்டு ஆண்டுகளுக்கு முன்பு அதே அளவு ஒரு வாரம் எடுத்தது. வித்தியாசம் நாங்கள் குவித்த maintenance overhead."
- **அவர்கள் கவலைப்படும் outcomes-உடன் இணைக்கவும்.** மெதுவான delivery, customers-ஐ அடையும் அதிக bugs, புதிய பணியாளர்களுக்கு கடினமான onboarding, ஒரு outage-இன் உயரும் risk. debt-ஐ revenue, reputation, மற்றும் roadmap வேகத்துடன் இணைக்கவும்.

## நான் அதை ஒரு புகார் அல்ல, ஒரு முடிவாக எப்படி ஆக்குகிறேன்

- ஒரு கோரிக்கை அல்ல, **options-உடன் கூடிய ஒரு trade-off ஆக** அதை முன்வைக்கவும்: "தற்போதைய மெதுவாகும் வேகத்தில் features-ஐ தொடர்ந்து ship செய்யலாம், அல்லது எதிர்கால feature செலவை தோராயமாக மூன்றில் ஒரு பங்காக குறைக்க இப்போது இரண்டு sprints முதலீடு செய்யலாம்."
- என்னால் முடிந்த இடத்தில் அளவிடுங்கள்: ஒரு sprint-க்கு இழந்த நேரம், incident அதிர்வெண், firefighting-இல் செலவழித்த திறன் சதவீதம்.
- **சில debt பரவாயில்லை** என்று நேர்மையாக இருங்கள். எல்லா debt-ஐயும் செலுத்தக்கூடாது; delivery-ஐ தீவிரமாக வரிவிதிக்கும் debt-ஐ செலுத்துவதே நோக்கம்.

## தவறுகள்

- **jargon பயன்படுத்துவது** ("refactor," "coupling," "architecture தவறு"). நீங்கள் code-ஐ gold-plate செய்ய விரும்புவது போல ஒலிக்கிறது.
- engineers தனக்காக clean code விரும்புவது போல வடிவமைப்பது; அது சுய-மகிழ்ச்சியாக படிக்கிறது.
- ஓநாய் அழுவது — எல்லாவற்றையும் debt என்று அழைப்பது உண்மையிலேயே அவசரமான ஏதாவது வரும்போது நம்பகத்தன்மையை அரிக்கிறது.

## இது ஏன் முக்கியம்

tech debt-ஐ வணிக சொற்களில் விளக்க முடியாவிட்டால், அது ஒருபோதும் நிதியளிக்கப்படாது, மேலும் velocity ஏன் குறைகிறது என்று leadership ஆச்சரியப்படும்போது team மெதுவாக நின்றுவிடுகிறது. அதை செலவு, வேகம், மற்றும் risk ஆக வடிவமைப்பதுதான் அது ஒரு நெருக்கடியாகும் முன்பு அதை சரிசெய்ய உங்களுக்கு நேரத்தைப் பெற்றுத் தருகிறது.