ज़्यादातर तकनीकी समस्याएँ दरअसल लोगों की समस्याएँ होती हैं

 (blog.joeschrag.com)
29 पॉइंट द्वारा GN⁺ 2025-12-06 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें
  • बड़े पैमाने के technical debt वाली कंपनियों में code duplication और पुराने framework के कारण अक्षम्यता पैदा होती है
  • प्रोजेक्ट के दौरान management का भरोसा खोना और संगठन के भीतर बदलाव का विरोध प्रमुख बाधा बनते हैं
  • technical debt के मूल कारण अस्पष्ट requirements, अवास्तविक deadlines, पुरानी तकनीक की पसंद, management की अल्पकालिक प्रतिक्रिया, व्यक्तिगत अहं जैसे मानवीय कारक हैं
  • प्रोजेक्ट की सफलता के लिए तकनीकी उपलब्धियों के साथ perception management और communication भी अनिवार्य हैं
  • engineer को तकनीकी क्षमता के अलावा संगठन के भीतर collaboration और मानवीय संबंधों को संतुलित करने की क्षमता भी रखनी चाहिए

technical debt और duplicated code की समस्या

  • एक पहले की कंपनी में लाखों lines of code, unit tests की अनुपस्थिति, और 10 साल से पुराने framework के उपयोग के कारण गंभीर technical debt मौजूद था
    • Windows-विशिष्ट module को Linux पर चलाने के लिए लाखों नहीं बल्कि सैकड़ों हज़ार lines of code को copy-paste करके काम चलाया गया
    • इसके कारण दो अलग codebase बन गए, और feature जोड़ने व bug fix करने का काम दोनों में अलग-अलग करना पड़ता था
  • ऐसी स्थिति maintenance के लायक न रहने वाली संरचना पैदा करती है, और लंबे समय में code के बीच का अंतर बढ़ता जाता है

लोगों की समस्याओं से पैदा होने वाला technical debt

  • technical debt projects के लिए management को मनाना कठिन होता है, और क्योंकि नतीजतन feature-level बदलाव लगभग नहीं दिखते, इसलिए दृश्य उपलब्धि कम रहती है
    • प्रोजेक्ट में देरी होती है और management का भरोसा कम हो जाता है
  • समस्या की जड़ तकनीक नहीं बल्कि लोगों का रवैया और संगठन की संस्कृति है
    • कई developer बदलाव का विरोध करते हैं और पुराने तरीकों में सहज बने रहते हैं
    • code structure उसके लेखक के स्वभाव और बदलाव स्वीकारने की क्षमता को दर्शाती है
  • technical debt अस्पष्ट requirements, अवास्तविक वादों, पुरानी तकनीक के चयन, management द्वारा बीच में रोक देने के फैसलों, और व्यक्तिगत अहं से पैदा होता है
    • जिन टीमों में बदलाव से बचने की प्रवृत्ति अधिक होती है, उनके code में भी बदलाव-प्रतिरोधी विशेषताएँ दिखती हैं
  • कई developer सालों से उसी तरीके से काम कर रहे थे, यहाँ तक कि यह भी कहा गया कि “मैं कुछ नया सीखना नहीं चाहता”
  • ऐसे माहौल में सफाई की गति से ज़्यादा तेज़ी से debt जमा होता है, इसलिए debt घटाने से पहले यह रोकना ज़रूरी है कि नया debt और न बढ़े
    • emergency room के triage (प्राथमिक वर्गीकरण) की तरह, पहले “खून बहना रोकने” का चरण ज़रूरी होता है

आदर्श दुनिया और वास्तविकता के बीच की खाई

  • engineering समस्याओं को राजनीति या संगठनात्मक संदर्भ से अलग करके सुलझा सकने वाला आदर्श माहौल लगभग कभी नहीं होता
    • अधिकांश प्रोजेक्ट में गैर-तकनीकी stakeholders मौजूद होते हैं
    • “हम यह कर रहे हैं, बस हम पर भरोसा कीजिए” वाला रवैया काम नहीं करता
  • उपलब्धियों की perception management वास्तविक उपलब्धियों जितनी ही महत्वपूर्ण है
    • गैर-तकनीकी लोग technical debt साफ़ करने की ज़रूरत को सहज रूप से नहीं समझते, इसलिए इसे मात्रात्मक और business value के रूप में समझाना पड़ता है
    • अगर leadership का engineering background न हो, तो दिखाई देने वाले metrics और असर पेश करना आवश्यक है
  • आखिरकार टीम का productive दिखाई देना भी वास्तविक productivity जितना ही महत्वपूर्ण होता है

senior engineer के लिए ज़रूरी क्षमताएँ

  • senior या उससे ऊपर के स्तर पर विभागों के बीच collaboration और मानवीय संबंधों का समन्वय अनिवार्य है
    • computer science education में स्वभाव, अहं, और रिश्तों के प्रबंधन जैसी ‘लोगों को संभालने’ की बातें नहीं सिखाई जातीं
  • बेहतरीन तकनीकी कौशल वाला engineer भी बड़े पैमाने के, संगठनात्मक बदलाव माँगने वाली समस्याओं में अटक सकता है
    • व्यक्तिगत productivity ऊँची हो सकती है, लेकिन संगठनात्मक प्रभाव सीमित रह सकता है
  • ‘Heads up coder’ की भूमिका महत्वपूर्ण है
    • जो गहरी तकनीकी क्षमता बनाए रखते हुए भी प्रोजेक्ट risk को जल्दी पहचान सके और टीम को समन्वित कर सके
    • single core की तरह अकेले तेज़ काम करने के बजाय, पूरी टीम को कुशलता से आगे बढ़ाने वाली भूमिका
    • शुद्ध तकनीकी engineer से अलग, ऐसा व्यक्ति संगठन के संदर्भ और risk दोनों को साथ पढ़कर काम कर सकता है

निष्कर्ष

  • तकनीकी समस्याओं की जड़ में हमेशा लोग होते हैं
    • ज़्यादातर तकनीकी समस्याएँ आखिरकार लोगों, संस्कृति, और communication की समस्याओं पर जाकर टिकती हैं
  • technical debt code की समस्या नहीं, बल्कि संगठन के व्यवहारिक पैटर्न और संस्कृति का परिणाम है
    • technical debt को हल करने के लिए संगठनात्मक बदलाव को स्वीकारना और leadership की समझ पहले आनी चाहिए
  • और केवल तकनीकी उत्कृष्टता से हल न होने वाली समस्याएँ करियर के बाद के चरणों में बड़े मंच पर इंतज़ार कर रही होती हैं
    • सच्चा senior engineer वह संतुलित leader है जो तकनीक और मानवीय समझ, दोनों को साथ लेकर चलता है

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.