आपके रोडमैप का कितना हिस्सा technical debt को जाता है, और बिजनेस के सामने आप उसे कैसे सही ठहराते हैं?

क्षमता का एक तयशुदा हिस्सा हमेशा के लिए रखिए, आम तौर पर पंद्रह से बीस प्रतिशत, ताकि उसे किसी feature से बहस जीतनी ही न पड़े। उसे बिजनेस की भाषा में सही ठहराइए: cycle time, incident rate, on call का बोझ, और पिछले outage की लागत। इंजीनियरिंग की साफ सफाई कहकर पेश किया गया debt हर बार हारता है; अगली तीन features तिमाहियों की जगह हफ्तों में क्यों ship होंगी, यह कहकर पेश किया गया debt टिक जाता है।

मैं उसे मुकाबला करने ही नहीं देता। अगर debt को हर sprint किसी feature से बहस जीतनी पड़े तो वह हर sprint हारता है, इसलिए हम क्षमता का एक तयशुदा हिस्सा रखते हैं, करीब बीस प्रतिशत, जिसे इंजीनियरिंग तय करती है। फिर काम यह है कि उसकी कीमत पढ़ी जा सके। मैंने बिजनेस के सामने technical debt शब्द इस्तेमाल करना पूरी तरह बंद कर दिया, क्योंकि वह घर की सफाई जैसा सुनाई देता है। उसकी जगह मैं cycle time और incident count बताता हूं। जब build को दुरुस्त करने के बाद हमारा deploy time चालीस मिनट से आठ पर आ गया, तो वह किस्सा सुनाना बहुत आसान था, क्योंकि कंपनी में हर इंसान ने वे चालीस मिनट भुगते थे। मैं इंजीनियरिंग लीड से यह भी कहता हूं कि ख्वाहिशों की सूची नहीं, उस debt की छोटी क्रम में लगी सूची रखें जो सचमुच चुभ रहा है, ताकि जब बड़ी खिड़की मिले तो हम उसे उस चीज पर खर्च करें जो रोडमैप का रास्ता खोलती है, न कि उस पर जो सबसे ज्यादा खिझाती है।