તમે technical debt ને બિન-technical પ્રેક્ષકોને કેવી રીતે સમજાવો છો?

Question

Accepted Answer

**હું tech debt ને એ ભાષામાં અનુવાદ કરું છું જે પ્રેક્ષકો પહેલેથી વાપરે છે: પૈસા, ઝડપ, અને જોખમ.** એક બિન-technical stakeholder ને coupling અથવા test coverage ની પરવા નથી; તેમને એ પરવા છે કે features ship કરવા ધીમા અને વધુ મોંઘા થઈ રહ્યા છે. તેથી હું debt ને કોડ સમસ્યા નહીં, પણ એક નાણાકીય અને delivery સમસ્યા તરીકે ઘડું છું.

## હું જે ઘડતર વાપરું છું

- **નાણાકીય રૂપક, કાળજીપૂર્વક વપરાય.** "અમે ઝડપથી ship કરવા shortcut લીધો, loan લેવા જેવો. તે કામ કર્યું, અને હવે અમે દર sprint તેના પર વ્યાજ ચૂકવી રહ્યા છીએ. આ area માં દરેક નવું feature તે વ્યાજને કારણે વધુ ખર્ચ કરે છે." આ ઊતરે છે કારણ કે દરેક debt અને વ્યાજ સમજે છે.
- **તેમના metrics સાથે તેને નક્કર બનાવો.** "કોડ ગૂંચવાયેલો છે" નહીં પણ "આ feature ત્રણ અઠવાડિયા લાગ્યું; બે વર્ષ પહેલા એ જ size એક અઠવાડિયું લેતું. તફાવત એ maintenance overhead છે જે અમે ભેગો કર્યો છે."
- **તેને એવા પરિણામો સાથે જોડો જેની તેમને પરવા છે.** ધીમી delivery, ગ્રાહકો સુધી પહોંચતા વધુ bugs, નવા hires માટે અઘરું onboarding, outage નું વધતું જોખમ. debt ને revenue, પ્રતિષ્ઠા, અને roadmap ઝડપ સાથે જોડો.

## હું તેને ફરિયાદ નહીં, એક નિર્ણય કેવી રીતે બનાવું છું

- તેને માગણી નહીં, **વિકલ્પો સાથેના trade-off** તરીકે રજૂ કરો: "અમે વર્તમાન ધીમી પડતી ગતિએ features ship કરવાનું ચાલુ રાખી શકીએ, અથવા હવે બે sprints રોકાણ કરી ભવિષ્યના feature ખર્ચને લગભગ ત્રીજા ભાગ સુધી કાપી શકીએ."
- જ્યાં શકું ત્યાં માત્રામાં માપો: દર sprint ગુમાવેલો સમય, incident frequency, firefighting પાછળ ખર્ચાયેલ ક્ષમતાનો ટકાવારી.
- પ્રામાણિક રહો કે **કેટલીક debt ઠીક છે.** બધી debt ચૂકવવી ન જોઈએ; મુદ્દો એ છે કે જે debt સક્રિય રીતે delivery પર કર લાદે છે તે ચૂકવો.

## ભૂલો

- **jargon વાપરવો** ("refactor," "coupling," "architecture ખોટું છે"). તે તમને એવું દેખાડે છે કે તમે કોડને gold-plate કરવા માગો છો.
- તેને engineers ને પોતાના ખાતર સ્વચ્છ કોડ જોઈએ છે એમ ઘડવું; તે સ્વ-ભોગવિલાસી લાગે છે.
- ખોટી બૂમ પાડવી — દરેક વસ્તુને debt કહેવી જ્યારે કંઈક ખરેખર તાકીદનું આવે ત્યારે વિશ્વસનીયતા ઘટાડે છે.

## આ શા માટે મહત્વનું છે

જો તમે tech debt ને business દ્રષ્ટિએ સમજાવી ન શકો, તો તેને ક્યારેય funding મળતું નથી, અને ટીમ ધીમે ધીમે ઠપ થઈ જાય છે જ્યારે leadership વિચારે છે કે velocity શા માટે ઘટી રહી છે. તેને ખર્ચ, ઝડપ, અને જોખમ તરીકે ઘડવું એ છે જે તમને કટોકટી બને તે પહેલા તેને ઠીક કરવાનો સમય આપે છે.